Active Directory domain (join)own accounts - security considerations

This article written by Andreas Vikerup, Security Consultant at Sentor, highlights the risks of using domain join accounts in an Active Directory.

There is probably no need for an introduction to Active Directory. Most both small businesses and large enterprises have been using Active Directory since the move from NT 4.0 back in 1999 and probably everyone in the IT industry have had the opportunity to both hate and love Active Directory domain services.

As most of the Active Directory instances date back to early 2000 and the high number of system administrators that's been in charge of the domain and domain controllers makes it hard to build a security baseline over time. Most often the system administrators'
main purpose is to support an organization or enable growth or scaling, where maybe security actually comes at best as a second priority.

Having security as a number one priority will never generate the most revenue, however lacking the security aspect and suffer a breach or a ransomware attack can very well break a company. Enough off-topic, on to the technical…

Domain join

For a Windows computer to have a membership in an Active Directory domain it needs to be joined. This is done either via the Windows GUI or the netdom.exe command. Most often, this domain join action is done via Microsoft Deployment Toolkit (MDT) or Microsoft Endpoint Configuration Manager (a.k.a. SMS, SCCM, CCM) in an automated fashion during operating system deployment.

By default, joining the domain requires a valid username with a corresponding password for an account that exists in the Active Directory environment. If the domain join account is a dedicated account with the sole purpose of joining computers, it is extremely important that this domain join account is configured with the least privileges necessary since it will be widely used in scripts, on servers or exposed to the Windows client during operation system deployment.

Domain join account permissions

Microsoft has created an article for creating an Active Directory domain join account (“Error: Access is denied when non-administrator users who have been delegated control try to join computers to a domain controller”) but it is difficult to find.

The article highlights the specific permissions needed for creating a low-privilege account dedicated to domain join actions. But following these recommendations does not address a subtle, undocumented Active Directory feature which is the topic of this article.
The Microsoft article recommends the following permissions:

In Active Directory Users and Computers (ADUC):

Locate and right-click the OU that you want to modify, and then select Delegate Control.

1. In the Delegation of Control Wizard, select Next.

2. Select Add to add a specific user or a specific group to the Selected users and groups list, and then select Next.

3. In the Tasks to Delegate page, select Create a custom task to delegate, and then select Next.

4. Select Only the following objects in the folder, and then from the list, click to select the Computer objects check box. Then, select the check boxes below the list, Create selected objects in this folder and Delete selected objects in this folder.

5. Select Next.

6. In the Permissions list, click to select the following check boxes:

• Reset Password
• Read and write Account Restrictions
• Validated write to DNS host name
• Validated write to service principal name

Domain object ownership

Accounts with membership of high privilege groups (Domain Admins, Enterprise Admins, etc.) in Active Directory are allowed to join an unlimited number of computers to the domain. A default, regular user account with Domain Users membership is allowed to join ten computers to the domain. This is set by the ms-DS-MachineAccountQuota attribute.

An Active Directory object is an entity that represents a resource that is present in the Active Directory domain. This may be a user account, a group, a computer, a printer or a folder to name a few. All of these objects need to have an owner. This is a permission that gives full control of the object without having any specific Access Control List (ACL) on said object. By having owner rights on an object you can simply assign yourself the Full control ACL, and if you have malicious intent this indirectly gives you administrative permissions on the target.

If you join a computer to the domain with a high-privileged account or a regular user account which is not configured according to Microsoft article, the owner of the object will default to the Domain Admins group which is completely fine. This means that only high privileged users in the domain can manipulate the computer object.

The user account used to join the domain is also assigned the following permissions to the computer object:

With these permissions you are allowed to change the computer name via the Validate write to DNS host name if you re-join to the domain with the same account that was used during the initial join. By default, the computer objects are created in the Computers container in the Active Directory if nothing else is specified.

However, if you follow the instructions and you specifically assign the permissions as described in the article, the domain join behavior will change and the account used to join will become the owner of the object, and not Domain Admins.

And as discussed earlier, the Owner permissions enable full, complete control of the object. This means that, rather than assigning least privilege to the account, we have actually created an account that eventually will be the owner of all computer objects that it has created.

Attack

When having the Owner permission on an object, both Resource Based Constrained Delegation (RBCD) and Shadow Credentials attacks are available to compromise the targets and gain NT Authority\SYSTEM level permissions. If an attacker successfully
executes these attacks they may laterally move to the target computer and dump credentials, network pivot or logging keystrokes from the machine to name a few attack scenarios. Describing these attacks is out of scope for this article.

During Sentor's many Active Directory penetration tests, RedSOC assessments, red team engagements or internal network assessments, this domain join permission problem is a regular occurrence and more often than not, a compromise of this domain join account will lead to full domain compromise by means of lateral movement.

Recommendations

Also, make sure that all existing computer accounts have their owner set to Domain Admins.

This in combination with Microsoft's initial recommendation on permissions will help build more resilience during a possible compromise.
In addition, Microsoft provides two additional protections to the domain join account however they are located on a ConfigMgr documentation site:

• Don't assign interactive sign-in permissions to this account.
• Don't use the network access account for this account.

These two permissions help limit lateral movement with the domain join account if it should be compromised. Note that this does not mitigate the problems with object ownership.

Additional information (dSHeuristics)

There is actually a way to deny an Owner of a computer object the rights to gain full control ACL. The dSHeuristics attribute BlockOwnerImplicitRights in Active Directory can be changed to control this behavior. Meager documentation of the impact created by this change exists and more importantly it is unknown how it may affect your environment. It is not recommended to change this attribute unless the full implications are known.

Microsoft

Back in October 2021 Sentor's security consultant Andreas Vikerup contacted Microsoft Security Response Center (MSRC) to ask for updates to their recommendations regarding domain join accounts and highlight the undocumented risks of having these specific permissions. This was registered as Case number 68204 and after one month Microsoft responded with:

”Hello,
We have completed our investigation and determined that this issue does not meet MSRC's bug bar for a security update.”

Hopefully this article helps administrators know the risks of using domain join accounts configured with least-privileges and maybe makes Microsoft update their guidelines in this matter. One would also be glad if this documentation was easy to find, and preferably on one site.