When objects are created in
Active Directory, the Relative Distinguished Name (RDN) must be unique in the parent Organizational
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.
↑ Return to Top
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 in the same site and well connected.
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
DN: CN=Ansel Adams\0ACNF:c93dad3e-4178-48aa-94c6-16237ba5aeaa,OU=West,DC=MyDomain,DC=com
cn: Ansel Adams
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. We can tell on which domain controller each object was created 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:
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. We are left with two objects with the same sAMAccountName in the domain. 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.
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.