Authentication Protocols
Windows 2000 Server and Windows XP Professional support several protocols for verifying the identity of users who claim to have accounts on the system. These include protocols for authenticating dial-up connections and protocols for authenticating external users who try to connect to the network over the Internet. However, the following authentication protocols are the primary choices for network authentication between Windows NT 4.0, Windows 2000, and Windows 2000 Server domains, and Windows XP Professional based clients:
-
Kerberos V5 protocol. The default authentication protocol for Windows 2000 and Windows XP Professional.
-
NTLM protocol. The default authentication protocol in Windows NT 4.0.
Even though the Kerberos V5 authentication protocol is the default for Windows 2000 Server and Windows XP Professional, both the network domain controllers and the client computers must be running Windows 2000 or Windows XP Professional for Kerberos authentication to be used. The alternative NTLM protocol is used for authentication if the following conditions exist:
-
Computers running Microsoft Windows 3.11, Microsoft Windows 95, Microsoft Windows 98, or Windows NT 4.0 use the NTLM protocol for network authentication in Windows 2000 domains.
-
Computers running Windows 2000 Professional or later or Microsoft Windows 2000 Server or later use the NTLM protocol to authenticate to servers running Windows NT 4.0.
-
Computers running Windows 2000 Professional or later and Windows 2000 Server or later use the NTLM protocol to authenticate when they are not participating in a domain. That is, when they operate as stand-alone computers or as part of a workgroup.
Protocol Selection
The following processes determine whether the Kerberos or NTLM protocol is used to complete the network authentication process:
-
After the user name and password are entered, the LSA passes this information to the Security Support Provider Interface (SSPI), an interface that communicates with both the Kerberos and NTLM services.
Tip SSPI also allows developers to write security-aware applications whether the Kerberos or NTLM protocol is used.
-
SSPI passes the user name and password to the Kerberos Security Support Provider (SSP), which exchanges messages directly with the domain s Kerberos Key Distribution Center (KDC). The Kerberos SSP determines whether the target computer name is the local computer or the domain name.
-
If the domain name is referenced, and the KDC recognizes the user name, the Kerberos authentication process proceeds.
-
If the user name is not recognized, the KDC passes an internal error message to the SSPI. If a KDC cannot be found, the following message (transparent to the user) is passed back to the LSA:
No logon server available.
-
The internal error message triggers the process to start over again. MSGINA passes the information to LSA again, and then LSA passes the information back to SSPI.
-
SSPI then passes the user name and password to the NTLM driver, MSV1_0 SSP. MSV1_0 then uses the Net Logon service to complete the NTLM authentication process.
If both the Kerberos and NTLM protocols fail to authenticate the user account, the following error message appears, and the user can try to log on again:
"The system could not log you on. Make sure your User name and domain are correct, then type you password again. Letters in passwords must be typed using the correct case. Make sure that Caps Lock is not accidentally on."
| Note | The same error message appears whether the password is typed incorrectly or the user name is not in the local SAM database. This is done to make it more difficult for an intruder to determine the reason that the logon attempt failed. |
NTLM
The NTLM protocol authenticates users and computers based on a challenge/response mechanism. When the NTLM protocol is used, a resource server must contact a domain authentication service on the domain controller for the computer or user s account domain to verify its identity whenever a new access token is needed.
| Note | In the absence of a domain, the NTLM protocol can also be used for peer-to-peer authentication. |
NTLM authentication in Windows 2000 and Windows XP Professional supports the following three methods of challenge/response authentication:
-
LAN Manager (LM). The least secure form of challenge/response authentication that is supported by Windows XP Professional, (but more secure than cleartext). LM is available so that computers running Windows XP Professional can connect to file shares on computers running Microsoft Windows for Workgroups, Windows 95, or Windows 98.
-
NTLM version 1. A more secure form of challenge/response authentication than LM. It is available so that computers running Windows XP Professional can connect to servers in a Windows NT domain that has at least one domain controller running Windows NT 4.0 Service Pack 3 or earlier.
-
NTLM version 2. The most secure form of challenge/response authentication that is supported by Windows XP Professional. It is used when computers running Windows XP Professional connect to servers in a Windows NT domain where all domain controllers are upgraded to Windows NT 4.0 Service Pack 4 or later. It is also used when computers running Windows 2000 or Windows XP Professional connect to servers running Windows NT in a Windows 2000 domain. In addition, computers running Windows 95 or Windows 98 can use this form of challenge/response authentication if the Directory Service Client Pack has been installed.
By default, all three challenge/response mechanisms are enabled so that clients running Microsoft Windows for Workgroups, Windows 95, or Windows 98 can access network resources. You can disable authentication that uses weaker variants by setting the LAN Manager authentication level security option in Local Security Policy\Computer Configuration\Windows Settings\Local Policies\Security Options or in the appropriate security template. If you do so, however, computers that rely on the weaker variants for authentication might not be able to access network resources.
For more information about configuring the LAN Manager authentication level, see Account Policies later in this chapter.
Interactive Logon with NTLM
The following process, shown in Figure 15-3, is essentially the same on any version of NTLM you use:
-
The user presses CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS) on computers that have a standard Windows XP Professional configuration. Winlogon calls a replaceable Graphical Identification and Authentication (GINA) dynamic-link library (DLL) to display a logon user interface.
-
After the user enters a user name and password, Winlogon sends the information to the LSA.
-
If the user s account is local to the computer, the LSA uses the MSV1_0 authentication package to compare the user s logon information with data in the computer s SAM database. If the user is not local to the computer, the LSA validates the user s credentials by using the MSV1_0 authentication package and Net Logon service to query the SAM on a Windows NT domain controller.
-
If the user s logon name and password are valid, the SAM communicates this information back to the LSA, along with the user s security identifier (SID) and the SIDs that apply to any groups that the user belongs to. The LSA uses this information to create an access token that includes the user s SIDs.
-
Winlogon starts the user s shell with the token attached.
Figure 15-3: NTLM logon process
Kerberos V5 Authentication Protocol
The Kerberos V5 protocol provides a means for mutual authentication between a client, such as a user, computer, or service, and a server. This is a more efficient means for servers to authenticate clients, even in the largest and most complex network environments. The Kerberos protocol is based on the assumption that initial transactions between clients and servers take place on an open network an environment in which an unauthorized user can pose as either a client or a server and intercept or tamper with communication between authorized clients and servers. Kerberos V5 authentication also provides secure and efficient authentication for complex networks of clients and resources.
The Kerberos V5 protocol uses secret key encryption to protect logon credentials that travel across the network. The same key can then be used to decrypt these credentials on the receiving end. This decryption and the subsequent steps are performed by the Kerberos Key Distribution Center (KDC), which runs on every domain controller as part of Active Directory.
An authenticator a piece of information such as a time stamp that is different each time it is generated is included with the encrypted login credentials to verify that previous authentication credentials are not being reused. A new authenticator is generated and incorporated with the KDC s encrypted response to the client to confirm that the original message was received and accepted. If the initial logon credentials and the authenticator are accepted, the KDC issues a ticket-granting ticket (TGT) that is used by the LSA to get service tickets. These service tickets can then be used to access network resources without having to re-authenticate the client as long as the service ticket remains valid. These tickets contain encrypted data that confirms the user s identity to the requested service. Except for entering an initial password or smart-card credentials, the authentication process is transparent to the user.
Interactive Logons Using Kerberos Authentication
The Kerberos authentication process was designed to be more secure and scalable across large, diverse networks than NTLM authentication. The Kerberos authentication process includes the following actions:
-
The user presses CTRL+ALT+DEL, the SAS on computers that have a standard Windows XP Professional configuration. Winlogon calls a replaceable Graphical Identification and Authentication (GINA) dynamic-link library (DLL) to display a logon user interface.
-
After the user enters a user name and password, Winlogon sends the information to the LSA.
-
When the logon request reaches the LSA, it passes the request to the Kerberos authentication package. The client sends an initial authentication request (AS_REQ), which includes the user s credentials and an encrypted timestamp to the KDC. This is a request for authentication and a TGT.
Note The logon request uses the principal name of krbtgt@ domain_name, where domain_name is the name of the domain in which the user account is located. The first domain controller in the domain generates the krbtgt@ domain_name account.
-
The KDC uses the secret key to decrypt the timestamp and issues a TGT to the client. This TGT (AS_REP) contains a session key, the name of the user to whom the session key was issued, the maximum lifetime of the ticket, and any additional data fields or settings that might be required. The AS_REP is encrypted in the user s key and returned to the user. The ticket is encrypted in the KDC s key and enclosed in the AS_REP. The authorization data portion of the TGT contains the SID for the user account and SIDs for any global and universal groups to which the user belongs.
Note The SIDs are returned to the LSA for inclusion in the user s access token. The maximum lifetime of a ticket is defined by the domain policy. If a ticket expires during an active session, the client requests a new ticket.
-
When the user attempts to access a resource, the client system uses the TGT to request a service ticket (TGS_REQ) from the Kerberos ticket-granting service on the domain controller (see Figure 15-4). The TGS then issues a service ticket (TGS_REP) to the client. This service ticket is encrypted using the server s secret key. The SIDs are copied by the Kerberos service from the TGT into all subsequent service tickets obtained from the Kerberos service.
Note This TGS session uses a separate session key than the earlier TGT transaction.
-
The client presents this service ticket directly to the requested network service. The service ticket proves both the user s identity and permissions to the service, and the service s identity to the user.
Figure 15-4: Logon process using the Kerberos V5 authentication protocol
For more information about Kerberos V5 authentication, see Logon and Authentication in the Distributed Systems Guide. For more information about configuring the Kerberos V5 authentication service, see Account Policies later in this chapter.
