Appendix C: Establishing Trust Relationships

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Archived content - No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Traffic generated by trust relationships occurs when there is at least one backup domain controller. This section following the traffic process when trust relationships ...

Trusting Domain Traffic

After the trusted domain has permitted the new domain to trust its accounts, the trusting domain will accept the offer, and complete the trust relationship communications link. This process includes the primary domain controller of the trusting domain:

  • Querying WINS for IP address of primary domain controller in trusted domain.

  • Querying the IP address of trusted domain's primary domain controller for computer name using a NETLOGON\GETDC mailslot.

  • Establishing a TCP session with primary domain controller of trusted domain.

  • Establishing a NetBIOS session with primary domain controller of trusted domain.

  • Negotiating SMB protocol with primary domain controller of trusted domain.

After this, the primary domain controller of the trusting domain will attempt to connect to IPC$ of the primary domain controller using domainname$ as the user account. This is unsuccessful, and results in a "STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT" response. This is unsuccessful because this account is not permitted to be used for normal session logon.

Receiving this error informs the trusting domain that the trust exists. After this, the TCP session is terminated.

The next steps include the primary domain controller of the trusting domain:

  • Requesting a list of backup browser servers in trusted domain.

  • Establishing TCP and NetBIOS sessions with a backup browser in the trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ of the backup browser in the trusted domain.

  • Retrieving the browse list of the trusted domain.

  • Establishing TCP and NetBIOS sessions with a server in the trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ of the server in the trusted domain.

  • Establishing a named pipe session with the server, and remoting a NetrWkstaGetInfo API over RPC to acquire the computer and domain name of the server.

The primary domain controller of the trusting domain then establishes a named pipe session with the server, and remotes four API calls using RPC to the server. These API's are to the LSA, or Logon Security Authority of the target server. Depending on computer names, these four API calls, with responses, total approximately 1,560 bytes.

This session is then terminated, and another session is established that delivers three API calls using RPC to LSA at the server.

The establishment of the trust relationship is completed with the primary domain controller of the trusting domain querying for a logon server in the trusted domain. This query is both broadcast on the local subnet, and delivered to each domain controller returned by the WINS server in response to a query to domain <1C>.

This frame is identified by having an operation code of "SAM LOGON request from client" and is directed to the mailslot \MAILSLOT\NET\NTLOGON at the target domain controller.

A domain controller in the trusted domain will then respond with a frame to indicate success to the SAM LOGON request. This frame has an operation code of "SAM Response to SAM LOGON request".

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. The trust relationship is established at this point.

This entire process took 107 frames, and three second to complete. The total network traffic was just over 15,230 bytes. There may be more or fewer frames, depending upon the number of backup domain controllers in the trusted domain.

Trusted Account Traffic

Once a trust relationship has been established, the trusting domain can assign permissions to local resources to user or group accounts from the trusted domain. Often, this is accomplished by adding a global group from the trusted domain to a local group in the trusting domain.

Verifying the Trust Relationship

In order to import a user or global group account from a trusted domain, traffic is generated by the primary domain controller of the trusting domain as follows:

  • Establishing a TCP session with primary domain controller of trusted domain.

  • Establishing a NetBIOS session with primary domain controller of trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ (using a null username) of the primary domain controller of trusted domain.

The primary domain controller of the trusting domain then establishes a named pipe session with the primary domain controller of the trusted domain, and delivers four API calls using RPC to LSA at the server. These four API calls, with responses, total approximately 1,560 bytes, depending on computer names.

The trusting primary domain controller will then establish a session with the primary domain controller of the trusted domain using the logged on username. A named pipe session is then established, and a remote NetrWkstaGetInfo API call over RPC to the Workstation service of the trusted domain controller to acquire the computer and domain name of the server.

The primary domain controller of the trusting domain then establishes a named pipe session with the primary domain controller of the trusted domain, and sends four API calls using RPC to LSA at the server.

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. This all serves to verify the trust relationship?.

Retrieving a List of Trusted Accounts

Next, to display a list of accounts that can be imported to the trusting domain, the primary domain controller of the trusting domain then establishes TCP and NetBIOS sessions with the primary domain controller of the trusted domain. SMB protocol negotiation, and a IPC$ then follow (using logged on username).

