When dealing with Active Directory (or Entra) replication error 5: Access is denied in Windows Server, it typically indicates a permissions or authentication issue between domain controllers (DCs). Below is a troubleshooting guide to help resolve this error.
1. Verify Domain Controller’s Connectivity
The first step is to ensure that both DCs can communicate with each other properly.
Check network connectivity between the DCs by pinging them (using ping DC-name or ping IP-address).
Use telnet DC-name 135 to test if you can establish an RPC connection (port 135 is crucial for RPC used in replication).
Use nslookup or ping to test if DNS resolution is functioning correctly.
2. Check Active Directory Replication Status
Use repadmin to identify replication issues.
repadmin /showrepl
This command shows replication information. Look for any errors related to “Access is denied” on the connections between domain controllers.
You can also use:
repadmin /replsummary
This will give you a summary of replication across your domain controllers.
3. Check Permissions and Account Membership
Access is denied could indicate a problem with permissions on the destination DC or with the credentials of the account trying to perform replication.
Ensure that Domain Admins, Enterprise Admins, or Replication Administrators have the necessary rights.
Confirm that the KDC (Key Distribution Center) service is running on all DCs.
Make sure Replication permissions are properly set on both source and destination DCs.
Check if the replication account is in the correct groups:
Use whoami /groups on the DC and verify that the replication account is in Domain Admins, Enterprise Admins, or Replication Operators.
4. Verify Time Synchronization (Kerberos Dependency)
Active Directory replication relies heavily on Entra and Kerberos authentication, and time discrepancies can cause issues.
Ensure that the system clocks on the DCs are synchronized within a 5-minute difference. You can use the w32tm /query /status command to verify the current time configuration.
If you find any time discrepancy, reset the Windows Time Service (w32tm /resync) or reconfigure it to point to a valid time source.
5. Check Kerberos Authentication
Since Kerberos authentication is often involved in “Access is denied” errors, it’s important to check that Kerberos is functioning correctly.
Check for Kerberos-related errors in the Event Viewer on the affected domain controller. Look under Event Viewer -> Windows Logs -> System for any Kerberos or KDC errors.
6. Check for DNS Configuration Issues
DNS plays a crucial role in AD replication. Incorrect DNS settings can cause failed replication attempts.
Ensure that each domain controller is using the correct DNS server settings. Each DC should have itself and other DCs listed as DNS servers.
Verify DNS health using:
dcdiag /test:dns
This will help identify any DNS configuration issues that could lead to replication errors.
7. Force KCC to Rebuild Topology
You can force the Knowledge Consistency Checker (KCC) to rebuild the replication topology.
repadmin /kcc DC-Name
This will trigger the DC to recalculate its replication links and might resolve any improper connections causing replication failure.
8. Check SYSVOL and NTFRS Permissions
Replication of the SYSVOL folder is a common cause of “Access is denied” errors. Check the permissions on the SYSVOL and NTFRS (or DFSR if you’re using Distributed File System Replication).
Verify Permissions on the SYSVOL folder. Ensure that the Authenticated Users, System, and Domain Controllers groups have the correct permissions.
Run DCDiag to check for replication-related issues with FRS/DFSR:
dcdiag /test:frssysvol
Restart the NTFRS service on the DC:
net stop ntfrs
net start ntfrs
9. Synchronize Domain Controllers Manually
If necessary, you can try forcing replication using the following command:
repadmin /syncall /AdeP
This will attempt to synchronize all domain controllers in the domain and give verbose output (/A), showing errors (/e) if present.
10. Review Event Logs
Always check the Event Viewer for detailed logs on replication and security issues. Focus on logs from Event Viewer -> Applications and Services Logs -> Directory Service and Event Viewer -> Windows Logs -> Security.
Summary of Common Causes of Error 5 (Access Denied):
Insufficient permissions: The account used for replication doesn’t have the necessary rights.
Kerberos authentication failure: Time or service issues affect Kerberos tickets.
DNS misconfiguration: The domain controllers cannot properly locate or authenticate with each other.
RPC issues: Ports related to RPC communication (like 135) are blocked or inaccessible.
FRS/DFSR problems: File replication services not working correctly.
By following the above steps, you should be able to isolate and resolve the replication error 5: Access is denied.