JSI Tip 3370. Active Directory replication and Knowledge Consistency Checker fail without trusted domain object?

Microsoft has written Knowledge Base article Q257844. I quote:

Active Directory Replication and Knowledge Consistency Checker Fail without Trusted Domain Object

• 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:

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/mydomain.com@mydomain.com.

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.

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.

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



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

   Active Directory cannot verify the trust. Access is denied.

   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:

   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:

   Active Directory cannot verify the trust. Access is denied.

   Click OK. Again, note that Active Directory Domains and Trusts displays the trust as type "Shortcut" and that it is transitive.



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



4. Reboot the PDC where these changes were made.



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