Replication error 8453 Replication access was denied

  • Article

Updated: March 1, 2012

Applies To: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2

This topic explains symptoms, causes and how to resolve Active Directory replication error 8453 Replication access was denied.

  • Symptoms

  • Causes

  • Resolutions

Symptoms

  1. 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

  2. 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 
Replication Synchronization 
Manage Replication Topology 
Replicating Directory Changes In Filtered Set 
access rights for the naming context: 
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

Note

The list of missing access rights required for each security group could vary depending on your environment.

  1. 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

  2. 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/2010 07:45:07
Event String:
A client made a DirSync LDAP request for a directory partition. Access was denied due to the following error. 
Directory partition: 
<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.

  3. 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:

    • REPADMIN /KCC

    • REPADMIN /REHOST

    • REPADMIN /REPLICATE

    • REPADMIN /REPLSUM
    • REPADMIN /SHOWREPL

    • REPADMIN /SHOWREPS

    • REPADMIN /SHOWUTDVEC

    • REPADMIN /SYNCALL

    Sample output from "REPADMIN /SHOWREPS" depicting inbound replication from CONTOSO-DC2 to CONTOSO-DC1 failing with the "replication access was denied" error is shown below:

    Default-First-Site-Name\CONTOSO-DC1
DSA Options: IS_GC 
Site Options: (none)
DSA object GUID: b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01
==== INBOUND NEIGHBORS ======================================
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>.

  4. 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

  5. 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:

    Event ID Event Source Event String

    1699

    Microsoft-Windows-ActiveDirectory_DomainService

    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.

    2896

    Microsoft-Windows-ActiveDirectory_DomainService

    A client made a DirSync LDAP request for a directory partition. Access was denied due to the following error.

    1655

    NTDS General

    Active Directory attempted to communicate with the following global catalog and the attempts were unsuccessful.

    1265

    NTDS KCC

    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:

    1925

    NTDS KCC

    The attempt to establish a replication link for the following writable directory partition failed.

Causes

The status 8453: "Replication Access was denied" has multiple root causes including:

  1. The UserAccountControl attribute on the destination domain controller computer account is missing either the SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION flags.

  2. The default permissions do not exist on one or more directory partitions to allow scheduled replication to occur in the operating system's security context.

  3. 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 similar commands.

  4. The permissions needed to trigger ad-hoc replication is correctly defined on the relevant directory partitions but the user is *NOT* a member any security groups that have been granted the replication directory changes permission.

  5. 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 and Windows Server 2008.

Note

Do not confuse the User Account Control split token security feature introduced in Windows Vista and Windows Server 2008 with the UserAccountControl attribute defined on DC role computer accounts stored in Active Directory.

  1. RODCPREP has not been run in domains currently hosting read-only domain controllers.

  2. 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 topic 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 that 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 intradomain trusts

  • CrashOnAuditFail = 2 in the Registry

