Kerberos: Why and When you Should use it

Microsoft Active Directory Domain Services (ADDS) is the defacto directory service in today’s enterprise. Most organizations run Active Directory on-premises to provide access to internal resources, such as file services, email, intranets, SharePoint sites, and to provide role-based access control.

Azure Active Directory (Azure AD) is the cloud equivalent to Microsoft’s legacy AD DS solution. Both technologies share similarities and differences, including authentication protocols. Active Directory Domain Services has traditionally used Kerberos for authentication. What is Kerberos, and how is it used in Active Directory Domain Services? Does it also work with Azure AD?

What is Kerberos, How Does it Work, and What is it Used for?

Many attribute the Kerberos authentication protocol to Microsoft since Kerberos is often associated with Microsoft Active Directory Domain Services (AD DS). However, the Kerberos protocol was initially developed by the Massachusetts Institute of Technology (MIT). Kerberos Version 5 was included in RFC 1510.

The actual name for “Kerberos” comes from Greek mythology. Kerberos was the three-headed dog guarding Hades. The number “three” fits with the Kerberos authentication protocol since it leverages the third party to validate an authentication request (which we will describe later).

The Kerberos protocol is designed with security in mind as it provides the means to have secure authentication over an insecure network. It includes authentication that never sends passwords over the network, and encryption keys are not directly exchanged. Instead, Kerberos authentication works on the premise of secure “tickets” to provide secure, single-sign-on mutual authentication using a third party.

The Kerberos tickets are time-limited encrypted messages that establish user identity to a server without exchanging passwords across the network or storing these locally. With Kerberos, the authentication ticket granted to users establishes identity. Once the user has authenticated once at the beginning of the login session, the credentials are transparently passed to other network resources to validate the user has permission to access these throughout their login session.

Kerberos works using a centralized authentication server. In Active Directory Kerberos, it is the domain controller. The domain controllers serve as the “trusted third-party” enabling the mutual authentication service. All authentication requests are routed through Active Directory domain controllers.

As mentioned earlier, Kerberos provides mutual authentication. It helps to establish and protect sensitive information in both directions. It establishes the user’s identity as who they say they are and establishes the server’s identity.

Kerberos uses a set of centralized servers (domain controllers in AD) that Kerberos calls Key Distribution Center (KDC). The KDC is the entity that stores the usernames and passwords for users and special Kerberos-enabled services. As mentioned earlier, Kerberos is a ticket-based authentication protocol that uses the tickets to prove the identities of users and servers. The KDC(s) generate the tickets used by users to authenticate to the network.

The KDC stores all the secret symmetric keys for users and services. The KDC itself contains three core components. Keep in mind these components in many implementations of Kerberos, including across Active Directory domain controllers, are shared in the same Kerberos process, including:

• • Database of user principals – contains all users and their passwords and other password information such as password expiration, etc. In Active Directory, this information is contained in the Active Directory database.

The Active Directory Domain Services database

• • Authentication Server – Issues the Ticket-Granting Ticket (TGT), enabling client logins to the Kerberos Realm

• • Ticket Granting Server (TGS) – It can be easily confused with the Ticket Granting “Ticket.” It is the server that issues individual service tickets to clients that request them

The Kerberos V5 protocol is designed to assume the network where the authentication flow happens on an open, insecure network where packets could potentially be “sniffed” or monitored in some way. This assumption parallels the Internet today, where an attacker can easily pose as either a client or server.

How can authentication be validated if Kerberos doesn’t send the user’s password across the network? When a user requests to authenticate on the Kerberos Realm (the Active Directory domain in Microsoft’s AD DS implementation), the user’s password is verified via decryption. Why is this important? Since only the KDC and the user are the only ones that “know” the password for the user, the encrypted ticket can only be decrypted if the correct password is known.

Let’s step through the authentication request and how the information exchange is handled between the client and the KDC in the Active Directory login process. Below is a visual representation of the Kerberos login process and the steps involved with communication between the client, domain controllers, and server. By default, Kerberos communicates over UDP port 88.

The Kerberos authentication process

      1. When the user login process is initiated on the client workstation, it sends a plaintext request (TGT request). This request contains the following information: userID, the ID of the requested service (TGT), the IP address of the client, and validation lifetime
2. The Authentication Server (domain controller) checks to see if the userID is valid in the KDC database (Active Directory database). If the user is found:
a. The AS generates a random session key to use between the user and Ticket Granting Server (TGS)
b. Two messages are sent back to the client:
i. One is encrypted with the TGS key (a key shared between the client and TGS)
ii. The other is encrypted with the client secret key (which is a hash of the username and password)
3. The client decrypts the key and can successfully log in. The key and the TGT are stored locally
a. Now, the client has a locally cached TGT that can be used to send requests to the TGS with the target resource name
4. The TGS decrypts the user information, and it provides the Kerberos service ticket and a service session key for accessing the service. This information is sent back to the client after it is encrypted
5. The client then sends the request to the desired server for access. The request is encrypted with the service ticket and the session-key
6. The target server decrypts the session request and verifies it is valid. If valid, the service access is granted.

