An important part of Windows NT administration is control over user access to systems within and across domains. When a user logs on to an NT system, NT validates the user's account and authorizes access to the appropriate system or domain. To manage user access, you need to understand the Windows NT logon process and the three types of interactive logons--local, domain, and trusted domain--that NT uses to validate accounts on a local or remote system. You initiate another type, a remote logon, when you map a network drive in Explorer or File Manager or enter a net use command from a console window or script file. Before reading further, you need to be familiar with the different types of user and group accounts (see "Windows NT Accounts") and how to create or modify them with User Manager. You also need to understand how Windows NT creates a computer account when you add a new workstation or server to a domain, either during the installation process or explicitly in Server Manager. And finally, you need to know how the system creates interdomain trust accounts when you establish a domain trust relationship in User Manager. (For more information about these concepts, see "Related Articles from Windows NT Magazine.")
Local Logon
When you log on to an NT system, you specify a username, password, and
domain name in the logon dialog's From: field. The domain name is strictly
associated with a Security Accounts Manager (SAM) database, which contains user
and group accounts and rights, and security policies. (For more information on
the SAM, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability,"
August 1996.) On an NT workstation or server (not a domain controller), you
select the local machine name or the name of any domain in the From: field's
pulldown list. When you enter the local machine name, you direct NT to validate
the account against the local, machine-specific SAM database. Note that when an
NT workstation or member server does not have a computer account in a domain,
the From: list shows only the local system name. Once NT creates a computer
account in a domain, that domain also appears in the From: list. And if the
domain in which a computer account exists trusts other domains, the trusted
domains also appear in the From: list.
The Local Security Authority (LSA--see lsass.exe in the process list of Task Manager) manages NT authentication. The LSA initiates interactive, service, and network logon processing and invokes the native authentication package, MSV1_0, to perform the authentication. The msv1_0.dll is in the system32 directory of the system root. (Third-party vendors can offer replacements for MSV1_0 to perform custom logon validation, such as code that authenticates users by voice or fingerprint recognition.)
MSV1_0 consists of two parts. The top half executes on the system you are logging on to (the local system), and the lower half runs on the system that contains the requested domain SAM database (for a local logon, both parts run on the same computer). The top half of MSV1_0 encrypts the text password entered in the logon dialog, and passes the logon credentials to the lower half of MSV1_0. The lower half compares the logon credentials against the username and password in the requested SAM database and either validates or refuses the logon request.
Figure 1 shows how a local logon works. User Paula logs on to workstation Aspen, which can be a standalone workstation or server. A local logon does not require a computer account in an NT domain. Paula enters her username and password and selects Aspen in the From: field's pulldown list. Winlogon, the NT component that presents the dialog, passes the logon credentials to the LSA, and the LSA invokes MSV1_0 to validate the credentials.
The top half of MSV1_0 encrypts the password and determines that the requested domain, Aspen, matches the local workstation domain. MSV1_0 then passes the username, a function of the encrypted password that it has computed, and the domain name (Paula, xxxxxx, and Aspen) to the lower half of MSV1_0. The lower half of MSV1_0 asks the SAM to validate the username and password, which it does by checking for a match in the local SAM database. At this point, three possibilities exist:
1. The username does not exist in the local account database.
2. The username matches, but the password does not.
3. The username and password both match.
In case 1 or 2, the SAM returns this information to MSV1_0, which passes the data back to the LSA. You see the following Logon Message:
The system could not log you on. Make sure your username and domain are correct, then type your password again.
If the account and password encryptions match, the SAM returns a Security Identifier (SID) that describes the rights and group membership associated with username Paula to the lower half of MSV1_0. The lower half of MSV1_0 returns this information to the top half of MSV1_0, and then back to the LSA. In the final authentication step, the LSA constructs an access token that contains Paula's rights and group membership and attaches it to the process created for her on workstation Aspen.
The access token defines Paula's rights and group membership, based on her account in User Manager on the local workstation. The rights control which operations Paula can perform (e.g., log on locally or access this computer from the network), and group membership controls the resources Paula can access once she is logged on. For example, if Paula is a member of the Engineers group and the engineers have group directories, files, or a private printer, Paula can access the group resources, even though other users cannot.
If the administrator changes Paula's rights or group membership, the SID will reflect those changes the next time she logs on. In other words, NT recreates the SID each time a user logs on; this is the primary mechanism that enforces the object-based security model in Windows NT.
Domain Logon
NT uses a slightly different authentication process for a domain logon
(i.e., when the domain name specified in the logon dialog is different from the
local system name). To log on to a domain, the originating, or local, system
must have a computer account in the domain. If your system's computer account
isn't in the domain, Winlogon displays an error message stating that no computer
account exists in the requested domain. Netlogon records this error condition in
the system log as Event ID 5721; the text of the message indicates that the
session setup to the NT domain controller failed.
If the local system has an account in the requested domain, the logon process is straightforward, as you see in Figure 2. During a domain logon, MSV1_0's top half runs on the system where you log on (workstation Aspen in Figure 2) and the lower half runs on the system where the account is located (the Wildwood Primary Domain Controller, or PDC). When you enter a domain name that is different from the local system name, your logon information (username, domain, and password) must find its way to a domain controller in the domain you specified. This process is called passthrough authentication.
MSV1_0 compares the requested domain against the name of the local workstation, and because they are different, determines that passthrough authentication is required. As shown in Figure 2, MSV1_0 passes the logon credentials to Aspen's Netlogon service, which examines the cached list of previously discovered systems to locate a Wildwood domain controller. (NT systems generally find each other with NetBIOS broadcasts issued after a system boots and regularly thereafter, or via an lmhosts file or Windows Internet Name Service--WINS--servers if they're available.) Aspen's Netlogon then routes the logon credentials to Netlogon on the closest Wildwood domain controller, via a remote procedure call (RPC). When the domain controller's Netlogon service receives the logon credentials, it passes them to the lower half of MSV1_0 for authentication and requests the domain SIDs. (For more information about Netlogon, see "The Netlogon Service")
Assuming user account Paula exists in the Wildwood domain, the SAM returns SIDs to the lower half of MSV1_0, which passes them back to Netlogon on the Wildwood domain controller. Wildwood's Netlogon returns the SIDs associated with Paula's domain account to Aspen's Netlogon, which returns the same information to the top half of MSV1_0 on Aspen, and then on to the LSA on Aspen.
The LSA on Aspen then constructs an access token for Paula's process that contains two sets of SIDs. In a domain logon, the security model is two-tiered. The first tier consists of Paula's domain account rights and group memberships, which the Wildwood domain administrator assigns. The second tier comes from the rights and group memberships defined at the local workstation where she logs on. For example, Paula has access this computer from the network right in the Wildwood domain, and she has membership in the global Domain Users and Engineers groups. On the local workstation, Paula has the log on locally right, and she is a member of the local Administrators group. To accurately define rights in the domain and on the local machine, the LSA on Aspen constructs the access token using the domain SIDs and local system SIDs, and the authentication process is complete.
Trusted Domain Logon
Figure 3 shows the trusted domain logon process. Workstation Aspen has a computer account in domain Skunkworks. User Paula doesn't have an account in Skunkworks but does have an account in domain Wildwood, and Skunkworks has a
trust relationship with Wildwood. Paula logs on and requests domain Wildwood.
Because Skunkworks trusts Wildwood, the Skunkworks domain controller
automatically forwards Paula's logon credentials to a Wildwood domain controller
for authentication.
After Paula enters her logon information, Aspen's LSA passes that information to the top half of MSV1_0. MSV1_0 determines the requested domain is nonlocal and passes the logon credentials to Netlogon. Netlogon forwards the logon request to a domain controller where the computer account resides, in Skunkworks. Netlogon on the Skunkworks domain controller forwards the logon credentials via an RPC to the Netlogon service on the nearest Wildwood domain controller.
At this point, the authentication process is the same as a domain logon. MSV1_0 asks the SAM on the Wildwood domain controller for SIDs and returns them to the local Netlogon service (Wildwood). Netlogon returns the SIDs to Netlogon on the Skunkworks domain controller, which routes the information back to Netlogon on Aspen, the originating workstation. To complete the process, Aspen's LSA uses the returned SIDs and any SIDs on the local system to construct the access token.
Authentication Accomplished
Now you understand how NT local, domain, and trusted domain logons work. You
can use this knowledge to set up accounts and establish domains that effectively
meet users' needs while restricting system access appropriately.