Resolutions

  1. Perform a health-check with DCDIAG + DCDIAG /test:CheckSecurityError

    1. Run DCDIAG on the "destination DC" reporting the 8453 error or event.

    2. Run DCDIAG on the "source DC" that the DC reporting the 8453 error or event is "pulling from."

    3. Run DCDIAG /test:CheckSecurityError on the "destination DC" reporting the 8453 error or event.

    4. Run DCDIAG /test:CheckSecurityError on the "source DC" that the DC reporting the 8453 error or event is "pulling from."

  2. 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:

    Property flag Hex value Decimal Value

    SERVER_TRUST_ACCOUNT

    0x2000

    8192

    TRUSTED_FOR_DELEGATION

    0x80000

    524288

    UserAccountControl Value

    0x82000

    532480

    The typical UserAccountControl attribute value for a read-only domain controller computer account is 83890176 decimal or 5001000 hex:

    Property flag Hex value Decimal Value

    WORKSTATION_TRUST_ACCOUNT

    0x1000

    4096

    TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION

    0x1000000

    16777216

    PARTIAL_SECRETS_ACCOUNT

    0X4000000

    67108864

    Typical UserAccountControl Value for RODC

    0x5001000

    83890176

    1. 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.

      To add the SERVER_TRUST_ACCOUNT flag to the UserAccountControl attribute

      1. Start ADSIEDIT.MSC on the console of DC missing the SERVER_TRUST_ACCOUNT reported by DCDIAG.

      2. Right-click ADSI Edit in the top left pane of ADSIEDIT.MSC and chose Connect to....

      3. Within the Connection Settings dialog:

        • Click Select a well known Naming Context and chose Default naming context (that is, the computer account’s domain partition).

        • Click Default (Domain or server that you are logged on to).

        • Click OK.

        <<Insert ADDS_ADSIEditConnectionSettings>>

      4. In the domain naming context, locate and then right-click the domain controller computer account and chose Properties.

      5. Double-click the userAccountControl attribute and record its decimal value.

      6. Start the Windows calculator in Scientific (Windows 2000 or Windows Server 2003) or Programmer mode (Windows Server 2008 and later) and enter the decimal value for userAccountControl.

      7. Convert the decimal value to its hexadecimal equivalent.

      8. Add 0x80000 to the existing value and press "=".

      9. Convert the new calculated userAccountControl value to its decimal equivalent.

      10. Type the new decimal value from the Windows calculator in the userAccountControl attribute in ADSIEDIT.MSC. Click OK twice to save.

    2. 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.

      To add the TRUSTED _FOR_DELEGATION flag to the userAccountControl attribute

      1. Start Active Directory Users and Computers (DSA.MSC) on the console of the DC tested by DCDIAG.

      2. Right-click the DC computer account, and then click Properties.

      3. Click the Delegation tab.

      4. Click Trust this computer for delegation to any service (Kerberos only), and click OK.

        <<insert ADDS_DCDelegationTab>>

  3. 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 (groups that the user is direct 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.

    More information about default directory partitions is available at Default Security of the Configuration Directory Partition.

    1. 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 Admins group, focus on NC head permissions granted to the Enterprise Admins group.

      • If ad-hoc replication is failing for members of a Domain Admins 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 Read-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 operating system version:

      DACL required on each directory partition Windows 2000 Windows Server 2003 Windows Server 2008 and later

      Manage Replication Topology

      X

      X

      X

      Replicating Directory Changes

      X

      X

      X

      Replication Synchronization

      X

      X

      X

      Replicating Directory Changes All

      X

      X

      Replicating Changes in Filter Set

      X

Note

The DCDIAG NcSecDesc test may report false positive errors when run in environments with mixed operating system 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\>”.  
      
    
        C:\>dsacls dc=contoso,dc=com
    
    The command can be targeted to a remote domain controller using the syntax:  
      
    
        c:\>dsacls \\contoso-dc2\dc=contoso,dc=com
    
    Be wary of "DENY" permission on NC heads removing the permissions for groups that the failing user is a direct or nested member of.  
      

2.  Add required permissions that are missing  
      
    Use the Active Directory ACL editor in ADSIEDIT.MSC to add the missing DACLS.  
      
    ACLS can be "restored" to their default settings using the "DSACLS \<DN path of directory partition\> /S /T" command.

  1. 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 cannot initiate ad-hoc replication between DCs in the same domain or different domain.

    There are two solutions to this problem:

    1. Add users to existing groups that have already been the granted the required permissions to replicate directory partitions (Domain Admins groups for replication in the same domain or the Enterprise Admins group to trigger ad-hoc replication between different domains).

      -Or-

    2. Create your own group, grant that group the required permissions on directory partitions throughout the forest, and 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.

      Related content:

      MSKB article 303305: "Access Denied" Error Message When You Use the Active Directory Sites and Services Tool

      Best Practices for delegating Active Directory

  2. 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.

    1. Log on with the user account where ad-hoc replication is failing with "replication access was denied.”

    2. 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 again and retry the "whoami /all" command.

      If "WHOAMI /ALL" still does not show membership in the expected security groups, launch an elevated CMD prompt (right-click Command Prompt and click Run as Administrator) on the local machine and run the "WHOAMI /ALL" from inside the elevated CMD prompt.

      If the group membership is different between the WHOAMI /ALL output generated by elevated and non-elevated CMD prompts, refer to MSKB 976063.

    3. 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 a tested 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 Admins and Enterprise Admins groups were removed from the Built-in Administrators groups.

  3. RODC Replication

    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.

  4. Office Communication Server

    If you notice AD operations failing with 8453 "replication access was denied", in an existing forest running either Office Communication Server 2005 or Office Communication Server 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

See Also

Other Resources

Troubleshooting Active Directory operations that fail with error 8453: "Replication access was denied."