Windows NT Authentication

An important part of Windows NT administration is control over useraccess to systems within and across domains. When a user logs on to an NTsystem, NT validates the user's account and authorizes access to the appropriatesystem or domain. To manage user access, you need to understand the Windows NTlogon process and the three types of interactive logons--local, domain, andtrusted 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 inExplorer or File Manager or enter a net use command from a console window orscript file. Before reading further, you need to be familiar with the differenttypes of user and group accounts (see "Windows NT Accounts") and howto create or modify them with User Manager. You also need to understand howWindows NT creates a computer account when you add a new workstation or serverto a domain, either during the installation process or explicitly in ServerManager. And finally, you need to know how the system creates interdomain trustaccounts when you establish a domain trust relationship in User Manager. (Formore information about these concepts, see "Related Articles from WindowsNT Magazine.")

Local Logon
When you log on to an NT system, you specify a username, password, anddomain name in the logon dialog's From: field. The domain name is strictlyassociated with a Security Accounts Manager (SAM) database, which contains userand group accounts and rights, and security policies. (For more information onthe SAM, see Ed Tittel and Mary Madden, "PDCs, BDCs, and Availability,"August 1996.) On an NT workstation or server (not a domain controller), youselect the local machine name or the name of any domain in the From: field'spulldown list. When you enter the local machine name, you direct NT to validatethe account against the local, machine-specific SAM database. Note that when anNT 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 computeraccount in a domain, that domain also appears in the From: list. And if thedomain in which a computer account exists trusts other domains, the trusteddomains also appear in the From: list.

The Local Security Authority (LSA--see lsass.exe in the process list ofTask 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 system32directory of the system root. (Third-party vendors can offer replacements forMSV1_0 to perform custom logon validation, such as code that authenticates usersby voice or fingerprint recognition.)

MSV1_0 consists of two parts. The top half executes on the system you arelogging on to (the local system), and the lower half runs on the system thatcontains the requested domain SAM database (for a local logon, both parts run onthe same computer). The top half of MSV1_0 encrypts the text password entered inthe 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 passwordin 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 andpassword and selects Aspen in the From: field's pulldown list. Winlogon, the NTcomponent that presents the dialog, passes the logon credentials to the LSA, andthe LSA invokes MSV1_0 to validate the credentials.

The top half of MSV1_0 encrypts the password and determines that therequested domain, Aspen, matches the local workstation domain. MSV1_0 thenpasses the username, a function of the encrypted password that it has computed,and the domain name (Paula, xxxxxx, and Aspen) to the lower half ofMSV1_0. The lower half of MSV1_0 asks the SAM to validate the username andpassword, which it does by checking for a match in the local SAM database. Atthis 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 passesthe data back to the LSA. You see the following Logon Message:

The system could not log you on. Make sure your username and domain arecorrect, then type your password again.

If the account and password encryptions match, the SAM returns a SecurityIdentifier (SID) that describes the rights and group membership associated withusername Paula to the lower half of MSV1_0. The lower half of MSV1_0 returnsthis information to the top half of MSV1_0, and then back to the LSA. In thefinal authentication step, the LSA constructs an access token that containsPaula's rights and group membership and attaches it to the process created forher on workstation Aspen.

The access token defines Paula's rights and group membership, based on heraccount in User Manager on the local workstation. The rights control whichoperations Paula can perform (e.g., log on locally or access thiscomputer from the network), and group membership controls the resourcesPaula can access once she is logged on. For example, if Paula is a member of theEngineers group and the engineers have group directories, files, or a privateprinter, Paula can access the group resources, even though other users cannot.

If the administrator changes Paula's rights or group membership, the SIDwill reflect those changes the next time she logs on. In other words, NTrecreates the SID each time a user logs on; this is the primary mechanism thatenforces 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 thelocal system name). To log on to a domain, the originating, or local, systemmust have a computer account in the domain. If your system's computer accountisn't in the domain, Winlogon displays an error message stating that no computeraccount exists in the requested domain. Netlogon records this error condition inthe system log as Event ID 5721; the text of the message indicates that thesession setup to the NT domain controller failed.

If the local system has an account in the requested domain, the logonprocess 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 inFigure 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 namethat 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 youspecified. This process is called passthrough authentication.

MSV1_0 compares the requested domain against the name of the localworkstation, and because they are different, determines that passthroughauthentication is required. As shown in Figure 2, MSV1_0 passes the logoncredentials to Aspen's Netlogon service, which examines the cached list ofpreviously discovered systems to locate a Wildwood domain controller. (NTsystems generally find each other with NetBIOS broadcasts issued after a systemboots and regularly thereafter, or via an lmhosts file or Windows Internet NameService--WINS--servers if they're available.) Aspen's Netlogon then routes thelogon credentials to Netlogon on the closest Wildwood domain controller, via aremote procedure call (RPC). When the domain controller's Netlogon servicereceives the logon credentials, it passes them to the lower half of MSV1_0 forauthentication and requests the domain SIDs. (For more information aboutNetlogon, see "The Netlogon Service")

Assuming user account Paula exists in the Wildwood domain, the SAM returnsSIDs to the lower half of MSV1_0, which passes them back to Netlogon on theWildwood domain controller. Wildwood's Netlogon returns the SIDs associated withPaula's domain account to Aspen's Netlogon, which returns the same informationto 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 thatcontains 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 therights and group memberships defined at the local workstation where she logs on.For example, Paula has access this computer from the network right inthe Wildwood domain, and she has membership in the global Domain Users andEngineers groups. On the local workstation, Paula has the log on locallyright, and she is a member of the local Administrators group. To accuratelydefine rights in the domain and on the local machine, the LSA on Aspenconstructs the access token using the domain SIDs and local system SIDs, and theauthentication 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 atrust relationship with Wildwood. Paula logs on and requests domain Wildwood.Because Skunkworks trusts Wildwood, the Skunkworks domain controllerautomatically forwards Paula's logon credentials to a Wildwood domain controllerfor authentication.

After Paula enters her logon information, Aspen's LSA passes thatinformation to the top half of MSV1_0. MSV1_0 determines the requested domain isnonlocal and passes the logon credentials to Netlogon. Netlogon forwards thelogon request to a domain controller where the computer account resides, inSkunkworks. Netlogon on the Skunkworks domain controller forwards the logoncredentials via an RPC to the Netlogon service on the nearest Wildwood domaincontroller.

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 themto the local Netlogon service (Wildwood). Netlogon returns the SIDs to Netlogonon the Skunkworks domain controller, which routes the information back toNetlogon on Aspen, the originating workstation. To complete the process, Aspen'sLSA uses the returned SIDs and any SIDs on the local system to construct theaccess token.

Authentication Accomplished
Now you understand how NT local, domain, and trusted domain logons work. Youcan use this knowledge to set up accounts and establish domains that effectivelymeet users' needs while restricting system access appropriately.