LDAP Is Dead

Strictly speaking, LDAP is a protocol that is specified in a series of Internet Engineering Task Force RFCs, which also includes information models, schemas, authentication mechanisms, identifier format, search filter structure and other details. The specifications are quite comprehensive. Interoperability was clearly one of the primary goals of specification authors.

However, LDAP practice does not really comply with the specifications. There are many conventions, unwritten rules, dos and don’ts, server-specific tricks and workarounds in the LDAP world. Strict adherence to LDAP specification is an assurance to get you into interoperability problems. E.g. the usual LDAP grouping mechanisms do not really work unless standard schema is modified in non-standard way. This is a widely accepted fact in LDAP community, therefore most LDAP servers come off-the-shelf with a pre-violated schema.

I’m not talking about server-to-server interoperability here, which (as far as I know) was never the intention of the protocol. I’m talking about simple down-to-earth client-to-server interoperability. In practice, LDAP server cannot be easily replaced without adjusting all the clients. Client cannot connect to an LDAP server without setting up annoying details, such as account object class, identifier names, group object class, account and group locations or identifier patterns, attribute names and reference mechanisms - details that should have been specified by the standard. By the way, LDAP has more than three (!) grouping mechanisms, which are mutually non-compatible. This is just insane.

Moreover, non-standard extensions are necessary to support reasonable interaction with the server once you dare to go beyond the very basics. Non-standard mechanisms such as memberOf and Virtual List Views (VLV) are absolutely necessary to work with LDAP data at scale. Permissive modify is necessary for maintaining consistency (in case the server has not already deviated from the specifications for your convenience). Such non-standard mechanisms have server-specific nuances, working slightly differently in each implementation.

Even worse, some issues are not solved at all, not even by non-standard extensions. Account activation (ability to disable and enable an account) is a notorious example. Every LDAP server has its own method to do it (except for OpenLDAP, which does not have any way to do it). There are server-specific mechanisms, specifics and tweaks for almost everything.

In practice, LDAP interoperability is very limited. Honestly, it is mostly just a myth. There is no LDAP server that I know of which is completely compliant with LDAP specifications, and I have seen a lot of LDAP servers during my long career. LDAP protocol is mostly used for password-based authentication for simple applications, using just one or two basic LDAP operations (search and bind). Some applications are bold enough to support rudimentary authorization based on LDAP groups, despite all the notorious problems. However, LDAP clients always have to adapt to a specific LDAP server, its data structure, configuration, design choices and conventions. Isn’t it strange that we have got used to this painful practice so easily?

You may think that my "LDAP is dead" statement is too bold or premature. Maybe it is. There are many operational LDAP servers out there, many applications support LDAP authentication, the ecosystems seem to (somehow) work. However, that is not the point.

The point is that we are using LDAP for integrations like it is still the 1990s. Every integration path is customized and fine-tuned to specific server. This is error-prone, time-consuming and fragile. It requires expertise that is increasingly harder to come by. Clearly, this not the right way.

Moreover, cybersecurity and identity landscape is vastly different from it was in the 1990s. We are supposed to have zero trust now, and machine identities are finally getting some attention. LDAP is built to use service accounts for application authentication. Are you regularly updating the credentials of the service accounts? Can you? Do you even know that you should?

Can LDAP adapt to new cybersecurity landscape and requirements? Technically, it could. There is nothing in the protocol itself that would prohibit that. Will it adapt? That is very unlikely. Last significant update of LDAP specifications was in June 2006. Even though there are painful problems all this time, nobody bothered to fix them - for almost two decades. My interpretation is that LDAP community thinks that LDAP is not worth fixing any more.

Nevertheless, LDAP should be considered unmaintained legacy protocol by now. Call it dead, dying, undead, legacy or whatever you want. These are just terminology nuances.

One thing is clear: If LDAP cannot be fixed, it will get replaced. It is perhaps for the better. The legacy of the 1990s (and the 1980s in its X.500 roots) goes very deep into LDAP core. The foundations are very obvious in LDAP schema among other places.

