Appendix B: Analyzing Account Synchronization 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.

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:

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

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.

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.

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

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:

1. RPC Bind

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

1. RPC Request

2. RPC Response

3. RPC Request

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

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

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

• BDC terminates the connection and session.

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.

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:

1. From Server Manager, select the backup domain controller.

2. From the Computer menu, choose Synchronize With Primary Domain Controller.

3. Choose Yes when prompted for confirmation to synchronize the controllers.

4. Choose OK to close the message referencing viewing the Event Log to verify the success of the update.