Kerberos is a Single Sign-On (SSO) authentication protocol developed by the Massachusetts Institute of Technology in the 1980s. It is also a written standard in RFC 4120. As an SSO technology, users don’t have to worry about entering different login credentials every time they access a resource. If we didn’t have SSO technology, it wouldn’t be very scalable to use a different set of login credentials every time we wanted to access a file server, E-mail server, a printer, or an application running any other type of service on the network. Users cannot (and should not) be required to remember all these different login credentials because they are more likely to forget their passwords and write them down (poor password security).

Kerberos is heavily used in Microsoft environments for Active Directory (AD). It uses the open standard Kerberos version 5.0 since it’s compatible with other operating system devices besides Windows. With Kerberos, we only need to authenticate one time. There is no need to re-authenticate if we want to access a resource. Kerberos also provides mutual authentication, meaning both the client and the server trust each other. In other words, if you are authenticating onto an environment utilizing Kerberos, you can be assured that the server you are communicating with is the actual server and not a man-in-the-middle.

Kerberos’s Three Heads

The Kerberos authentication protocol is named after “Kerberos,” the three-headed dog that guards Hades in Greek Mythology. It gets its name from the fact that it has three main components:

1. Key Distribution Center (KDC): This component is installed in the Domain Controller (DC) running Active Directory (AD). It is essentially just a Windows server handling authentication, identity management, access control, and other features suitable for AD services. The KDC contains two services, which are the remaining two heads of Kerberos
2. Authentication Service (AS): This service is what authenticates you to the network. It handles your login credentials
3. Ticket Granting Service (TGS): Kerberos uses a complex process of distributing “tickets.” The TGS grants you a “Ticket Granting Ticket (TGT)” once you successfully authenticate. Should you ever wish to use a resource on the network, you must present your TGT back to the TGS to get a specific “ticket” for that particular service.

This might sound confusing, but if we step through some examples, all might become more clear.

Client Authentication

Before a user can login to the network and begin accessing resources, the user first must authenticate with the KDC over udp/tcp port 88. To do this, the user submits a login request to the AS using his username and password. The username, password, and the current date/time is encrypted with the hash of the user’s password. For example, “AB7F9c8d21ef01bAc23DE54ae56” is the password hash that acts as the encryption key.

This hash is not sent over the network though because the AS inside the KDC
already knows what the user’s password should be since it is connected with AD. The AS simply receives the encrypted login request and queries AD using a LDAP or LDAPS to find the user’s password.

LDAP stands for “Lightweight Directory Access Protocol” and we use this x.500 standard to query and modify items in a directory like AD over tcp/udp port 389 (tcp port 636 for LDAPs). LDAPS is the encrypted version of LDAP, but we now use LDAPv3 as an updated version. The AS then finds the password for the user’s username, hashes it, and uses that hash as the decryption key. This is symmetric encryption because the user and the AS are both sharing the password hash as the encryption/decryption key.

When the AS decrypts the login request, the username, password, and timestamp should all be revealed. The AS checks to see if everything matches and also checks to see if the timestamp is within the last 5 minutes. This time check is to prevent replay attacks. If the timestamp is not within the last 5 minutes, it will not authenticate the user.

The AS then grants the user a Ticket Granting Ticket (TGT), which contains the user’s name, IP address, timestamp, and a maximum validity period of 10 hours. The TGT is encrypted by the KDC with its private key, and therefore, cannot be decrypted or read by the user (you).

Along with the TGT, the AS also grants a Ticket Granting Session (TGS) key, which is used to encrypt the communication between the user and the TGS should there be a request to a service or resource (prevents MITM attacks). The TGS key is also encrypted with the user’s password hash. The TGS knows the user’s password hash and both can decrypt the session…nobody else. The user must refer back to the TGS to get a ticket for a resource.

Accessing Resources in Other Domains

If the user needs access to a resource in another domain, the user can use a “referral ticket” as long as there is a transitive trust between his current domain and the other domain.

Once a trust has been established between two domains, referral tickets can be granted to users requesting authorization for services in other domains. When there is a trust established between the two domains, an “interdomain key” based on the trust password becomes available for authenticating KDC functions. In the figure above, a user client in Entcert1.com requests authority for a server in Entcert2.com. He utilizes referral tickets to do this. The numbers in the figure below correspond to the following numbered explanations:

1. The client contacts its domain KDC-TGS using a TGT. The KDC recognizes a request for a session with a foreign domain server and responds by returning a referral ticket for the KDC in that particular foreign domain.
2. The client contacts the KDC of the foreign domain with the referral ticket. This ticket is encrypted with the interdomain key. Given that the decryption works, the TGS service for the foreign domain returns a service ticket for the server service in Entcert2.com.
3. The client performs the client/server exchange with the server and begins the user session with the service.

References

Walla, M. (2000). Kerberos Explained. Microsoft Corporation. Retrieved from https://msdn.microsoft.com/en-us/library/bb742516.aspx