Lesson 3: The Kerberos Protocol in Windows 2000 | MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000

A standard process within computer security is to include a function that requires users to prove that they are who they claim to be. This affirmation of identity is accomplished when the user supplies the correct password for the user account. For example, when User1 attempts to connect to a server to access a file, the server must be sure that it is really User1 sending the request. Traditionally, the server assumes that it is User1 because the correct password was supplied when the connection was established. Stronger security is accomplished by having a trusted third party verify the identity of the user. This is a core function of the Kerberos authentication protocol.

After this lesson, you will be able to

Describe the Kerberos protocol and how it works in Windows 2000

Estimated lesson time: 35 minutes

Overview of the Kerberos Protocol

The Kerberos protocol is the default authentication provider in Windows 2000 and the primary security protocol. It allows users to use a single logon to access all resources. The Kerberos protocol verifies both the identity of the user and the integrity of the session data. This is accomplished by having a Kerberos protocol service installed on each domain controller and a Kerberos client installed on all computers running Windows 2000.

NOTE
The Active Directory client for Windows 95 and Windows 98 allows users to log on by using the Kerberos v5 authentication protocol.

When the Kerberos authentication protocol is used, a trusted Kerberos service on a server verifies the user's identity. Before connecting to the server the user requests a ticket from the Kerberos service, called the Kerberos Key Distribution Center service, to confirm the user's identity. The user then sends this ticket to the target server. Because the server trusts the Kerberos service to vouch for user identities, the server accepts the ticket as proof of the authenticity of the user.

When using the Kerberos authentication protocol, users can no longer log on and then access resources simply by providing a valid user ID and the correct password. Instead of trusting the source, the resource must contact the Kerberos service to obtain a ticket that vouches for the user. The Kerberos service operates as a trusted third party to generate session keys and grant tickets for specific client/server sessions.

When the Kerberos service issues a ticket, it contains the following components:

Session key
Name of the user to whom the session key was issued
Expiration period of the ticket
Any additional data fields or settings that may be required

The expiration period of a ticket is defined by the domain policy. If a ticket expires during an active session, the Kerberos service notifies the client and the server to refresh the ticket. The Kerberos service then generates a new session key and the session is resumed.

Kerberos Protocol Terms

To better understand the Kerberos protocol, you should review the following terms used to describe the various components of the Kerberos protocol.

Principal

A principal is a uniquely named user, client, or server that participates in a network communication.

Realm

A realm is an authentication boundary, which can be compared to a Windows 2000 domain. Each organization wishing to run a Kerberos server establishes its own realm. A Windows 2000 domain is a Kerberos realm but is named domain to maintain naming conventions established previously for Windows NT.

Secret Key

A secret key is an encryption key that is shared by a client or a server and a trusted third party to encrypt the information that is to be moved between them. In the case of the Kerberos protocol, the trusted third party is the Kerberos service. In the case of a principal, the secret key is typically based upon a hash or encryption of the principal's password. Secret keys are never transmitted on the network; only the encrypted information is transmitted.

Session Key

The session key is a temporary encryption key used between two principals, with a lifetime limited to the duration of a single login session. The session key is exchanged between the communication partners and is therefore known as a shared secret. The session key is always sent encrypted.

Authenticator

An authenticator is a record that is used to verify that a request actually originated from the principal. An authenticator contains information that verifies the identity of the sender and the time the request was initiated. This information is encrypted with the shared session key that is known only by the communicating principals. An authenticator is typically sent along with a ticket to allow the receiver to verify that the intended client recently initiated a request.

Key Distribution Center

The key distribution center (KDC) provides two functions: acting as the authentication server (AS) and the ticket granting service (TGS). The TGS distributes tickets to clients that wish to connect to services on the network. However, before a client can use the TGS to obtain tickets, it must first obtain a special ticket (the ticket granting ticket [TGT]) from the AS.

Privilege Attribute Certificate

The privilege attribute certificate (PAC) is a structure that contains the user's security ID (SID).

Tickets

In a basic Kerberos protocol exchange, the client contacts the TGS and requests a ticket for the target server before contacting the target server. A ticket is a record that allows a client to authenticate itself to a server; it is simply a certificate issued by the Kerberos service. The ticket is encrypted so that only the target server is able to decrypt and read it. Tickets contain the identity of the requesting client, the timestamp, the servers session key, the lifetime of the ticket, and other information (such as the PAC) that helps verify the identity of the client to the target server. Tickets are reusable within their life span, which is usually 8 hours.

Ticket Granting Tickets

One method for using the Kerberos protocol is to simply request a ticket for each target server from the TGS portion of the Kerberos service whenever the user wants to access the specified target server. Using this method, the response from the request would contain a session key and other information that is encrypted with the user's secret key. This method results in a component of the user's secret key being exposed on the network every time a new ticket request is made.

