Return to index


With the exception of Domain Controllers, all NT machines have their own local Security Accounts Manager (SAM) and are, therefore, able to maintain and validate their own local accounts. So, a non-DC NT machine's 'Domain' list will always include the machine itself.

In DCs, the domain SAM becomes the local SAM. So a DC's 'Domain' list will always include the domain and never include the DC itself. If a domain trusts another domain, then the 'Domain' list of the trusting domain DCs will include the name of the trusted domain.

An NT domain member obtains the list of trusted domains (e.g. the Domain Field of the logon Dialog) from a DC it it's home domain. Let's say you have:


2 domain's: AccDom and ResDom


ResDom trusts AccDom


PC1 is a member of ResDom.


PC1's domain list will automatically include itself (all NT machines, except DCs have their own local SAM) and ResDom (it's home domain).


When PC1 establishes a secure channel with a ResDom DC, one of the activities it will carry out is to request a list of trusted domains. Once the ResDom DC tells it that Accdom is a trusted domain, PC1's domain list will include Accdom (unless a ResDom DC gives it a new list that doesn't contain Accdom).


In this example:


An NT domain member never directly contacts a DC from a trusted domain to authenticate an account. Instead, the domain member passes the credentials to a DC from it's home domain and the home domain DC contacts a DC from the trusted domain. Roughly the same procedure is followed when NT domain member needs to validate in incoming network connection from a trusted domain account and when it needs to validate a logon. In the example above, when you try to log onto PC1 with an Accdom account:

  1. PC1 contacts a ResDom DC and passes the credentials (username, domain, password) to it for authentication.
  2. The ResDom DC verifies that Accdom is a trusted domain, then contacts an Accdom DC and passes the credentials to it.
  3. The ResDom DC relays the result back to PC1. If the credentials are valid and the account has a logon script defined, the relayed information includes the name of the Accdom DC that validate the account.
  4. Is the logon succeeded and the account has a logon script defined, PC1 establishes a connection to the netlogon share of the Accdom DC specified in the relayed information.



While it's probably possible to access the registry key where the domain list is stored and manually alter the domain list of a domain member, the poke would be unlikely to serve any functional purpose. The list would be reset the next time the member contacted a DC from its home domain and the NT domain member still be unable to validate an account from the fake 'trusted' domain.