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:
- 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
- Authentication Service (AS): This service is what authenticates you to the network. It handles your login credentials
- 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.
Before you can login to the network and begin accessing resources, you first must authenticate with the KDC over udp/tcp port 88. To do this, you must submit a login request using your username and password to the AS inside the KDC. The username, password, and the current date/time is encrypted with the hash of your password. For example, “AB7F9c8d21ef01bAc23DE54ae56” is the password hash that acts as the encryption key.
This hash is not sent over the network though. The AS inside the KDC
already knows what your 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 your 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 your username, hashes it, and uses that hash as the decryption key. This is symmetric encryption because you and the AS are both sharing your 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 no authenticate you.
The AS then grants you a Ticket Granting Ticket (TGT), which contains your 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 you and the TGS should you wish to request a service or resource (prevents MITM attacks). The TGS key is also encrypted with the user’s password hash. The TGS knows your password hash and you both can decrypt the session…nobody else. You must refer back to the TGS to get a ticket for a resource.
Accessing Resources in Other Domains
If you need to access to a resource in another domain, you can use a “referral ticket” as long as there is a transitive trust between your domain and the other domain.
Once a trust has been established between two domains, referral tickets can be granted to clients 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:
- 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.
- 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.
- The client performs the client/server exchange with the server and begins the user session with the service.
Walla, M. (2000). Kerberos Explained. Microsoft Corporation. Retrieved from https://msdn.microsoft.com/en-us/library/bb742516.aspx