In Windows 2000, the Kerberos protocol protects the secret key by initially authenticating the user and then requesting a ticket granting ticket (TGT). A TGT is a request for a ticket and a random session key to be used with the TGS portion of the Kerberos service. After obtaining the ticket, the user can contact a service at any time; the requested ticket does not come from the AS, but from the TGS. The reply is encrypted not with the user's secret key, but with the session key that the AS provided for use with the TGS.

Features of the Kerberos Protocol

The Kerberos protocol has several advantages over traditional challenge/response authentication systems.

Mature Open Standard

The Windows 2000 implementation of the Kerberos protocol complies with RFC 1510 and RFC 1964. It can interoperate with other implementations of the Kerberos protocol that also comply with the RFCs. Therefore, Kerberos protocol clients on other platforms, such as UNIX, can be authenticated by Windows 2000. In some cases, however, implementation-dependent values do not exist or are unavailable. In the absence of required data, the Windows 2000 Kerberos service attempts to match the principal name in the ticket either to a Windows 2000 user account or to a default account created for this purpose.

Faster Connection Authentication

When using the Kerberos protocol, servers do not need to do pass-through authentication. A server running Windows 2000 can verify the client credentials by using the client-supplied ticket, without having to query the Kerberos service. This is because the client will have already obtained a Kerberos protocol ticket from a domain controller, which the server can then use to build the client's access token. Since the server is required to do less work when establishing a connection, it can more easily accommodate a large number of simultaneous connection requests.

Mutual Authentication

The Kerberos protocol provides mutual authentication of both the client and server. The Windows NTLM authentication protocol provides only client authentication, and it assumes that all servers are trusted. It does not verify the identity of the server that a client connects to. The assumption that all servers can be trusted is no longer valid. Mutual authentication of both client and server is an important foundation for secure networks.

Delegation of Authentication

Delegation of authentication allows a user to connect to an application server, which in turn can connect to one or more additional servers on the client's behalf, by using the client's credentials.

Transitive Trusts

Authentication credentials issued by one Kerberos service are accepted by all Kerberos services within the domain.

Kerberos Authentication Process

The Kerberos authentication process involves the client computer negotiating exchanges between the target server and the KDC. Figure 27.12 provides an overview of the authentication process. The numbered steps shown in the illustration are described below.

Figure 27.12 Kerberos authentication process

The Kerberos authentication process works as follows:

The client sends an initial AS request to the AS portion of the Kerberos service. The AS includes the client's principal name and the principal name of the target server for which it is requesting a ticket.
The Kerberos service generates an AS reply and sends it to the client. The reply contains the following:
- A TGT for the TGS portion of the Kerberos service. The TGT is encrypted with the TGS secret key. The TGT contains the user's SID. By encrypting the TGT with the TGS secret key, the client is unable to change the SID properties.
- A session key for exchanges with the TGS portion of the Kerberos service. The session key is encrypted with the client's secret key. The client's secret key is a computation of the client's password. It is similar to the session key used in NTLM challenge/response. The encryption here makes it difficult for someone to steal the session key.
The client generates and sends a TGS request that contains the client's and target server's principal names, realms, and the TGT that identifies the client.
The TGS portion of the Kerberos service generates and sends a TGS reply to the client. This reply contains a ticket for the target server. The ticket is encrypted with the server's secret key. The server's secret key is a computation of the password generated when the server joined the domain. The reply also includes other information, including the session key.
The client extracts the session key for the target server and generates a request for the server. This request contains the target server and an authenticator encrypted with the session key. The client sends this request to the target server by using an established transport path.
The target server decrypts the ticket by using its secret key to obtain the session key. The server then uses the session key to decrypt the authenticator to verify the client. If the client has requested mutual authentication, the target server generates a reply encrypted with the session key and sends it to the client. Mutual authentication not only authenticates the client to the target server, but also authenticates the target server to the client.

NOTE
The AS and TGS exchanges with the Kerberos service operate over UDP port 88. The exchanges between the client and target server are dependent on the protocol in use between the two principals.

Kerberos Protocol Delegation

Occasionally, it is necessary for an application server to connect to another server on behalf of a client. Like impersonation, delegation is used to ensure that proper security permissions are applied against the application server's request.

The Kerberos authentication protocol supports delegated authentication. This type of authentication is used when a client transaction involves multiple servers. In this case, each of the verifying servers obtains another ticket and authenticates the ticket to the requested server on behalf of the client. There is no restriction on the number of consecutive servers that can delegate authentication. This is different than impersonation, in that the server accesses remote resources on the behalf of the client instead of local resources.

Figure 27.13 provides an overview of the Kerberos protocol delegation process. The numbered steps in the diagram are described below.

Figure 27.13 Kerberos protocol delegation process

The following steps describe the access of resources involving two servers:

The client requests and receives a ticket for target Server A from the Kerberos service.
The client sends the ticket directly to Server A.
Server A sends a request, impersonating the client, to the Kerberos service for a ticket for target Server B. The Kerberos service responds with a ticket that allows the client to access Server B.
Server A can send the ticket to Server B, accessing Server B as the client.

Kerberos Protocol Logon Processes

