Kerberos is an industry-standard authentication protocol and part of the TCP/IP suite of internetworking protocols. Originally developed at MIT, Kerberos is now up to version 5, which is primarily defined in Internet Request for Comments (RFC) 1510.
You can find RFC 1510 at http://www.ietf.org/rfc/rfc1510.txt. Microsoft has proposed several extensions to Kerberos that are used in Windows 2000 (Win2K) and later; review RFCs 3244 and 1964 at the same site for more information about Kerberos specifics and Microsoft extensions.
Kerberos provides a number of advantages over Microsoft's older authentication protocols:
Kerberos is named for the dog in Greek mythology that guarded the gates to the underworld. Like the three-headed mythical dog, the Kerberos protocol identifies three primary roles for authentication participants:
Any discussion of Kerberos in the Microsoft world can become confusing because computers often hold all three roles. For example, all domain controllers in an Active Directory (AD) domain are KDCs. They might also be file servers, making them Kerberos servers. You might also log on to a domain controller's console and attempt to access files on another server, in which case the domain controller becomes a Kerberos client. So in any discussion of Kerberos, it's important to consider what role each participant is playing in a single particular authentication transaction.
Kerberos defines two basic processes, which are functionally very similar to one another. The first process occurs whenever a security principal, such as a user or computer, logs on to an AD domain. The second process occurs whenever a logged-on principal attempts to access a resource located on another computer. For information about how encryption relates to Kerberos, see the sidebar "Encryption and Kerberos.")
Remember that both users and computers have accounts in an AD domain, and that both are considered individual security principals. For example, the logon process occurs twice on every Windows XP Professional computer: Once when the computer starts, and again when a user logs on to the computer's console.
Understanding how digital encryption works is a key to understanding Kerberos. By default, Kerberos uses shared secret encryption, which means that both the sender and recipient know a secret phrase or password that is used as an encryption key. Generally, this shared secret is the recipient's password, something that both the recipient—whether a computer or a user—and the KDC both know.
In Win2K and later, Microsoft extends the standard Kerberos protocol to support Public Key Infrastructure (PKI) and digital certificates. In this scenario, the security principals and the KDC don't share a secret. Instead, they use each others' public keys—obtained from a certificate authority (CA) server—to encrypt data, and their own private keys—stored in the computer or on a smart card—to decrypt data.
When a security principal authenticates to a domain, the principal has to prove its identity to the domain controller. This is done by creating a special packet of data called an authenticator, then encrypting the packet and sending it to the KDC. A clear-text (unencrypted) version of the authenticator is also sent. How the authenticator is encrypted depends on the encryption scenario in use.
Usually, the principal's hashed password is used as the encryption key. For example, if the principal is a user, the user would type his or her user name and password into the logon dialog box on the client computer. The client computer hashes the password and uses the result to encrypt the authenticator. The domain controller receives the authenticator and looks up the user account in AD to retrieve its copy of the hashed password. If the hashed password from AD can be used to decrypt the authenticator, then the user must have typed the correct password. If the user hadn't, the password stored in AD wouldn't be able to decrypt the authenticator.
A hash is the result of a one-way encryption algorithm, meaning it is impossible to start with the encrypted result and ever arrive at the original unencrypted password. Domain controllers only store hashed passwords for principals; when passwords are changed, they are immediately re-hashed and stored.
In a PKI scenario, the user's client computer would use a smart card containing the user's private key to encrypt the authenticator. Smart cards generally require the user to provide a PIN or some other identifying factor (such as a thumbprint) to unlock the card. Once the domain controller received the authenticator, it would obtain the user's public certificate from AD or a CA, and try to use the public key to decrypt the authenticator. If the decryption works, the user's identity would be verified.
Technically, anyone could intercept the authenticator and use the user's public key to decrypt it. Because the authenticator doesn't contain any sensitive data, that's fine. An intruder could not modify and re-encrypt the authenticator without the user's private key, which is safely stored in the smart card.
The authenticator includes a timestamp and a unique identifying number. Domain controllers will reject any authenticators that are too old (5 minutes, by default) or that the domain controller has already processed. This behavior reduces the likelihood that an intruder could capture an authenticator off of the network and replay it against the domain controller at a later time (presumably after modifying it in some way).
Once the domain controller is convinced of the principal's identity, it creates a ticket-granting ticket. The TGT contains a unique, temporary encryption key that the domain controller makes up on the spot. By using this session key for future communications, the user's regular encryption key won't be overexposed on the network. One copy of the TGT is encrypted with the domain controller's private encryption key, and can be decrypted only by that domain controller. That copy of the TGT, along with an unencrypted copy, are encrypted using the principal's shared secret (or, in a PKI scenario, with the principal's public key), then sent back to the principal.
When the principal receives the TGT, the principal decrypts it—using either its shared secret or private key—and store it in memory. So now the principal has two important pieces of information:
The TGT is also marked with an expiration time (8 hours, by default) and a maximum lifetime (7 days, by default). When the TGT expires, the principal can ask the KDC to renew the TGT for up to the maximum lifetime. Expiration times and maximum lifetimes ensure that session keys aren't used for such a long time that an intruder might be able to compromise them. Once the two copies of the TGT are in RAM, the logon process is complete.
TGTs are stored in a special non-swappable area of volatile RAM. In other words, the TGTs can't be written to disk under any circumstances and will be lost if the client computer loses power. User TGTs are also destroyed when the user logs off.
By now, the principal has a TGT from the KDC. That TGT is a key part of further authentication operations, such as attempting to access resources on a server. Note that Kerberos doesn't directly provide authorization, which determines which resources a principal may access. Kerberos simply provides authentication, which tells the server who the principal is. The server can then use other technologies—such as NTFS file access control lists (ACLs)—to determine what the principal is allowed to do.
When a client needs to access resources on a server, it contacts the KDC and requests a ticket for that server. The ticket request is accompanied by the KDC-encrypted copy of the TGT from the client's memory, and the request itself is encrypted with the session key from the unencrypted copy of the TGT. The result:
Satisfied with the client's identity, the KDC generates a ticket. This ticket contains a new, unique session encryption key. One copy of the ticket is encrypted with the session key shared between the client and KDC. Another copy is encrypted with a secret shared between the KDC and the server to which the client is requesting access. Both copies are sent back to the client.
The client can decrypt one half of the ticket to obtain a session key, which it uses to encrypt an access request packet. The client sends this encrypted packet to the server, along with the other half of the server ticket—the half that only the server can decrypt.
When the server receives the request, it decrypts its half of the server ticket, revealing a session key. The server then uses the session key to decrypt the actual request. The result:
The server can now process the access request and provide the client with the resources requested.
Kerberos has an additional advantage over Microsoft's older authentication protocols: delegation and proxying. These techniques essentially allow a background service or application to access resources using a user's security credentials, ensuring that the service or application can only access resources that the end users would normally be allowed to access on their own. However, both delegation and proxying require services and applications that have been specially programmed to deal with Kerberos' advanced features, making a discussion of how these features work beyond the scope of tip.