What is Kerberos and how does it work?

What does the Kerberos authentication protocol do?

Kerberos provides a standardized way to verify a user's or host's identity over a network. Its aim is to authenticate service requests between trusted hosts, such as clients and servers, on untrusted networks, like the internet.

The protocol's mechanism assumes that the transactions between those hosts are happening on an open network, meaning the packets traveling on it are susceptible to eavesdropping and tampering. To prevent these issues, it uses secret key cryptography. This facilitates mutual authentication between the hosts and allows their identities to be verified prior to the establishment of a secure network connection. To authenticate user identities and authorize users for access, Kerberos uses symmetric key cryptography and a key distribution center (KDC).

The name Kerberos was taken from Greek mythology; Kerberos (Cerberus) was a three-headed dog who guarded the gates of Hades. Like the mythical dog, the Kerberos protocol has three heads:

1. Client or principal. The entity that initiates a service request on behalf of a user.
2. Network resource. The application server that provides access to the network resource requested by the client.
3. KDC. A centralized server that acts as Kerberos' trusted third-party authentication service. The KDC includes an authentication server (AS) that does the initial authentication, a ticket-granting server (TGS) that issues service tickets and connects the service-requesting user to the service server (SS), and a database that stores the details of all verified users to facilitate authentication and authorization.

Kerberos was also designed to interface with secure accounting systems. This provided the third "A" of the authentication, authorization and accounting, or AAA, triad.

How does the Kerberos authentication protocol work?

A simplified description of how Kerberos works follows; the actual process is more complicated and may vary from one implementation to another:

1. AS request. To access a service, the initiating client starts the Kerberos client authentication process. To do this, it sends an authentication request to the Kerberos KDC AS. The initial authentication request is sent as plaintext because no sensitive information is included in the request. The AS verifies that the client is in the KDC database and retrieves the initiating client's private key.
2. AS response. The AS starts the initial authentication by looking for the initiating client's username in the KDC database. If the name is not found, the client cannot be authenticated, and the authentication process stops. Otherwise, the AS sends the client a ticket-granting ticket (TGT) and a session key.
3. Service ticket request. Once authenticated by the AS, the client asks for a service ticket from the TGS. This request must be accompanied by the TGT sent by the KDC AS.
4. Service ticket response. If the TGS can authenticate the client, it sends credentials and a ticket to access the requested service. This transmission is encrypted with a session key specific to the user and service being accessed. This proof of identity is used to access the requested "Kerberized" service. That service validates the original request and then confirms its identity to the requesting system.
5. Application server request. The client sends a request to access the application server. This request includes the service ticket received in step 4. If the application server can authenticate this request, the client can access the server.
6. Application server response. In cases where the client requests the application server to authenticate itself, this response is required. The client has already authenticated itself, and the application server response includes Kerberos authentication of the server.

The service ticket sent by the TGS enables the client to access the desired service. The service ticket is timestamped, so a single ticket can be used for a specific period without having to be reauthenticated.

Making the ticket valid for a limited time reduces the possibility that some other user or attacker is able to use it later. The maximum lifetime can be set to 0, in which case service tickets do not expire. Microsoft recommends a maximum lifetime of 600 minutes for service tickets; this is the default value in Windows Server implementations of Kerberos.

Benefits of Kerberos authentication

Kerberos provides an extensive and proven authentication mechanism for service systems and users. Users, systems and services relying on Kerberos need only trust the KDC. It runs as a single process and provides two services: the authentication service and the ticket-granting service.

Kerberos authentication uses conventional shared-secret cryptography to prevent packets that are traveling across the network from being read or changed.

Kerberos' authentication mechanism also protects messages from eavesdropping and replay attacks. This is due to the use of strong cryptography with encrypted secret keys and third-party authorization. Also, passwords are never sent over networks, minimizing the potential for threat actors to steal user identities or impersonate them to access systems and services on the network.

Another benefit of Kerberos is that it enables effective access control. IT admininistrators can enforce security policies to control system access. It also improves user experience because they need to be authenticated only once. As long as the Kerberos ticket is active, users don't have to enter their login credentials multiple times to access a system.

Kerberos objectives, concepts and terms

Goals for the Kerberos system are spelled out in a tutorial written by Fulvio Ricciardi of the National Institute of Nuclear Physics in Lecce, Italy. They include the following:

