When Active Directory replication fails with error 5: Access is denied, the message is misleading in a useful way. It tells you the network worked. One domain controller found its partner, opened a connection, and got far enough to attempt an authenticated bind — and that bind was refused.
That makes error 5 a different animal from the more common error 1722, which is a pure connectivity failure. With 5, you can stop chasing DNS and firewall ports and focus on the security layer: Kerberos, time, the machine secure channel, and the RPC policies that govern authenticated calls between DCs.
This guide walks through the causes in the order that resolves the most cases fastest.
What error 5 is telling you
Replication between DCs runs over authenticated RPC. The destination DC binds to the source using the source DC’s service principal name (SPN) and a Kerberos ticket. If anything in that chain is wrong — the ticket can’t be issued, the SPN doesn’t resolve to the right account, the clocks are too far apart, or a policy blocks the call — the bind is rejected and Windows returns access denied.
You’ll typically see it in one of these forms:
The replication generated an error (5):
Access is denied.Or from dcdiag /test:checksecurityerror:
DsBindWithSpnEx() failed with error 5,
Access is denied.The common thread is authentication. Network reachability is not the problem here.
Step 1: Identify the exact failing pair
Don’t fix anything until you know which source and destination DCs are involved and in which direction. Run these from an elevated prompt on the DC reporting the error:
repadmin /showrepl
repadmin /replsummaryshowrepl lists each inbound partner and the last result per naming context. Note the source DC (the one being replicated from) and the destination (the one reporting access denied). Replication is directional, so a failure from DC-A to DC-B is a separate problem from B to A.
Step 2: Check time synchronization
Kerberos is time-sensitive. By default, if two computers’ clocks differ by more than five minutes, ticket validation fails and you get access denied. Time skew is one of the most common and most overlooked causes of error 5.
Check the time hierarchy and the offset between DCs:
w32tm /monitorLook at the offset reported for each DC. Anything approaching or past the five-minute window will break Kerberos. If a DC is badly skewed, resync it against the PDC emulator:
w32tm /resync /rediscoverStep 3: Verify the machine secure channel
Each domain controller maintains a secure channel with the domain. If that channel is broken — often after a restore from an old backup, a clone done incorrectly, or a long isolation — authenticated operations like replication start failing with access denied.
Test it on the DC that’s failing:
nltest /sc_verify:yourdomain.localA healthy result confirms the trust and secure channel are working. If it reports a failure, that DC’s relationship with the domain needs repair before replication can succeed.
Step 4: Look at the RPC security policy (RestrictRemoteClients)
If time and the secure channel both check out, the next suspect is an RPC policy that blocks the authenticated calls replication depends on. Microsoft specifically documents the RestrictRemoteClients registry value: when it’s set to 2, certain remote RPC calls are refused and DCs report access denied during replication.
This value is usually set by a Group Policy or a hardening template rather than by hand, so check whether a recently applied policy introduced it. The relevant key is:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC
Value: RestrictRemoteClientsPer Microsoft’s article, a value of 2 is the problem case. Resetting it (or correcting the GPO that sets it) restores the RPC behavior replication needs. Because this is often pushed by policy, fix it at the GPO level so it doesn’t come back at the next refresh.
Step 5: Check Kerberos, SPNs, and duplicate names
If the bind is still refused, dig into Kerberos itself. A missing or duplicate SPN on the source DC’s computer account can stop the destination from getting a valid ticket for it.
Purge cached tickets on the destination and force a fresh request, then look for errors:
klist purge
repadmin /replicate <destination-DC> <source-DC> <naming-context-DN>Check for duplicate SPNs across the domain, which break Kerberos authentication for the affected accounts:
setspn -XIf setspn -X reports duplicates involving a domain controller’s host SPNs, resolve them — duplicates are a known cause of access-denied failures.
It’s also worth confirming the DC’s computer object isn’t in a bad state in the directory. An incorrect userAccountControl value or a DC object that lost its server reference in the configuration partition can both produce error 5.
A fast diagnostic order
Under pressure, this is the sequence that resolves error 5 in most environments:
Error 5 troubleshooting order
- repadmin /showrepl — identify the exact failing source and destination pair
- w32tm /monitor — confirm time skew is under 5 minutes between the DCs
- nltest /sc_verify — verify the failing DC's secure channel
- Check RestrictRemoteClients (RPC policy) for a value of 2 from a GPO
- klist purge + setspn -X — rule out stale tickets and duplicate SPNs
- Fix the cause, then repadmin /syncall /AdeP and re-check /showrepl
Here’s how the most likely causes map to the fix, so you can jump to the right one based on what you’ve already ruled out:
Error 5 causes and where to look
| Time skew over 5 minutes | w32tm /monitor, then /resync against the PDC emulator |
|---|---|
| Broken secure channel on a DC | nltest /sc_verify; repair per Microsoft DC guidance, or rebuild a long-isolated DC |
| RestrictRemoteClients = 2 | Correct the registry value / the GPO that applies it |
| Duplicate or missing SPN | setspn -X to find duplicates; remove the stale entry |
| Stale Kerberos tickets | klist purge on the destination, then force replication |
| Bad DC computer object state | Check userAccountControl and the server object in the config partition |
After the fix: confirm it actually replicated
Once you’ve corrected the cause, force replication and verify it succeeds rather than assuming it will:
repadmin /syncall /AdeP
repadmin /showreplA clean /showrepl with recent success timestamps for the previously failing partner means you’re done. If error 5 persists for the same pair after a genuine fix, re-run the diagnostic order — there may be a second cause stacked on the first, which happens often when a hardening change touched several settings at once.
For broader replication health and the related connectivity failures, our guide on forcing Active Directory replication and the error 1722 walkthrough cover the neighboring problems you’ll run into on the same DCs.
Wrapping up
Error 5 is an authentication failure wearing a vague label. The network is fine — what failed is the security handshake between two domain controllers. Work the causes in order: pin down the failing pair, rule out time skew, verify the secure channel, check for an RPC policy like RestrictRemoteClients, then dig into Kerberos and SPNs. Fix the real cause and replication recovers; forcing it without a fix just repeats the same denied bind.
