Active Directory replication is a critical process for maintaining consistency across domain controllers within a Windows Server environment. When this process fails, it can lead to significant issues, including inconsistent data, authentication problems, and delays in propagating configuration changes. One common error encountered during Active Directory replication is error 5, which translates to “Access is denied.” This error indicates a permission issue preventing the source domain controller from replicating changes to the destination domain controller. Understanding the symptoms and potential causes is crucial for effective troubleshooting.
When Active Directory replication fails with error 5, you may observe one or more of the following symptoms:
Symptom 1: Dcdiag Reports Replication Failure with Error 5¶
The Dcdiag.exe command-line tool is frequently used to assess the health of domain controllers and detect replication issues. When you run Dcdiag, the replication test specifically may fail and report status code 5, along with the “Access is denied” message. This output clearly indicates that a replication attempt from a specific source domain controller to a destination domain controller failed due to access permissions.
For example, the Dcdiag output might resemble the following:
Testing server: <Site_Name>\<Destination_DC_Name>Starting test: ReplicationsReplications Check[Replications Check,<Destination_DC_Name>] A recent replication attempt failed:From <Source_DC> to <Destination_DC>Naming Context: <Directory_Partition_DN_Path>The replication generated an error (5):Access is denied.The failure occurred at <Date> <Time>.The last success occurred at <Date> <Time>.<Number> failures have occurred since the last success.
Symptom 2: DsBindWithSpnEx Function Failure Reported by Dcdiag¶
Another specific test within Dcdiag, DCDIAG /test:CHECKSECURITYERROR, checks for potential security-related issues that might impede replication. This test uses the DsBindWithSpnEx function to establish a connection. If this function fails with error 5 during the security check, it strongly suggests that authentication or authorization issues are preventing the required communication between domain controllers. This symptom points directly towards problems with secure channel, SPNs, or permissions.
The REPADMIN.exe command-line tool is another essential utility for diagnosing and managing Active Directory replication. Various REPADMIN commands can be used to check replication status, manually initiate replication, or summarize replication health. If these commands indicate error 5 as the last replication status for a connection or partition, it confirms the access denied issue.
Commands like REPADMIN /KCC, REPADMIN /REPLICATE, REPADMIN /REPLSUM, REPADMIN /SHOWREPL, REPADMIN /SHOWREPS, and REPADMIN /SYNCALL are commonly used to check replication and may report status 5.
A sample output from REPADMIN /SHOWREPL illustrating this error might look like this:
Events related to Active Directory replication are logged in the Directory Services log within Event Viewer. When replication encounters error 5, specific events from sources like NTDS KCC, NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService may be logged, citing the status code 5. These events provide valuable context, often including the source and destination domain controllers, the naming context being replicated, and the error code.
Common Event IDs associated with replication failures, although potentially showing status 5 or other errors like 8524 (Replication access was denied), include:
Event ID
Source
Event string
1655
NTDS General
Active Directory tried to communicate with the following global catalog and the attempts were unsuccessful.
1925
NTDS KCC
The attempt to establish a replication link for the following writable directory partition failed.
1926
NTDS KCC
The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
These events serve as primary indicators in server logs that replication is failing.
Symptom 5: Replicate Now Fails in Active Directory Sites and Services¶
When you manually initiate replication between domain controllers using the “Replicate Now” option in the Active Directory Sites and Services snap-in, the operation might fail and display an error message box. This message box explicitly states that the synchronization attempt failed with “Access is denied” when replicating a specific naming context from the source to the destination domain controller. This graphical interface failure confirms the issue observed via command-line tools and event logs.
The dialog box title might be “Replicate Now,” and the message text could state:
The following error occurred during the attempt to synchronize naming context %% from Domain Controller to Domain Controller :
Access is denied.
The operation will not continue.
This direct feedback from the GUI reinforces that the replication is being blocked by an access permission issue.
Before diving into specific causes, a general troubleshooting approach using built-in Windows tools can often identify and resolve common issues.
Use the generic DCDIAG and NETDIAG command-line tools to perform initial checks on the affected domain controllers. Specifically, the DCDIAG /TEST:CheckSecurityError command is designed to look for potential security configuration problems that might cause replication failures, including SPN registration and time synchronization issues.
To begin troubleshooting error 5:
Run DCDIAG on the destination domain controller. This provides an overall health report of the DC, highlighting many potential configuration issues.
Run DCDIAG /TEST:CheckSecurityError and NETDIAG. These commands perform more targeted tests related to security and network connectivity, which are often at the root of “Access is denied” errors.
Review the output from DCDIAG and NETDIAG carefully. Address any errors or warnings reported by the tools, as they often point to the underlying cause.
After resolving the identified faults, retry the previously failed replication operation using REPADMIN or Active Directory Sites and Services. If replication still fails with error 5, proceed to investigate the specific causes detailed below.
The following sections discuss known causes for Active Directory replication error 5 and provide solutions.
Cause 1: Invalid Secure Channel or Password Mismatch on the Source or Destination DC¶
Active Directory domain controllers rely on a secure channel to communicate securely, especially for tasks like replication. This secure channel is established using the domain controller’s machine account password. If there is a password mismatch between the domain controller’s stored password and the password object in Active Directory (on the PDC emulator), the secure channel becomes invalid. This invalid channel prevents the domain controller from authenticating correctly to other domain controllers, leading to access denied errors during replication attempts.
You can validate the secure channel status using the following commands:
* nltest /sc_query:<Domain Name>: This command attempts to query the secure channel to the specified domain. A successful output indicates the secure channel is working.
* netdom verify <DC Name>: This command verifies the secure channel for the specified domain controller.
Solution
If the secure channel is invalid, you can reset the machine account password of the affected domain controller. The NETDOM /RESETPWD command is used for this purpose.
Disable the Kerberos Key Distribution Center (KDC) service on the destination domain controller. This prevents the DC from issuing potentially stale Kerberos tickets while its password is being reset and propagated.
Purge existing Kerberos tickets on the destination domain controller from an elevated command prompt. Run Klist -li 0x3e7 purge. This clears any cached tickets that might interfere with establishing a new secure channel after the password reset. The 0x3e7 represents the logon session ID for the system account.
Reset the machine account password of the destination domain controller using the NETDOM RESETPWD command. Run this command from another domain controller or a member server that can contact both the destination DC and the PDC emulator for the DC’s domain.
Note: The /usero and /passwordo parameters might not be strictly necessary if running with sufficient domain administrator credentials. The /server should point to a DC holding the PDC emulator role for the destination DC’s domain.
Ensure password replication: Verify that the new password has replicated inbound to other potential KDCs and specifically to the source domain controller involved in the failed replication. You can use repadmin /showrepl to check for recent replication successes of the domain partition.
Restart KDC service and retry replication: Start the KDC service on the destination domain controller and retry the replication operation. The reset password and refreshed Kerberos tickets should allow the secure channel to be re-established, resolving the access denied error.
For detailed instructions on using Netdom.exe to reset machine account passwords, refer to Microsoft documentation on the topic.
The CrashOnAuditFail setting in the registry determines system behavior when security audits cannot be logged. When the Group Policy setting Audit: Shut down system immediately if unable to log security audits is enabled, the CrashOnAuditFail registry value is set to 2. If the local security event log becomes full and security audits cannot be written, a CrashOnAuditFail value of 2 will cause the system to stop responding or shut down to prevent security events from being missed.
Active Directory domain controllers generate a high volume of security audit events, especially when detailed auditing is configured. If the security event log size is restricted (e.g., set to “Do not overwrite events” or a fixed size that is too small) and it becomes full, the CrashOnAuditFail=2 setting will block further operations, including replication, which rely on proper auditing. This block can manifest as an “Access is denied” error.
Solution
To resolve this, you need to ensure that the security event log is not full and that the CrashOnAuditFail setting allows for normal operation.
Clear the security event log: Open Event Viewer, navigate to the Security log, and clear it. Save the log to another location if necessary for later analysis.
Re-evaluate security log size constraints: Review the size and overwrite settings for the security event log. Ensure that the log is configured to automatically overwrite old events or has a sufficiently large maximum size to prevent it from filling up rapidly. Check both local policy and domain/OU Group Policy settings that apply to the domain controller.
Modify the CrashOnAuditFail registry entry:
Open Registry Editor (regedit).
Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.
Locate the CrashOnAuditFail entry.
If the value is 2, change it to 1.
If the entry exists and its value is already 0 or 1, you might still try deleting the entry, clearing the security log again, and then recreating the entry with a value of 1. This has resolved the issue in some cases.
Value 0: Security audits are not written, and the system continues without crashing. (Not recommended for DCs)
Value 1: Security audits are written, and if the log is full, new events are discarded. (Default behavior when the policy is disabled)
Value 2: Security audits are written, and if the log is full, the system crashes or stops.
Restart the destination domain controller: A restart is required for the changes to the CrashOnAuditFail setting to take effect.
Retry replication: After the restart, attempt to replicate again.
Ensure that Group Policy updates don’t re-enable the restrictive “Audit: Shut down system immediately if unable to log security audits” policy setting.
Active Directory replication between domain controllers in different domains relies on the health and validity of the trust relationships between those domains. If the secure channel underlying a trust is broken, or if there are issues with trusts along the trust path in a multi-domain forest, replication attempts traversing those trusts can fail with “Access is denied”. This is because the domain controller cannot securely authenticate to its replication partner across the trust boundary.
You can use the Netdiag tool to check the health of trusts. A failed trust relationship test in Netdiag will explicitly state that the secure channel to a domain is broken:
Trust relationship test. . . . . . : FailedTest to ensure DomainSid of domain '<domainname>' is correct.[FATAL] Secure channel to domain '<domainname>' is broken.[% <variable status code> %]
In complex forest structures with multiple domains (e.g., root, child, grandchild, tree domains), replication failures might occur between non-adjacent domains. For example, replication between a grandchild domain and a tree domain would rely on the transitive trusts: Grandchild -> Child, Child -> Root, and Root -> Tree. All these trusts must be healthy. If a shortcut trust exists directly between the two communicating domains, only the health of that shortcut trust needs verification.
Consider the following forest structure: mermaid
graph TD
Root(Contoso.COM) --> Child(B.Contoso.COM);
Child --> Grandchild(C.B.Contoso.COM);
Root --> Tree(Fabrikam.COM);
Grandchild -- Replication Failure (Error 5) --> Tree;
If replication fails between domain controllers in C.B.Contoso.COM and Fabrikam.COM, you must check the trust health along the path: C.B.Contoso.COM <-> B.Contoso.COM, B.Contoso.COM <-> Contoso.COM, and Contoso.COM <-> Fabrikam.COM.
Trust passwords are automatically managed by the KDC and are changed periodically. If replication latency prevents a domain controller from receiving the updated trust password for its domain’s trust relationship objects (TDOs), the trust can become invalid. You can check for recent trust password changes by examining the object metadata for the TDO using Repadmin /showobjmeta.
Solution
To fix a broken trust relationship:
Verify trust health: Use Netdiag or nltest /trusts to identify which specific trusts in the path are broken.
Reset the trust: Reset the trust relationship from both sides of the trust, typically starting with the PDC emulator of the root domain and then the PDC emulator of the child or tree domain involved in the trust.
From the root domain PDC emulator (e.g., Contoso.COM):
Ensure replication of TDO changes: After resetting the trust, ensure that the domain controllers involved, especially those failing replication, have inbound replicated the directory partition containing the TDOs with the new password. The TDO is located in the domain partition of the trusted domain.
Retry replication: Once the trusts are verified healthy and the changes have replicated, retry the Active Directory replication.
Kerberos authentication, which is fundamental to Active Directory operations including replication, relies on time synchronization between the client (the destination domain controller initiating replication) and the server (the source domain controller being replicated from). The Kerberos policy, by default defined in the Default Domain Policy, allows a maximum time difference (skew) of five minutes between the KDC issuing the ticket and the target server using the ticket. If the time difference exceeds this tolerance, Kerberos authentication will fail, resulting in an “Access is denied” error.
It’s important to note that Kerberos checks the relative time difference between the KDC and the target server, not their absolute time difference from a real-world clock. The destination DC acts as the client, and the source DC acts as the target server. Any domain controller running the KDC service could potentially issue the Kerberos ticket used by the destination DC. Therefore, time must be synchronized between the destination DC, the source DC, and any KDC that might serve the destination DC.
You can check for time skew using:
* DCDIAG /TEST:CheckSecurityError: As seen in Symptom 2, this test specifically checks for time skew and will report it if found.
* W32TM /MONITOR: This command displays the time synchronization status of domain controllers in the domain, showing their time source and offset from the PDC emulator.
Look for specific events and network trace details indicating time skew:
* LSASRV event ID 40960: On the destination domain controller, look for this event citing a GUID (often from the source DC’s CNAME record) and extended error 0xc000133. This extended error translates to “The time at the Primary Domain Controller is different than the time at the Backup Domain Controller or member server by too large an amount.”
* Network Trace (Kerberos): A network trace capturing the replication attempt might show a Kerberos TGS (Ticket Granting Service) request followed by a KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) response. TKE_NVV means “Ticket not yet valid,” indicating that the timestamp in the ticket is outside the acceptable window (usually in the future relative to the target server’s time).
Solution
To fix excessive time skew, ensure that all domain controllers are synchronizing time correctly.
Identify time source: Use W32TM /query /source on the affected domain controllers to determine their current time source. DCs should ideally synchronize time from their hierarchical parent in the Active Directory time hierarchy, culminating at the PDC emulator of the forest root domain (which should sync from an external reliable time source).
Correct time synchronization configuration: Configure domain controllers to follow the AD time hierarchy. The PDC emulator in child domains should sync from a DC in the parent domain. DCs within a domain should sync from a DC holding the PDC emulator role or another reliable DC.
Force time synchronization: Use w32tm /resync on the affected DCs to force immediate time synchronization. You may need to restart the Windows Time service (net stop w32time && net start w32time).
Verify time sync: After synchronization, use W32TM /monitor or w32tm /query /status to confirm that the time difference between the affected DCs and their time sources is within the Kerberos tolerance. Also, directly check the time difference between the source and destination DCs’ system clocks.
Retry replication: Once time is synchronized correctly across the necessary domain controllers, retry the replication operation.
Configuring time synchronization correctly in an Active Directory forest is detailed in Microsoft documentation regarding the Windows Time service (W32Time).
Cause 5: RestrictRemoteClients Setting Value is 2¶
The “Restrictions for Unauthenticated RPC clients” Group Policy setting controls whether unauthenticated RPC clients can connect to RPC servers on a computer. If this policy is enabled and set to “Authenticated without exceptions,” it configures the RestrictRemoteClients registry value to 0x2 under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC.
Setting RestrictRemoteClients to 2 strictly enforces that only authenticated RPC clients can connect. It disallows anonymous RPC calls. While this might enhance security for member servers, applying this setting to a domain controller severely disrupts normal Active Directory operations, including replication. Many internal DC-to-DC communications, even those that are eventually authenticated, involve initial RPC binding attempts that might be affected by this restriction. Domain controllers require the ability to accept authenticated RPC connections without such strict blanket restrictions.
Solution
The recommended solution is to disable this policy setting on domain controllers.
Disable the Group Policy: Locate the Group Policy setting “Restrictions for Unauthenticated RPC clients” under Computer Configuration\Administrative Templates\System\Remote Procedure Call. Set this policy to “Disabled.” This policy should typically be configured as “Not Configured” or “Disabled” for the Default Domain Controllers Policy.
Force Group Policy update: Run gpupdate /force on the affected domain controller to apply the policy change.
Remove the registry value: Even after disabling the policy, the RestrictRemoteClients registry value might persist. Open Registry Editor and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC. Delete the RestrictRemoteClients entry.
Restart the domain controller: A restart is necessary for the registry change and policy update to fully take effect.
Retry replication: After the domain controller restarts, attempt to replicate again.
Applying the “Restrictions for Unauthenticated RPC clients” policy with a value of 2 to domain controllers is a known misconfiguration that causes widespread communication issues, including replication failures with access denied errors.
Cause 6: “Access this computer from network” User Right Not Granted¶
Active Directory replication requires the initiating security context (typically the destination DC’s machine account or the user account manually triggering replication) to have the “Access this computer from network” user right on the source domain controller. This right is necessary for the client (destination DC) to establish a network connection to the server (source DC) using protocols like SMB or RPC, which are used during replication.
By default, the “Access this computer from network” user right is granted to several groups in the Default Domain Controllers Policy, which is linked to the Domain Controllers organizational unit (OU). These groups include:
* Administrators
* Authenticated Users
* Everyone
* Enterprise Domain Controllers
* Pre-Windows 2000 compatible Access
If Active Directory operations fail with error 5, verify the following:
Policy Configuration: Ensure the “Access this computer from network” user right is granted to the “Enterprise Domain Controllers” group (which contains all domain controllers) and “Authenticated Users” or “Everyone” in the Default Domain Controllers Policy or any policy applied to your domain controllers.
OU Placement: Confirm that the domain controller computer accounts are located in the default “Domain Controllers” OU or another OU to which the appropriate policy granting this right is linked.
Policy Application: Use gpresult /h report.html on the destination domain controller to verify that the Group Policy containing the correct “Access this computer from network” settings is being applied to the computer.
“Deny access this computer from network”: Check the “Deny access this computer from network” user right in applied Group Policies. Ensure that this setting does not explicitly deny access to the computer account of the destination DC or any group it is a member of (like “Enterprise Domain Controllers”). Deny settings override grant settings.
Policy Inheritance/Filtering: Investigate potential issues like blocked inheritance on the Domain Controllers OU, WMI filters applied to the policy, or security filtering that might prevent the policy from applying correctly to the affected DC.
Solution
Review and correct Group Policy configurations related to user rights on domain controllers.
Open Group Policy Management: Access Group Policy Management Console (GPMC).
Edit Default Domain Controllers Policy: Navigate to Forest\Domains\\Domain Controllers OU. Right-click the “Default Domain Controllers Policy” and select “Edit.”
Configure User Rights: Go to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
Ensure “Access this computer from network” is granted: Double-click “Access this computer from network.” Ensure that “Enterprise Domain Controllers” and “Authenticated Users” (or groups containing your DCs’ machine accounts) are listed. Add them if they are missing.
Check “Deny access this computer from network”: Double-click “Deny access this computer from network.” Ensure that no group listed here includes the domain controllers’ machine accounts or the user account used for manual replication.
Force policy update: Run gpupdate /force on the destination domain controller and potentially the source DC.
Verify policy application: Use gpresult again to confirm the policy is now applied correctly.
Retry replication: Attempt to replicate again.
Correct user rights assignment is fundamental for successful communication between domain controllers.
Server Message Block (SMB) signing is a security feature that helps prevent man-in-the-middle attacks by digitally signing SMB communications. There are policy settings to configure SMB signing for both the client (the machine initiating the connection) and the server (the machine being connected to). These settings can require signing or allow it if the other party agrees.
A mismatch in SMB signing configurations between the source and destination domain controllers can prevent them from establishing an SMB connection needed for certain aspects of replication or related operations. For instance, if one DC requires SMB signing, but the other has it disabled, the connection will fail.
The relevant policy settings and their registry equivalents are:
Policy Setting
Registry Path
Registry Value Name
Microsoft network client: Digitally sign communications (if server agrees)
Note: Internal testing has sometimes shown SMB signing mismatches resulting in error 1722 “The RPC Server is unavailable” instead of error 5. However, it’s a potential cause for communication failures that can lead to access denied issues in various scenarios.
Solution
Ensure consistent and compatible SMB signing settings between the source and destination domain controllers.
Review Policy Settings: Check the relevant Group Policies applied to the domain controllers. The settings are typically found under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
Check Registry Values: Examine the registry keys mentioned above on both the source and destination DCs to see the effective settings. Policy settings will override manual registry changes.
Ensure Compatibility:
If “Microsoft network server: Digitally sign communications (always)” is enabled on one DC, the other DC must have either “Microsoft network client: Digitally sign communications (always)” enabled OR “Microsoft network client: Digitally sign communications (if server agrees)” enabled AND “Microsoft network server: Digitally sign communications (if server agrees)” enabled.
A common and secure configuration is to enable “Microsoft network client: Digitally sign communications (always)” and “Microsoft network server: Digitally sign communications (always)” on all domain controllers via Group Policy. This ensures all required SMB communication is signed.
Force Policy Update and Restart: After making changes to Group Policy, force a policy update (gpupdate /force) and restart the affected domain controllers to ensure the new settings are fully applied.
Retry replication: Attempt to replicate again after the configuration is consistent.
Cause 8: UDP-Formatted Kerberos Packet Fragmentation¶
Kerberos tickets and DNS responses (especially with EDNS0) can sometimes be large. These are often sent over UDP. Network devices like routers, switches, or firewalls may have limits on the size of UDP packets they can handle before fragmentation or dropping. If UDP-formatted Kerberos packets used during replication or associated lookups are fragmented or dropped due to network limitations, the authentication process can fail, leading to an access denied error.
Solution
Test for UDP fragmentation issues and configure Windows to use TCP for Kerberos if necessary.
Test for Maximum Transmission Unit (MTU): From the console of the destination domain controller, use the ping command with the “Don’t Fragment” flag and varying packet sizes to test the network path’s MTU to the source domain controller. Ping the source DC by its fully qualified domain name (FQDN).
Start with a large packet size like 1472 bytes (1500 MTU - 28 bytes for IP/ICMP headers). Decrease the packet size until the ping is successful without fragmentation. The largest size that succeeds plus 28 bytes is the effective MTU.
Address Fragmentation: If the largest non-fragmented packet size found in step 1 is significantly less than 1472 bytes, it indicates network fragmentation issues.
Preferred: Modify the network infrastructure (routers, switches, firewalls) to correctly handle fragmented UDP packets or increase the MTU if possible. Consult network hardware documentation.
Alternative (Workaround): Configure the destination domain controller to limit the size of UDP packets it sends for Kerberos or force Kerberos to use TCP.
Set maxpacketsize: In the registry on the destination DC, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Create or modify a DWORD value named maxpacketsize. Set its value to the largest non-fragmented packet size found in the ping test, minus 8 bytes (to account for the Kerberos CRC). Restart the DC.
Force TCP: Set maxpacketsize to 1. This forces Kerberos clients to use TCP for tickets larger than 1 byte, effectively bypassing UDP fragmentation issues. Restart the DC.
Retry replication: After implementing a solution for fragmentation (network fix or maxpacketsize registry change), retry the failed Active Directory replication operation.
Setting maxpacketsize to 1 is a common workaround but fixing the underlying network fragmentation is the ideal solution.
Cause 9: Network Adapters Have the “Large Send Offload” Feature Enabled¶
“Large Send Offload” (LSO) is a feature on network adapters that offloads the task of segmenting large chunks of data into smaller packets to the network card hardware, instead of the operating system software. While this can improve network performance in some cases, it can also cause issues with certain network protocols or specific network drivers, potentially leading to packet corruption or drops that disrupt communications like Active Directory replication, manifesting as access denied errors.
Solution
Disabling Large Send Offload on the network adapter of the affected domain controller can resolve this issue.
Open Network Connections: On the destination domain controller, open Network Connections (ncpa.cpl).
Open Adapter Properties: Right-click the network adapter used for domain communication and select “Properties.”
Configure Adapter: Click the “Configure” button next to the adapter name.
Advanced Tab: Go to the “Advanced” tab in the adapter properties window.
Disable LSO: Look for properties named “Large Send Offload,” “IPv4 Large Send Offload,” “IPv6 Large Send Offload,” or similar. Disable these properties. The exact name may vary depending on the network adapter manufacturer and driver version.
Restart Domain Controller: Restart the domain controller for the change to take full effect on the network stack.
Retry Replication: After the restart, attempt the replication operation again.
If disabling LSO resolves the issue, consider updating the network adapter driver to see if a newer version fixes the compatibility problem and allows LSO to be re-enabled for performance benefits.
A Kerberos realm is essentially the administrative boundary for a Kerberos service. In Active Directory, the Kerberos realm name is synonymous with the Active Directory domain name (e.g., CONTOSO.COM). Kerberos authentication relies on correct realm information. An invalid Kerberos realm configuration on a domain controller can prevent it from correctly processing Kerberos tickets or authenticating against other domain controllers, leading to “Access is denied.”
Two specific registry conditions can indicate an invalid Kerberos realm configuration:
Incorrect KDCNames entry: The KDCNames registry entry, intended for mapping external Kerberos realms, incorrectly contains the local Active Directory domain name or another domain name from the same forest. KDCNames is only for trusts with non-Active Directory Kerberos realms.
PolAcDmN and PolPrDmN mismatch: The PolAcDmN and PolPrDmN registry keys store the domain name information used by the Local Security Authority (LSA). If these values are inconsistent or corrupted, it can lead to authentication failures. PolPrDmN stores the primary domain name, and PolAcDmN stores the account domain name.
Solutions
Correcting the registry values related to the Kerberos realm can fix this issue.
Solution to the Incorrect “KDCNames” Registry Entry¶
Open Registry Editor (regedit): Log on to the destination domain controller and open Registry Editor.
Navigate to Kerberos Domains: Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains.
Review KDCNames: Under the Domains key, you will see subkeys for each domain configured. For each subkey corresponding to your local Active Directory domain or other domains within your forest, examine the KdcNames entry. The KdcNames value should be empty or non-existent for domains within your AD forest. If it contains your local domain name or another in-forest domain name, delete that value. KdcNames is only relevant for explicitly configured trusts to external, non-AD Kerberos realms.
Restart DC: Restart the domain controller after making registry changes.
Solution to the Mismatched “PolAcDmN” and “PolPrDmN” Registry Keys¶
Correcting these values requires careful editing of the SECURITY hive in the registry.
Open Registry Editor: Start regedit.
Load the SECURITY hive: You need to access the SECURITY hive, which is not loaded by default.
Select HKEY_LOCAL_MACHINE.
Go to File > Load Hive…
Navigate to %SystemRoot%\System32\config and select the SECURITY file.
Provide a temporary Key Name (e.g., “SECHIVE”).
Grant Permissions: By default, administrators may not have full permissions on the loaded SECURITY hive.
Right-click the loaded hive (e.g., “SECHIVE”) and select “Permissions…”.
Add the local “Administrators” group and grant them “Full Control.” Ensure “Read” is also checked. Click “Apply” and “OK.”
Navigate to Policy Keys: Expand the loaded hive (e.g., “SECHIVE”) and navigate to Policy\PolPrDmN.
View Binary Data for PolPrDmN: In the right pane, select the (Default) entry (or the entry with “No Name: REG_NONE”). Go to View > Display Binary Data.
Observe Domain Name: In the Binary Data dialog, select the “Byte” format. On the right side of the dialog, you should see the NetBIOS domain name (e.g., “CONTOSO”) as a string. This is the value you need. Note it down precisely.
Navigate to PolAcDmN: Navigate to Policy\PolACDmN under the loaded hive.
Modify PolAcDmN: Double-click the (Default) entry (or the entry with “No Name: REG_NONE”).
Paste NetBIOS Domain Name: In the Binary Editor dialog, carefully paste or type the exact NetBIOS domain name you observed in step 6. The value is a REG_NONE type, so you are editing the raw binary data representation of the string.
Unload the hive: Select the loaded hive (e.g., “SECHIVE”) and go to File > Unload Hive. Confirm when prompted.
Restart the domain controller: Restart the domain controller.
Verify: After the restart, check if replication is successful. If the domain controller has other issues after this operation, further troubleshooting might be required (refer to Microsoft KB articles like 837513 if issues persist).
Cause 11: LAN Manager Compatibility (LM Compatibility) Mismatch¶
LM Compatibility level settings control which authentication protocols (LM, NTLM, NTLMv2) are used and whether plaintext passwords or hashed challenge/response are sent over the network. Mismatches in these settings between the source and destination domain controllers can prevent successful authentication during replication setup. While less common in modern environments configured with secure defaults, legacy or misconfigured LM Compatibility settings can still cause authentication failures and thus Access Denied errors.
Solution
Ensure that the LM Compatibility level settings are consistent and appropriately configured (ideally to use NTLMv2 only or higher, effectively disabling insecure LM and NTLM) via Group Policy under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, specifically the “Network security: LAN Manager authentication level” setting.
Cause 12: Service Principal Names (SPNs) Either Not Registered or Not Present¶
Service Principal Names (SPNs) are unique identifiers used by Kerberos to identify a service instance (like the LDAP service on a domain controller). Client computers use SPNs when requesting a service ticket for a service. Domain controllers register SPNs for their services (LDAP, KDC, etc.) in their own machine account object in Active Directory. Replication relies on proper SPN registration for the destination DC to obtain Kerberos tickets to authenticate to the source DC’s LDAP service.
If the required SPNs for a domain controller are missing, duplicated, or incorrect in Active Directory, the destination DC cannot obtain a valid Kerberos ticket to connect to the source DC. This leads to authentication failure and “Access is denied.” This can happen due to simple replication latency (if the source DC recently registered or updated its SPNs and the destination DC hasn’t replicated the change yet) or a persistent SPN registration issue.
The DCDIAG /TEST:CheckSecurityError command (as shown in the “More information” section’s sample output) explicitly checks for missing or duplicated SPNs on domain controller accounts.
Solution
Check for missing or duplicated SPNs and ensure they are correctly registered.
Check SPNs: Use Setspn -L <DC_Name> to list the registered SPNs for the source domain controller’s machine account. Compare this list against the expected SPNs for a domain controller (LDAP, HOST, GC SPNs with hostname and FQDN). Use Setspn -X to check for duplicate SPNs across the forest.
Register Missing SPNs: If SPNs are missing, register them manually using Setspn -A <SPN_type>/<name> <DC_Name>. Be cautious when manually adding SPNs. Incorrectly adding SPNs can cause other issues. Often, restarting the KDC service or the DC itself will trigger automatic registration of default SPNs.
Remove Duplicate SPNs: If duplicate SPNs are found using Setspn -X, delete the incorrect or outdated duplicate SPN using Setspn -D <duplicate_SPN> <offending_object_name>.
Ensure Replication: Ensure that the SPN changes have replicated throughout the domain and potentially the forest (for GC SPNs). Replication latency is a common reason for temporary SPN-related issues.
Retry Replication: Attempt replication after verifying and correcting SPNs and allowing for replication convergence.
Cause 13: Antivirus Software Uses a Mini-Firewall Network Adapter Filter Driver¶
Some antivirus or network security software installs filter drivers (like NDIS filters) that operate in the network stack. These drivers can sometimes interfere with low-level network communications required for Active Directory replication, effectively acting as a mini-firewall or inspection engine that blocks necessary RPC or other traffic between domain controllers. This interference can result in “Access is denied” errors.
Solution
Temporarily disabling or uninstalling antivirus software on the affected domain controllers is a common troubleshooting step to rule it out as the cause.
Disable Antivirus: On the destination domain controller (and potentially the source DC if troubleshooting indicates a problem there), temporarily disable the antivirus software and any associated firewall or network inspection components.
Test Replication: While the antivirus is disabled, attempt to run Active Directory replication.
Evaluate Results:
If replication succeeds with the antivirus disabled, the antivirus software or its configuration is the likely cause. Re-enable the antivirus and try to configure exceptions for Active Directory replication ports and processes (dsrs.exe, services.exe hosting NTDS, etc.) or consult the antivirus vendor’s documentation for compatibility with domain controllers.
If replication still fails with the antivirus disabled, the antivirus is not the cause, and you should re-enable it and continue troubleshooting other causes.
Consider Uninstallation: If configuration changes within the antivirus software do not resolve the issue, you may need to temporarily uninstall it for testing. If uninstallation resolves the error, work with the antivirus vendor to find a compatible version or configuration.
Always re-enable security software after testing, finding a permanent solution, or concluding it is not the cause.
It’s important to distinguish Active Directory replication error 5 (“Access is denied”) from error 8453 (“Replication Access was denied”). Although the error strings sound similar, they often indicate different underlying causes. Error 8453 specifically points to issues related to the “Replicating Directory Changes” permission, which is a distinct access control entry (ACE) on directory partitions.
Situations that commonly cause Active Directory replication to fail with error 8453 (“Replication Access was denied”) but not typically error 5 (“Access is denied”) include:
Missing “Replicating Directory Changes” permission: The security principal initiating replication (the destination DC’s machine account or a user account) is not granted the “Replicating Directory Changes” permission on the specific naming context (directory partition) being replicated.
Incorrect group membership: The security principal is not a member of a group (like “Enterprise Domain Controllers” or “Administrators”) that is granted the “Replicating Directory Changes” permission.
Missing UserAccountControl flags: Essential flags like SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION are missing from the UserAccountControl attribute of the domain controller’s machine account object. These flags are crucial for a DC’s proper function and authentication.
RODC ADPREP not run: A Read-Only Domain Controller (RODC) was deployed into a domain without first running ADPREP /RODCPREP. This step prepares the forest schema and configuration for RODCs by setting the necessary permissions for RODC replication.
These conditions are specific permission or configuration issues on the directory objects themselves or required preparation steps, distinct from the lower-level authentication and network access issues typically indicated by error 5.
Sample Output from “DCDIAG /TEST:CheckSecurityError”¶
As mentioned earlier, this command is invaluable for diagnosing security-related replication issues. Here are sample outputs demonstrating how it highlights time skew and missing SPNs.
Sample output showing excessive time skew:
Doing primary testsTesting server: <Site_Name>\<Destination_DC_Name>Starting test: CheckSecurityErrorSource DC <Source DC> has possible security error (5). Diagnosing...Time skew error between client and 1 DCs! ERROR_ACCESS_DENIED or down machine recieved by:<Source DC>Source DC <Source DC>_has possible security error (5). Diagnosing...Time skew error: 7205 seconds different between:.<Source DC><Destination_DC>[<Source DC>] DsBindWithSpnEx() failed with error 5,Access is denied..Ignoring DC <Source DC> in the convergence test of object CN=<Destination_DC>,OU=Domain Controllers,DC=<DomainName>,DC=com, because we cannot connect!......................... <Destination_DC> failed test CheckSecurityError
This output clearly identifies the time skew difference (7205 seconds) and relates it to the DsBindWithSpnEx failure with error 5.
Sample output showing missing SPN names:
Doing primary testsTesting server: <site name>\<dc name>Test omitted by user request: AdvertisingStarting test: CheckSecurityError* Dr Auth: Beginning security errors check'Found KDC <KDC DC> for domain <DNS Name of AD domain> in site <site name>Checking machine account for DC <DC name> on DC <DC Name>* Missing SPN :LDAP/<hostname>.<DNS domain name>/<DNS domain name>* Missing SPN :LDAP/<hostname>.<DNS domain name>* Missing SPN :LDAP/<hostname>* Missing SPN :LDAP/<hostname>.<DNS domain name>/<NetBIOS domain name>* Missing SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>* SPN found :E3514235-4B06-I1D1-AB�4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root domain DNS name>* Missing SPN :HOST/<hostname>.<DNS domain name>/<DNS domain name>* SPN found :HOST/<hostname>.<DNS domain name>* SPN found :HOST/<hostname>* Missing SPN :HOST/<hostname>.<DNS domain name>/<NetBIOS domain name>* Missing SPN :GC/<hostname>.<DNS domain name>/<DNS domain name>Unable to verify the machine account (<DN path for Dc machine account>) for <DC Name> on <DC name>.
This output lists specific SPNs that are expected for a domain controller but were not found on the machine account object, indicating a potential SPN registration issue.
Troubleshooting Active Directory replication error 5 requires a systematic approach, checking for issues related to secure channels, time synchronization, trust relationships, required user rights, and network communication settings like SMB signing and packet handling. Using diagnostic tools like DCDIAG and REPADMIN is essential in identifying the specific cause among the many possibilities.
Have you encountered Active Directory replication error 5 in your environment? Which of these causes was responsible, and how did you resolve it? Share your experiences and tips in the comments below!
Post a Comment