- Security Model
- Securing Objects
- SAM Database
- The Flow of a User Logon
- Summary
The Flow of a User Logon
An interactive user logon begins when a user at the local console activates the SAS (by pressing Ctrl+Alt+Del). Similarly, a network logon begins when the NetLogon service receives a request over the network for logon.
On activation of the SAS, WINLOGON jumps into action and switches to the secure desktop. Capturing of the user's credentials is handled by functions in the GINA, which WINLOGON calls at this time. Under the default configuration, WINLOGON displays the familiar security interaction dialog shown in Figure 3.11.
){kind=link}
Figure 3.11 The familiar security interface dialog provided by the default GINA, MSGINA.
WINLOGON also creates a new, unique local group for this user and assigns the local console to this user. You saw this group in the analysis of SIDs previously.
WINLOGON is now ready to call the LSA to authenticate and authorize this logon. A call to LsaLogonUser contains the credentials the user provided, as well as the group that was just created. In the event of a network logon, the NetLogon service makes the call to LsaLogonUser; WINLOGON doesn't get involved because WINLOGON controls the local console only.
If this is a domain logon, meaning that the user specified in the logon dialog that the account resided on a machine other than the local one, the LSA attempts to use Kerberos to authenticate with the active directory. The LSA locates a nearby AD Key Distribution Center (KDC) server and forwards to the KDC a request that includes the client's name domain name. The AD server looks up the username in the AD and returns a ticket-granting ticket (TGT) to the LSA, part of which is encrypted with the client's secret key (password). Assuming the client knows the correct secret, the TGT can be decrypted and used to obtain a another ticket, allowing access to the local workstation (and to any additional resources the client requests in the future). The TGT also contains the user's SIDs, which are passed back to LSA for later inclusion in the user's token. I talk much, much more about Kerberos and AD in later chapters.
NOTE
Multiple cryptographic protocols are available for Windows 2000 to authenticate logon requests. In previous versions of Windows NT, the MSV1_0 protocol was used extensively. MSV is based on ancient Microsoft LanManager technology, is very dated, and has multiple vulnerabilities that were exploited in previous versions of Windows NT. The addition of Kerberos, a strong, well-tested protocol, is truly one of Windows 2000's best new security features. I discuss Kerberos in detail in Chapter 11.
Naturally, Windows 2000 must support MSV1_0 to maintain backward compatibility with Windows NT 4.0 domains. For a domain logon to a Windows 3.x or 4.x domain, the LSA uses the MSV1_0 protocol to authenticate.
The Registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages, as shown in Figure 3.12, lists the authentication packages available to Windows 2000.
){kind=link}
Figure 3.12 The Kerberos package, as well as MSV1_0 and Schannel, ships with Windows 2000.
For a local account, the LSA uses MSV1_0 to authenticate with the local SAM. MSV accomplishes the same type of thing that the Kerberos negotiation accomplishes—namely the verification of the user's credentials and the obtaining of account information (SIDs) for the LSA.
No matter which protocol is used, if the logon is authentic and allowed by policy, the LSA winds up with the user's SIDs, a hash of the user's password, and any account policy restrictions (such as hours or type of access). If the logon isn't allowed due to restrictions, the authentication procedure fails.
Let's pick up an authentic, allowed logon from there.
Next, a unique logon user ID, or LUID, is created and the LSA associates this LUID with the user and session. This information is gathered for the eventual creation of an access token.
The LSA checks the local policy database to make sure the logon type, in this case interactive, is allowed. It also checks for any other system policies that might forbid the logon. If the logon isn't allowed by the local workstation, the LSA terminates the logon procedure, cleans up, and returns an appropriate error to WINLOGON.
If the logon is allowed, the LSA adds other appropriate SIDs such as everyone, interactive, authenticated user, and so on. Next, the LSA augments this user's existing list of privileges with any granted to those new SIDs.
When the LSA assembles all of this information, it calls on the Executive to create the user's token. The Executive creates a primary access token for the interactive logon but would have created an impersonation token had this been a network logon. The Executive passes a handle to the new token back to the LSA, and, if necessary, the logon operation is audited and logged to the event log. In addition to the handle to the user's token, the LSA also passes back to WINLOGON the LUID as well as any profile information (such as user's home directory and logon script) contained in the AD or SAM.
Following the example of an interactive logon, WINLOGON starts USERINIT.EXE to create the local shell. I talked about the process from here in Chapter 1.