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.
WINDOWS NT ACCOUNTS
User Account:
A username and password in the Security Accounts Manager (SAM) database of a workstation, server, or domain controller. A user account can be either local or global.
Group Account:
An account that contains one or more user accounts whose purpose is to simplify sharing of and access to group-based resources. A group account can be either local or global.
Computer Account:
An account consisting of a computer name, followed by a dollar sign. The account is a member of the Domain Users global group in the SAM database of a domain controller. NT creates a computer account when a workstation, server, or Backup Domain Controller (BDC) joins a domain. Computer accounts provide secure communication between a workstation or server and a domain controller, and between domain controllers in the same domain.
Trust Account:
An account consisting of the trusted domain name preceded by G$$. NT creates this account between a domain controller in a trusted domain and a domain controller in a trusting domain when it establishes the trust relationship. Trust relationships ensure secure, interdomain communication and are essential for passthrough authentication.
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. 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:
The username does not exist in the local account database.
The username matches, but the password does not.
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.”)
THE NETLOGON SERVICE
Every Windows NT workstation, server, or domain controller has a Netlogon service. This service is responsible for communication between systems in response to a logon request, a domain synchronization request, and a request to promote a Backup Domain Controller (BDC) to a Primary Domain Controller (PDC). The Netlogon service performs several tasks when servicing network logon requests. It
selects the target domain for logon authentication
identifies a domain controller in the target domain to perform authentication
creates a secure channel for communication between Netlogon services on the originating and target systems
passes an authentication request to the appropriate domain controller
returns authentication results to Netlogon on the originating system
Netlogon is a key part of passthrough authentication. Passthrough authentication requires a secure communication channel between the Netlogon services on two systems: the originating, or local, system and a domain controller in the requested domain. Before they pass logon information between them, the Netlogon services on each system perform a handshake, called Challenge and Challenge Response, to validate the authenticity of the originating system. To ensure interdomain communication remains secure, PDCs change trusted account passwords weekly and synchronize the password change with the machine that owns the account.
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.
Critical Challenges of ESI & Email Retention Are you storing too much electronic information? Get expert legal advice and better understanding of what you are required to do as an IT professional.
Rev Up Your IT Know-How with Our Recharged Magazine! The improved Windows IT Pro provides trusted IT content with an enhanced new look and functionality! Get comprehensive coverage of industry topics, expert advice, and real-world solutions—PLUS access to over 10,000 articles online. Order today!
Get It All with Windows IT Pro VIP Stock your IT toolbox with every solution ever printed in Windows IT Pro and SQL Server Magazine plus bonus Web-exclusive content on hot topics. Subscribe to receive the VIP CD and a subscription to your choice of Windows IT Pro or SQL Server Magazine!
Order Your Fundamentals CD Today! Gain an introduction to Exchange, learn server security requirements, and understand how unified communications can play a role in your messaging strategies with this free Exchange CD.
Windows IT Pro
Register
