Windows NT UAS Replication (Windows NT and LAN Manager)

ID: q102717


The information in this article applies to:
  • Microsoft Windows NT operating system version 3.1
  • Microsoft Windows NT Advanced Server version 3.1


SUMMARY

This article discusses Windows NT UAS replication and the differences between Windows NT and Microsoft LAN Manager.


MORE INFORMATION

The NetLogon service on each Windows NT Advanced Server replicates both the security accounts manager (SAM) and local security authority (LSA) security databases. The security databases are replicated from the Domain Controller in the domain to all the Windows NT Advanced Servers in the domain. (The security database is also replicated to LAN Manager BDCs in the Windows NT domain by using the same protocols and procedures that LAN Manager uses.)

Replication does not apply to Windows NT workstations. The security databases are actually three separate databases: the SAM Accounts database, the SAM Built-in database, and the LSA database. Each database is replicated as described below. The SAM Built-in database contains all the default local groups installed with the system. The SAM Accounts database include all other SAM objects: users, global groups, site-specific local groups, and global security policy. The LSA database contains user rights, secret objects, and trusted domain objects.

Security database replication is "pull" replication. That is, each Advanced Server in the domain independently recognizes that replication is needed and then makes API calls to the Domain Controller to pick up the requisite changes. Each Advanced Server then updates its own security database.

The replication paradigm is almost identical to that used by LAN Manager. Two types of replication occur: "Full Sync" replication and "Partial Sync" replication. These are described below.

Full Sync Replication

Full sync replication copies the entire security database from the Domain Control to the Windows NT Advanced Server. Full sync replication occurs when any one of the following circumstances exists:

  • When NetLogon starts on the Advanced Server and any of the following are true:


    • If the netlogon\parameters\update field in the registry is TRUE.


    • If the Advanced Server was doing a full sync replication when NetLogon was last stopped.


    • If this is the first boot after installation.


  • If the Domain Controller changes.


  • If the user interface (UI) forces a full sync replication.


  • If the Domain Controller tells the Advanced Server to do full sync replication with any of the following conditions:


    • If the change log, %SystemDirectory%\netlogon.chg, wraps.


    • If the Domain Controller crashes in the middle of a previous full sync replication.


    • If the serial number of a database wraps.


  • If the Advanced Server, gets an error from SAM or the LSA while updating the database on a partial sync replication.


To do full sync replication, the Advanced Server performs a remote I_NetDatabaseSync API call to the Domain Controller. I_NetDatabaseSync returns up to 128K of security database data on each call. NetLogon unpacks the received data and updates the information in the security database. If all the data wasn't retrieved in a single call, the Advanced Server calls I_NetDatabaseSync again to retrieve more data. This process is repeated for the SAM Account database, the SAM Built-in database, and the LSA database.

Partial Sync Replication

Partial sync replication ensures individual changes made to the security database on the Domain Controller are updated on the other Advanced Servers in the domain. The Domain Controller sends a periodic pulse to the other Advanced Servers in the domain. The pulse message contains the serial number of each database. Each Advanced Server checks to see if the serial number in the message is greater than the one on its local copy of the database. If it is, that Advanced Server asks for the changes by sending an I_NetDatabaseDeltas API call to the Domain Controller. I_NetDatabaseDeltas returns up to 128K of security database data on each call. NetLogon unpacks the received data and updates the information in the security database. If all the data wasn't retrieved in a single call, the Advanced Server calls I_NetDatabaseDeltas again to retrieve more data.

The pulse message is sent to the \mailslot\net\netlogon second-class mailslot. The pulse message is first sent to all Windows NT Advanced Servers in the domain by sending it to the XXX<1C> NetBIOS group name where "XXX" is the name of the domain and "<1C>" is the hexadecimal value of the 16th byte of the name. All Windows NT Advanced Servers in the domain register this global group name and receive this mailslot message. The NBT (NetBIOS over TCP/IP) transport treats this <1C> name specially. It first broadcasts to the group name and then does individual sends to all machines in domain "XXX" as determine by the lmhosts file. This ensures the mailslot send reaches all Advanced Servers in the domain even if they reside on a different subnet than the Domain Controller. The NetLogon service on the Domain Controller repeats this mailslot send to each LAN Manager server in the domain (since they don't have the <1C> address registered). The mailslot message is sent individually to each server that is a member of the SERVERS global group name. You should ensure that the SERVERS global group only contains member of this domain to prevent the LAN Manager server from receiving mailslot messages from a domain of which it is not a member.

The Domain Controller keeps track of the changes made to the security databases by recording them in the change log, %SystemDirectory%\netlogon.chg. Each change to the security databases is recorded in the change log along with the serial number of the change. (The serial number is maintained separately for each of the three security databases. It is incremented once for each change to the databases.) Later, when an Advanced Server requests a particular change from the Domain Controller (by calling I_NetDatabaseDeltas), the Domain Controller consults the change log to determine what the change was.

Secure Channel

Each Windows NT Advanced Server sets up a secure channel to the Domain Controller in the domain. A server trust account is set up for the Advanced Server on the Domain Controller. This account is set up either from the Server Manager (srvmgr) by selecting Add to Domain from the Computer menu or directly when the Windows NT Advanced Server is set up if an administrator account name is specified when the Advanced Server joins the domain. At this time, the password on the account is set to a well-known constant (the server name in lowercase, truncated to 14 characters).

In either case, when the Advanced Server is set up, it stores the password for the account in LSA secret storage in a secret file named $machine.acc. The NetLogon service on the Advanced Server immediately changes this default password the first time it is started and once a week thereafter to ensure it is kept secret.

To set up the secure channel, the Advanced Server calls I_NetServerRequestChallenge, passing the Domain Controller a challenge. The challenge is a pseudo-random number based on the time of day and a serial number. Both the Advanced Server and the Domain Controller use the two challenges and the password known by each machine to compute a Session Key. Each machine then computes a credential as its own challenge encrypted by the Session Key. The Advanced Server then calls I_NetServerAuthenticate, passing the Domain Controller its credential and then returning the Domain Controller's credential. Each machine local recomputes its partners credential, thereby verifying that the partner knows the shared password. The I_NetDatabaseSync and the I_NetDatabaseDeltas application program interface (API) functions are only valid across this secure channel to prevent others from calling these APIs and getting a copy of the security databases.

Additional query words:

Keywords : kbnetwork
Version : 3.1
Platform : WINDOWS
Issue type :


Last Reviewed: August 27, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.