Lesson 2: Designing Kerberos Authentication | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

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

Design a network to support Kerberos authentication for Windows 2000–based clients

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.
NOTE
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.
NOTE
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.

Designing Kerberos Authentication

Kerberos provides the following advantages over the NTLM protocol:

Mutual authentication. For all Kerberos transactions, both the user and the server are authenticated. This prevents identity spoofing of both the user and the server and ensures that only the desired communications take place. For example, if a client computer is connecting to a server and is protecting the data transmission using IPSec, Kerberos can be used to authenticate both ends of the data transmission.
Single sign-on. Within a forest, a user who authenticates to the network using Kerberos v5 authentication won't have to provide any other credentials when accessing any resources in the forest.
Ticket caching. After acquiring a service ticket from the KDC, the user then caches the service ticket in the client's personal ticket cache. This reduces the number of times that a user must contact DCs for authentication. For the lifetime of the service ticket, the user can simply present the ticket anytime she is required to authenticate with the server. The user needs to contact a DC to acquire another service ticket only when the ticket expires.
TIP
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.
Delegation. Kerberos lets services impersonate connecting users when the service connects to services located on other servers. For example, if a user is connecting to an application server using his network credentials, that application server can then query a database under the security context of the connecting user.
Standards-based protocol. Kerberos is an industry standard authentication protocol. The Windows 2000 implementation of Kerberos v5 is compliant with Request for Comment (RFC) 1510 and RFC 1964.
NOTE
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."
Interoperability. You can use Kerberos authentication to provide interop-erable authentication between Windows 2000 domains and Kerberos realms in a UNIX environment. This allows ease of access to resources using a secure authentication protocol.

Understanding the Kerberos Message Exchanges

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

Authentication Service Exchange. Used by the KDC to provide a user with a logon session key and a TGT for future service ticket requests. The Authentication Service Exchange is comprised of a Kerberos Authentication Service Request (KRB_AS_REQ) sent from the user to the KDC and a Kerberos Authentication Service Reply (KRB_AS_REP) returned by the KDC to the user.
Ticket Granting Service Exchange. Used by the KDC to distribute service session keys and service tickets. The service ticket that's returned is encrypted using the master key shared by the KDC and the target server so that only the target server can decrypt the service ticket. A Ticket Granting Service Exchange is comprised of a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ) sent from the user to the KDC and a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP) returned by the KDC to the user.
Client/Server Authentication Exchange. A user uses this message exchange when presenting a service ticket to a target service on the network. The message exchange is comprised of a Kerberos Application Request (KRB_AP_REQ) sent from the user to the server and a Kerberos Application Response (KRB_AP_REP) returned by the target server to the user.

NOTE
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.

Analyzing Kerberos Authentication

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:

click to view at full size.

Figure 3.3 The Kerberos authentication exchange

The user presses Ctrl+Alt+Del to display the Windows 2000 Login dialog box. Within the dialog box, the user enters his login name, password, and the domain he wants to authenticate to.
The client computer queries the DNS server to find a _Kerberos service locator (SRV) resource record based on the client's domain and site. The returned SRV resource record is for a KDC that's at the client's local site for the domain the user wants to log on to.
The user sends a Kerberos Authentication Service Request (KRB_AS_REQ) to the DC indicated in the returned SRV resource record. The user's account information and the current computer time are encoded using the long-term key shared between the user's account and the KDC. As mentioned earlier, this long-term key is based on the user's password.
The authentication service at the KDC authenticates the user, generates a TGT for the user, and then sends back the TGT to the user in a Kerberos Authentication Service Response (KRB_AS_REP) message.

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.

click to view at full size.

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:

The user sends a Ticket Granting Service Exchange Request (KRB_TGS_REQ) to the KDC to acquire a service ticket for his computer. The KRB_TGS_REQ contains an authenticator and the TGT that was issued to the user.
The Ticket Granting Service of the KDC checks the TGT and the authenticator. If both are valid, the Ticket Granting Service generates a service ticket and sends it back to the user using a Ticket Granting Service Response (KRB_TGS_REP).
At the client computer, the service ticket is presented to the Local Security Authority, which will create an access token for the user. From then on, any process acting on behalf of the user can access the local machine's resources.

Network Authentication

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.

click to view at full size.

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:

The user sends a Ticket Granting Service Request (KRB_TGS_REQ) to the KDC to acquire a service ticket for the target computer. The KRB_TGS_REQ includes the TGT and an authenticator.
The Ticket Granting Service of the KDC checks the authenticator and the TGT, generates a new service ticket, and sends it back to the user using a Kerberos Ticket Granting Service Response (KRB_TGS_REP). The service ticket is encrypted using the long-term key between the KDC and the target service.
The user sends the service ticket and an authenticator to the target server using a Kerberos Application Request (KRB_AP_REQ).
The target server verifies the ticket with the authenticator, decrypts the session key using the master key that's shared with the KDC, and sends back an authenticator to the user in a Kerberos Application Response (KRB_AP_REP). This authenticator provides mutual authentication of the user and server.

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

Process	Key Used
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:

click to view at full size.

Figure 3.6 Smart card authentication

The user starts the logon process by introducing a smart card and by authenticating to the card using the user PIN code. The smart card contains the user's public key credentials, private/public key pair, and certificate.
A modified Kerberos Authentication Service Request (PA_PK_AS_REQ) message is sent to the KDC. This request contains the user principal name and time stamp and a copy of the user's certificate. The user principal name and time stamp are signed by the user's private key.
The KDC validates the request by verifying the user's certificate and the digital signature with the Certification Authority (CA) that issued the certificate.
The KDC queries Active Directory to determine the mapping between the certificate included in the PA_PK_AS_REQ and a Windows 2000 SID. When the mapping is determined, the KDC will issue a TGT for the corresponding SID.
The KDC sends the TGT back to the user in a modified Kerberos Authentication Service Response (PA_PK_AS_REP). Within the response, the session key is encrypted with the user's public key. This ensures that only the correct user can decrypt the session key.
The user retrieves the session key by decrypting the session key with the private key located on the smart card.

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.

