This is an interesting question that I would like to share my view of here.

The question: What are the security implications of someone being able to modify permissions protecting the domain root object?

Let’s start with some basics:

• All Objects in AD are securable
• Securable Objects has a Security Descriptor (SD)
• The SDs contains Owner SID, Group SID, DACL, SACL (known as ACLs) and the header with control flags
• The ACLs contain ACEs
• ACEs contains a set of access rights and a security identifier (SID) that identifies a trustee for whom the rights are allowed, denied, or audited

This topic focuses on the Write_DAC or Modify Permissions. If a Security Principal (User, Sec group, Computer) has the Write_DAC he is allowed to modify the Security Descriptor guarding the object.

So what are the implications of someone having the permission to modify the SD on the Domain Root?

First off, as a user with Modify Permissions you can grant yourself Full Controll Permissions on the object itself, AND you can set the inheritance flag to: “This Object and all descendant objects” (which we will come back to a little bit later).

Grant yourself Full Control

If we look at the root object what’s in there of interest?

Account Policys:
The domain wide password/account lockout policys are stored in the domain root. Normally if we want to change the password policy for the domain we modify the GPO: Default Domain Policy, and then the DC holding the PDCe role applies it to this object and it’s replicated out to all DCs in the domain.
But, we can also modify the policy attributes directly and the PDCe DC will do a write and update the Default Domain Policy with the new password policy that also will be applied on all machines in the domain (for local accounts). Over time this is a bad thing, but it doesn’t give us any direct access to other accounts.

GP Links:
We can modify the gPLink attribute. Clear the attribute and no GPOs will be linked to the Domain root.

But that could be quite obvious. If we look at a gPLink you’ll see that we also can set the value if its enforces, enabled or disabled.
Example: [LDAP://cn={1605342D-11B2-4EDC-9DAA-8BC73AA4D952},cn=policies,cn=system,DC=ad,DC=secid,DC=se;0]
Table:
0=link enabled
1=link disabled
2=link enforced
3=link enforce but not enabled

If we change the last value after the groupPolicyContainer object DN to 1. The link will be disabled and maybe not that obvious in the GPMC tool.

And of course we can link other GPOs that already exists in the domain and create some damage.

Domain Join Computers:
Default in an Active Directory deployment Authenticated Users is allowed to join 10 machines to the domain. This is controlled by the User Rights Assignment: Add workstations to domain in the “Default Domain Controllers Policy” and the attribute: ms-DS-MachineAccountQuota in the domain root. I prefer to have the attribute set to 0 because I don’t see any value in users being able to add computers by themselves. But if you have Full Control permissions this can be changed (if you want to be more granular when you mess things up Write Propertie ms-DS-MachineAccountQuota will do just fine).

Move PDC Emulator FSMO role Owner:
In AD there is 3 domain wide and 2 Forest wide FSMO roles. To be able to move the PDCe role to another DC you need the Extended Rights: Change-PDC permission and Write fSMORoleOwner properties on the domain root object. If you have Full Controll, then youre free to move it to maybe a branch office DC and potentially making it unavailable for many machines on the network.
A few examples what the PDCe DC is part off:

• Emulates a Primary DC (NT4 Compatibility)
• Special password update handling
• Change password policy
• Account lockout
• Default target for Group Policy updates
• Master time source for domain
• Domain master browser
• Handles pass-thru authentication (NTLM)
• AdminSDHolder process
• Raise DFL
• Trusts
• DFS-N
• Dfsrmig for SYSVOL
• Redirect users and computers default container
• Cloning VM DC

That’s a few examples of bad stuff you can do.

Now we have the first scenario of how you compromise the whole domain. And remember the user in all of these scenarios is a regular domain user that happened to have WRITE_DAC on Domain Root Object by some poorly delegation.

DCSync:

If you can grant yourself permissions on the domain root you only need two more permissions.
Extended Rights:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All

Then you’re able to use a tool like mimikatz and DCSync all the secrets in the domain including the KRBTGT account. When this is done, well you can use mimikatz to create your own Kerberos tickets and make yourself BA, DA and EA or what ever you like.

But what if we don’t have any cool tools and just have to settle with some native AD admin tools (and this is maybe a little bit cooler in my book) ADUC and GPMC will work just fine in this case.

Privilege escalation with native tools:

Remember that we could grant Full Control to all subordinate inheritable objects in the domain structure? Well this pretty much means that you now can manage group memberships, reset passwords of user accounts, manage computer accounts including DCs and so on. But your still not able to touch the BA, DA and EA accounts because their part of Protected Groups guarded by the AdminSDHolder which you can read more on here.

Since inheritance is disabled we can’t manage them. One thought is to use Group Policy and modify the “Default Domain Controllers Policy”. The only problem is that the inheritance also is disabled on GPO objects created in the CN=Policy container. Since I have Full Control on the Policy container I should be able to create a new GPO, but instead I get an Access Denied message.

The problem is that the user doesn’t have any rights to write to the SYSVOL catalogue, and I can’t give myself any permissions to the filesystem on Domain Controllers. Or can I?
One interesting group that is not guarded by AdminSDHolder is Group Policy Creator Owners and can be found in the Users container. I can make myself a member of that group and now I am allowed to create Group Policys, YAY!

I still don’t have any permissions to modify the “Default Domain Controllers Policy”, but that’s no problem now. I create a new GPO and link it to the Domain Controllers OU and give it the highest precedence.

In that GPO I configure the User Rights Assignment: Take ownership of files or other objects and add my user account.

Group policy refresh on Domain Controllers is default 5 min. If we take a look at the RSoP on the DC.

Now cool stuff happens, my user Lara has now the privilege to take the ownership of ALL objects in the domain (including ConfigurationNC, SchemaNC and ND-NCs if it’s the forest root domain).
And what permissions does Object owners have? Yes, WRITE_DAC!
Now as a regular domain user I have the privilege to take ownership, change the SD and add myself as a BA/DA/EA, password reset/disable all High-Priv accounts and totally own them by myself.

So the moral of the story is, don’t delegate at the domain level. Use OUs, that’s what they’re for. If you have to delegate something on the domain root, be very restrictive. And that also goes for OUs and every delegation decision you make.

That’s all folks!