How to Delegate Control in Active Directory
Because of the complexities outlined in the Domain Join Process Overview, the basic delegation procedure described in the Delegation of Control Overview is not sufficient. Additional modifications are required to ensure that a computer account can join the domain in all circumstances. The following procedure can be performed either at the root of the domain, the Computers OU, or one or more specific OUs.
We recommend designating a specific OU to hold all subordinate AD Bridge joined systems and that delegation is granted over this OU. This is the preferred method since scoping the location for an account to create computer objects in the domain is more secure. Additionally, joining systems directly to a targeted OU ensures that they will receive the appropriate security and configuration setting (for example, GPO) without delay.
For more information about the basic rights required for joining a computer to a specific OU, please see the following knowledgebase article from Microsoft under the section “Users cannot join a computer to a domain”: https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers
Following the KB article grants the minimum required rights to limit any errors on domain join. However,AD Bridge requires additional rights not required natively by Windows systems. While domain join errors may not be immediately present when following the KB article only, we recommend you complete the procedure below to ensure optimal operation of AD Bridge.
Granting a user or group Full Control to all computer objects in a subset of the directory (Container or OU) can be sufficient. This might conflict with the desired security policy of the organization. The following procedure outlines the minimal rights required by AD Bridge to work in all join scenarios.
To delegate control, first identify a specific user or (preferably) group with the right to join. Then, using Active Directory Users and Computers, perform the following tasks:
- Right-click the OU to add computers to, and then click Delegate Control.
- In the Delegation of Control Wizard, click Next.
- Click Add to add a user or group to the Selected users and groups list, and then click Next. We strongly recommend using a group, even if that group only contains one user.
- On the Tasks to Delegate page, click Create a custom task to delegate, and then click Next.
- Click Only the following objects in the folder,
- From the list, select Computer objects.
- Select the following options below the object list:
- Create selected objects in this folder
- Delete selected objects in this folder
- Read permissions are not absolutely required, but preferred since Write permissions are granted.
- Using a Write permission allows any value to be placed in the attribute without validation. Using only a Validated Write permission might be more secure. However, this might limit AD Bridge's ability to create hashed names when conflicts occur.
For more information on the Microsoft requirements, please see https://docs.microsoft.com/en-US/troubleshoot/windows-server/identity/access-denied-when-joining-computers.
|Permission||Microsoft Requirement||AD Bridge Requirement|
Read and write Account Restrictions
|Validated write to DNS host name||X|
|Validated write to service principal name||X|
|Read Operating System||X|
|Write Operating System||X|
|Read Operating System Version||X|
|Write Operating System Version||X|
AD Bridge supports the ability to target a computer to a specific OU at join time. If the delegation procedure specified in the previous section has been performed, users will be able to join new computer objects in all scenarios, including a targeted OU. However, when attempting to re-join a computer with an existing object already in AD (including pre-staged computer objects), additional complications can arise when requesting a targeted OU.
When rejoining the domain and targeting a specific OU (using the domainjoin-cli --ou parameter), LDAP requests a move on the computer object in the AD hierarchy (even if specifying the same OU the object already resides). The modification of the object requires the ability to write to specific attributes of the object which will need to be properly delegated.
To allow rejoins when using the targeted --ou parameter the appropriate modDNRequest LDAP operations need to be performed on the existing object. The following permissions must be delegated:
- DELETE_CHILD on the source container or DELETE on the object being moved
- CREATE_CHILD on the destination container.
- WRITE_PROP on the object being moved for two properties: name/Name and cn (or whatever happens to be the cn: RDN attribute for the class. For example, ou for organizational units).
The DELETE_CHILD and CREATE_CHILD are standard permissions granted to an OU if the steps in “Delegate Control to Join AD Bridge Computers to the Domain” are followed (specifically Step #5). Ensure these permissions are granted on any additional OUs the computer objects will be moved between.
The WRITE_PROP permissions need to be assigned using ADSIEdit as the necessary permissions are not exposed using Active Directory Users and Computers.
To use ADSIEdit to set the appropriate WRITE_PROP permissions, perform the following on each required OU:
- Launch adsiedit.msc.
- Connect to the Default Naming Context for the domain.
- Right-click the OU and choose Properties.
- Click the Security tab.
- Click Advanced.
- Click Add to add the security principal.
- Enter the group name to delegate and click OK.
- Select the Properties tab.
- From the menu, select Descendent Computer Objects.
- Select the following Allow permissions:
- Read and Write canonicalName
- Read and Write name
- Read and Write Name