Kerberos and LDAP are both authentication and authorization protocols, and both often work with on-premises resources. However, they function very differently from one another, and Kerberos and LDAP tend to work best in different use cases and with different types of resources. This blog will lay out a Kerberos vs. LDAP comparison, including their differences, the pros and cons of each, and how they can work together in a modern multi-protocol environment.
It’s important to understand the basics of each protocol before diving into how they differ. We’ll start with Kerberos.
What Is Kerberos?
Kerberos is a protocol that facilitates mutual authentication across an untrusted network (like the internet) and authorization of a client (i.e., user) to services (i.e., applications). Kerberos uses shared key cryptography through a ticket-based authentication system, whereby tickets are issued, encrypted, and decrypted by a key distribution center (KDC).
Kerberos is often used for single sign-on (SSO) purposes (though its reach is limited — see Kerberos disadvantages below). The protocol is open source, although Microsoft’s proprietary version of Kerberos is one of its most popular use cases — Microsoft uses Kerberos for many of its major systems and services, including Microsoft Windows and Active Directory.
How Does Kerberos Work?
Kerberos facilitates mutual authentication: it authenticates both the user and the service before the user can begin a session with the service. Once each party is authenticated, they are allowed to communicate directly with one another to initiate a session.
When the user is authenticated, they receive a ticket granting ticket (TGT), which proves their identity for the subsequent steps in the Kerberos authentication process. This TGT’s lifespan can be extended to facilitate SSO: the user remains authenticated during an active session, and can reuse that secure authentication to access any resource within the domain.
Kerberos authentication is facilitated through the key distribution center (KDC), which is hosted by the domain controller and uses shared-key cryptography for authentication. The KDC contains an authentication server and a ticket granting server (TGS), which create, encrypt/decrypt, and send messages to users and services. The KDC also has a database, which stores the secret symmetric keys that encrypt messages for both users and services. Mutual authentication is achieved through a series of encrypted messages and tickets sent amongst the user, service, and KDC.
Kerberos Pros and Cons
- Mutual authentication: Mutual authentication requires both the client and the service to verify their identities before they are granted access to communicate with one another. This differs from many authentication protocols, which only verify the user. Verifying the identities of both the client and the server protects both parties in the transaction.
- Wide usage: Kerberos is a popular protocol that’s available for most main operating systems, including Windows, Mac, and Linux. It is widely used, especially for Microsoft systems, which use Microsoft’s proprietary version of Kerberos.
- Open standard: Kerberos is an open standard, which makes it available to a wide variety of software and applications. This has contributed to its extensive adoption and usage.
- Single sign-on: Kerberos can extend the lifetime of the user’s authentication ticket for reusable authentication, which acts as SSO.
- Security challenges: With great power comes great probability of getting hacked. The key distribution center holds the ability to grant users time-based authentication tickets to all the resources in the domain. This is great for SSO — and not so great for security. In the aptly named “golden ticket attacks,” attackers gain control over the key distribution center and forge ticket granting tickets, which essentially allows them to access anything in the domain.
Kerberos faces other security issues as well; for example, Microsoft’s iteration of Kerberos doesn’t salt the hashes used for its stored long-term secret keys, making them easier to crack.
- Limited to the (on-premises) domain: Because Kerberos authenticates by storing and passing secret-key cryptography messages to and from the client and service, both the client and service must be within the domain (often, the domain is Microsoft Active Directory). This means that Kerberos cannot authenticate to cloud-based resources and other resources outside the domain without using an extension like Microsoft AD Domain Services (AD DS), which charges a monthly subscription fee, or a VPN that simulates an on-prem network, which can quickly become complex and hard to manage.
In today’s increasingly cloud-based business environment, this limitation can be significant. Kerberos SSO, for example, only extends to resources within the domain rather than all the resources a user needs to do their work.
- Often requires third-party integrations: Because Kerberos is designed for on-premises resources and requires an on-premises KDC, it requires third-party integrations to accommodate many modern functions, from extending it to the cloud to adding multi-factor authentication (MFA). These integrations tend to require manual configurations and somewhat complex processes. These integrations also create supply chain risk: compromise to an integrated third-party solution could spread throughout the domain.
- Microsoft lock-in: While Kerberos is not limited to Microsoft, Microsoft’s usage of Kerberos tends to lock users into the Microsoft suite. The need to extend on-premises setups to the cloud is increasing, and more and more businesses are turning to solutions like Microsoft AD Domain Services to solve this problem with Microsoft AD and Kerberos. However, these cloud extensions tend to create complex networks of Microsoft-based integrations that are difficult to prize apart, creating a lock-in effect.
What Is LDAP?
LDAP stands for lightweight directory access protocol. It is a protocol that facilitates directory management and communication, including setting up and modifying a LDAP directory as well as authenticating and authorizing to the directory. LDAP is most commonly used by technical applications (like Jenkins, OpenVPN, and the Atlassian suite), server infrastructure, file servers, and networking equipment.
One of the most common instances of LDAP is OpenLDAP, a free and open source LDAP implementation. Others include cloud-based LDAP on platforms like JumpCloud. Cloud-based LDAP removes the need for hosting LDAP infrastructure and opens the possibility for multi-protocol environments.
How Does LDAP Work?
The LDAP protocol defines a method of directory storage, and allows for directory creation, maintenance, and authentication/authorization. LDAP can perform the following main functions:
- Update: This includes adding, deleting, or modifying directory information.
- Query: This includes searching and comparing directory information. Authentication is built off of queries: the user enters login credentials, and the LDAP protocol queries the LDAP directory to confirm a match with their user identity stored within the directory.
- Authenticate and authorize: The LDAP protocol both authenticates and authorizes users to their resources. It authenticates users with a bind operation that allows the user to communicate with an LDAP directory, then authorizes the authenticated user to the resources they need if their input login information matches what’s listed for them in the database.
For a deeper dive into how LDAP works, read the blog, What Is LDAP?
LDAP Pros and Cons
Directory management and lookup capabilities: One of the key differences between Kerberos and LDAP is LDAP’s ability to manage directories. In addition to authentication, LDAP can also facilitate directory queries and management, which Kerberos cannot do.
Flexibility: LDAP has open source implementations (OpenLDAP, for instance) that allow you to build a directory from scratch or according to pre-built schemas. It is also not closely tied to one provider, preventing vendor lock-in.
LDAPS security: LDAP has a secure encrypted counterpart, LDAPS. LDAPS encrypts LDAP data in transit over a secure connection (SSL or TLS). LDAPS is implemented at the root level, which makes it available to any LDAP server.
On-premises: LDAP was developed in the ʼ90s, and therefore was designed to work with on-premises resources. As premised equipment makes its way to the cloud, LDAP is becoming a bit less common; however, it is still used for technical resources and some server infrastructure.
Requires expertise when implementing your own instance: Flexibility can sometimes lead to complexity. Open source implementations like OpenLDAP grant so much flexibility that they require expertise to configure and manage. However, there are ways to apply a GUI wrapper or use a cloud LDAP provider to ease the burden of manual management.
Security challenges: Like Kerberos (and most protocols), LDAP can run into security issues, especially when it is not configured securely. For example, it’s possible to inject malicious code into LDAP queries, often referred to as LDAP injection. Fortunately, using LDAPS and applying certain configuration settings — like setting data return limits and disallowing anonymous binds — solve most of these issues.
Kerberos vs. LDAP: Comparison Summary
In short, Kerberos and LDAP are both network protocols used for authentication and authorization, but they differ in their intended usage, authentication process, and types of resources they work with.
- Intended usage: Kerberos was designed for authentication, while LDAP is a directory management protocol that can also facilitate authentication.
- Authentication process: Kerberos uses symmetric key cryptology to facilitate mutual authentication between a client and a resource; LDAP queries a database to compare a user’s input credentials with those stored in the directory.
- Resource type: While Kerberos authenticates resources within the domain and is heavily popular with Microsoft systems, LDAP is more commonly used for technical applications and on-premises infrastructure, like file servers.
Because Kerberos and LDAP differ in these key areas, they actually work fairly well together. For example, a system might use Kerberos to authenticate users to resources and use LDAP to store users’ data, which would inform their permission levels within their resources.
This pairing is just one example of the diversification of business applications and the protocols they use. Corporate resources are becoming increasingly cloud-based and diverse, and the protocols they support are following suit. That means businesses today need to be able to support a wide range of protocols to ensure their employees have access to the resources they need to do their work. The best way to achieve this is through an open directory platform.
An open directory platform is a cloud-based directory that allows users to securely connect to all the resources they need to do their work — from anywhere, on any trusted device, and with one trusted identity. Open directories support a wide range of protocols and resource types — for instance, JumpCloud’s open directory platform is so diverse in the resources it supports that it can facilitate SSO to virtually every resource a user needs to do their work. Learn more about True SSO with an open directory platform.