The trusting primary domain controller establishes a named pipe session with the server, and remotes one API call using RPC to SAMR, or SAM service, at the server. This API connects to the SAM service at the trusted domain.

The primary domain controller of the trusting domain then establishes a named pipe session with the server, and remotes eleven API calls using RPC to LSA at the server. These API's are used to retrieve a list of trusted accounts at the trusted domain.

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. User and/or group accounts can then be selected and added to the list of local groups in the trusting domain.

This entire process took 111 frames, just over 24,000 bytes, and ten seconds to complete. Additional frames may be necessary depending upon the number of trusted accounts that can be imported at the trusting domain.

Analyzing Pass Through Authentication Traffic

When a user in a trusted domain attempts to access a resource in a trusting domain, its account must be validated. The trusting domain is not able to do this, and in order to validate the account, a process called "pass through authentication" takes place.

Making a Remote Resource Request

The network traffic generated by a Windows for Workgroups client computer accessing a resource in a remote Windows NT Server domain is as follows:

  • Requesting a browse list from a backup browser in the remote domain.

  • Establishing TCP and NetBIOS sessions with the target server in the remote domain, as well as negotiating SMB protocols.

At this point, the client attempts to connect to the desired sharename at the target computer. The target computer is not able to validate the logon request, and pass through authentication occurs.

Validating the User Account

When a request to logon validate a user account that is in a trusted domain occurs, the domain controller in the trusting domain must contact a domain controller in the trusted domain. The traffic generated by the trusting domain controller to complete this process is:

  • Establishing TCP and NetBIOS sessions with the domain controller in the trusted domain, as well as negotiating SMB protocols.

  • Creating a null session to IPC$ of the trusted domain controller.

The domain controller of the trusting domain then establishes a named pipe session with the domain controller of the trusted domain, and remotes three API calls using RPC to the NetLogon service at the server.

The first two API's, and responses, serve to establish a secure channel between the two domain controllers, and were documented in the section on synchronizing the directory services database.

The third API requests logon validation, and provides the username, computername, and domain name of the logon request from the client computer.

These three requests, with accompanying responses, totaled almost 1,800 bytes, and took only 120 milliseconds to complete.

The entire process of validating the user account using pass through authentication required 3,700 bytes of traffic, 20 frames, and 200 milliseconds to complete. A later pass through validation attempt took only two frames, 942 bytes and 13 milliseconds with the secure channel already established.

Analyzing the Trusted Domain Traffic

Establishing trust relationships is an easy task for the administrator. This process does generate some network traffic.

When the trusted domain adds a new domain to its list of trusting domains, the resulting process is the same as if a user account has been added to the directory services database. If there are no backup domain controllers initialized in the domain, no network traffic is present. If there is at least one backup domain controller, the process includes:

  • The primary domain controller announcing a change to the UAS or SAM.

  • The backup domain controller connecting to IPC$ of the primary domain controller.

  • The backup domain controller uses the NetLogon service to verify the account database.

  • The backup domain controller transfers the updated data using SMB or RPC calls (depending on the size of the update).

This entire process took 17 frames, and just over one second to complete. The total network traffic was just over 3,400 bytes. One RPC Response frame contained the name of the domain to be added to the "Permitted to Trust this Domain" list.

Analyzing the Trusting Domain Traffic

After the trusted domain has permitted the new domain to trust its accounts, the trusting domain will then accept the offer, and complete the trust relationship communications link. This process includes the primary domain controller of the trusting domain:

  • Querying WINS for IP address of primary domain controller in trusted domain.

  • Querying the IP address of trusted domain's primary domain controller for computer name using a NETLOGON\GETDC mailslot.

  • Establishing a TCP session with primary domain controller of trusted domain.

  • Establishing a NetBIOS session with primary domain controller of trusted domain.

  • Negotiating SMB protocol with primary domain controller of trusted domain.

After this, the primary domain controller of the trusting domain will attempt to connect to IPC$ of the primary domain controller using domainname$ as the user account. This is unsuccessful, and results in a "STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT" response. This is unsuccessful because this account is not permitted to be used for normal session logon. This response frame has the following characteristics:

  • 93 bytes in size.

  • SMB Status Code System Error of "STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT"

  • SMB flags to indicate a "Server response" and "Using NT status codes".

