Microsoft has written Knowledge Base article Q257844. I quote:
Active Directory Replication and Knowledge Consistency Checker Fail without Trusted Domain Object
The information in this article applies to:
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Datacenter Server
- Microsoft Windows 2000 Server
SYMPTOMS
In the event log of a Windows 2000 domain controller, one of the following error messages may appear:
From the source "NTDS Replication", Event ID 1645:
From the source "NTDS KCC", Event 1265:The Directory Service received a failure while trying to perform an authenticated RPC call to another Domain Controller. The failure is that the desired Service Principal Name (SPN) is not registered on the target server. The server being contacted is afb720fd-38c7-4505-aa9f-b658ca124773._msdcs.MyDomain.com. The SPN being used is E3514235-4B06-11D1-AB04-00C04FC2DCD2/afb720fd-38c7-4505-aa9f-b658ca124773/[email protected].
Please verify that the names of the target server and domain are correct. Please also verify that the SPN is registered on the computer account object for the target server on the KDC servicing the request. If the target server has been recently promoted, it will be necessary for knowledge of this computer's identity to replicate to the KDC before this computer can be authenticated.
From attempting to synchronize replication partners through Active Directory Sites and Services, Active Directory Replication Monitor (REPLMON) or Repadmin.exe:The attempt to establish a replication link with parameters Partition: CN=Configuration,DC=MyDomain,DC=net Source DSA DN: CN=NTDS Settings,CN=MyServer,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=MyDomain,DC=com Source DSA Address: 5e5abf03-e902-48e2-a326-41977dee176d._msdcs.MyDomain.com Inter-site Transport (if any): failed with the following status: Logon Failure: The target account name is incorrect. The record data is the status code. This operation will be retried.
Logon Failure: The target account name is incorrect.
CAUSE
If this error is being reported for Active Directory replication between two domain controllers of different domains which have a parent/child or tree root trust relationship, this error may be due to an absent critical object that represents the trust relationship between the two domains. This object is known as a "trustedDomain" object (TDO) and is found in the System container in the Active Directory Users and Computers tool. This type of object directly relates to the trust relationships displayed in the Active Directory Domains and Trusts administrative tool. If this object is not present in the Active Directory, cross-domain authentication will not be able to succeed contributing to the errors described above.
RESOLUTION
To resolve this issue:
NOTE: This procedure should only be performed if the TDO for the remote domain is not present in the System container.
- From the domain that is generating the error messages listed earlier in this article, open the Active Directory Domains and Trusts administrative tool on the domain controller that holds the PDC Flexible Single Master Operations (FSMO) role for the domain. Right-click the object that represents the domain, and then click Properties.
- Click the Trusts tab, and then click Add to create both sides of the trust relationship to the remote domain. Because this
would normally be a Kerberos trust, creating both sides of the trust is required. Creating the trusted side first generates the following error message:
Click OK. Note that Active Directory Domains and Trusts displays the trust as type "Shortcut" and that it is transitive. Adding the trusting side generates the following message:Active Directory cannot verify the trust. Access is denied.To verify the new trust, you must have permissions to administer trusts for the domain XXX. Do you want to verify the new trust?
Click Yes, and then supply the administrator credentials for the remote domain. Whenever you are prompted for credentials, be sure to specify the domain name as well as the user name, for example, NetBIOSDomainName\Administrator. The following error message is generated:
Click OK. Again, note that Active Directory Domains and Trusts displays the trust as type "Shortcut" and that it is transitive.Active Directory cannot verify the trust. Access is denied. - After both sides of the trust relationship have been created, run the following command.
NOTE: The NETDOM utility is included with the Windows 2000 Support Tools included in the \Support\Tools folder of your Windows 2000 Server or Professional CD-ROM.NETDOM TRUST local_domain /Domain:remote_domain /UserD:administrator /PasswordD:* /UserO:administrator /PasswordO:* /Reset /TwoWay
where "local_domain" is the domain on which the trust is being created and "remote_domain" is the parent, child, or tree root domain being trusted. In either case, the fully qualified domain name (FQDN) should be used. For example, "MyDomain.com". This should result in the following message:Type the password associated with the domain user: (This is UserD) Type the password associated with the object user: (This is UserO) Resetting the trust passwords between local_domain.com and remote_domain.com The trust between local_domain.com and remote_domain.com has been successfully reset and verified The command completed successfully.
- Reboot the PDC where these changes were made.
- After rebooting, allow time for the Active Directory to establish a secure channel and the Knowledge Consistency Checker to attempt to re-establish replication links to the domain controllers in the remote domain. During this period, test that logons across the trust relationship are successful and that the event log errors have ceased.
STATUS
Microsoft has confirmed the display of the re-created trust as "Shortcut" to be a problem in Microsoft Windows 2000.
MORE INFORMATION
The two-way trust relationship will continue to be displayed as a "Shortcut" trust in Active Directory Domains and Trusts, however, the trust relationship will function correctly and will be transitive. It is important that this trust not be mistaken as an optimization to the trust hierarchy and be removed in the future until a supported fix for this problem is released by Microsoft.