If the user sends the wrong password, the AS can’t decrypt the request, resulting in a login failure. In this way, the password is never sent in clear text across the network. Instead, the password is used to encrypt the request itself instead of being validated by the AS directly. This password verification by decryption proves to be an effective and secure way to verify the password without sending it across the network.

As shown above, when the user encrypts the request with the correct password, the KDC Authentication Server can decrypt the request successfully. It then issues a ticket-granting ticket (TGT). The TGT is encrypted with the Ticket-Granting Server’s key, a shared key between the Authentication Server and the Ticket-Granting Server.

The issued Ticket-Granting Ticket includes many pieces of information, including:

• • The user’s principal name

• • The service principal name

• • Ticket validity time period

• • Client IP address

• • A secret encryption key called a “session” key used for communication with applications

Microsoft took the Kerberos protocol and adapted its use into Microsoft Windows. Many of these Microsoft customizations are documented in RFC 3244. The specific Microsoft implementation of Kerberos found in Active Directory is based on Kerberos Network Authentication Service (V5) defined in RFC 4120

The Kerberos authentication protocol enables many capabilities in the context of an Active Directory Windows network. It is used to verify the identity of users and computers on the network and provides many practical benefits, including:

• • A more efficient and secure authentication protocol – Before Kerberos, NTLM was used in the Windows NT 4.0 days and is a much less efficient and less secure protocol. With NTLM, the application server is required to connect to a domain controller to authenticate every client, regardless of whether the client was authenticated a few minutes before. The ticket-based authentication provided by Kerberos allows a much more efficient, renewable session ticket authentication where the server can examine credentials presented by the client ticket and reuse these as needed during the ticket lifetime. When it comes to security, NTLM is notoriously insecure. NTLMv1 hashes can be cracked in seconds with today’s computing power since they are the same length and not salted. NTLMv2 is better since the length is variable and is salted. However, the unsalted hash is saved in memory. With Kerberos, the password is stored locally or sent over the network, and encryption is used for communications to validate credentials.

• • It provides delegated authentication – Kerberos can provide delegated authentication for accessing backend systems, which is not possible with NTLM. Delegated authentication allows Windows to impersonate a client when accessing resources on the client’s behalf. Kerberos V5 includes this proxy mechanism that enables the service to impersonate its client when connecting to other services, such as Microsoft SQL Server.

• • Interoperability – The Kerberos V5 protocol implemented in Active Directory Domain Services is based on standards set forth by the IETF. It allows Kerberos implementations in Active Directory to interoperate with other networks in which Kerberos V5 is used for authentication

• • Mutual Authentication – By design, Kerberos allows the entities on both sides of the network connection to verify the other side is who they say they are, providing mutual authentication. NTLM does not provide this capability. In addition, Kerberos assumes no trust at the outset, making it a much more modern authentication platform dealing with the cybersecurity challenges of password authentication.

How does the use of Kerberos in Active Directory Domain Services (AD DS) compare with authentication protocols in the cloud-native Azure Active Directory (Azure AD)?

Does Azure AD use Kerberos?

Azure Active Directory did not natively support using the Kerberos authentication protocol until recently. Instead, it has supported several other modern and standardized protocols for direct authentication, including SAML 2.0, OpenID Connect, OAuth 2.0, and WS-Federation, which are much more cloud-oriented authentication protocols.

However, early in December 2021, Microsoft announced Azure AD Kerberos. So what is Azure AD Kerberos, and why was it introduced? Microsoft Azure AD Kerberos is a new authentication capability of Azure AD that allows using the Kerberos authentication protocol to authenticate against Azure AD, specifically, at this point, to access Azure File shares configured to use Azure AD authentication.

It’s another move from Microsoft to incorporate natively on-premises technologies, adding the ability to perform Kerberos authentication natively helps to bridge the gap between legacy applications tied to using Kerberos instead of OAuth and allowing these to be augmented with the security-rich features of Azure AD, including Conditional Access Policies and implementing passwordless security mechanisms, such as Windows Hello.

Most of the very difficult security mechanisms that required tedious configuration, PKI infrastructure, and many other moving pieces and parts with AD DS and Kerberos on-premises are simply checkboxes or radio buttons in Azure AD. By introducing Azure AD Kerberos, Microsoft is removing an age-old dependency in requiring traditional Active Directory Domain Services.

Before introducing the new Azure AD Kerberos functionality, to use Kerberos authentication, you would create an Azure Active Directory Domain Services (Azure AD DS) managed domain. With the Azure AD DS managed domain, the directory synchronizes accounts from Azure AD, and Azure AD is synchronizing accounts from the on-premises AD DS environment. Traditionally, this approach has been the standard way to get Kerberos authentication services in Azure.

The Azure Active Directory Kerberos Authentication Process

There are various components to the login process with Azure AD. Referencing a deep dive review of Azure AD authentication with Kerberos implemented, the authentication process looks like the following:

