Fix ERROR_DS_DRA_ACCESS_DENIED (0X00002105) on Domain Controller

What Causes 0X00002105

The error ERROR_DS_DRA_ACCESS_DENIED shows up in the Directory Service log when a domain controller tries to replicate but gets denied. I've seen this mostly in two scenarios:

• After promoting a new DC that had a cloned VM snapshot with bad time
• When a DC's computer account loses its replication permissions after a password reset

The culprit here is almost always one of three things: time skew between DCs, broken delegation on the computer account, or a stale Kerberos ticket. Don't bother with DNS checks first — that's a different error.

Quick Fix (30 seconds) — Check Time Sync

Run this on both the source and destination DCs:

w32tm /query /status

If the time difference is more than 5 minutes, Kerberos fails. That gives you this exact error. Fix it fast:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

Then force replication on the destination DC:

repadmin /syncall /AdeP

Time sync fixes about 40% of these errors. If it's still broken, move on.

Moderate Fix (5 minutes) — Verify Replication Permissions

The destination DC needs permission to replicate from the source. Check the delegation on the source DC's computer account in AD Users and Computers:

1. Open AD Users and Computers on any DC
2. Find the source DC's computer account in the Domain Controllers OU
3. Right-click → Properties → Security tab
4. Make sure the destination DC's computer account has Allowed to Authenticate and Replication Synchonization permissions

If it's missing, add it. But more commonly, the permissions got stripped because someone manually edited the ACL. Reset them with:

repadmin /options +DISABLE_INBOUND_REPL
repadmin /options -DISABLE_INBOUND_REPL

That toggles replication off and on, which often picks up default permissions. Then retry replication.

Advanced Fix (15+ minutes) — Reset the DC's Computer Account

If time and permissions are fine, the DC's computer account password is likely out of sync with Active Directory. This happens after a system state restore or VM snapshot rollback. Do this on the destination DC that's failing:

1. Open Command Prompt as Administrator
2. Reset its own account password:

   netdom resetpwd /server:<source-DC-name> /userd:<domain>\administrator /passwordd:*

3. You'll be prompted for the admin password. Enter it.
4. Reboot the DC after the command completes.

After reboot, check replication again:

repadmin /showrepl

If you still see access denied, you need to force a full sync by resetting the replication link:

repadmin /syncall /AdeP /e /d

This forces all partition syncs. Takes a few minutes on large domains.

When to Nuke and Repromote

If none of that works, and the DC has been offline for weeks, your best bet is to demote it and promote fresh. Run:

dcpromo /forceremoval

Then seize the roles if needed. But honestly, I've seen the computer account reset fix 9 out of 10 cases. Start there if time is tight.

One Thing Nobody Tells You

Check the Domain Controllers group membership. If the DC's computer account was removed from that group, replication is dead. Add it back with ADSI Edit or PowerShell:

Add-ADGroupMember -Identity "Domain Controllers" -Members "DESTINATION-DC$"

That's a rare but real cause. I've seen it after a failed domain join attempt.