Active Directory requires unique names for objects of the same type. For example, if there is already a user object in the domain called “User1” Active Directory will not let you create another user object by that same name. However occasionally circumstances arise such that object naming conflicts can occur. One such example is if a domain controller is offline for a period of time, objects are created on that server, and when the DC is brought back online there are already objects in the directory occupying names of the objects created on the offline DC. This represents a conflict. In response, Active Directory deals with this by appending the constant “CNF:” and a variable GUID accompanied by System Event 12292 in the event logs.
What do we do about it?
- When the conflicting objects are security principals, typically the conflicting object is the newer of the two and can be deleted. You can safely delete the CNF object if you can verify that the original object is the object in use. An example of data used to verify might be lastlogon, lastlogontimestamp or pwdlastset data on a user object. Or you could simply disable the computer or user account and ensure that the user/system can still access the domain by re-authenticating.
- In an instance where it’s known that 2 separate computer objects tried to join the domain at the same time in different locations using the same name, it’s best to rename both client systems and rejoin them to the domain. Upon successfully rejoining the domain, the previously conflicting objects can be deleted out of the directory.
CNF’s & Lingering Objects:
A preponderance of these CNF objects can be a symptom of lingering objects. This would happen in cases where a domain controller was disconnected for a period longer than the tombstone lifetime and brought back online. To help substantiate whether there really is an issue with lingering objects in your domain or forest, check for the existence of Event 1388 or 1988 in the Directory Services logs of destination domain controllers (meaning the replication partners of the DC that spent so much time offline.) To clean up lingering objects, perform the following steps.
- Download a utility called repldiag. This is easier to use than repadmin since it automatically scans all naming contexts on all DC’s in the domain.
- Pre-requisites (Note: Though it is not a requirement to run the utility from a domain controller, I would certainly recommend it where possible.):
- Ensure a minimum of .Net 2 sp1 is installed on the system you’re running the utility from. .Net 3.5 can be installed as a feature on Server 2008 R2 & 2012 to meet this requirement.
- Ensure that you are using credentials with Enterprise Admin rights.
- Open an elevated command prompt and navigate to the location of repldiag.exe. Run “repldiag /RemoveLingeringObjects”
- Wait for completion and scan the results for errors. The beauty of repldiag is there’s no need to remote to each DC and run the repadmin sequence (http://technet.microsoft.com/en-us/library/cc785298(v=ws.10).aspx). The utility does it for you.