It will take many years for LDAP to visibly decline, even more decades to disappear completely. However, LDAP eventual demise is inevitable. It has started already. LDAP is dead. Identity industry should finally get over LDAP and move on.

Right! LDAP needs to be replaced. What to replace LDAP with? That is a billion-dollar question. Quite literally.

Some parts of LDAP functionality are easy to replace, others are not.

Authentication is the easy part: Just don’t use LDAP for authentication. LDAP is not sufficient for your needs, anyway. You absolutely need strong authentication (passkeys, multi-factor), which LDAP cannot really provide. Use OpenID Connect and/or proper authentication server instead of LDAP. LDAP was never meant to be an authentication server anyway.

Authorization functionality is much more difficult to replace. In fact, there is no easy answer to authorization question in the identity industry at large. There is no easy way to conduct authorization properly. Rough-grain is not the problem. Rough-grain authorization can be enforced by the single sign on (SSO) server, as a follow-up to authorization. Many servers that implement OpenID Provider functionality are capable of enforcing rough-grain authorization. The servers can decide which applications are allowed or denied for a particular user. However, when it comes to fine-grain authorization, things tend to get unbelievably complicated. There is a good reason for this complexity. Fine-grain authorization inherently depends on the application data and, even more importantly, on application concepts. Therefore, the specific details of authorization mechanism are going to be different for each application. However, even LDAP is not able to address that. The usual practice of LDAP integration is for application to consume LDAP groups. The application implements its local kind of authorization magic on top of the groups. Identity administrator can control user membership in the groups, but no other details of the authorization magic. Similar functionality can be reproduced even without LDAP, e.g. by a creative use of OpenID Connect scopes, or by employing SCIM to control group membership (see below). Such approaches leave a lot to be desired - but so does LDAP. At the enterprise scale, full-featured identity management solution (Identity governance and administration platform) is a must anyway, which can easily replace LDAP group management functionality.

Then there is synchronization and provisioning. These mechanism make sure that identity data are consistent across all the relevant directories, databases and applications. As LDAP was designed for distributed (replicated) directories, LDAP servers were traditionally seen as central points for identity data synchronization. Even though LDAP was never designed for heterogeneous synchronization, synchronization capabilities of LDAP servers are often (ab)used by synchronization and provisioning engines of all kinds.

Strictly speaking, synchronization and provisioning are not LDAP responsibilities, and LDAP server cannot implement them alone. Additional software is always needed anyway. There are many systems that can handle synchronization without any need for LDAP. This is the domain where identity governance and administration (IGA) platforms really shine. However, IGA tools need to access the data somehow. LDAP was instrumental as a common protocol to access (some) identity repositories. However, LDAP is slowly replaced by SCIM.

System for Cross-domain Identity Management (SCIM) is an IETF specification (RFC7642) of a service for identity provisioning. SCIM specification describes services to create, read, update and delete (a.k.a. "CRUD") data about users and groups, which is almost exactly the functionality that LDAP provides. SCIM has (theoretical) advantage over LDAP, as it can be used to reach much more than just identity repositories. In theory, every application is supposed to implement SCIM API, allowing standardized external access to identity data. However, there is a lot of problems when it comes to practice. Despite the problems, SCIM may be a better choice than LDAP for future applications.

When it comes to its future potential, LDAP is dead. It is cold rotting corpse. Despite being dead, it still kicks. It is being used in many deployments, which have to deal with the same unsolvable problems over and over again.

LDAP is not going to disappear quickly. It will take years, even decades. It is going to be slow and painful death.

Soon, LDAP won’t be considered for new deployments. LDAP functionalities are going to be replaced by other protocols, such as OpenID Connect or SCIM. The sooner we let LDAP go, the better. LDAP is not evolving, it has become a dead weight. Sticking to LDAP is holding us back. It is time to let go.

Confused? You are probably thinking "This can’t be right!" - especially if you are part of the identity community for some time already. Maybe some of your thoughts and questions can be answered below.