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
Estimated lesson time: 35 minutes
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.
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:
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.
To better understand the Kerberos protocol, you should review the following terms used to describe the various components of the Kerberos protocol.
A principal is a uniquely named user, client, or server that participates in a network communication.
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.
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.
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.
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).
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.
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.
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.
Authentication credentials issued by one Kerberos service are accepted by all Kerberos services within the domain.
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 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.
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 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.
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:
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:
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.
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.
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.