LDAP vs Active Directory: a protocol is not a directory

LDAP and Active Directory are often used as if they were the same thing. They are not: LDAP is a protocol for talking to a directory, and Active Directory is a directory service that speaks several protocols, LDAP among them.

You can run LDAP without Active Directory (OpenLDAP, 389 Directory Server). You can also use Active Directory without writing LDAP queries (Kerberos-based Windows logon). The confusion comes from the fact that both answers use the word "directory".

What LDAP is

LDAP (Lightweight Directory Access Protocol) is defined in RFC 4511. It is a wire protocol for reading and changing a directory: a tree of entries, each identified by a distinguished name (DN) and described by attributes.

An entry looks like this:

• DN: uid=alice,ou=people,dc=example,dc=com
• objectClass: inetOrgPerson
• uid: alice
• mail: alice@example.com

The protocol defines a small set of operations: bind (authenticate the connection), search, compare, add, modify, delete, and extended operations such as StartTLS. It does not define how a server stores data or hashes passwords; that is left to the implementation.

Servers that implement LDAP include OpenLDAP, 389 Directory Server and Microsoft Active Directory. When a company says "the LDAP server", it usually means one of these.

What Active Directory is

Active Directory Domain Services (AD DS) is Microsoft's directory service for Windows domains. It is more than an LDAP server:

• LDAP is one of its access protocols.
• Kerberos handles authentication between domain members.
• DNS locates domain controllers.
• Group Policy configures users and machines.
• SMB and other Windows services rely on it.

AD DS stores objects with an extensible schema and organizes them into domains, trees and forests. A lighter variant, AD LDS, provides an LDAP directory without the domain services.

The overlap, side by side

The practical consequence: every Active Directory is an LDAP server, but most LDAP servers are not Active Directory. If an application says "supports LDAP", it can usually talk to AD. If it says "supports Active Directory", it may rely on AD-specific behavior such as Kerberos or the AD schema.

Authentication: where the difference shows

LDAP authentication is a simple bind: the client sends a DN and a password, and the server says yes or no. The password is in the request, so the connection must be encrypted with StartTLS or LDAPS.

Active Directory prefers Kerberos: the client proves its identity to a domain controller and receives a ticket, and services accept the ticket without seeing the password. AD also accepts LDAP simple binds, which is why many third-party apps integrate with AD over LDAP.

Neither is a web single sign-on protocol. LDAP tells an application who a user is; it does not give you SAML, OIDC or CAS flows for browser-based applications. For that, see SAML vs OIDC and what an identity provider and a service provider do.

When you would use which

• Windows-centric company, employees on domain-joined machines: Active Directory, with Group Policy and Kerberos. Applications integrate over LDAP or federate to AD through SAML or OIDC.
• Cross-platform application directory: OpenLDAP or 389 Directory Server. No Windows domain, no Group Policy, just entries and bind operations.
• Appliances and network gear: most NAS boxes, VPNs and printers speak LDAP, not SAML. An LDAP directory is the integration point.
• Customer-facing web and mobile apps: neither. Use an identity provider that speaks OIDC, SAML or CAS, and connect it to the directory if employees are involved.

How Casdoor connects to LDAP and Active Directory

Casdoor covers both sides of the boundary:

• As a client. Each organization can point at an LDAP server or an Active Directory domain: server host and port, LDAPS, base DN, a search filter such as (objectClass=posixAccount), the attributes used as the login name, and a bind account. Users under the base DN can be listed and synced into Casdoor, and an auto-sync interval keeps them current. See the LDAP configuration docs.
• As a server. Casdoor can act as a simple LDAP server on port 389 for tools that only speak LDAP, such as Nexus. It supports bind and search with Simple Authentication, exposes users as posixAccount entries with the Samba object classes, and reads the username from cn and the organization from ou. See the LDAP server docs.

That means a legacy appliance can keep using LDAP while your web applications move to OIDC or SAML against the same user store.

The short version

LDAP is how you talk to a directory. Active Directory is a directory service that answers LDAP and adds Kerberos, DNS and Group Policy. If you are choosing the directory for a Windows estate, that is AD. If you are choosing how applications authenticate, that is an identity provider speaking OIDC or SAML, with LDAP as the directory underneath if you still need one.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees. It can sync from LDAP and Active Directory today and serve LDAP to devices that have no other option.