The addition of the Kerberos protocol as an authentication package in Windows 2000 affects various aspects of the logon process. However, the portions of the logon process that run before an authentication package becomes involved remain unchanged in Windows 2000.

Local Interactive Logon

When a local interactive logon occurs, the user logs on with a user account that exists on the local computer rather than with a domain user account. Figure 27.14 provides an overview of the local interactive logon process in Windows 2000. The numbered steps in the diagram are described below.

Figure 27.14 Local interactive logon process

For local user accounts, the following takes place in Windows 2000:

When the Graphical Identification and Authentication (GINA) DLL receives the logon request, it forwards the request to the Local Service Authority (LSA). This request specifies the Kerberos protocol as the authentication package to use because this is the default package in Windows 2000.
LSA processes the request and sends it to the Kerberos authentication package.
When the Kerberos protocol receives the logon request. The Kerberos protocol returns an error because it is used only when authenticating logon requests for domain user accounts, not local user accounts.
LSA receives the error and returns an error to the GINA.
The GINA resubmits the logon request to LSA specifying the "MSV1_0" authentication package. The logon process then takes place as it would for a local interactive logon under Windows NT 4.0.

Domain Interactive Logon

The exchange that occurs when a user logs on to Windows 2000 with a domain user account is similar to the basic Kerberos protocol exchange. Figure 27.15 provides an overview of this logon process. The number steps in the diagram are described below.

Figure 27.15 Domain interactive logon process

The following are the steps in the domain interactive logon process:

When the logon request reaches the LSA, it passes the request to the Kerberos authentication package. The client sends an initial AS request to the Kerberos service, providing the user name and domain name. This is a request for authentication and a TGT. The request is made by using 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 automatically generates the krbtgt@<domain_name> account.
The Kerberos service generates an AS reply containing a TGT (encrypted with the Kerberos secret key) and a session key for the TGS exchanges (encrypted with the client's secret key). This response is sent back to the client. The authorization data portion of the TGT contains the SID for the user account and SIDs for any global groups to which the user belongs. The SIDs are returned to the LSA for inclusion in the user's access token. The SIDs are copied by the Kerberos service from the TGT into subsequent tickets obtained from the Kerberos service.
The client generates and sends a TGS request containing the client's principal name and realm, the TGT to identify the client, and the local workstation name as the target server. This is done to request access to the local computer for the user.
The Kerberos service generates and sends a TGS reply. This reply contains a ticket for the workstation and other information, including the session key (encrypted by using the session key from the TGT). Also included in the authorization data portion of the TGS reply are the SIDs for the user account and any global groups copied by the Kerberos service from the original TGT.
The Kerberos authentication package returns the list of SIDs to the LSA.

Windows 2000 services use the Kernel Mode SSPI to perform authentication. Instead of communicating directly with the Kerberos authentication package, both services access the Kerberos protocol through an authentication package built into LSA. This authentication package is called the Negotiate package.

During startup, both the Server and Workstation services initialize their interface with the Negotiate package in LSA by using SSPI. During this process, the server service obtains a credential handle for its default credentials.

The network communication occurs in two segments: protocol negotiation and session setup. Before a user can establish a session with the server, the client computer and the server must agree on the security protocol to use by determining which version of security they both support. Once the client has been authenticated and has a ticket, it can establish a session with the server.

Kerberos Protocol Public Key Support

Windows 2000 extends the functionality of the Kerberos protocol to allow it to interact with the Active Directory service. Windows 2000 includes extensions to the Kerberos v5 authentication protocol to support public key-based authentication. The public key extensions allow clients to request an initial TGT by using a private key. The Kerberos service verifies such a request by using the user's public key that is obtained from the user's X.509 certificate published to the Active Directory store. In order to obtain a ticket, the user's X.509 certificate must be stored in their user object. If the Kerberos service finds the certificate, the Kerberos service issues a ticket for the client and the standard Kerberos authentication procedure is followed thereafter. This replaces the secret key that is known only to the principal and the KDC. Smart cards, for example, use public key extensions provided by the Kerberos protocol.

Lesson Summary

The Kerberos protocol is the default authentication provider in Windows 2000 and the primary security protocol. To better understand the Kerberos protocol, you should be familiar with the terms common to the Kerberos protocol, including principal, realm, secret key, session key, authenticator, KDC, AS, TGS, PAC, ticket, and TGT. The Kerberos authentication process involves the client computer negotiating exchanges between the target server and the KDC. The Kerberos authentication protocol supports delegated authentication. When a local interactive logon occurs, the user logs on with a user account that exists on the local computer rather than with a domain user account. The exchange that occurs when a user logs on to Windows 2000 with a domain user account is similar to the basic Kerberos protocol exchange. Windows 2000 services use the Kernel Mode SSPI to perform authentication. In addition, Windows 2000 extends the functionality of the Kerberos protocol to allow it to interact with Active Directory services. Windows 2000 includes extensions to the Kerberos v5 authentication protocol to support public key-based authentication.