STATUS_DS_DUPLICATE_ID_FOUND (0xC0000405) fix

Quick answer

Run repadmin /showrepl to identify the offending object, then use ntdsutil to delete or reanimate the duplicate entry in the AD database.

What's actually happening here

You're getting STATUS_DS_DUPLICATE_ID_FOUND (0xC0000405) because Active Directory encountered an object – usually a user, computer, or domain controller – that has a non-unique objectGUID or objectSid. This is almost always the result of a tombstone reanimation gone wrong: you restored a deleted object from backup, but its original GUID survived and now clashes with a newly created object that inherited the same GUID from replication. I've seen this most often after a domain controller was restored from an outdated system state backup on Server 2012 R2 or later, where the backup predated a tombstone reanimation that had already created a replacement object.

The error pops up in NTDS Replication events (ID 1925) or when you attempt to open Active Directory Users and Computers and it refuses to display certain objects. The system can't decide which object to return, so it throws the error.

Step-by-step fix

1. Isolate the duplicate object
   Open an elevated command prompt on an affected domain controller. Run:

   repadmin /showrepl * /csv > replication.csv

   Search the output for 0xC0000405 or failure status. Note the object GUID and distinguished name listed in the failing replication link.
2. Find the duplicate in the database
   Use ntdsutil to query the object directly:

   ntdsutil
   ntdsutil: "ntdsutil>"
   semantic database analysis
   go
   check duplicate objects

   This scans the entire database for duplicate objectGUIDs and prints their DNs. Write down both entries.
3. Delete the duplicate
   You need to remove the object that was incorrectly restored – usually the one that doesn't match the current replication topology. Use ldp.exe or ADSI Edit to delete the stale object. If you're sure which one is the imposter, run:

   ntdsutil
   ntdsutil: "ntdsutil>"
   authoritative restore
   restore object "CN=OldObject,DC=domain,DC=com"

   Then delete it with ADSI Edit. The authoritative restore marks it as the correct version so replication doesn't bring it back.
4. Force replication
   After deletion, trigger immediate replication:

   repadmin /syncall /AdeP

   Wait 5 minutes, then check the event log for any new 0xC0000405 errors.

If the main fix doesn't work

Sometimes the duplicate is embedded in the database itself and won't delete cleanly. In that case:

• Perform a non-authoritative restore of the affected domain controller from a known-good backup (one that predates the duplicate). Boot into Directory Services Restore Mode (DSRM), restore the system state, then reboot normally. The DC will replicate a fresh copy of the object from a healthy partner.
• Demote and re-promote the DC if the duplicate is on a single domain controller. Run dcpromo /forceremoval (Server 2008/2008 R2) or use Server Manager to remove the AD DS role, clean up metadata with ntdsutil metadata cleanup, then reinstall the DC role. This is brute force but guaranteed effective.
• If the object is a user account, manually export its attributes (groups, email, SID history) via PowerShell, delete it, and re-create with a new GUID. Use Get-ADUser -Identity "username" -Properties * to grab everything, then run Remove-ADUser and New-ADUser with the same sAMAccountName.

Prevention tip

Stop restoring domain controllers from backup unless you absolutely know the backup is within the tombstone lifetime (default 180 days for Server 2016+). If you must restore, take a full system state backup of every DC before making changes, and never restore a backup that's older than the tombstone lifetime. Instead, demote the faulty DC and let it replicate fresh data. This one habit will save you from 0xC0000405 permanently.