click to view at full size.

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:

The user sends a Ticket Granting Service Request (KRB_TGS_REQ) to the KDC in his domain to acquire a service ticket for the srv1.east.microsoft.com computer. Because the target computer is in a different domain, the KDC that receives the request looks at the trust relationships that exist for the domain. Because no explicit trust relationship exists between the west.microsoft.com domain and the east.microsoft.com domain, only the default transitive trusts of a Windows 2000 forest, the KDC issues a TGT referral ticket to the microsoft.com domain in the KRB_TGS_REP packet that's sent back to the client. The TGT is encrypted using the interdomain key between the west.microsoft.com domain and the microsoft.com domains.
TIP
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.
The user sends a KRB_TGS_REQ message to a KDC located in the microsoft.com domain to acquire a service ticket for the srv1.east .microsoft.com computer. Because the target computer is in a different domain, the KDC that receives the request looks at the explicit trust relationships that exist for the domain. The KDC in the microsoft.com domain issues a TGT referral ticket to the east.microsoft.com domain in the KRB_TGS_REP packet that's sent back to the client. The TGT is encrypted using the interdomain key between the microsoft.com domain and the east.microsoft.com domains.
The user sends a KRB_TGS_REQ message to a KDC located in the east.microsoft.com domain to acquire a service ticket for the srv1.east.microsoft.com computer. Because the target computer is in this domain, the KDC that receives the request verifies the TGT and the authenticator provided in the KRB_TGS_REQ. If it's valid, the KDC issues a KRB_TGS_REP that contains a service ticket to connect to the SRV1.east.microsoft.com computer. The service ticket is encrypted using the long-term key shared by the KDC and the srv1.east.microsoft.com computer.
The user sends a KRB_AP_REQ containing the service ticket to the srv1.east.microsoft.com computer. The srv1.east.microsoft.com validates the service ticket, and if it's valid, it responds with a KRB_AP_REP message. The user can now access the resource.

Delegation

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:

The computers that are hosting the client process, the service process, and processes for any back-end services must all be running Windows 2000 in a Windows 2000 domain.
The client's user account must be enabled for delegation.
NOTE
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.
The service's account must be enabled for delegation.
NOTE
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):

click to view at full size.

Figure 3.8 Kerberos authentication when delegation takes place

The user sends a KRB_TGS_REQ message to the KDC requesting a service ticket for Server1.
The KDC sends the service ticket in a KRB_TGS_REP message back to the user.
The user sends the service ticket to Server1 in a KRB_AP_REQ message.
Server1 responds to the authentication request with a KRB_AP_REP message.
Server1 sends a KRB_TGS_REQ message, impersonating the user, to the KDC for a service ticket to access Server2 in the security context of the user.
The KDC sends a KRB_TGS_REP message containing the service ticket that allows the user to access Server2.
Server1 sends the service ticket to Server2 in a KRB_AP_REQ message.
Server2 responds to the authentication request with a KRB_AP_REP message validating the authentication. Server1 now has access to services on Server2 at the security level of the original user.

Making the Decision

When you design your network for Kerberos Authentication support, you must consider the following points:

Kerberos authentication relies on Windows 2000 DCs being available on the network. Each site defined in Active Directory should have at least one domain controller available to ensure that authentication can take place.
DNS services must be available to find Windows 2000 DCs for Kerberos authentication services. When a Windows 2000 client computer attempts to connect to a KDC, it queries DNS for a _Kerberos SRV resource record. If DNS services are unavailable, the client won't be able to find a KDC for authentication.
If the Windows 2000 domain is in native mode and the forest has multiple domains, the authenticating DC must contact a global catalog server to enumerate universal group membership. A global catalog server should be located at each remote site.
Global catalog server SRV resource records are stored in the _msdcs.forestrootdomain zone, where forestrootdomain is a variable representing the name of the domain in question. This zone should be delegated to DNS servers at remote sites to ensure that global catalog servers can be found by authenticating DCs.
Only Windows 2000 clients and UNIX clients can use Kerberos authen-tication. Even with the Directory Services Client loaded, Windows 95, Windows 98, and Windows NT clients can't authenticate using Kerberos.
Smart card logon requires that Kerberos be used for authentication. If Kerberos services are unavailable, the smart card logon attempt fails.
Kerberos settings are part of the domain account policy. Within the Kerberos settings is the option to enforce logon restrictions. This setting should always be applied to ensure that disabled user accounts can no longer acquire service tickets. These Kerberos settings can be edited in the Default Domain Policy for the domain as shown in Figure 3.9.

Figure 3.9 Setting the Kerberos policy for a domain

Applying the Decision

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:

Each of the domains has sufficient DCs at each of the four sites.
The San Francisco site doesn't have a dedicated DNS server. If the WAN link to Seattle is unavailable, the clients will be unable to access a DNS server to find SRV resource records for Kerberos authentication. This can result in cached credentials being used for authentication.
The DNS servers in Winnipeg and Monterrey don't have a secondary zone for the _msdcs.marketflorist.tld domain. If the WAN link to either of these sites is down, this can render the authenticating DCs unable to find a global catalog server for universal group enumeration. You should configure this zone as a secondary zone on the DNS servers in Winnipeg and Monterrey.
The Winnipeg and Monterrey sites don't have a local global catalog server. You should configure at least one DC at each site as a global catalog server to ensure that all global catalog access isn't over the WAN links as currently configured.

Lesson Summary

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.