What Is Kerberos?

Kerberos Explained  

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 on 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. 

How Does Kerberos Work? 

Kerberos was originally named after Cerberus – the three-headed dog, in Greek mythology, that guards the gates of Hades – because of the three distinct actors in the protocol: 

• Client: The entity seeking to provide its identity. 
• Application Server (AP): The service that the client (or user) wants to access. 
• Key Distribution Center (KDC): The trusted third-party, which issues tickets. In Active Directory each domain controller acts as a KDC. The KDC provides two core services: Authentication Service (AS) which authenticates clients and issues them tickets and the Ticket-Granting Service (TGS) which accepts authenticated clients and issues them tickets to access other resources. 

Kerberos Authentication Flow 

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 it’s 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:

1. KRB_AS_REQ: Request TGT from Authentication Service (AS) 

• The client’s request includes the user’s User Principal Name (UPN) and a timestamp. It is encrypted using the user’s password hash. 

2. KRB_AS_REP: TGT Received from Authentication Service 

• The KDC uses the UPN to look up the client in its database and uses the user’s password hashto attempt to decrypt the message. 
• If the KDC successfully decrypts the TGT request and if the timestamp is within the KDC’s configured time skew, the authentication is successful. 
• A TGT and a TGS session key are sent back to the client. The TGS session key is used to encrypt subsequent requests. 

3. KRB_TGS_REQ: Present TGT and TGS request 

• The client presents its TGT along with a request including the Service Principal Name (SPN) for the service it wants to access. 
• The TGS request is encrypted with the TGS session key. 

4. KRB_TGS_REP: Receive TGS from KDC 

• The KDC validates the TGT, and if successful a TGS is generated. The TGS contains information about the requestor (like their SID and group memberships) and is encrypted with the service’s password hash. 
• The TGS and the service session key are encrypted with the TGS session key then sent back to the client. 

5. KRB_AP_REQ: Present TGS to Application Server for Authorization 

• The client sends the TGS which it received from the KDC to the application server along with an authenticator message which is encrypted with the service session key. 

6. KRB_AP_REP: Grant Client Access to the Service 

• The client receives the message and decrypts it with the service session key. 
• The Application Server extracts the Privilege Attribute Certificate (PAC) from the service ticket to verify its contents with a domain controller. 
• Validation of the ticket/PAC only happens when the Ticket Granting Ticket (TGT) is older than 20 minutes. 

Important Factors 

There are a handful of factors that influence how Kerberos operates, and can be sources of problems if not sufficiently provided for. 

• Replication between domain controllers 
  If multiple domain controllers (i.e. multiple KDCs) are deployed, then replication must be enabled and converge in a timely manner. Should replication fail or convergence be delayed, authentication failures are possible when a user changes their password.  
   
• Clients and KDCs must use NETBIOS and DNS name resolution 
  Kerberos Service Principal Names normally include NETBIOS and DNS addresses, which means both the KDC and Client must be able to resolve those names the same way. In certain situations, IP addresses may also be used in Service Principal Names. 
   
• Clients and KDCs must have their clocks synchronized 
  Accurate measurement of time is important in Kerberos to prevent replay attacks. Kerberos supports a configurable time skew (default 5 minutes) outside of which authentication will fail. 

• Clients and KDCs must be able to communicate on the network 
  Kerberos traffic occurs on TCP and UDP port 88, which must be accessible from all clients to at least one KDC (domain controller). 
   
• Clients, Users, and Services must have unique names 
  Duplicate names for computers, users, or Service Principal Names can cause Kerberos unexpected Kerberos authentication failures. 

Where is Kerberos Used? 

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. 

Kerberos vs LDAP 

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.  

How can I see my Kerberos Tickets? 

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

Conclusion 

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.