• Passwords must never be transmitted over the network.
• Passwords must never be stored on client systems and always must be discarded immediately after they are used.
• Passwords are never stored in plaintext, even on the ASes.
• A password is entered only once in each session. This is an early form of single sign-on (SSO) authentication, and it means that users can authenticate themselves just once but still access any systems for which they are authorized.
• All authentication information is maintained in a centralized AS. The application servers themselves do not store any authentication information. This enables the following features:
• • An administrator can disable authorization for a user to use any application server from the centralized AS. Access to individual servers is not necessary to revoke authorization.
  • A single user password is enough to access all Kerberos-authenticated services. A user can reset their password just once, no matter how many services they are authenticated to use.
  • Protecting user information is simplified because all user authentication information is stored on one centralized AS rather than on all the individual servers the user is authorized to use.
• All parties -- users and application servers -- must authenticate themselves when prompted. Users authenticate when they sign in. Application services may be required to authenticate themselves to the client.
• Kerberos provides a mechanism for clients and servers to set up an encrypted circuit so that networked communications are private.

History of Kerberos

Kerberos was developed in the 1980s at the Massachusetts Institute of Technology (MIT) as part of Project Athena. This project, named after the ancient Greek goddess of wisdom, aimed to provide MIT students with easier access to computing resources. One of the outcomes of this groundbreaking project was the development of Kerberos as the authentication system.

Before Athena and Kerberos, networked systems at MIT typically authenticated users with a user ID-and-password combination. Systems routinely transmitted passwords "in the clear," meaning unencrypted. Attackers with access to the network could eavesdrop on network transmissions, intercept user IDs and passwords, and then attempt to access systems for which they were not authorized.

Kerberos developers set out to provide a network authentication protocol that could authenticate trusted hosts communicating over untrusted networks. In particular, they intended to provide system administrators with a mechanism for authenticating access to systems over an open network -- the internet.

Kerberos was initially designed as the Kerberos Authentication and Authorization System in a paper with the same name written by S.P. Miller, B.C. Neuman, J.I. Schiller and J.H. Saltzer. The designers intended Kerberos' authentication as a means for supporting authorization. Thus, its original objectives were to provide a way for users of the MIT network to do the following:

• Securely authenticate themselves to the systems they needed to use.
• Be authorized to access those systems.

In 2005, the Internet Engineering Task Force published the Kerberos protocol as a Proposed Standard in Request for Comments 4120. The MIT Kerberos Consortium was founded in September 2007 to further the development of the technology. In 2013, the consortium was expanded and renamed the MIT Kerberos and Internet Trust Consortium.

Since its early days, numerous OSes have incorporated Kerberos' authentication system. Starting with Windows 2000, Microsoft has used the Kerberos protocol as the default authentication method in Windows versions, and it is an integral part of the Windows Active Directory (AD) service. Broadband service providers also use the protocol to authenticate cable modems and set-top boxes accessing their networks. Many secure systems also use Kerberos for authentication, including file sharing software, file storing mechanisms and SSO systems.

The current version of Kerberos -- as of March 2025 -- is V5 Release 1.21.3. This version, which was released in June 2024, is free to download from MIT's Kerberos webpage. It fixes many issues from previous versions, including vulnerabilities in General Support System message token handling and a memory leak in the macOS cache type.

What is Kerberos used for?

The protocol is used by default in many widely used networking systems. Some systems in which Kerberos support is incorporated or available are the following:

• Amazon Web Services (AWS). A cloud computing platform that provides 200-plus services, like compute, storage, databases, analytics and artificial intelligence -- all of which can be accessed on demand from anywhere and in a pay-as-you-go fashion.
• Google Cloud. Similar to AWS, a set of cloud computing services delivered on demand from Google's globally distributed data centers.
• Microsoft Azure. Another cloud computing platform that provides services like compute, storage, networking and analytics delivered over the cloud.
• Apple macOS. A GUI-based OS for Apple's Mac computers.
• Hewlett Packard Unix. A proprietary OS for HP systems that provides high availability and security, plus features for virtualization and workload management for mission-critical computing applications.
• IBM Advanced Interactive eXecutive. A stable and secure Unix-based OS for use in workstations, servers and network-attached storage.
• Microsoft Windows Server. A family of server OSes that implements Kerberos V5 for public key authentication.
• Microsoft AD. A directory service to manage user access and permissions -- it uses a domain controller and Kerberos to authenticate user accounts.
• Oracle Solaris. A proprietary Unix OS and platform for deploying enterprise-grade clouds.
• Red Hat Enterprise Linux. An enterprise Linux platform that runs on all major public clouds, including AWS, Azure and Google Cloud.
• FreeBSD and OpenBSD. Two free, open source, Unix-like OSes suitable for a wide range of applications.

