Error 8453 replication access denied: repairing AD replication permissions

Fix it now

Error 8453 is published as “Replication access was denied”. Microsoft’s own troubleshooting for it has two main branches, and only one of them is about permissions: the other is an invalid UserAccountControl on the domain controller’s computer account. Run the health checks before you touch an access control list.

dcdiag /test:CheckSecurityError
dcdiag /test:NCSecDesc
dcdiag /test:MachineAccount
whoami /all

1. Read the MachineAccount result first. If it reports a missing SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION flag, the DC’s own computer account is wrong and no permission change will help.
2. For a writeable DC the documented UserAccountControl value is 532480 decimal, 0x82000 hex; for an RODC it is 83890176 decimal, 0x5001000 hex. The two flags are SERVER_TRUST_ACCOUNT (0x2000) and TRUSTED_FOR_DELEGATION (0x80000).
3. Set delegation the supported way where you can: in Active Directory Users and Computers, open the DC’s computer account, Delegation tab, and select “Trust this computer for delegation to any service (Kerberos only)”.
4. If NCSecDesc reports missing permissions on the naming context head, inspect them with dsacls <naming context DN>, or dsacls \\<dc>\<naming context DN> for a remote one.
5. If you are running replication as a person rather than as the DC, check your own groups with whoami /all, and compare an elevated prompt against a non-elevated one.

Compare the failing partition’s permissions against one that replicates normally before adding anything. You are looking for a difference, not for a list you half remember.

If replication runs, stop here. If it does not, the next section covers what is being denied and by which of the two mechanisms.

Why it happens

Directory replication is an authenticated remote procedure call. The destination binds to the source, proves who it is, and asks for the changes it has not seen. Error 8453 is published as “Replication access was denied”, and Microsoft’s troubleshooting for it lists causes on both sides of that sentence: what the destination is allowed to ask for, and whether the destination is recognised as a domain controller at all.

The half most articles skip is the second one. A domain controller’s own computer account carries flags in its UserAccountControl attribute, and if SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION is missing, the machine is not being treated as a domain controller. Microsoft publishes the expected values: 532480 decimal, 0x82000 hex, for a writeable DC, and 83890176 decimal, 0x5001000 hex, for a read-only one. The dcdiag test that reports it is MachineAccount, and it takes seconds to run.

The permission half is a set of control access rights held on the head of each naming context. Microsoft names five that must be present: Manage Replication Topology, Replicating Directory Changes, Replication Synchronization, Replicating Directory Changes All, and Replicating Changes in Filter Set. The groups that must hold them are Enterprise Domain Controllers, the domain’s own Domain Controllers group, and, where read-only DCs exist anywhere in the forest, Enterprise Read-Only Domain Controllers. An article that names only Enterprise Domain Controllers and only two of the rights will get you close and leave you failing.

Full reference

The dcdiag tests Microsoft names for this error

The five rights, and who has to hold them

Grant to these groups, not to individual controllers. Group membership is maintained automatically as controllers are promoted and demoted; individual entries rot the first time the topology changes and leave a trap for whoever is on call.

The UserAccountControl values, written out

If you have to correct this by hand, Microsoft’s documented method is to read the current decimal value in ADSI Edit, convert it to hex in Calculator’s programmer mode, add the missing flag, convert back, and write the decimal result. The supported alternative for the delegation flag alone is the Delegation tab in Active Directory Users and Computers, which is less error-prone and worth preferring.

The neighbouring codes, and what each one takes you to

Two more events worth recognising

• Event ID 1699: this directory service failed to retrieve the changes requested for the following directory partition. It names the partner and the partition, which saves you reading a whole replication summary.
• Event ID 2896: a client made a DirSync LDAP request for a directory partition and access was denied. Microsoft lists it among the symptoms of 8453, and it points at an application doing directory synchronisation rather than at DC-to-DC replication.
• Microsoft also lists Event IDs 1655, 1265 and 1925 among the symptoms, so a DC reporting several of these at once is telling one story rather than several.

Where this article deliberately does not go

Two remedies circulate for 8453 that are not in Microsoft’s cause or resolution list for it: resetting the DC’s own computer account password with the Key Distribution Center service stopped, and chasing user rights assignments in a hardening baseline. The first is a real procedure for a different problem and it is disruptive; the second belongs to error 5. If the checks above all pass and you are still getting 8453, that is the point to collect the dcdiag output and open a case, rather than to start resetting machine account passwords on live controllers.

Every code this article covers

Confirm the fix worked

1. dcdiag /test:CheckSecurityError passes on both the destination and the source.
2. dcdiag /test:MachineAccount reports no missing SERVER_TRUST_ACCOUNT or TRUSTED_FOR_DELEGATION flag.
3. dcdiag /test:NCSecDesc reports no missing permissions on any naming context head.
4. repadmin /replsummary shows no partner with a failure or a stale last-success time.
5. Create a test object on one controller and confirm it appears on the previously failing one within the expected interval.

Questions people ask about this