Kerberos is an authentication protocol enabling systems and users to prove their identity through a trusted third-party. The protocol was initially developed at the Massachusetts Institute of Technology (MIT) as part of a larger project called Project Athena. Project Athena was a joint initiative of MIT, Digital Equipment Corporation, and IBM to build a distributed computing environment for educational use.
The protocol centers around tickets. Tickets are issued by the trusted third-party and utilize symmetric encryption (the key known only to the trusted third-party) to establish their trust. As we’ll explain later, certain user passwords are also used to encrypt and sign specific tickets. However, the root of the protocol’s security is the key used by the trusted third-party.
The Kerberos implementation found within Microsoft Active Directory is based off of the Kerberos Network Authentication Service (V5), which is detailed in RFC 4120. Microsoft expanded upon the base protocol specification adding a number of extensions to the protocol (MS-KILE) to implement behaviors and features specific to Active Directory and the Windows operating system.
Kerberos was originally named after Cerberus – the three headed dog, in Greek mythology, that guards the gates of the Hades – because of the three distinct actors in the protocol:
TL;DR: A client requests a ticket for a user from the KDC using the user’s password to encrypt the request. If the KDC can decrypt the request with the user’s password it knows, it knows the client has supplied the correct password for the user. The KDC creates a ticket-granting ticket (TGT) for the user and encrypts the TGT with the user’s password and returns it to the client. If the client can decrypt the ticket with the password it has then it knows that the KDC is legitimate (this is a form of mutual authentication).
A client requests a ticket for a service from the KDC by presenting its TGT and a ticket-granting service (TGS) request that includes the service principal name for the service it would like to access. The KDC creates a service ticket (TGS)which is encrypted with the service’s password hash, then encrypts the ticket and authenticator message with the shared ticket-granting service session key, and finally sends the TGS back to the client.
A client requests access to an application server (service) by presenting the service ticket it obtained from the KDC to the application server, which decrypts the message using its own password hash. If it successfully decrypts the TGS, the application server grants access to the client.
What follows is a more detailed step-by-step diagram and breakdown:
There are a handful of factors that influence how Kerberos operates, and can be sources of problems if not sufficiently provided for.
Microsoft’s Active Directory is the most widely consumed Kerberos implementation. Support for Kerberos is found in almost every operating system – from Apple OSX/iOS to many UNIX and Linux distributions. While Microsoft implements a heavily extended version of the Kerberos protocol, there are also software packages that implement the core specification that can be used to provide secured authentication in several contexts.
When reading about Kerberos, you’ll frequently see mentions of LDAP. Kerberos and LDAP are commonly joined together (including in Active Directory) to provide a centralized user directory (LDAP) and authentication (Kerberos) services.
LDAP, the Lightweight Directory Access Protocol, stores information about users, groups, and other objects (like computers) in a central location. It can also provide for simple authentication, however these native protocols, unlike Kerberos, generally require the user’s secret (i.e. password) to be transmitted over the network. Each resource the user wants to access must handle the user’s password and separately authenticate the user to the directory.
Unlike LDAP, Kerberos provides for single sign-on functionality. Once a user has authenticated to the KDC, no other service (like an intranet site or file share) needs the user’s password. The KDC – that trusted third-party – is responsible for issuing tickets that each service trusts. The combination of LDAP and Kerberos provides centralized user management and authentication, and in larger networks this provides substantial security benefits.
If you’re curious, it is easy to see your Kerberos tickets in the wild. On a Microsoft Windows computer, you can use the klist.exe program to enumerate them.
You can view the tickets issued to you on your computer by opening a command prompt or Powershell and running klist tickets. In the example below, you can see that Joe has a ticket for the CIFS service, which is file share access, to a server called fileserver1.
PS C:\Windows\system32> klist tickets Current LogonId is 0:0xe67df Cached Tickets: (4) #0> Client: Joe @ domain.local Server: cifs/fileserver1.domain.local/domain.local @ DOMAIN.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize Start Time: 7/10/2020 12:33:49 (local) End Time: 7/10/2020 22:32:13 (local) Renew Time: 7/17/2020 12:32:13 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x40 -> FAST Kdc Called: DC1.domain.local
Kerberos is a well-known and widely used authentication protocol that also lies at the heart of Microsoft’s Active Directory. Given this stature, it has become one of the protocols most targeted for abuse by adversaries of all shades. At Stealthbits, we’ve dedicated ourselves to helping enterprises protect themselves from and detect these attacks. If you’re interested in learning more about attacks on Active Directory and Kerberos, visit the Stealthbits Attack Catalog; or, learn about how our solutions can help you defend your network.
Start a Free Stealthbits Trial!
No risk. No obligation.