Appendix A: Directory Services Traffic
| 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.
Analyzing Logon Validation Traffic
One of the first functions a network needs to provide to users is logon validation. This is accomplished by the set of domain controllers for the domain the user is requesting validation. This topic examines the network traffic generated between the logon client and the domain controller validating the logon request.
By identifying the network traffic generated during user logon validation, the network planner can more adequately equip the network with the proper number of domain controllers to support the needs of the users.
Finding a Logon Server
In a TCP/IP environment, logon validation cannot take place until the client has initialized its networking services with an IP address. A Microsoft networking client computer can acquire its IP address through DHCP, and use WINS for computer name registration and resolution. The following sequence of events occur to prepare the computer for logon validation:
Acquires an IP address from a DHCP Server.
Registers various names with WINS.
Once an IP address has been acquired, the first step in the logon process is finding a domain controller to validate the user account. This is accomplished using one of the following two methods:
Querying WINS for all registered domain controllers in the domain.
Broadcasting a request to the mailslot NETLOGON.
Delivery Tips
Start Network Monitor, open "BOOTWFW.CAP", and point out frame number 21 to show the NETLOGON broadcast.
This size of this request is dependent upon the sizes of the user and computer names. For an eight character computer name, with a thirteen character user name, the request is 270 bytes in size. It is broadcast at the physical layer (Ethernet), and a subnet broadcast at the IP level. UDP port 138 (NetBIOS Datagram Service) is used to service the request.
The destination NetBIOS name is the domain name being logged into, with a <00> in the 16th position. For example, if attempting to find a logon server in the domain DOMAIN0, the request would be sent to "DOMAIN0 <00>" with spaces padded through 15 characters, then <00>.
Delivery Tips
Display frames 25 and 26 of "BOOTWFW.CAP" to show the NETLOGON broadcast response.
Each logon server registered in the domain running the NetLogon service will respond to the client, indicating it can accommodate the logon request. This is done via a directed reply to the requesting computer name over UDP port 138 and the mailslot \MAILSLOT\TEMP\NETLOGON. This frame is approximately 230 bytes in size, depending on the logon server name.
Included in this frame is the Source IP Address and computer name of the logon server.
Delivery Tips
Display frames 22 and 27 of "BOOTWFW.CAP" to show the WINS query and response.
Using WINS
If the client computer is configured as an H-node WINS client , it will send a query to the WINS server for the domain name, appended with a <1C> as the 16th character. For example, if the client is attempting to find a logon server in the domain DOMAIN0, the request would be sent to "DOMAIN0 <1C>" with spaces padded through 15 characters, then <1C>.
In response to the query, the WINS server returns a frame that includes the IP address of all registered domain controllers in the WINS database for that domain.
The client would then send a directed message to each server listed in the WINS response asking if it can validate the logon request.
Validating the Logon Request
During the next part of the logon validation process, the client computer takes the first response to its NETLOGON request, and initiates the following traffic between itself and the logon server:
The client resolves the NetBIOS name of the selected logon server, either by querying WINS, or by broadcast.
A TCP session is established with the logon server using the TCP three-way handshake process.
A NetBIOS session is established with the logon server.
SMB protocol negotiation occurs.
SMB tree connection to \\logonserver\IPC$ is established.
At process completion, the client initiates a conversation with the logon server using remote API calls to validate the logon. The first API called is NetWkstaUserLogon, which requests logon validation. The server then responds with a success or failure message. The second API called is NetRemoteTOD, to synchronize the client's clock with the server's. The server then responds with the correct time as kept at the domain controller. This set of two API calls and responses, totals four frames, and approximately 750 bytes.
After the specific user account has been validated, logon scripts, user profiles, or system policies may be executed. This would result in additional network traffic. For example, a user logging onto the domain from a Windows 95 client computer would generate an additional 35 frames. These 35 frames show the client computer establishing a session with the primary domain controller, connecting to the NETLOGON share, and executing a logon script or system policy. This process will add another few seconds to the logon process of the client, as well as the frames required to perform the transfer.
Finally, the connection to IPC$ would be disconnected, and the NetBIOS and TCP sessions would be terminated. This would take another five frames and approximately 560 bytes of traffic total.
Analyzing Account Synchronization Traffic
In a Windows NT Server network, user logon validation requests are processed by either the primary domain controller or a backup domain controller. Often times logon validation is handled by a backup domain controller. This is because the client accepts the first response to its query, and uses that server to perform validation. Primary domain controllers are typically busier than backup domain controllers, thus preventing the PDC from replying as quickly as a BDC.
To ensure that each backup domain controller in the domain properly validates each user logon request, it is important that each backup domain controller has an exact copy of the directory services database maintained on the primary domain controller. This happens through the NetLogon service's ability to perform directory services synchronization.
The NetLogon Service
Windows NT uses the NetLogon service on the domain controllers to synchronize the directory services database on the primary domain controller with backup domain controllers. On a domain controller, the Windows NT NetLogon service has a number of responsibilities. The NetLogon service must perform the following functions:
Provide for the synchronization of the directory services database between the primary domain controller and the backup domain controllers.
Provide for user account logon validation.
Provide support for trust relationships between domains.
Provide for membership of computers in a domain.
If, for any reason, the NetLogon service fails to start on a domain controller, it will be unable to provide any of these services to other domain controllers or users on the network.
Windows NT Database Synchronization
Windows NT database synchronization occurs on three databases that are maintained by the system, the SAM Accounts database, the SAM Built-in database, and the LSA database. These databases contain the following information:
Windows NT Database |
Description |
|---|---|
SAM Accounts database |
Contains the user and group accounts that the administrator creates. Also includes all computer accounts added to the domain, such as domain controllers and Windows NT Workstation computers. |
SAM Built-in database |
Contains the built-in user and group accounts, such as Administrator, Domain Admins, and so on. |
LSA database |
Contains the LSA Secrets that are used trust relationships and domain controller computer account passwords. Also included in the LSA database are the account policy settings as configured by the administrator. |
Synchronization of the Windows NT databases occurs during the following times:
When a backup domain controller is initialized or restarted into the domain.
When forced by the administration using Server Manager.
Automatically by the domain controllers, depending upon Registry configuration.
Backup Domain Controller Initialization Traffic
Delivery Tips
Use Network Monitor to display frames 1-15 in "BDCBOOT.CAP" to show DHCP and WINS traffic.
To effectively provide logon validation for users on the network, it may be necessary to implement backup domain controllers. These backup domain controllers need to maintain duplicate copies of the directory services database.
When a backup domain controller initializes, it verifies that its directory services database is up to date. This is accomplished through normal acquisition/verification of IP address and registration of various NetBIOS names, including the backup domain controller registering itself as a member of the Domainname <1C> group name.
Once the backup domain controller has initialized, the next set of events generate traffic that can have an effect on system performance. Particularly:
Traffic generated when the backup domain controller is trying to locate the primary domain controller to verify its directory services database.
Traffic generated when the backup domain controller is updating its directory services database from the primary domain controller.
Finding the Primary Domain Controller
After the backup domain controller has successfully initialized its protocol and networking services, it needs to find the primary domain controller to update its directory services database.
Delivery Tips
Use Network Monitor to display frames 17-18 in "BDCBOOT.CAP" to show the WINS query and response, and frame 19 to show the query for the PDC.
Querying for the Primary Domain Controller
To find the primary domain controller, the client queries WINS by sending a request for Domainname <1B>. This name is only registered by a primary domain controller. The WINS server then returns the IP address of the primary domain controller.
The backup domain controller then sends a "Query for Primary DC" message to the owner of the Domainname <1B> address returned by WINS. This is done to determine the name of the primary domain controller. This message is sent as a second class mailslot to \MAILSLOT\NET\NETLOGON.
This frame is approximately 270 bytes in size, and is directed to the hardware and IP address of the primary domain controller (as returned by WINS using the query on domainname <1B>.
The source and destination UDP ports are 138, NetBIOS Datagram Service.
The NBT header indicates this frame is a Type 16, which is a Direct Unique request. The source name is that of the backup domain controller <00>, and the destination name is Domainname <1B>.
The next portion of the frame is the SMB header. It is 92 bytes in size, with a Mailslot opcode of "Write mailslot", and a Path name of \MAILSLOT\NET\NETLOGON.
The final portion of this frame is the NETLOGON mailslot properties. Its Opcode is "Query for Primary DC", and the specific Mailslot Name (or command) is \MAILSLOT\NET\GETDC. The Computer Name listed is that of the backup domain controller.
Delivery Tips
Use Network Monitor to display frame 20 in "BDCBOOT.CAP" to show the response to the query for the PDC.
Primary Domain Controller Response
The primary domain controller then responds to the backup domain controller with a "Response to Primary Query" frame. This frame:
Is approximately 276 bytes in size, and is a directed send to the backup domain controller.
Uses UDP port 138 is used for both source and destination, as does the original query.
Is identified as is a Type 16, Direct Unique request, in the NBT header. The source name is that of the primary domain controller <00>, and the destination name is that of the backup domain controller <00>.
Has a 92 byte SMB header, with a Mailslot opcode of "Write mailslot", and a Path name of \MAILSLOT\NET\GETDC.
Is completed with the NETLOGON mailslot properties. Its Opcode is "Response to Primary Query", and the primary domain controller's name is listed as Primary DC Name.
Verifying the Directory Services Database
Delivery Tips
Use Network Monitor to display frames 23-31 in "BDCBOOT.CAP" to show the TCP session, NetBIOS session, SMB protocol negotiation, and connection to IPC$.
Once the backup domain controller has found the primary domain controller, it will proceed verifying its version of the directory services database. To complete this process, the following sequence of frames appear to prepare the for verification and synchronization of the directory services database:
Three-way TCP session initialization.
NetBIOS session establishment.
SMB protocol negotiation.
SMB connection to IPC$ of primary domain controller.
Note: These frames are covered in Module 3: "Network Services".
The final step establishes a secure channel with the primary domain controller. Before the backup domain controller can verify that its user accounts database version is up to date, it must establish a secure channel with the primary domain controller. This is done using the following series of frames containing RPC calls to the NetLogon Service of the primary domain controller:
RPC Bind
RPC Bind Ack
These two frames have same basic properties. They establish a named pipe connection between the two domain controllers.
The secure channel is established over this named pipe connection. This is accomplished by the following series of two RPC Request frames, with appropriate RPC Responses from the primary domain controller.
Delivery Tips
Display frames 34-35 to show the named pipe establishment.
RPC Request
RPC Response
RPC Request
RPC Response
RPC Bind Frame
The RPC Bind frame is 214 bytes in size. It is a directed frame at both the hardware and IP layers. In the TCP header, the "Acknowledgement field significant" and Push bits are set.
The NBT header indicates this is a "Session Message".
The SMB header indicates this is a "Transact named pipe" call.
The final 72 bytes represent the MSRPC header. This frame lists a "Packet Type" of Bind.
RPC Bind ACK Frame
The RPC Bind Ack frame is 182 bytes in size. It is a directed frame at both the hardware and IP layers. In the TCP header, the "Acknowledgement field significant" and Push bits are set.
The NBT header indicates this is a "Session Message".
The SMB header indicates this is a "Transact named pipe" call.
The final 68 bytes represent the MSRPC header. This frame lists a "Packet Type" of Bind Ack. The Secondary Address is listed as \PIPE\lsass for the Local Security Authority Subsystem. Further diagnosis of the frame reveals that the Result is "Acceptance", indicating the RPC session has successfully been initialized.
Delivery Tips
Display frames36-39 to show the establishment of the secure channel.
RPC Request Frames
Each of the RPC Request frames may request different information from the primary domain controller. The RPC operation number, or opnum, of the MSRPC header of the frame must be determined in order to determine the RPC Request that is being made.
The size of each RPC Request frame will vary, depending on the call being made, and the names of the servers involved. The ranges were from 244 to 282 bytes in size for six and ten character computer names respectively. They are directed frames at both the hardware and IP layers. In the TCP header, the "Acknowledgement field significant" and Push bits are set.
The NBT header indicates this is a "Session Message".
The SMB header indicates this is a "Transact named pipe" call.
The final portion of the frame, from 102 to 140 bytes, represent the MSRPC header. There will be two RPC Request calls that are initiated when a backup domain controller is initialized to establish the secure channel.
The first RPC Request has an Operation Number of 0x4. This is a NetrServerReqChallenge request to verify that the backup domain controller is a BDC for the primary domain controller specified in the frame.
This frame lists a "Packet Type" of Request. The Operation Number is listed as 0x4. The Stub Data portion of the frame contains the primary and backup domain controller names, as well as challenge keys to be verified.
The second RPC Request has an Operation Number of 0xF. This is a NetrServerAuthenticate2 request to verify the account name of the backup domain controller. This completes the secure channel setup, and provides a path to access the directory services database at the primary domain controller.
This frame lists a "Packet Type" of Request. The Operation Number is listed as 0xF. The Stub Data portion of the frame contains the primary and backup domain controller names to be verified.
The next RPC Request frame will be duplicated numerous times, each with the same operation number. There will be a minimum of three frames that are NetrDatabaseDeltas (Operation Number 0x7). These frames are used to tell the primary domain controller the serial number, or version ID, of each of the databases at the backup domain controller. They are also used to request updates to the directory services database.
RPC Response Frames
Each RPC Request frame elicits a RPC Response frame(s) from the primary domain controller to satisfy the request of the backup domain controller. These response frames vary in size from 150 to 174 bytes in size depending upon the data requested and returned.
When the backup domain controller receives a response to these two frames , a secure channel has been established with the primary domain controller, and database verification and possible updating can occur.
Periodic Updates of the Databases
By default, the primary domain controller verifies its databases every five minutes, looking for changes to any of the three databases. When a change is noticed, it sends a message to all backup domain controllers that need the notification, indicating that an update has been made to one of the databases. The PDC maintains a table of each BDC, and the version ID of each of their databases. If a BDC has an up-to-date database, it is not notified of the update.
When a new user account is added to the user account database, the primary domain controller detects the change. At the point when the change is detected, the following sequence of events occur:
The PDC announces a change to the SAM.
The BDC connects to IPC$ of the PDC.
The BDC establishes a secure channel to the PDC, and uses the NetLogon Service to verify the account database.
The BDC uses SMB or RPC calls (depending on the size of the update) to transfer the updated data.
This entire process could take as few as 12 frames, and under one second to complete (for the addition of two users). These 12 frames totaled 4,411 bytes of data in a test environment with full information for one user account, including full name, comment, and group membership. The second user did not have a full name or comment created. Two frames, one 1,138 bytes and the other 462, transferred the two user accounts.
Primary Domain Controller Announcement
When the primary domain controller detects a change to one of its databases, it notifies each backup domain controller that needs to be updated with an "Announce Change to UAS or SAM" message to the NETLOGON mailslot.
Depending on the primary domain controller name and the domain name, this frame will be approximately 392 bytes in size. The frame is directed to each backup domain controller, and is not a broadcast message.
The frame consists of the following:
A reference to UDP port 138 (NetBIOS Datagram Service) which is used to deliver the message.
The NBT header that includes both the Source primary domain controller and Destination backup domain controller names.
The SMB header that designates this frame as an operation code of "Write Mailslot", and the Path name is \MAILSLOT\NET\NETLOGON.
The remainder of the frame, approximately 175 bytes, is the NETLOGON header and data. The operation code is "Announce Change to UAS or SAM" and includes:
The serial number.
Encrypted date and time.
Pulse and Random parameter values.
The Primary DC Name and Domain Name values.
The version ID's, or serial numbers, for each of the three databases, as well as the Domain SID.
Periodic Update
When the backup domain controller receives the update announcement from the primary domain controller, it checks to verify the version numbers referenced in the announcement message. If the version ID's are later than the version ID's of the local databases, the backup domain controller requests the updated data. This is done through the following sequence of steps:
BDC connects to IPC$ of the PDC.
BDC establishes a secure channel to the PDC.
BDC uses NetLogon Service to verify the account database.
The updated data is transferred using SMB or RPC calls (depending on the size of the update).
BDC terminates the connection and session.
Complete Update
With Windows NT 3.5x, most synchronization events are partial updates. This means that the entire database is not delivered to the backup domain controller, rather, only updated records are transferred.
However, occasionally it is possible for a complete, or full, synchronization to occur. This generally happens in the following circumstances:
If a new backup domain controller is installed.
If the change log file fills, and starts wrapping (over-writing changes).
If the administrator using Server Manager forces an update.
If an error occurs during a partial synchronization attempt.
In this event, much more data is transferred between the primary domain controller and the backup domain controller than is probably necessary, but to ensure the integrity of the databases, the full data transfer occurs.
To force a backup domain controller to synchronize its databases with the primary domain controller, complete the following steps:
From Server Manager, select the backup domain controller.
From the Computer menu, choose Synchronize With Primary Domain Controller.
Choose Yes when prompted for confirmation to synchronize the controllers.
Choose OK to close the message referencing viewing the Event Log to verify the success of the update.
Establishing Trust Relationships
MIS often requires centralized administration of user accounts, while distributed control of resources is a wish of individual departments. In this environment, establishing an accounts domain, with multiple resource domains makes sense. To allow user accounts from the accounts domain to have access to resources in the resource domains, trust relationships need to be established.
In a trust relationship, one domain, the trusting domain, is allowed to assign permissions to users and global groups from another domain, called the trusted domain. Often, this process is accomplished by adding trusted accounts into local groups, and assigning the local group permissions to a resource.
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 trusting primary domain controller establishes a named pipe session with the server, and remotes one API call using RPC to the server. This API is to the SAMR, or SAM service, of the target server, and includes:
something...
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.
WAN Considerations
In larger organizations, a single domain may be implemented over multiple physically distinct locations. In this environment, it is important to make sure that user logon validation requests are able to be handled, regardless of the status of the WAN link. In this case, it would be necessary to place a backup domain controller at each remote site to ensure users could log on and become validated in the event the WAN link becomes unusable.
Additionally, it is important to ensure that the process of synchronizing the directory services account database does not utilize the entire WAN bandwidth. Using the entire WAN for account synchronization would effectively prevent user access to remote resources and applications during synchronization.
Database Synchronization over a WAN
Directory service database synchronization takes, on average, 1K per change if multiple changes are propagated, and as much as 4K for a single change. On a 56K point-to-point circuit, it would take about 24 hours to replicate a 30,000 user SAM.
There were several enhancements made to Windows NT 3.5 in order to reduce the frequency of full replication events, as well as allow for controlling the amount of data transferred during synchronization. These enhancement make it is less likely that a full synchronization event will occur in Windows NT 3.5x. (Refer to the previous list of instances requiring a full synchronization).
Additionally, by default Windows NT 3.5x primary domain controllers only send update notices to ten backup domain controllers at one time. When one of these controllers has completed its updating, a notice is sent to another backup domain controller. This also reduces the load on a WAN.
When a primary domain controller prepares to send updated data to a backup domain controller, the data is buffered in a 128K buffer. The primary domain controller can have synchronization messages on the network 100% of the time, effectively utilizing the entire network bandwidth, especially over a WAN. Note that this may effectively prevent user generated traffic from accessing the WAN.
It is also important to remember that by default, if the NetLogon service change log becomes full and starts wrapping, a backup domain controller would force a full synchronization event to occur. This could happen if the WAN link is somewhat unstable, resulting in partially completed synchronization events. In this case, the remote backup domain controller will need to force a full synchronization in order to ensure a valid directory services database.
In Module 4: "Analyzing and Optimizing Your Windows NT Server Network", parameters will be introduced that allow the network administrator to control the amount of data sent over a WAN connection during directory services synchronization. Also presented there is information on how many changes are recorded in the change log before overwriting occurs.