This chapter is from the book
This chapter is from the book
This chapter is from the book
Logon Process
Having covered the basic components of the authentication process, we now examine how all these come together and function in Windows XP logons. We first examine the log-on types supported by XP.
Types of Logon
In Windows XP, just as in previous versions of Windows, users can log on over a variety of connections, including network, Internet, dial-up, and local logons. An account holder can attempt to make a connection to a resource and provide the appropriate identifying credentials, such as username and password, to a computer over any of these connection types. The four main types of OS authentication are: interactive, network, service, and batch. Dial-up authentication is covered in Chapter 12, Remote Access.
Interactive Logons
Interactive logons include log-on attempts from a user sitting at the physical workstation where the logon is occurring, users logging in via Terminal Services, and users logging in via Remote Desktop. Interactive logon credentials can be validated by a local accounts database, a domain SAM, or Active Directory.
Interactive logons utilize a number of components to pass credentials entered by the user to the appropriate account database for authentication. The first component is the Winlogon process. Winlogon.exe is a secure user mode process that launches when a user presses Control + Alt + Delete. After a user types that combination of keys, Winlogon calls the Microsoft Graphical Identification and Authentication DLL (MSGINA) to collect username name and password. The MSGINA provides the standard Windows log-on dialog box, but it can be replaced with a custom or third-party GINA.
Once the user has entered his or her username and password in the log-on dialog box and pressed enter, the MSGINA passes this information back to Winlogon, which in turn passes the credentials to the Local Security Authority, running as LSAS.exe. Finally, as discussed previously, the LSA determines whether authentication should occur locally or remotely, as demonstrated in Figure 16.2. The Winlogon process works with the MSGINA to pass user credentials to the LSA.
)
Figure 16.2 Components used in interactive logons
Network Logons
An account attempting to log on to a computer remotely (with the exception of Terminal Services, Remote Desktop, and dial-up) is said to be performing a network logon. The remote connection is attempted with the credentials you used to log on interactively. The LSA on the remote computer treats that logon as it would a local logon and uses the appropriate accounts database for authentication of the credentials it presented.
Service Logons
Users and computers are not the only entities that require authentication. Many applications require access to resources that are secured by the operating system. These resources may require the application to have an account so that the appropriate access can be given to the application. Just as a user has to have an account in the domain or on a computer where he or she is trying to print a document, an application or service also has to have the ability to log on to a computer or domain where it must access resources such as files or folders. These applications are given service accounts, which are then granted access to resources after successful authentication. As mentioned earlier in this chapter, there are three built-in service accounts in Windows XP: LocalSystem, Network Service, and LocalService; and it is also possible to create a service account manually. If you want a specific application to have access to certain protected folders or files, you may choose to create a special service account for that purpose.
When would you want to use a service account? Well, let's say that you have a Web site running on a Windows XP workstation that requires a specific application to always be running with it. You can add that application to the startup group to run automatically upon login, but that only works if someone is there to log in. If the computer crashes and reboots in the middle of the night and you are not there to log in after the reboot has completed, the application cannot start. However, you can configure that application (using a resource kit utility called srvany.exe) to run as a service and log on with a service account. It will automatically start up when the computer starts and does not require any human-user intervention.
Batch Logons
A batch logon is used by applications that run as a batch job, such as a job scheduled with the task scheduler. The job is logged on as a batch user by default in Windows XP, rather than as an interactive user.
Authentication Process
Now that you are familiar with the types of logons supported in Windows XP, as well as the basic components used to gather user credentials for logons, we look at how the actual authentication process takes place.
The Windows XP authentication process, like that of Windows 2000, supports multiple authentication protocols for use in a variety of log-on scenarios. The authentication protocol defines the process by which the supplied account credentials are verified. For the log-on types above, the protocols Windows XP uses for authentication are Windows NT LAN Manager (NTLM) and Kerberos. The default authentication protocol is Kerberos, with NTLM used as Windows XP's second choice. Windows XP determines which protocol to use based on a simple trial and error mechanism. If Kerberos authentication fails, the backup, NTLM, attempts to authenticate.
Here is how the protocol selection process works. After the username and password passes to the LSA, the LSA passes user credentials to the Security Support Provider Interface, or SSPI. The SSPI is the boundary between the LSA and the Kerberos and NTLM authentication providers. It is a protocol-independent interface, which has the benefit of allowing developers to write applications that can function with both Windows 2000 and Windows NT 4.0 domains. The SSPI hands-off the username and password to the Kerberos server for the appropriate domain. If the Kerberos server recognizes the credentials, authentication continues, and is either deemed successful or unsuccessful. If no Kerberos server is found, however, the LSA is notified to kick off the process once again. The LSA passes the user credentials to the SSPI, which in turn passes it to the NTLM service for authentication. If no authentication provider can provide authentication of the credentials, an error message is returned to the user. Figure 16.3 illustrates this process. This flowchart demonstrates the Windows XP authentication protocol selection process.
)
Figure 16.3 Selection of authentication protocol
Kerberos
The open network is full of risks. The computers connected to it may not be secured against intrusion, and the media over which network data flows can be easily tapped into. This means users can pose as someone else, computers can be fraudulently set up on the network to pose as legitimate servers, and data can easily be monitored or even modified. Both the client requesting logon and the server that provides the authentication service need to be mutually assured that they are speaking to the correct party.
Kerberos protocol is the namesake of the guardian of the gates of the underworld in Greek mythology. Kerberos, also commonly called Cerberus, was charged with preventing the living from entering and the dead from leaving the underworld. In the same way that Cerberus verified the identities of those entering and leaving the underworld, Kerberos also verifies the identity of parties communicating over a network. Kerberos is the default network authentication protocol for Windows XP and provides mutual authentication for both client and server involved in a transaction. This means that it verifies that both communicating parties are who they say they are. Kerberos version 5 is the version implemented within both Windows XP and Windows 2000, and is based on RFC 1510.
Shared Secret Overview
Kerberos uses shared secrets to validate identity. A shared secret is something that is known by all parties involved in a transaction, but by no one else. Let's say two spies, Boris and Alexandra, are meeting in a park to exchange information. When they arranged the meeting, they also came up with a secret code—"73"—so they can be mutually assured that Boris is speaking to Alexandra and Alexandra is speaking to Boris. Both parties arrive at the right place and time, and Boris walks up to the woman he believes to be Alexandra and says, "By any chance do you know the current temperature in San Jose?" to which Alexandra replies, "It's 73 degrees Fahrenheit in San Jose." Boris then says "I was last in San Jose in '73. It was a lovely place." At this point both parties have shared the mutual secret with each other and the information exchange can now occur, as illustrated in Figure 16.4. Shared secrets are used to mutually validate identity of both parties in a transaction.
)
Figure 16.4 Shared secret authentication
In order for this to have qualified as mutual authentication, the secret has to be repeated by each party to ensure that both sides know the secret. By hiding the secret in the conversation, it makes it difficult for eavesdroppers to understand exactly what portion of the conversation was the secret. Kerberos handles both these tasks as well as the added feature of acting as a trusted third party, distributing the secrets to parties that wish to conduct a transaction with each other, much as a secret intelligence team would provide this service to their own agents. Let's take a look at how this works with Kerberos.
Imagine that now Alexandra and Boris want to exchange information via computer, rather than in person. In the physical world, they have all sorts of spygadgets to protect their conversations in which they planned meetings and shared secret codes. They need to do the same thing with their computer-based communications. The first thing they have to do is determine how to share the secret code, or password, that will prove to both Boris and Alexandra that they are communicating with each other.
Because networks can be very insecure, they cannot just e-mail the password that they want to use. They need a way to ensure confidentiality. Someone could be sniffing packets as they come over the network for just such an e-mail. So how do you send a password to someone so that that person, and only that person, knows what the password is? Easy—you encrypt it and share the key to decrypt it. Kerberos does this by providing a single key that will encrypt and decrypt the password. This is known as symmetric secret key cryptography, and the "package" that contains the shared secret password is called an authenticator.
Another challenge facing Boris and Alexandra is that although they have protected the password, they need a way to be sure that someone scanning the network does not take those packets containing authenticators and reuse them to fraudulently pose as one party or the other. By using an authenticator that is different each time it is sent, it is possible to prevent these types of replay attacks. Kerberos provides this function by using a unique shared secret. It is encrypted with the secret key and decrypted by the secret key at the other end.
Now that you are familiar with the basic concepts of shared secret authentication with Kerberos, let's walk through an example of Boris and Alexandra using this protocol.
Boris and Alexandra need to send sensitive documents to each other across the network. Because this is top-secret information, Boris needs to be sure that it is actually Alexandra that he is contacting, and Alexandra likewise needs assurance that the person contacting her is actually Boris. Boris and Alexandra have decided that shared secret authentication is the way to handle this mutual identification validation, and now Boris has some information he needs to share with Alexandra. Here is the process that they use to authenticate each other:
-
As shown in Figure 16.5, Boris sends Alexandra a message that is encrypted with their secret key. The encrypted message contains the authenticator, which in turn contains two pieces of information. One piece identifies the sender as Boris and the other is the time on Boris' computer. The time stamp acts as a unique identifier, to prevent fraudulent reuse of the authenticator.
Figure 16.5 Boris makes initial contact with Alexandra. -
Alexandra receives the message from Boris, as shown in Figure 16.6. She decrypts the authenticator with the shared key and takes a look at the time stamp from Boris' computer. The time shown must be within the acceptable range of difference from the time on Alexandra's computer. For the sake of this discussion, let's say it must be within plus or minus two minutes. If the time is within that range, Alexandra can be reasonably sure it is Boris, but if it is not, then she can refuse to communicate with the person claiming to be Boris. It is still possible for that packet to have been replayed from a previous attempt by Boris to communicate with Alexandra, but the time stamp also acts as a unique identifier. If Alexandra had previously received an authenticator from Boris with an identical time stamp, the second one could be rejected. The same holds true of any time stamp that is from a time earlier than the last time stamp received.
Figure 16.6 Alexandra receives Boris' message. -
Because Alexandra is now reasonably sure that the authenticator that she received is from Boris, she responds to the message as shown in Figure 16.7. Alexandra removes just the time stamp from the message and encrypts it with the secret key. By doing so, she not only proves that she knows the secret, she also proves that she is able to decrypt and modify the message with the secret key that only Boris and Alexandra share. This assures Boris that it is actually Alexandra who is responding.
Figure 16.7 Alexandra replies to Boris' message. -
Boris receives Alexandra's response (shown in Figure 16.8) and decrypts it. Once he examines the time stamp and successfully compares it with the time stamp in his original authenticator, Boris can be confident that it was from Alexandra, since only he and Alexandra share that key.
Figure 16.8 Boris receives Alexandra's response.
)
Figure 16.5)
Figure 16.6)
Figure 16.7)
Figure 16.8Key Distribution and Tickets
The above scenario explains how Boris and Alexandra use secret keys to authenticate each other. But there is a large piece of information missing: Exactly how and where did Boris and Alexandra get their secret keys? They would like to exchange keys with each other and only each other, prevent others from being able to use the keys, and at the same time guarantee that the sender and receiver of the keys are really Boris and Alexandra. Involving a trusted party to provide the secret key is the way this problem is solved in Kerberos.
Let's take the example of Boris and Alexandra a step further. Both of these people need to communicate with other people and exchange information over the network, as well as connect to shared resources such as databases, printers, and e-mail. Each of these resources requires a secret key to mutually authenticate both the client and server in the transaction. If each user is required to have a different secret key for each resource he or she wants to access, the total number of secret keys required for all users and resources on the network could be huge—a potential management nightmare!
Kerberos solves the two problems of key distribution and management with a Key Distribution Center, or KDC. The KDC maintains a central database of keys and the accounts that they belong to. The group of accounts that the KDC is responsible for is called a realm. You can think of a realm as being analogous to a domain. The KDC is a service running on a Windows 2000 or Windows 2003 domain controller. In fact, all Windows 2000 and Windows 2003 domain controllers are Key Distribution Centers. In this section, we walk through the process of key distribution.
When a client wants to talk to a server to access resources located on that server, such as files or printers, the client sends a request for authentication to the KDC. Kerberos caches account passwords as a piece of encrypted data, called a long-term key, on both the client and the KDC. This long-term key is used to secure communications between the KDC and clients that use Kerberos for authentication. The authentication request is composed of two parts:
-
An identifier for the client that is requesting authentication and the service or resource the client wants to access.
-
An authenticator for the KDC that contains a time stamp from the client and the client's long-tem key.
Figure 16.9 illustrates such a request from a client.
)
Figure 16.9 A client requests authentication assistance from the KDC.
The KDC responds with a session key to be used by the client and server that wish to communicate. The session key is encrypted with the long-term key of the parties that will be communicating. The client's session key will be encrypted with the client's long-term key while the server's session key will be encrypted with the server's long-term key. The server's session key is grouped with the client's authorization level for the requested server or service. The two are encrypted together with the server's long-term key, and the resulting piece of information is called a session ticket. You can think of a ticket as a permit or license for accessing a server or service within a Windows 2000 domain. Tickets are required for accessing all resources in a Windows 2000 domain, including the log-on process. A session ticket is shown in Figure 16.10.
)
Figure 16.10 A session ticket
The first time the client contacts the KDC for authentication assistance, which occurs at logon, the KDC generates a session key for that client. In this case, the KDC is the service for which client authentication assistance is being requested. The KDC responds with a special session ticket called a TGT, shorthand for Ticket-Granting Ticket, which is to be used for further communication with the KDC itself. It contains two pieces of information:
-
A copy of the logon session key generated by the KDC
-
Client authorization data
Just as in the case of ordinary session tickets, the session key for the client is encrypted with the client's long-term key, while the TGT is encrypted in the KDC's long-term key. The TGT is illustrated in Figure 16.11.
)
Figure 16.11 A Ticket-Granting Ticket
Sending session keys to both the client and server would place a significant load on the system resources of the server where the KDC is running. Instead, the burden of session management is placed squarely upon the client. Both of these session keys are sent directly to the client that wishes to initiate communication with a server. The client is responsible for managing the ticket and all subsequent attempts to access resources with that ticket. By eliminating the need for the KDC to act as the manager of session messaging between client and server, the potential load on the memory of the server or servers running the KDC service is reduced. Making the client responsible for the session ticket management provides the additional benefit of allowing the client to directly contact the server without going through the KDC for a new session key each time it needs to access a network resource for which it has already been given session-specific information.
The session ticket is good for as long as the client remains logged on or until the ticket expires, whichever comes first. Typically, session tickets expire after eight hours. If a ticket is still valid at the time a user logs off, the ticket is destroyed to prevent unauthorized reuse of that ticket. The client can attempt to access the network resource for which it has been issued a ticket for as long as the session-specific data it has been given is valid. The client simply presents his or her ticket for a specific resource or server each time he or she attempts to access that resource.
We now look at how the Windows XP logon process works with Kerberos.
The Kerberos Logon Process
If a workstation is not part of a Windows 2000/2003 domain, there is no Kerberos authentication, so there is not a requirement for stand-alone work stations or Windows NT 4.0 domain members to have tickets to access resources. (Kerberos is an industry standard method of authentication. Because Microsoft's Kerberos implementation is interoperable with other implementations of Kerberos, it is possible that some sort of Kerberos authentication scheme could be used in the above scenario. That is beyond the scope of this book, however.) Windows 2000 domain members must have tickets for accessing any resources or services within the domain, including logon or services running on the local computer where a user has logged on.
So how does the user get a ticket from the KDC before logging on? Recall that all Windows 2000 domain controllers are also KDCs. When a user logging on from a Windows XP workstation attempts to contact the Windows 2000 domain controller for logon, he or she needs two pieces of data:
-
A TGT that allows access to the ticket-granting service
-
A ticket that allows access to the workstation used for logon
Figure 16.12 illustrates this activity.
)
Figure 16.12 The components required for Kerberos-based logon.
Now we walk through how this process takes place.
-
The user (Boris, for example) presses Control + ALT + Delete, also known as the Secure Attention Sequence. The MSGINA appears, Boris enters his username and password, and clicks OK. MSGINA hands the log-on credentials to Winlogon, which in turn passes them along to the LSA.
-
The LSA takes Boris' password and converts it to a preauthentication encrypted key that is stored in the workstation's credential cache and can be used by whatever authentication provider is indicated for the logon type, which in this case is for a Windows 2000 domain. The LSA hands this information to the Kerberos SSP, which handles communication with the KDC. The LSA interfaces with the Kerberos SSP as shown in Figure 16.13.
Figure 16.13 Kerberos and LSA interaction -
The Kerberos SSP sends the preauthentication key to the authentication service on the Kerberos server. This request contains the following items:
-
An identifier for the client that it wishes to be authenticated and the service or resource the client wants to access. In this case, the client is Boris and the specific service is the authentication service.
-
An authenticator for the KDC. It contains a time stamp from Boris and his preauthentication data (Boris' password as encrypted by the LSA).
-
-
On receipt of this authentication request, the KDC verifys that the time stamp contained within the package is within the range of time that is permissible for that realm. If it is acceptable, the KDC sends the Kerberos SSP a ticket-granting ticket for Boris to use. The actual data structure contains the following items:
-
The session key for Boris to use.
-
A TGT for the KDC that has been encrypted with the KDC's secret key, and includes a session key for Boris and the KDC to use when communicating with each other, as well as information detailing Boris' authorization level for the KDC. Now the Kerberos SSP is in possession of one of the two items Boris needs to complete his logon.
-
-
The Kerberos SSP receives this message and turns its attention to the matter of obtaining access to the ticket-granting service. The ticket-granting service provides the ticket that is needed to log on to the local workstation. The Kerberos SSP sends a message to the KDC that includes these pieces of information:
-
The name of the workstation Boris is attempting to log in from and the domain the workstation belongs to.
-
Boris' TGT and authenticator that are encrypted with the session key obtained in Step 4.
-
-
The KDC examines the request for access to the ticket-granting service and ensures its authenticity as discussed in the previous section. If the request is deemed legitimate, the KDC returns the following items to the Kerberos SSP for use by Boris:
-
A session key, encrypted with Boris' secret key, for Boris and the workstation to use when communicating with each other.
-
A session ticket for accessing the local workstation, which is encrypted with the workstation's secret key.
-
-
Now that the Kerberos SSP has both items required for logon, it can pass this information to the LSA, which handles the task of querying the local SAM to determine what authorization levels Boris has for this workstation. On completion of that query, an access token is created. (Access tokens are discussed in Chapter 17, Authorization and Access Control.) The LSA passes this token and confirmation of Boris' identity to Win logon, which completes the logon process and displays the Windows XP desktop.
)
Figure 16.13Windows NT LAN Manager
Windows NT LAN Manager (NTLM) is the authentication protocol used for credential validation when one of the computers is running Windows NT 4.0 or when computers involved in the authentication process are configured to act as stand-alone or workgroup members, specifically:
-
Windows XP authenticating to Windows XP computers in the absence of a domain
-
Windows XP authenticating to a Windows NT 4.0 domain
-
Windows XP authenticating to Windows for Workgroups, Windows 95, Windows 98, Windows 98 Second Edition, and Windows Me
-
Windows XP authenticating to Windows NT 4.0 computers running in a Windows 2000 domain
This is not an exhaustive list of all possible instances where NTLM could be used, but is instead a list of where Windows XP would use NTLM.
NTLM Types
NTLM relies on a challenge/response method for validation of username and password. Username and password are sent across the network as a hash, rather than in clear text. It does not provide mutual authentication; that is, verification that both the user and the authentication provider are who they say they are. Instead, it only provides authentication of the account being used to log on to a server.
There are three types of NTLM supported in Windows XP. Multiple versions provide backward compatibility to older versions of Windows and provide varying levels of security. The three NTLM types are as follows
-
LAN Manager: The oldest version of NTLM challenge/response provided by Windows XP is also the least secure. It is used when a Windows XP computer is attempting to authenticate to a computer running older versions of Windows: Windows for Workgroups, Windows 95, or Windows 98. If you are not planning to access any resources shared from workstations running these operating systems, you may wish to disable this protocol, because it is not as strong as the other versions of NTLM provided. The algorithm used to encrypt these passwords effectively limits password strength to seven characters and is not case sensitive. We cover disabling LAN Manager authentication in the next section, "Configuration and Recommended Practices."
-
NTLM version 1: NTLM version 1 provides a more secure method of authentication than LAN Manager. It uses 56-bit encryption, allowing it to have an effective password strength of 14 characters and also allows both upper- and lowercase characters to be used. It is used on Windows NT 4.0 Service Pack 3.0 and earlier domains.
-
NTLM version 2: With the advent of Windows NT 4.0 Service Pack 4, a newer and more secure challenge/response mechanism was made available. NTLM version 2 offers message integrity, 128-bit encryption, and session-level security. Session security is provided by the use of separate keys for message integrity and confidentiality. The RFC-compliant HMAC-MD5 algorithm used in NTLMv2 provides message integrity checking, and 128-bit encryption is used for message confidentiality.
Authentication Process
As you have learned, user authentication in Windows XP uses the LSA to pass credentials to the authentication provider. NTLM is the fallback authentication provider for Windows XP, used when Kerberos is not available. NTLM uses the MSV1_0 Authentication Package, which references the SAM database as its user accounts database.
There are two parts of MSV1_0; one that runs on the computer where the logon was initiated, and the other that runs on the computer where the account is located, as shown in Figure 16.14. If the log-on computer also houses the user account, then both portions run on the same computer. If the user account is located on a remote machine, MSV1_0 hands the request to the Netlogon service, which in turn sends the request to the remote machine.
)
Figure 16.14 NTLM uses MSV1_0 to authenticate accounts.