When one domain is permitted to trust another, User Manager for Domains creates an interdomain trust account in the directory database of the trusted domain. A trusted-domain object is created in the LSA of the trusting domain, and a secret object is created in the LSA of the trusting domain. This account is like any other global user account, except that the USER_INTERDOMAIN_TRUST_ACCOUNT bit in the control field for the account is set. The interdomain trust account is used only by the primary domain controller and is invisible in User Manager for Domains. The password is randomly generated and is maintained by User Manager for Domains.
When this trust relationship is established, the NetLogon service on the trusting domain attempts discovery on the trusted domain, and the interdomain trust account is authenticated by a domain controller on the trusted domain.
Similar accounts and procedures are used in the trust relationships between a PDC and a BDC, and between a domain controller running Windows NT and a computer running Windows NT Workstation in that domain.
In the following example, the trusted domain is referred to as Master and the trusting domain is referred to as Resource. The Master contains the user account information; the Resource trusts the Master to validate user access to its resources.
On each domain controller in RESOURCE, an LSA trusted-domain object represents the trust. This object contains the name of the trusted domain and the domain SID. The LSA trusted-domain object is replicated from the trusting domain PDC to each of the BDCs in the trusting domain.
On each domain controller in RESOURCE, a password is stored in an LSA secret object G$$<TrustedDomainName>, such as G$$MASTER. This object is stored in the registry key
HKEY_LOCAL_MACHINE\Security\Policy\Secrets
The LSA secret object for the trusted-domain trust relationship is replicated from the PDC in the trusting-domain to each of the trusting-domain BDCs.
On each domain controller in MASTER, the password is stored in the directory database user account marked as INTERDOMAIN_TRUST_ACCOUNT, such as RESOURCE$. This can be viewed in the registry path \SAM\SAM\Domains\Account\Users\Names
(HKEY_LOCAL_MACHINE subtree)
This account is replicated from the trusted-domain PDC to each of the trusted-domain BDCs.
These accounts are created when a trust is established. The administrator of the trusted domain, MASTER, permits RESOURCE to trust the MASTER accounts. When the domain is added in User Manager to the Trust Relationships dialog box, a hidden user account is created in the directory database for use by the trusting domain. The account contains the specified password, such as RESOURCE$.
For details on how to set up a trust relationship see "Managing Windows NT Server Domains" in Microsoft Windows NT Server 4.0 Concepts and Planning and online Help.
The administrator of the trusting domain establishes the trust. The administrator provides the password specified earlier, and User Manager creates the LSA secret object. The server in RESOURCE attempts to setup a session with the domain controller in MASTER, using the password RESOURCE$. The domain controller in MASTER responds with the error "0xc0000198, Status_Nologon_Interdomain_Trust_Account" because the special Interdomain Trust Account cannot be used in a normal session logon, and the session fails.
This error informs the domain controller in the RESOURCE domain that the trust account exists and a trust is possible. Upon receiving that response, it establishes a null session and then uses remote-procedure-call (RPC) transactions to call the remote APIs that establish the trusted domain relationship. A secure channel is set up later by the NetLogon service, using the trust information that was stored by the User Manager.
After the trust is established, the RESOURCE PDC changes the password for the trusted-domain object. All domain controllers in each domain receive the trust account objects through normal domain synchronization of the directory and the LSA databases. The domain controllers in RESOURCE receive the LSA secret object during the update of the LSA database, and the domain controllers in MASTER receive the account in the directory-database update. With these objects, any domain controller in the trusting domain can set up a secure channel to any domain controller in the trusted domain.
Maintenance of these accounts includes periodic password changes. Every seven days, the PDC of the trusting domain automatically changes the password of the trusted domain object by the following steps.
1. Setting the OldPassword field of the LSA secret object to the previous NewPassword field.
2. Selecting a new password.
3. Setting the NewPassword field in the LSA secret object to the selected password.
This ensures that the domain controllers can always access a valid password in the event of a crash.
4. Sending an I_NetServerPasswordSet RPC call to a domain controller of the trusted domain, asking it to set the password in the directory-database-user trust account to the value of the NewPassword field in the LSA secret object of the trusting domain. The trusting PDC sends the RPC call to the trusted domain controller with which it established the secure channel. That domain controller passes the request through to the trusted PDC.
The password is now changed on both PDCs. Normal replication distributes the objects to the BDCs.
A domain controller of the trusted domain (MASTER) never initiates the password change. It is always initiated by the trusting domain PDC. Initiating the password change requires that the secure channel has been set up.
It is possible, but not likely, that the trusting domain controller will change the password without updating a domain controller in the trusted domain. For example, this might happen if the trusted domain controller failed during the process and did not received the updated password. As a safeguard, both the old and new passwords are kept in the LSA secret object on the trusting side. The PDC in the trusting domain never changes the new password unless it has successfully set up a secure channel using the current new password. If the secure-channel setup fails because the new password is invalid, the trusting PDC tries the old password. If a secure channel is established using the old password, it immediately (within 15 minutes) continues the password change algorithm with step 4 (above).