AD Bridge Delegation of Domain Join Permissions

AD Bridge agents, like Windows systems, need to be joined into an Active Directory domain to participate in authentication, security, and configuration. In a typical Windows enterprise environment, a Domain Administrator grants the permissions to join computers to specific accounts for separation of duties or automation tasks. While the basic steps for delegating permissions to join AD Bridge systems is based on the standard Windows approach, AD Bridge requires additional permissions to provide the following abilities:

• Write additional AD Bridge specific information to the computer object.
• Support the ability to target a specific OU on join (--ou).
• Support the ability for long or duplicate computer names.

The remainder of this document describes how to delegate the permissions required for the various domain join methods.

Delegation of Control Overview

In a traditional Windows environment, all AD users can join up to ten systems to the default Computers container at a time (using the ms-DS-MachineAccountQuota attribute). After reaching this quota, additional attempts will be denied. To allow non-Administrator users to join Windows systems beyond their quota, the Delegation of Control Wizard in Active Directory Users and Computers can be used to provide basic join rights.

The basic procedure that most AD administrators are familiar with is as follows:

1. In Active Directory Users and Computers, right-click the root of the domain you want to add computers to, and then click Delegate Control.
2. In the Delegation of Control Wizard, click Next.
3. Click Add to add the specific security principal to the Selected users and groups list, and then click Next. We strongly recommend using a group, even if that group only contains a single user.
4. In the Tasks to Delegate page, click Join a computer to the domain and click Next, and then click Finish.

The delegated task, Join a computer to the domain, grants the Create computers object permission at the domain root to the selected security principals.

The above method is outlined for completeness; however it is not sufficient for joining AD Bridge systems to the domain in all circumstances. If only the above procedure is followed the actual results may vary; sometimes joining without error, and failing in other instances.

Joining a computer to the domain is not always a straightforward operation from a permissions perspective in AD. A computer object may already exist, or exist in another OU within the directory. It may have been pre-staged, or created previously by another account. It may have been moved from a different OU, bringing its previous permissions with it. Because of all the variations in how a system may be joined, the above procedure is not sufficient in all circumstances, even for Windows systems.

The remainder of this document discusses the various intricacies and scenarios that differ from a standard Windows domain join and why additional consideration is required when granting join rights. There are three main reasons why AD Bridge requires more rights. AD Bridge provides additional functionality that may not be found in a typical AD deployment:

• Ability or need to join two or more systems with the same host name (but unique FQDNs)
• Ability or need to join with a disjointed DNS name space
• Ability or need to set additional computer properties for functional or reporting purposes

AD Bridge Domain Join Process Overview

When a domain join process is initiated on the AD Bridge agent, it first must determine what name to join Active Directory with. By default, this name will be the FQDN of the system. If the system does not have a FQDN, the domain join process uses the host name of the system and update the FQDN to match the Active Directory domain being joined.

When joining the above systems to the contoso.com Active Directory domain, all three will be updated (if not already) to servername.contoso.com in their local configuration files and then created in AD with that updated information. The new computer object will be created with a sAMaccountName equal to the host name of the system and a dNSHostName equal to the FQDN.

If preserving the existing FQDN of a system is required, the domain join process can use an optional --disable hostname parameter. When used, the system will keep its FQDN and attempt to create the computer object in AD with a matching dNSHostName. This scenario is known as a disjointed namespace.

For more information, see Disjointed Namespaces in AD Bridge.

Once a system updates its local information, it then attempts to find a computer object in Active Directory with a dNSHostName attribute that matches its local value. For example, server03 will query AD looking for any computer object with a dNSHostName of server03.contoso.com (remember the domain values are updated by default to the domain being joined).

Assuming that server03 does not find a computer object in the directory with its desired dNShostName, it will attempt to create one. If it does find a computer object with a matching dNSHostName, it will attempt to join using the existing object. This is true even when the sAMAccountName of the computer object does not match the host name of the system. This function allows AD Bridge to support pre-staged computer objects.

For more information, see Avoid Generated (Hashed) Computer Names.

If the system decides to create a computer object, it must then determine the sAMccountName for the computer object. As discussed above, this will always default to the host name of the local machine. However, if the sAMAccountName is already present in the directory (with a different dNSHostName) or if it is greater than 15 characters, the system will generate a hashed computer name to ensure uniqueness.

When joining, System 2 will attempt to use a sAMAccountName of server01, which is already in use by System 1. Since, by default, System 2 will also update its FQDN to the AD domain it is joining it will attempt to overwrite the existing object.

However, when joining with the --disable hostname switch, System 2 will keep its FQDN as server01.widgets.com. Since no other computer object exists with this FQDN, and because another computer object already exists with a sAMAccountName of server01, System 2 will generate a hashed value (for example, server0-p37ym1j) to use as the new name.

A successful join, either with a new computer object or using an existing one, is always dependent on the rights the joining user has to the existing OU or objects.