What is the difference between LDAP and Active Directory?

LDAP is a protocol; Active Directory is a product. AD is Microsoft's directory service, and LDAP is one of the protocols it speaks, alongside Kerberos and others. Directories such as OpenLDAP and Oracle Unified Directory also implement LDAP, so applications written against the protocol can work with any of them.

The protocol can be operated securely, but its defaults are weak. Plain LDAP on port 389 sends bind passwords unencrypted, so LDAPS or StartTLS is mandatory in production. The larger limitation is architectural: LDAP authentication is single-factor by nature, so sensitive access should be fronted by a platform that adds MFA and risk policies.

Should new applications use LDAP for authentication?

Generally no. New applications should integrate with an identity provider over OpenID Connect or SAML, which delivers SSO, MFA, and centralized policy without the application ever handling passwords. LDAP remains the right answer for infrastructure that only supports it, ideally through a gateway backed by the same central platform.

LDAP (Lightweight Directory Access Protocol)

What is LDAP?

LDAP is the standard protocol applications use to query directory services and verify credentials, powering authentication for countless enterprise systems.

Last updated: 14 July 2026

How LDAP works

LDAP is a client-server protocol for reading and writing entries in a directory tree. Every entry has a distinguished name (DN) that encodes its place in the hierarchy, for example uid=jsmith,ou=people,dc=example,dc=com, plus attributes defined by a schema. Clients issue a small set of operations: bind to authenticate, search with filters like ([email protected]), and add, modify, or delete entries.

Authentication with LDAP usually takes one of two shapes. In a simple bind, the application sends the user's DN and password and the directory verifies them. In the search-then-bind pattern, the application first searches for the user's entry by username or email using a service account, then binds as the found DN with the supplied password. Traffic runs on port 389, or 636 for LDAPS; production deployments should always encrypt with TLS, since a plain bind transmits the password in clear text.

Why LDAP matters

LDAP is the lingua franca of enterprise infrastructure. Linux servers using PAM and SSSD, network appliances, Jenkins and other CI tools, VPN concentrators, databases, and thousands of business applications all authenticate users by speaking LDAP to a directory. It long predates SAML and OpenID Connect, and much of the software that depends on it will never be rewritten.

That ubiquity is both its strength and its risk. LDAP-based authentication is typically just a password check: no MFA, no device or risk signals, no phishing resistance. Directories reachable over unencrypted LDAP, over-privileged service accounts used for searches, and injection through unsanitized filter input are recurring findings. Any modern identity strategy has to answer the question of what to do with the LDAP-only estate.

LDAP in practice

The pragmatic path is to keep LDAP where it is needed but move its trust anchor. Enforce LDAPS everywhere, give search service accounts read-only access to the narrowest subtree possible, and inventory which systems still authenticate over LDAP so they are visible in risk assessments.

For modernization, an LDAP gateway lets legacy systems keep speaking the protocol they know while authentication decisions move to a central identity platform with MFA and adaptive policy behind the scenes. Monosign includes such an LDAP gateway, which lets Linux PAM/SSSD hosts, Jenkins, and NAS appliances authenticate against the platform without any changes on the client side.

Frequently asked questions

What is the difference between LDAP and Active Directory?: LDAP is a protocol; Active Directory is a product. AD is Microsoft's directory service, and LDAP is one of the protocols it speaks, alongside Kerberos and others. Directories such as OpenLDAP and Oracle Unified Directory also implement LDAP, so applications written against the protocol can work with any of them.
Is LDAP secure?: The protocol can be operated securely, but its defaults are weak. Plain LDAP on port 389 sends bind passwords unencrypted, so LDAPS or StartTLS is mandatory in production. The larger limitation is architectural: LDAP authentication is single-factor by nature, so sensitive access should be fronted by a platform that adds MFA and risk policies.
Should new applications use LDAP for authentication?: Generally no. New applications should integrate with an identity provider over OpenID Connect or SAML, which delivers SSO, MFA, and centralized policy without the application ever handling passwords. LDAP remains the right answer for infrastructure that only supports it, ideally through a gateway backed by the same central platform.