Active Directory Naming Limitations

The Active Directory database has certain constraints related to naming computer objects. Because these restrictions are often in conflict with the namespaces used within a Unix/Linux deployment, AD Bridge has ways to integrate the discrepancies between the two. AD Bridge accomplishes this by using the dNSHostName value of a computer object as the primary key to identify a computer in Active Directory. Because of this, the computer’s name in AD (sAMAccountName) does not necessarily have to match the local host name of the system.

Computer Names Greater Than 15 Characters

Windows systems (and Active Directory) have a computer name (sAMAccountName) limit of 15 characters. This limit is honored and enforced throughout Windows. In UNIX environments, machine names can be greater than 15 characters, such as prod-oracle-db12. AD Bridge supports computer names greater than 15 characters by generating a new hashed computer name during the join process. The generated name consists of the first seven characters from the original name, a hyphen, and then a unique seven digit code.

For example, the Oracle machine name prod-oracle-db12 might be joined as PROD-OR-PC3LRX4. This generated machine name represents the object in AD only. The name is not used as the host name on the local machine and is not used when communicating with the system from other hosts.

Duplicate Machine Names

A computer name must be unique throughout a particular Windows domain. When migrating UNIX system to AD with AD Bridge it is sometimes necessary to bring multiple machines with the same host name, but different FQDNs, into the same AD domain. For example, oracle12.prod.domain.com and oracle12.dev.domain.com both share the same host name of oracle12.

AD Bridge supports duplicate computer names by generating a new hashed computer name during the join process for subsequent conflicting computer names. The generated name will consist of the first seven characters from the original name, a hyphen, and then a unique seven digit code. The second Oracle machine oracle12.dev.domain.com might be joined as ORACLE12-298GG. This generated machine name represents the object in AD only. The name is not used as the host name on the local machine and is not used when communicating with the system from other hosts.

To preserve the FQDN of each machine, the --disable hostname parameter must be specified when performing the join operation.

For more information, see Disjointed Namespaces in AD Bridge

SPN Uniqueness

While not directly related to any of the delegation issues listed, the following limitation is worth bearing in mind. Beginning with Windows 2012 R2, Microsoft started implementing SPN uniqueness across the entire Active Directory forest. Since each computer object registers a short SPN in the form of HOST/COMPUTERNAME even computers with different FQDNs will have problems joining across multiple domains with duplicate computer names.

In previous versions (prior to 2012 R2), two computer objects with the same sAMAccountName could exist in different domains in the same forest. For example, DOMAINA\SERVERA and DOMAINB\SERVERA. While this may not have been recommended it was allowed and some organizations may depend on this feature based on their process. In 2012 R2 and later, joining with the same sAMAccountName as another system in the forest will fail.

This is a limitation of Windows and not AD Bridge.

For more information, see SPN and UPN Uniqueness.

Avoid Generated (Hashed) Computer Names

In some environments, it may be preferable to control the value on a created computer object instead of relying on the dynamically hashed values. This can be accomplished by pre-staging the computer object. When pre-staging the computer account it is still necessary to choose a unique name for each computer. The Oracle machines above, for instance, might be pre-staged as ORACLE12-PROD and ORACLE12-DEV prior to join.

To pre-stage a computer account to avoid generated/hashed names, follow the standard procedure for pre-staging computer accounts. Then, perform the following:

  1. Using Active Directory Users and Computers, ADSI Edit, or another tool able to directly modify AD attributes, locate and view the properties of the pre-staged computer account.
  2. Locate and modify the dnsHostName attribute to equal the FQDN of the computer that will be joined using this computer account.
  3. Save all changes.