This issue typically indicates a Kerberos authentication problem, although there are several exceptions. To resolve the replication failure in this case, resolve the authentication failure before you try to fix the replication problem. To resolve this issue:
1. Make sure the Access this computer from network user right in the source server's security policy includes the appropriate groups. To do this, check the <computername>_userrights.txt file in the Directory Services MPSReports to confirm which groups are listed. Everyone, Authenticated Users, and Enterprise Domain Controllers must have that user right for successful replication.
2. Make sure the Kerberos Key Distribution Center (KDC) service is started.
3. Make sure the Trust computer for delegation check box is selected on the General tab of the domain controller Properties dialog box in Active Directory Users and Computers.
4. Using Adsiedit or Ldp (both included in the Windows 2000 Support Tools), confirm that the userAccountControl attribute is set to 532480. To check this, perform the following steps:
- Type adsiedit.msc from Start, Run.
- Expand the Domain NC container.
- Expand the object below, i.e. DC=Contoso, DC=COM.
- Expand OU=Domain Controllers.
- Right-click CN=<domain_controller>, and select Properties.
- Under Select a property to view, select userAccountControl and verify the value is 532480.
5. If the problem exists between domain controllers from different domains, check the trust relationship by doing the following:
- Open Active Directory Domains and Trusts.
- Right-click the desired domain and select Properties.
- Click the Trusts tab.
- Highlight the domain to verify and click Edit.
- Click Verify.
The Netdom tool included in the Windows 2000 Support Tools can also be used to verify the trust.
netdom trust <trusting_domain_name> /domain:<trusted_domain_name> /userd:<administrator> /password:<password> /verify /kerberos
6. If replication is failing between domain controllers in different domains, follow these steps:
Add the following registry value to the upstream replication partner:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value name: Replicator Allow SPN Fallback
Value type: REG_DWORD
Value data: 1
Run the following command from the upstream partner:
repadmin /add CN=Configuration,DC=<domain controller>,DC=<com> <root DC name> <fully qualified name of child domain controller>
Remove the Replicator Allow SPN Fallback registry value after testing replication.
7. Attempt to reset the computer account password and force a refresh of Kerberos tickets of the downstream partner.
netdom resetpwd /server:<DC> /userd:<domain>\administrator /passwordd:<password>
Note Run the command on the problem domain controller. <DC> is any domain controller other than the domain controller with an invalid password. Set the Kerberos Key Distribution Center (KDC) service to manual on the problem domain controller and reboot. Restart the KDC service and switch it back to automatic after the reboot is completed.
8. Make sure the Service Principal Name (SPN) is registered for each domain controller object on each partner domain controller. For more information see KB article 308111.
Review the Registered Service Principal Names section of the Netdiag output on partner domain controllers to ensure that the test passes. Export the SPNs of each domain controller object involved in the replication failure from each partner using the following command:
ldifde -f spndump.txt -p base -l servicePrincipalName -d <DN of DC>
Either visually compare the SPNs or use the Windiff tool from the Windows 2000 Support Tools to compare the files for differences. Under the Options menu in Windiff, uncheck everything except Show different files, Show left-only lines, and Show right-only lines. After identifying the missing SPNs, edit the good SPN file as follows:
- Change changetype: add to changetype: modify.
- Add replace: servicePrincipalName after the changetype line.
- Add "-" to the last line of the file.
Import the correctly registered SPNs on the partner domain controllers that do not have proper SPNs registered for its replication partner domain controllers.
ldifde -I -f goodSPNs.txt
9. If the problem domain controllers exist in only one domain with more than two domain controllers, force all computer accounts to be replicated throughout the enterprise. That means all domain controllers must be synchronized with all other copies of their domain. For each computer that is reporting a replication error, use the following command to force that computer to become synchronized. The domain to synchronize must be specified. For more information see KB article 296993.
repadmin /syncall /d /e <problem domain controller> <DN of domain>
Note For large environments, remove the /e switch to replicate domain controllers with the same site, or use /sync to target specific domain controllers in remote sites.
10. If the failing domain controllers reside in different domains, then specify the configuration partition. For more information see KB article 296993.
repadmin /syncall /d /e <problem domain controller> <DN of config>
Note For large environments, remove the /e switch to replicate domain controllers with the same site or use /sync to target specific domain controllers in remote sites.
11. Make sure the Enterprise Domain Controllers group has the required permissions on the directory partition’s access control list (ACL):
- Start Active Directory Users and Computers.
- On the View menu, select Advanced Features.
- Right-click the root domain object, and then select Properties.
- Select the Security tab, click Enterprise Domain Controllers in the name list, and then make sure the following permissions are selected under Allow:
- Manage Replication Topology.
- Replicating Directory Changes.
- Replication Synchronization.
12. Use Active Directory Sites and Services to make sure the server object and its corresponding NTDS Settings child object exist in the correct site.
13. Verify the following Group Policy security options under Security Settings match on all partner domain controllers.
- Additional Restrictions for Anonymous Connections.
- Digitally Sign Client Communication (Always).
- Digitally Sign Client Communication (When Possible).
- Digitally Sign Server Communication (Always).
- Digitally Sign Server Communication (When Possible).
- LAN Manager Authentication Level.
14. Check for Kerberos fragmentation by typing ping <destination computer> -f -l 1500. Start with 1500 first, and then work up to 2000. If it fails before 2000, then packets are likely being fragmented. For more information see KB article 244474.