Receiving this error informs the trusting domain that the trust exists. After this, the TCP session is terminated. The next steps include the primary domain controller of the trusting domain:

  • Requesting a list of backup browser servers in trusted domain.

  • Establishing TCP and NetBIOS sessions with a backup browser in the trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ of the backup browser in the trusted domain.

  • Retrieving the browse list of the trusted domain.

  • Establishing TCP and NetBIOS sessions with a server in the trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ of the server in the trusted domain.

  • Establishing a named pipe session with the server, and remoting a NetrWkstaGetInfo API over RPC to acquire the computer and domain name of the server.

The primary domain controller of the trusting domain then establishes a named pipe session with the server, and remotes four API calls using RPC to the server. These API's are to the LSA, or Logon Security Authority of the target server, and include:

  • LsarOpenPolicy2

  • LsarQueryInformationPolicy

  • LsarQueryInformationPolicy

  • LsarClose

These four API calls, with responses, total approximately 1,560 bytes, depending on computer names.

This session is then terminated, and another session is established that mimics the just completed session, with only one LsarQueryInformationPolicy.

The establishment of the trust relationship is completed with the primary domain controller of the trusting domain querying for a logon server in the trusted domain. This query is both broadcast on the local subnet, and delivered to each domain controller returned by the WINS server in response to a query to domain <1C>. The properties of the queries include:

  • Approximately 330 bytes in size, depending upon computer and domain names.

  • Destination NetBIOS name of domain <1C>.

  • SMB Path name of "\MAILSLOT\NET\NTLOGON".

The remainder of the frame, approximately 110 bytes, represent the NETLOGON portion of the frame. This frame has the following details:

  • Operation code of "SAM LOGON request from client".

  • Unicode Computer Name of the trusting domain's primary domain controller.

  • Unicode User Name of domain$. This is a special name for the trust relationship.

  • Mailslot Name of \MAILSLOT\NET\NTLOGON.

  • An Allowable Account Control Bit of "Interdomain Trust User Account".

  • The trusting domain's SID.

  • LMNT Token of "WindowsNT Networking".

  • LM20 Token of "OS/2 LAN Manager 2.0 (or later) Networking".

A domain controller in the trusted domain will then respond with a frame to indicate success to the SAM LOGON request. This frame:

  • Is approximately 295 bytes in size, depending on computer and domain names.

  • Is directed to the client (primary domain controller) that initiated the original request at the hardware, IP and NetBIOS layers.

  • SMB Path name of "\MAILSLOT\NET\NTLOGON".

The remainder of the frame, approximately 80 bytes, represent the NETLOGON portion of the frame. This frame has the following details:

  • Operation code of "SAM Response to SAM LOGON request".

  • Unicode Logon Server of the responding domain controller.

  • Unicode User Name of domain$, which is the same as in the request. This is a special name for the trust relationship.

  • Unicode Domain Name of the trusted domain.

  • LMNT Token of "WindowsNT Networking".

  • LM20 Token of "OS/2 LAN Manager 2.0 (or later) Networking".

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. The trust relationship is established at this point.

This entire process took 107 frames, and three second to complete. The total network traffic was just over 15,230 bytes. There may be more or fewer frames, depending upon the number of backup domain controllers in the trusted domain.

Using Trusted Accounts

Once a trust relationship has been established, the trusting domain can assign permissions to local resources to user or group accounts from the trusted domain. Often, this is accomplished by adding a global group from the trusted domain to a local group in the trusting domain.

Verifying the Trust Relationship

In order to import a user or global group account from a trusted domain, traffic is generated by the primary domain controller of the trusting domain as follows:

  • Establishing a TCP session with primary domain controller of trusted domain.

  • Establishing a NetBIOS session with primary domain controller of trusted domain.

  • Negotiating SMB protocol and connecting to IPC$ (using a null username) of the primary domain controller of trusted domain.

