Active Directory: Duplicate Object Name Resolution
Relative Distinguished Names must be unique in the parent organizational unit or container. And sAMAccountNames must be unique in the domain. But duplicates can be created in rare cases. This article describes how they are handled by the system, how to find them, and how to fix the duplicates.
Objects in Active Directory Should Have Unique Names
When objects are created in Active Directory, the Relative Distinguished Name (RDN) must be unique in the parent Organizational Unit or container. This ensures that the distinguishedName and canonicalName attributes are unique in the forest. The parent OU/container is where the new object will reside in Active Directory. The RDN (Name) for most objects is the value of the cn attribute (the "Common Name"). The RDN of Organizational Unit objects is the value of the ou attribute.
Further, objects that are security principals require that the sAMAccountName attribute be unique in the domain. The NT form of the object name, <Domain>\sAMAccountName>, will be unique in the forest, where <Domain> is the NetBIOS name of the domain and <sAMAccountName> is the sAMAccountName of the object (also called the "pre-Windows 2000 name").
If you attempt to create an object in Active Directory with the RDN of an existing object in the same OU, you will get an error message, such as "Active Directory: The object already exists.". If you attempt to create an object with a unique RDN, but with a sAMAccountName that matches that of an existing object in the domain, you get the same error message.
How Duplicate Objects Can Be Created
It is possible to create duplicate objects (with the same RDN in the OU or the same sAMAccountName). This happens if the objects are created by different people at almost the same time while they are connected to different domain controllers. If the new objects are saved on different domain controllers before replication makes the conflict apparent, no error is raised. This will most likely happen if the objects are created on domain controllers in different sites, where replication may take a few minutes. However, it can even happen when the domain controllers are on the same site and well connected.
When a Duplicate RDN in an OU or Container is Detected
When two objects are created with the same Relative Distinguished Name (RDN) in the same parent Organizational Unit or container, the conflict is recognized by the system when one of the new objects replicates to another domain controller. When this happens, one of the objects is renamed. Some sources say the RDN is "mangled" to make it unique. The new RDN will be <Old RDN>\0ACNF:<objectGUID>. For example, assume that the user "cn=Ansel Adams" is created in "ou=West" in MyDomain.com by two different people on different domain controllers. After replication the two objects may have attribute values as follows:
DN: CN=Ansel Adams,OU=West,DC=MyDomain,DC=com
cn: Ansel Adams
sAMAccountName: AAdams
objectGUID: {96FDFE47-1BA5-42E2-B140-5A9B709758CB}
objectSID: S-1-5-21-73585374-152038242-839533224-1652
DN: CN=Ansel Adams\0ACNF:c93dad3e-4178-48aa-94c6-16237ba5aeaa,OU=West,DC=MyDomain,DC=com
cn: Ansel Adams
CNF:c93dad3e-4178-48aa-94c6-16237ba5aeaa
sAMAccountName: AAdams
objectGUID: {C93DAD3E-4178-48AA-94C6-16237BA5AEAA}
objectSID: S-1-5-21-73585374-152038242-839533224-4461
The sAMAccountName values are still the same, but one of the objects is renamed. The special character "\0A" is a line feed character (the backslash escape character followed by the 2 character hexadecimal representation of the line feed character). Of course, the two objects have different values for objectGUID and objectSID. The domain controller on which each object was created can be determined from the RID portion of the objectSID. Each domain controller assigns RID values from a unique RID pool. The special character added to the value of the cn attribute results in the common name appearing on two lines.
When a domain controller recognizes the conflict, it decides which object to rename based on the following:
- If the version numbers of the two objects are different, the object with the lowest version number is renamed.
- If the object version numbers are the same, the object with the oldest timestamp is renamed.
- If the timestamps are the same, the object with the lower GUID is renamed.
The version numbers and timestamps referred to above are replication metadata values, which are stored in the replPropertyMetaData attribute of the object. This attribute is not replicated, so the values are different on every domain controller. This metadata can be viewed using the repadmin command line utility. For newly created objects, the version number will most likely be 1. To display the replication metadata for "cn=Ansel Adams" on domain controller "DC1" you can use the following at the command console of a domain controller:
repadmin /showobjmeta "dc1" "cn=Ansel Adams,ou=West,dc=MyDomain,dc=com"
The important points are that one of the objects is renamed, but the sAMAccountName is not modified. The result can be two objects with the same sAMAccountName in the domain, at least until the process described in the next section recognizes the duplicate. Of course, one of the objects should be deleted.
When the duplicate objects are detected, an event is logged in the system event log with Event ID 1226. The details include the distinguished names and objectGUID of both objects.
You can find all "mangled" objects in Active Directory with the LDAP syntax filter "(cn=*CNF:*)". For example, you can use the following at the command prompt of a domain controller:
dsquery * -filter "(cn=*cnf:*)"
This will retrieve the distinguished names of all "mangled" objects. Then you can search for the corresponding object with the unmangled RDN value, to decide which to keep.
When a Duplicate sAMAccountName in Domain is Detected
You can also create two objects that are security principals at nearly the same time with different distinguishedName but the same sAMAccountName. Either the RDN is different, or if the RDN is the same the objects are in a different parent OU or container. In this case, the conflict is not recognized when the objects replicate. Instead, the Security Accounts Manager (SAM) service checks periodically for duplicate sAMAccountName values. In my tests, it took over 30 minutes for the conflict to be recognized, considerably longer than normal replication. When the process detects duplicate sAMAccountName values, one of the values is changed to the string "$DUPLICATE-xxx", where xxx is the RID of the object in hexadecimal. Again, one of these objects should be deleted. Interestingly, the process that detects duplicate sAMAccountName values does not find situations where the RDN has beem mangled to make the distinguishedName values unique, even though the sAMAccountName may be the same in the two objects.
When the object with the duplicate sAMAccountName is detected, an event is logged in the system event log with Event ID 12304. The details describe the object whose sAMAccountName was modified, but there is no information about the original value of sAMAccountName, or the conflicting object. You can find all objects whose sAMAccountName has been mangled because it was a duplicate with the LDAP syntax filter "(sAMAccountName=$DUPLICATE*)". For example:
dsquery * -filter "(sAMAccountName=$duplicate*)" -attr distinguishedName whenCreated
If you don't already know the original sAMAccountName, and the conflicting object, you must search for all objects created within a few minutes of the mangled object. You can use the whenCreated attribute value of the mangled object for this search. If more than one such object is found, you may be able to tell which sAMAccountName was the duplicate from your organization's naming policy. For example, if the first query for objects with mangled sAMAccountName values reveals an object created on January 18, 2013 15:34:21, then the following query should find the duplicate and reveal the original sAMAccountName:
dsquery * -filter "(&(whenCreated>=20130118152400.0Z)(whenCreated<=20130118154400.0Z))" -attr distinguishedName sAMAccountName
The query looks for all objects created within 10 minutes of the mangled object.
See Also
Other Resources
- sAMAccountName is always unique in a Windows domain… or is it? (Blog post by Joe Richards)
- Troubleshooting Directory Data Problems
- Duplicate Name on Network (Directory Services Forum question)
- Account Integrity
- Conflict Resolution, Lingering Objects, Printers (Microsoft blog post)
- I have objects in my Active Directory (AD) domain that have CNF in their name followed by a globally unique identifier (GUID). What are these objects?