1. When user credentials are validated, an OAuth Primary Refresh Token (PRT) is issued (contains the Device ID and Session Key)
2. A new Cloud Ticket Granting Ticket (Cloud TGT) has been introduced with Azure AD Kerberos
3. When Windows authenticates with Azure AD, it now gets a PRT and a Cloud TGT. If FIDO is used, they also get a partial TGT.
4. The client is now told to map a different realm for cloud resources. Resources destined for “*.windows.net” are mapped to KERBEROS.MICROSOFTONLINE.COM.
5. Any SMB resources that exist in *.windows.net, such as an FSLogix share that exists in Azure Files, will be authenticated using a Kerberos ticket from KERBEROS.MICROSOFTONLINE.COM.
a. This new Kerberos functionality is made possible with the new Windows mapping that introduces the Cloud TGT. The Kerberos stack places the Cloud TGT in the cache as well as the realm mapping and adds a KDC Proxy map between the realm mapping and the Azure AD tenant details.

Cloud TGT making Azure AD Kerberos functionality possible

6. Azure AD verifies the Cloud TGT matches, queries the user exists, looks up the requested Service Principal Name, and then generates a ticket.
7. The ticket is encrypted to the Azure Files storage keys, stored in its service principal name and returns this as a TGS-REP.
8. When Kerberos gets the TGS reply (TGS-REP) it strips out the ticket, generates an application request, and hands it to the SMB
9. The SMB protocol stuffs the AP-REQ into a header, and this is sent to the SMB hello to Azure Files
10. Azure Files receives the hello, the ticket is decrypted using the storage keys and now FSLogix or other application can read from the Azure File Share

The underlying process and the fact that the underlying Kerberos ticket didn’t come from a traditional on-premises Active Directory Domain Services environment is abstracted from Azure Files and SMB.

Azure AD Kerberos limitations?

There are limitations to be aware of with the new Azure AD Kerberos authentication capability. The solution is currently in Preview form at this time. It does not work with native Azure AD objects. Azure AD Kerberos does depend on users existing in an on-premises Active Directory environment, and these objects are synchronized using Azure AD Connect. While Microsoft as of yet doesn’t support cloud-only users for the new Kerberos functionality, this is a feature that will be coming soon.

Kerberos vs. LDAP

There is some confusion among many regarding the differences between Kerberos and LDAP as both terms get associated with Active Directory Domain Services. So what is LDAP, and how is it different from Kerberos? LDAP stands for Lightweight Directory Access Protocol and is a cross-platform protocol used to provide the query language that can communicate with directory servers quickly and at scale.

LDAP is not specific to Active Directory. Microsoft implemented LDAP as part of Active Directory capabilities to allow AD DS to work with LDAP-based applications. Kerberos is more secure than LDAP, but they are often used together in Active Directory. When you view objects in Active Directory Users and Computers (ADUC), you are authenticated with Kerberos, and then LDAP is used to query the Active Directory database efficiently and effectively.

Kerberos Troubleshooting Tools

There are several low-level command-line tools you can use to troubleshoot and explore Active Directory Kerberos. One of the primary tools you can use is a command-line tool called klist. The klist utility allows viewing and working with Kerberos tickets and other information.

Use the klist tickets command or simply klist to view your tickets:

Viewing Kerberos tickets using klist

You can view your TGT using the klist tgt command.

Viewing TGT ticket using klist

You can also view all the Kerbersos sessions you have with the klist sessions command.

Viewing Kerberos sessions with klist sessions

With the klist purge command you can purge all Kerberos tickets from your system.

Purging Kerberos tickets using the klist purge command

The ksetup command is another tool that allows performing tasks with the Kerberos protocol in setting up and maintaining Kerberos realms and the Key Distribution Center. These tasks include:

• • Changing Kerberos realm settings on the local computer in the Windows registry

• • Initializing registry keys for Kerberos Security Support Provider even if the computer is not a member of the Windows domain

• • Search the registry for the domain name of the user’s realm and queries DNS to resolve the name to an IP address.

Below is an example of listing the realm flags in place on a Windows computer using the ksetup command.

Listing realm flags using ksetup

Concluding Thoughts

The Kerberos authentication protocol has been a standard for authentication in the enterprise as part of Microsoft Active Directory Domain Services (AD DS) and other directory services. It provides great efficiency and security capabilities using a ticket-based authentication mechanism to establish mutual identity.

Passwords are not transmitted or stored. Instead, the password is used as part of the encryption process to send messages back and forth between the client and KDC. Since both entities should “know” the correct password, mutual authentication can occur as each can validate the exchanged information using encryption/decryption.

Azure Active Directory (Azure AD) is the cloud-based Active Directory solution that backs cloud services like Office/Microsoft 365. Until the end of 2021, Azure AD did not support Kerberos authentication. However, Microsoft has introduced Azure AD Kerberos to ease many of the challenges with legacy applications interacting with cloud-based services and allow organizations to take advantage of the security features found in Azure AD. Using Azure AD Kerberos, Kerberos authentication can now happen natively, without the need to send Kerberos authentication requests back to on-premises AD DS.

While Kerberos is not immune to security attacks, it is a robust and relatively secure authentication protocol that allows establishing identity and reducing the attack surface for compromising the authentication process.