The primary domain controller of the trusting domain then establishes a named pipe session with the primary domain controller of the trusted domain, and remotes four API calls using RPC to the server. These API's are to the LSA, or Logon Security Authority of the target server, and include:

  • LsarOpenPolicy2

  • LsarQueryInformationPolicy - retrieves the domain name

  • LsarQueryInformationPolicy - retrieves the domain name

  • LsarClose

These four API calls, with responses, total approximately 1,560 bytes, depending on computer names.

The trusting primary domain controller will then establish a session with the primary domain controller of the trusted domain using the logged on username. A named pipe session is then established, and a remote NetrWkstaGetInfo API call over RPC to the Workstation service of the trusted domain controller to acquire the computer and domain name of the server.

The primary domain controller of the trusting domain then establishes a named pipe session with the primary domain controller of the trusted domain, and remotes four API calls using RPC to the server. These API's are to the LSA, or Logon Security Authority of the target server, and include:

  • LsarOpenPolicy2

  • LsarQueryInformationPolicy - retrieves the domain name

  • LsarQueryInformationPolicy - retrieves the domain name

  • LsarClose

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. This all serves to verify the trust relationship?.

Retrieving a List of Trusted Accounts

Next, to display a list of accounts that can be imported to the trusting domain, the primary domain controller of the trusting domain then establishes TCP and NetBIOS sessions with the primary domain controller of the trusted domain. SMB protocol negotiation, and a IPC$ then follow (using logged on username).

The primary domain controller of the trusting domain then establishes a named pipe session with the server, and remotes eleven API calls using RPC to the server. These API's are to the LSA, or Logon Security Authority, of the target server, and include:

  • LsarOpenPolicy2

  • LsarQueryInformationPolicy

  • LsarQueryInformationPolicy - retrieves domain name

  • LsarQueryInformationPolicy

  • Lsar - retrieves list of global groups

  • LsarSetTrustedDomainInfo - retrieves list of user accounts

  • LsarSetTrustedDomainInfo

  • LsarDelete

  • LsarDelete

  • LsarDelete

  • LsarClose

At this point, the connection to IPC$ is disconnected, an SMB Logoff command is executed, and the TCP session is broken. User and/or group accounts can then be selected and added to the list of local groups in the trusting domain.

This entire process took 111 frames, just over 24,000 bytes, and ten seconds to complete. Additional frames may be necessary depending upon the number of trusted accounts that can be imported at the trusting domain.

Analyzing Pass Through Authentication Traffic

When a user in a trusted domain attempts to access a resource in a trusting domain, its account must be validated. The trusting domain is not able to do this, and in order to validate the account, a process called "pass through authentication" takes place.

Making a Remote Resource Request

The network traffic generated by a Windows for Workgroups client computer accessing a resource in a remote Windows NT Server domain is as follows:

  • Requesting a browse list from a backup browser in the remote domain.

  • Establishing TCP and NetBIOS sessions with the target server in the remote domain, as well as negotiating SMB protocols.

At this point, the client attempts to connect to the desired sharename at the target computer. The target computer is not able to validate the logon request, and pass through authentication occurs.

Validating the User Account

When a request to logon validate a user account that is in a trusted domain occurs, the domain controller in the trusting domain must contact a domain controller in the trusted domain. The traffic generated by the trusting domain controller to complete this process is:

  • Establishing TCP and NetBIOS sessions with the domain controller in the trusted domain, as well as negotiating SMB protocols.

  • Creating a null session to IPC$ of the trusted domain controller.

The domain controller of the trusting domain then establishes a named pipe session with the domain controller of the trusted domain, and remotes three API calls using RPC to the server. These API's are to NetLogon service of the target server, and include:

  • NetrServerReqChallenge

  • NetrServerAuthenticate2

  • NetrLogonSamLogon

The first two API's, and responses, serve to establish a secure channel between the two domain controllers, and were documented in the section on synchronizing the directory services database.

The third API requests logon validation, and provides the username, computername, and domain name of the logon request from the client computer.

These three requests, with accompanying responses, totaled almost 1,800 bytes, and took only 120 milliseconds to complete.

The entire process of validating the user account using pass through authentication required 3,700 bytes of traffic, 20 frames, and 200 milliseconds to complete. A later pass through validation attempt took only two frames, 942 bytes and 13 milliseconds with the secure channel already established.