This article describes the symptoms, cause, and resolution steps for situations where Active Directory operations fail with error 8453: Replication access was denied.
The DCDIAG Replication test (DCDIAG /TEST:NCSecDesc) reports that the tested DC "failed test Replications" with status 8453: Replication access was denied.
Starting test: Replications [Replications Check,<destination DC] A recent replication attempt failed: From <source DC> to <Destination DC Naming Context: <DN path of failing directory partition> The replication generated an error(8453): Replication access was denied. The failure occurred at <date> <time>. The last success occurred at <date> <time>. %#% failures have occurred since the last success. The machine account for the destination <destination DC>. is not configured properly. Check the userAccountControl field. Kerberos Error. The machine account is not present, or does not match on the. destination, source or KDC servers. Verify domain partition of KDC is in sync with rest of enterprise. The tool repadmin/syncall can be used for this purpose. ......................... <DC tested by DCDIAG> failed test Replications
The DCDIAG NCSecDesc test (DCDIAG /TEST:NCSecDes) reports that the DC tested by DCDIAG "failed test NCSecDec" and that one or more permissions are missing on the NC head of one or more directory partitions on the tested DC tested by DCDIAG:
Starting test: NCSecDesc
Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes <- List of missing access Replication Synchronization <- rights required for eachManage Replication Topology <- security group could vary Replicating Directory Changes In Filtered Set <- depending in missing access rights for the naming context: <- right in your environment DC=contoso,DC=com Error CONTOSO\Domain Controllers doesn't have Replicating Directory Changes All access rights for the naming context: DC=contoso,DC=com Error CONTOSO\Enterprise Read-only Domain Controllers doesn't have Replicating Directory Changes access rights for the naming context: DC=contoso,DC=com ......................... CONTOSO-DC2 failed test NCSecDesc
The DCDIAG MachineAccount test (DCDIAG /TEST:MachineAccount) reports that the DC tested by DCDIAG "failed test MachineAccount" because the UserAccountControl attribute on the DCs computer account is missing the SERVER_TRUST_ACCOUNT" OR "TRUSTED_FOR_DELEGATION" flags:
Starting test: MachineAccount The account CONTOSO-DC2 is not trusted for delegation.It cannot replicate. The account CONTOSO-DC2 is not a DC account.It cannot replicate. Warning:Attribute userAccountControl of CONTOSO-DC2 is: 0x288 = ( HOMEDIR_REQUIRED | ENCRYPTED_TEXT_PASSWORD_ALLOWED | NORMAL_ACCOUNT ) Typical setting for a DC is 0x82000 = ( SERVER_TRUST_ACCOUNT | TRUSTED_FOR_DELEGATION ) This may be affecting replication? ......................... CONTOSO-DC2 failed test MachineAccount
The DCDIAG KCC Event log test cites the hexadecimal equivalent of Microsoft-Windows-ActiveDirectory_DomainService event 2896
B50 hex = 2896 decimal. This error may be logged every 60 seconds on the infrastructure master domain controller.
Starting test: KccEvent * The KCC Event log test An error event occurred.EventID: 0xC0000B50 Time Generated: 06/25/201007:45:07 Event String: A client made a DirSync LDAP request for a directory partition. Access was denied due to the following error.
<DN path of directory partition> Error value: 8453 Replication access was denied.
User Action The client may not have access for this request.If the client requires it, they should be assigned the control access right "Replicating Directory Changes" on the directory partition in question.
REPADMIN.EXE reports that replication attempt has failed with status 8453.
REPADMIN commands that commonly cite the 8453 status include but are not limited to:
DC=contoso,DC=com Default-First-Site-Name\CONTOSO-DC2 via RPC DSA object GUID: 74fbe06c-932c-46b5-831b-af9e31f496b2 Last attempt @ <date> <time> failed, result 8453 (0x2105): Replication access was denied. <#> consecutive failure(s). Last success @ <date> <time>.
The "replicate now" command in Active Directory Sites and Services returns "Replication access was denied."
Right-clicking on the connection object from a source DC and choosing "replicate now" fails with "Replication access was denied. The on-screen error message is shown below:
Dialog title text: Replicate Now Dialog message text: The following error occurred during the attempt to synchronize naming context <%directory partition name%> from Domain Controller <Source DC> to Domain Controller <Destination DC>: Replication access was denied
The operation will not continue Buttons in Dialog: OK
NTDS KCC, NTDS General or Microsoft-Windows-ActiveDirectory_DomainService events with the 8453 status are logged in the directory service event log.
Active Directory events that commonly cite the 8453 status include but are not limited to:
This directory service failed to retrieve the changes requested for the following directory partition. As a result, it was unable to send change requests to the directory service at the following network address.
A client made a DirSync LDAP request for a directory partition. Access was denied due to the following error.
Active Directory attempted to communicate with the following global catalog and the attempts were unsuccessful.
The attempt to establish a replication link with parameters Partition: <partition DN path> Source DSA DN: <DN of source DC NTDS Settings object> Source DSA Address: <source DCs fully qualified CNAME> Inter-site Transport (if any): <dn path> failed with the following status:
The attempt to establish a replication link for the following writable directory partition failed.
The status 8453: "Replication Access was denied" has multiple root causes including:
The UserAccountControl attribute on the destination domain controller computer account is missing either the SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION flags.
The default permissions do not exist on the one or more directory partitions to allow scheduled replication to occur in the operating system's security context.
The default or custom permissions do not exist on one or more directory partitions to allow users triggering ad-hoc or immediate replication using DSSITE.MSC -> "replicate now", "repadmin /replicate", "repadmin /syncall" or like commands.
The permissions needed to trigger ad-hoc replication is correctly defined on the relevant directory partitions but the user is *NOT* a member of any security groups that have been granted the replication directory changes permission.
The user triggering ad-hoc replication *IS* a member of the required security groups AND those security groups have been granted the "replicating directory changes" permission but membership in the group granting the "replicating directory changes" permission has been removed from the users security token by the "User Account Control" (split user access token) feature introduced in Windows Vista / Windows Server 2008.
Note: Do not confuse the "User Account Control" split token security feature introduced in Vista / Windows Server 2008 with the UserAccountControl attribute defined on DC role computer accounts stored in Active Directory.
If the destination DC is an RODC, RODCPREP has not been run in domains currently hosting read-only domain controllers or the Enterprise Read-Only Domain Controllers group does not have Replicate Directory Changes permissions for the partition that is failing to replicate.
DCs running new operating system versions have been added to an existing forest where Office Communication Server has been installed.
Active Directory errors and events like those cited in the symptoms section of this KB can also fail with error 5: "Access is denied".
Applying the resolution steps for error 5: "access is denied" listed below WILL NOT resolve replication failures on computers are currently failing replication with error status 8453: and vice versa. Common root causes for Active Directory operations failing with error 5: "access is denied" include:
Excessive Time Skew
The fragmentation of UDP-formatted Kerberos packets by intermediate devices on the network
Missing "access this computer from network" rights.
Broken secure channels or intra-domain trusts
CrashOnAuditFail = 2 in the Registry.
Perform a health-check with DCDIAG + DCDIAG /test:CheckSecurityError
Run DCDIAG on the "destination DC" reporting the 8453 error or event
Run DCDIAG on the "source DC" that the DC reporting the 8453 error or event is "pulling from"
Run DCDIAG /test:CheckSecurityError on the "destination DC" reporting the 8453 error or event
Run DCDIAG /test:CheckSecurityError on the "source DC" that the DC reporting the 8453 error or event is "pulling from".
Fix Invalid UserAccountControl
The UserAccountControl attribute consists of a bitmask that defines the capabilities and the state of a user or computer account. More information on UserAccountControl flags can be found in MSKB 305144 and MSDN.
The typical UserAccountControl attribute value for a writable ("full") domain controller computer account is 532480 decimal or 82000 hex. UserAccountControl values for a domain controller computer account may vary but must contain the SERVER_TRUST_ACCOUNT and TRUSTED_FOR_DELEGATION flags shown in the table below:
The typical UserAccountControl attribute value for a read-only domain controller computer account is 83890176 decimal or 5001000 hex
Typical UserAccountControl Value for RODC
The UserAccountControl attribute on the destination DC is missing the SERVER_TRUST_ACCOUNT flag
If the DCDIAG MachineAccount test fails with "failed test MachineAcccount" AND the UserAccountControl attribute on the tested DC is missing the SERVER_TRUST_ACCOUNT flag, add the missing flag in the tested DCs copy of Active Directory
Start ADSIEDIT.MSC on the console of DC missing the SERVER_TRUST_ACCOUNT reported by DCDIAG Right click "ADSIEDIT" in the top left pane of ADSIEDIT.MSC and chose "connect to..." Within the Connection Settings dialog, Click "Select a well known naming context" and chose "Default naming context" (i.e. the computer accounts domain partition) Click "Select or type a domain or server...", and chose the name of the DC failing in DCDIAG Click "OK" In the domain naming context, locate then right click on the domain controller computer account and chose "Properties" Double click on the "UserAccountControl attribute and record its decimal value Start the Windows calculator in scientific ( Windows 2000 / Windows Server 2003) or programmer mode (Windows Server 2008 and later) and enter the decimal value for UserAccountControl Convert the decimal value to its hexadecimal equivalent. Add 0x80000 to the existing value and press "=" Convert the new calculated UserAccountContorl value to its decimal equivalent Enter the new decimal value from the Windows calculator to the UserAccountControl attribute in ADSIEDIT.MSC. Click OK twice to save.
The UserAccountControl attribute on the destination DC is missing the TRUSTED_FOR_DELEGATION flag
If the DCDIAG MachineAccount test fails with "failed test MachineAcccount" AND the UserAccountControl attribute on the tested DC is missing the TRUSTED _FOR_DELEGATION flag, add the missing flag in the tested DCs copy of Active Directory
Start Active Directory Users and Computers (DSA.MSC) on the console of the DC tested by DCDIAG. Right click on the DC computer account Click on the Delegation tab Enable the "Trusted for delegation right" on the DC machine account.
Fix Invalid Default Security Descriptors
Active Directory operations take place in the security context of the account that initiated the operation. Default permissions on Active Directory partitions allow
Members of the Enterprise Administrators group to initiate ad-hoc replication between any DC in any domain in the same forest
Members of the Built-in Administrators group to initiate ad-hoc replication between domain controllers in the same domain
Domain Controllers in the same forest to initiate replication using either change notification or replication schedule.
Default permissions on Active Directory partitions do not allow the following by default and, by design, will fail until default permissions or group memberships are modified:
Members of the Built-in Administrators group in one domain cannot initiate ad-hoc replication to DCs in that domain from DCs in different domains.
Users that are NOT members of the Built-in administrators group cannot initiate ad-hoc replication from any other DC in the same domain or forest.
Permissions are defined on the top of each directory partition (called a naming context or "NC" head) and inherited throughout the partition tree. Verify that explicit (groups that the user is directory a member of) and implicit groups (those that explicit groups have nested membership of) have the required permissions and that Deny permissions assigned to implicit or explicit groups are not trumping the required permissions.
Verify that default permissions exist in the "top" of each directory partition that is failing with the "replication access was denied" error.
If ad-hoc replication is failing between DCs in different domains, or between DCs in the same domain for non-domain administrators, see the "Grant non-domain admins permissions..." section below.
If ad-hoc replication for member of the Enterprise Administrators group, focus on NC head permissions granted to the Enterprise Administrators group.
If ad-hoc replication is failing for members of a domains domain administrators group, focus on permissions granted to the built-in Administrators security group.
If scheduled replication initiated by domain controllers in a forest are failing with 8453, focus on permissions for the Enterprise Domain Controllers and Enterprise Red-Only Domain Controllers security groups.
If scheduled replication initiated by domain controllers on a read-only domain controller (RODC) is failing with error 8453, verify that the enterprise read only domain controllers security group has been granted the required access on the NC head of each directory partition.
The table below shows the default permission defined on the schema, configuration, domain and DNS applications by OS version:
DACL required on each directory partition
Windows Server 2003 and 2003 R2
Windows Server 2008 and later
Manage Replication Topology
Replicating Directory Changes
Replicating Directory Changes All
Replicating Changes in Filter Set
Note: The DCDIAG NcSecDesc test may report false positive errors when run in environments with mixed OS versions as documented in MSKB 829306
The DSACLS command can be used to dump the permissions on a given directory partition using the syntax "DSACLS <DN path of directory partition.
The command can be targeted to a remote DC using the syntax
Be wary of "DENY" permission on NC heads removing the permissions for groups that the failing user is a direct or nested member of.
Add required permissions that are missing
Use the Active Directory ACL editor in ADSIEDIT.MSC to add the missing DACLS
Grant non-domain admins permissions to replicate between DCs in the same domain or non-enterprise administrators to replicate between DCs in different domains
Default permissions on Active Directory partitions do not allow the following and will fail until permissions on directory partitions are modified:
Members of the Built-in Administrators group in one domain cannot initiate ad-hoc replication from DCs in different domains.
Users that are NOT members of the built-in domain admins group to initiate ad-hoc replication between DCs in the same domain or different domain.
There are two solutions to this problem:
Add users to existing groups that have already been the granted the required permissions to replicate directory partitions (Domain administrators for replication in the same domain or the Enterprise Administrators group to trigger ad-hoc replication between different domains)
Create your own group, grant that group the required permissions on directory partitions throughout the forest, then add users to those groups.
MSKB 303972 describes the process of creating a security group, adding the required members to those groups, then granting the group the required DACLS on Active Directory partitions. Grant the security group in question the same permissions listed in the table of the "Fix Invalid Default Security Descriptors" section this article.
Verify group membership in the required security groups
Once the right security groups have been granted the required permissions on directory partitions, the last remaining task is to verify that users initiating replication have effective membership in direct or nested security groups being granted replication permissions.
Log on with the user account where ad-hoc replication is failing with "replication access was denied"
From a CMD prompt type "WHOAMI /ALL" and verify membership in the security groups that have been granted the "replicating directory changes" permissions on the relevant directory partitions.
If the user was added to the permissioned group modified after the last user logon, log on a 2nd time and retry "whoami /all:
If "WHOAMI /ALL" still does not show membership in the expected security groups, launch an admin privileged CMD prompt on the local machine and run the "WHOAMI /ALL" from inside the privileged CMD prompt.
If the group membership is different between the WHOAMI /ALL output generated by privileged and non-privileged CMD prompts, refer to MSKB 976063
Verify that the expected nested group memberships exist.
If a user is obtaining the permissions to perform ad-hoc replication by being a member of nested group that is a member of group that has been directly granted replication permissions, verify the nested group membership chain. For example, Microsoft CSS has seen ad-hoc AD Replication fail because "domain administrators and enterprise administrators groups" were removed from the built-in administrators groups.
If computer initiated replication is failing on RODCs, verify that you have run ADPREP /RODCPREP as specified in MSKB 967482 AND that the Enterprise Read-only domain controllers group has been granted "replicate directory changes" right on each NC head.
Office Communication Server
If you notice AD operations failing with 8453 "replication access was denied", in an existing forest running either OCS 2005 or OCS 2007 immediately after the promotion of, or upgrade to Windows Server 2008 or Windows Server 2008 R2 domain controllers, see MSKB articles:
982020: Office Communications Server 2007 R2, OCS 2007 or LCS 2005 does not work correctly after you upgrade to Windows Server 2008 R2 982021: Supportability is available for Office Communications Server 2007 R2 member server role on a Windows Server 2008 R2 operating system
Номер статьи: 2022387 — последний просмотр: 06/18/2012 11:58:00 — редакция: 22.0
Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Microsoft Windows Server 2003, Standard x64 Edition
Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)
Microsoft Windows Server 2003 R2 Standard x64 Edition