Is Kerberos secure?

The Kerberos protocol, which has been widely implemented in recent decades, is considered a secure, mature and safe mechanism for authenticating users. One reason is that it uses strong cryptography, including secret key encryption, to protect sensitive data and to limit resource access only to authenticated and authorized users.

Over the years, security researchers have found some weaknesses in specific Kerberos implementations and in the protocol itself. Some of these historic weaknesses as used in Windows networks were summarized in a 2015 blog post by security researcher Elmar Nabigaev. They included the following:

• Pass-the-key attack. This is a form of pass-the-hash attack in which attackers impersonate authorized users by replaying their credentials.
• Pass-the-ticket attack. Attackers intercept and reuse tickets sent to or from an authenticated user to impersonate them and reuse their service tickets.
• Golden ticket attack. This is an attack that uses access to the Windows domain controller to create credentials that give unlimited access to application services.

But these weaknesses have been addressed in subsequent releases, and Kerberos remains a secure choice for authentication applications over the internet.

To keep Kerberos secure, you should stay updated on information about its security vulnerabilities that may be published online, particularly on MIT's Kerberos webpage. It's equally important to implement all the software updates that can mitigate or remediate these flaws.

Kerberos vs. other network authentication protocols

Kerberos is not the only authentication protocol in general use, but it is probably the most widely used one. Kerberos has been proven to be a secure protocol, capable of coping with unexpected input or errors during execution.

Kerberos vs. Microsoft NTLM

Microsoft New Technology LAN Manager (NTLM) is a family of authentication protocols used in Microsoft Windows 10, Windows 11, Windows Server 2019, Windows Server 2022 and Windows Server 2025. These protocols incorporate a challenge-response mechanism to prove to a server that a user knows the password associated with an account, thus authenticating them for accessing that account.

Both Microsoft and non-Microsoft applications can use NTLM for user authentication. However, for AD environments, Microsoft prefers Kerberos V5 authentication.

Kerberos vs. LDAP

Lightweight Directory Access Protocol (LDAP) is a standard directory access protocol to connect to and search internet directories. Running above the TCP/IP stack, it offers a method for maintaining and accessing authoritative information about user accounts and for authorizing user access to accounts on networked services.

Unlike LDAP, Kerberos is a ticket-based authentication protocol. That said, LDAP and Kerberos are often used together, with LDAP providing authorization services and Kerberos providing authentication services for large networks.

Kerberos vs. RADIUS

The Remote Authentication Dial-In User Service (RADIUS) protocol was designed to provide an authentication service for dial-in users to remotely access internet service providers or corporate networks over direct connections, like dial-up phone lines. RADIUS can be used for authorization and accounting of network services. It can also be integrated with Kerberos to provide stronger authentication.

Three different sets of entities use Kerberos:

1. Kerberos principal. This is any unique identity that Kerberos can assign a ticket to. For most users, a principal is the same as a user ID. It also includes hosts and services that can be assigned Kerberos tickets. Individual clients are one type of Kerberos principal. The service principal is an identity assigned to an application service that is accessed through Kerberos. A principal is uniquely identified with at least three pieces of information:
1. For users, the principal primary is a username. For hosts, the primary is the word host. For services, the primary name is the service's name.
2. An optional identifier of the principal usually specifies the host name of the system the primary is associated with.
3. Kerberos servers operate in a limited network region, called a realm. Realms are identified by domain name system named domains. A principal's realm is the domain name in which the Kerberos server operates.
2. Kerberos application server. This is any system providing access to resources that need client authentication through Kerberos. For example, application servers can include file and print services, terminal emulation, remote computing and email.
3. Kerberos KDC. The Kerberos authentication process depends on the following KDC components:
1. Kerberos database. This maintains a record for each principal in the realm. This is the centralized repository for Kerberos authentication information. It includes identifying information of the principal and the systems and services for which that principal can be authenticated to use.
2. Kerberos authentication service. Network clients use this Kerberos service to authenticate themselves to get a TGT, also known as an authentication ticket.
3. Kerberos ticket-granting service. This Kerberos service accepts the TGT so that clients can access their application servers.

Authentication with Kerberos is based on the use of authentication tickets. An authentication ticket indicates that the user is authenticated through the Kerberos authentication service. After it has been granted, the user can request other tickets to access specific application services.

Authentication is a security layer used to protect all networks and applications. Read up on authentication types, from two-factor authentication to biometrics to certificates. Use these user authentication types to secure networks.