Windows 2000 is designed to use Kerberos v5 as the default authentication protocol. Kerberos v5 provides more flexibility in authentication than the NTLM authentication protocol did.
After this lesson, you will be able to
Estimated lesson time: 45 minutes
Reviewing Kerberos Components
This lesson examines in detail how Kerberos authentication is used as the default authentication mechanism for Windows 2000–based computers. Before we start looking into design considerations of how Kerberos authentication works and how you can optimize and secure Kerberos authentication, let's look at the core components of Kerberos authentication. The components of the Kerberos v5 protocol include
- Key distribution center (KDC). A network service that supplies both ticket-granting tickets (TGTs) and service tickets to users and computers on the network. The KDC manages the exchange of shared secrets between a user and a server when they authenticate with each other. The KDC contains two services: the Authentication Service and the Ticket Granting Service. The Authentication Service provides the initial authentication of the user on the network and provides the user with a TGT. Whenever users request access to a network service, they supply their TGT to the Ticket Granting Service. The Ticket Granting Service then provides the user with a service ticket for authentication with the target network service. In a Windows 2000 network, the KDC service is run at all Windows 2000 DCs.
In some cases, a computer account must also request a TGT. Because a computer is also a security principal in a Windows 2000 network, the process proceeds in the same manner as user authentication, except that a computer account is being authenticated.
- TGT. Provided to users the first time they authenticate with the KDC. The TGT is a service ticket for the KDC. Whenever the user needs to request a service ticket for a network service, she presents the TGT to the KDC to validate that she has already authenticated with the network.
For additional security, Windows 2000 by default always verifies that the user account is still active every time a TGT is presented to the KDC. In other words, the KDC verifies that the account hasn't been disabled. If the account has been disabled, the KDC won't issue any further service tickets to the user.
- Service ticket. The user provides a service ticket whenever he connects to a service on the network. The user acquires the service ticket by presenting the TGT to the KDC and requesting a service ticket for the target network service. The service ticket contains the target server's copy of a session key and also contains information about the user who's connecting. This information is used to verify that the user is authorized to access the desired network service by comparing the authentication information—namely, the user's Security Identifier (SID) and their group SIDs—against the Discretionary Access Control List (DACL) for the object that the user is seeking access to. The service ticket is encrypted using the key that's shared between the KDC and the target server. This ensures that the target server is authenticated because only the target server can decrypt the session key.
- Referral ticket. Issued anytime a user attempts to connect to a target server that's a member of a different domain. The referral ticket is actually a TGT to the domain where the resource is located that's encrypted using the interdomain key between the initial domain and the target domain.
These four components allow Kerberos authentication to take place between Windows 2000 clients and Windows 2000 DCs.
Kerberos provides the following advantages over the NTLM protocol:
You can view your ticket cache at any time by using Microsoft Windows 2000 Server Resource Kit utilities. Klist.exe provides a text-based listing of your currently cached TGTs and STs. The Kerbtray.exe utility provides a graphical viewing of the currently cached tickets. The Kerbtray.exe utility loads an easily accessible icon in the system tray.
Kerberos v5 is defined in RFC 1510. You can obtain a copy of this RFC by going to http://www.ietf.org/rfc and searching for "RFC 1510."
Three different message exchanges are used within Kerberos. All Kerberos authentication transactions will be composed from these three message exchanges.
The Kerberos message exchanges are
In the case of a failed authentication, all three message exchanges would replace the response sent from the KDC or the target server to the client with a Kerberos Error message (KRB_ERROR) that explains why the authentication attempt failed.
Kerberos authentication is used in a Windows 2000 network in many circumstances. The following sections outline the transactions that occur as Kerberos authentication takes place.
Initial Authentication with the Network
The Authentication Service Exchange is used when a user initially logs on to the network. This exchange provides the user with a logon session key and a TGT that will be used to acquire service tickets during the session. The process involves a message sent from the client computer to the server (KRB_AS_REQ) and a response sent from the server to the client (KRB_AS_REP). The information contained within the KRB_AS_REP is encrypted with the user's long-term key so that only the user can decrypt the session key and the TGT within the response message. Each user shares a long-term key with the KDC. The long-term key is derived from the account's password.
The Importance of Time in Kerberos Transactions
In Windows 2000 the current time of the client is included in any client requests sent to a target server or to the KDC. The time is compared with the target server's current time. By default, if the difference between the two times is greater than 5 minutes, the connection attempt is considered invalid. In this instance, the connection attempt is considered to be a replay attack.
To ensure that all computers in a forest have synchronized clocks, Windows 2000 uses the Windows Time Synchronization Service (W32time.exe) that's based on the Simple Network Time Protocol (SNTP).
The following processes occur in order to ensure time synchronization:
- The Primary Domain Controller (PDC) emulator in the forest root domain is considered the authoritative time source for the entire forest. The PDC emulator should synchronize its clock to an Internet Network Time Protocol (NTP) time source using the following command:
net time /setsntp:<NTP host name>
- For every other domain in the forest, the PDC emulator in that domain contacts the PDC emulator in the parent domain for clock synchronization. If the domain is parallel to the forest root domain (a separate tree in the forest), the PDC emulator contacts the PDC emulator in the forest root domain for time synchronization.
- Within each domain, all DCs synchronize their clocks with the PDC emulator of their domain.
All client computers in the domain synchronize their clocks with the authenticating DC. If the authenticating DC's clock is ahead of the local time or the time difference between the two clocks is more than 2 minutes, the time is immediately reset to match the DC's clock. If the authenticating DC's clock is behind the current time, the computer's clock is recalibrated over the next 20 minutes until the times match.
The Kerberos authentication exchange, shown in Figure 3.3, proceeds as follows:
Figure 3.3 The Kerberos authentication exchange
This provides the user with the proper TGT. If the user is using a Windows 2000–based computer, he must now acquire a service ticket for that computer, as shown in Figure 3.4.
Figure 3.4 Acquiring a service ticket for the computer that the user logs on to
The following steps explain how to acquire the service ticket for the computer:
Having initially authenticated with the network, the user has to authenticate with other computers as he accesses resources on those other computers. Each and every time that the user connects to a resource or service on a remote computer, he has to perform a network authentication as shown in Figure 3.5.
Figure 3.5 Network authentication
The following steps outline the authentication sequence that takes place when a user connects to a remote resource on the network:
Smart Card Authentication
Windows 2000 supports the use of smart card authentication by using PKINIT extensions for Kerberos. This allows public/private keys to be used to authen-ticate the user when he logs on to the network in place of the standard Kerberos Authentication Service Request and Response. KRB_AS_REQ and KRB_AS_REP are replaced with the PA_PK_AS_REQ and PA_PK_AS_REP messages.
Table 3.3 shows how the Kerberos Authentication Service uses the client's public key and private key when smart cards are used for logon.
Table 3.3 Private and Public Key Usage for Smart Card Logon
|Client-side encryption of the preauthentication data||Private key|
|KDC-side decryption of the preauthentication data||Public key|
|KDC-side encryption of session key||Public key|
|Client-side decryption of session key||Private key|
When the smart card is inserted into the computer, the process shown in Figure 3.6 takes place:
Figure 3.6 Smart card authentication
Multiple Domain Authentication
Your forest often needs to have more than one domain. If it does, authentication will be accomplished by using TGTs, referral tickets (TGTs for other domains), and service tickets. Figure 3.7 shows the typical process that occurs when a user accesses a resource in another domain.
Figure 3.7 Authentication in a multiple-domain environment
The following process would take place if a user in the west.microsoft.com domain attempted to access a network share on the computer named srv1.east.microsoft.com:
If users in the west.microsoft.com domain frequently access resources in the east.microsoft.com domain, you could shorten the length of this process transaction by creating a shortcut trust, or cross-link trust, between the west.microsoft.com and east.microsoft.com domains. If you did this, the TGT issued at this stage would be for the east.microsoft.com domain.
In client/server environments you might sometimes deploy multitiered client/server applications (commonly referred to as n-tiered applications). In these scenarios, the first server that the user connects to must often impersonate that user when that server connects to additional servers in order to ensure that the entire process is run in the connecting user's security context. Kerberos provides the functionality for this procedure through the process of delegation.
Delegation can take place only when the following criteria are met:
To enable a user account for delegation, edit the properties of the user account in Active Directory Users And Computers. On the Account tab you can select the Account Is Trusted For Delegation check box under Account Options and ensure that the Account Is Sensitive And Cannot Be Delegated option is cleared.
If the service account is running under the local system account, the computer account itself must be trusted for delegation. To enable this, open the properties of the computer account in Active Directory Users And Computers. In the General tab select the Trust Computer For Delegation check box.
When the account is designated as trusted for delegation, this enables the forwardable flag on the service ticket. This flag allows services to request service tickets on behalf of the client and run processes in the security context of the client.
Figure 3.8 shows the authentication process that occurs when delegation takes place in a client/server system where two servers are involved (Server1 and Server2):
Figure 3.8 Kerberos authentication when delegation takes place
When you design your network for Kerberos Authentication support, you must consider the following points:
Figure 3.9 Setting the Kerberos policy for a domain
Only the Windows 2000 clients in the Market Florist network can authenticate using Kerberos v5. (Remember that Windows 95 and Windows NT clients can't use Kerberos for authentication.) To ensure that Kerberos authentication is optimized for all four sites, you must include the following components in the authentication design for Market Florist:
Because Windows 2000 uses Kerberos as the default authentication protocol, you must ensure that your network infrastructure supports Kerberos authentication. This includes ensuring that essential network services, such as DNS, DCs, and global catalog servers are available in the event of a WAN link failure.
Also make sure that you understand how the Kerberos authentication process works for different scenarios. Knowing the process will help you troubleshoot authentication problems when they occur.