This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 1, 2026. Spotted a mistake? Tell us.
Kerberos and LDAP live side by side in almost every Windows network, which is why people assume they do the same job. They do different jobs:
- Kerberos is an authentication protocol. It proves who a user or service is, using tickets issued by a trusted third party.
- LDAP is a directory access protocol. It reads and writes entries — users, groups, machines — in a directory tree.
Active Directory implements both. When a user signs in to a domain-joined Windows machine, Kerberos does the authentication; when an application looks up that user's email or group membership, LDAP does the lookup.
What Kerberos does
Kerberos (RFC 4120) uses a Key Distribution Center (KDC) that holds a secret for every principal. The flow, simplified:
- The client asks the KDC for a ticket-granting ticket (TGT), proving its identity once.
- For each service it wants to use, the client presents the TGT and receives a service ticket.
- The service accepts the ticket without contacting the KDC and without seeing the user's password.
The result is single sign-on inside a domain: one login at the start of the day, and every Kerberos-aware service accepts the tickets. Passwords never travel to the services, and tickets have short lifetimes with renewals.
Kerberos does not store user profiles, group lists or application data. It authenticates principals.
What LDAP does
LDAP (RFC 4511) is a protocol for accessing a directory: a tree of entries, each with a distinguished name and attributes.
bind— authenticate the connection itself, typically with a DN and password.search— find entries matching a filter.add,modify,delete— manage entries.
LDAP is where the data lives: usernames, emails, phone numbers, group memberships, organizational units. It can authenticate a connection with a simple bind, but it does not issue tickets, does not manage sessions, and does not give you browser single sign-on.
Side by side
| Question | Kerberos | LDAP |
|---|---|---|
| What it is | Authentication protocol | Directory access protocol |
| Standard | RFC 4120 | RFC 4511 |
| Credential | Tickets (TGT, service tickets) | Bind credentials, usually DN + password |
| Stores user data | No | Yes |
| Single sign-on scope | Kerberos-aware services in a realm/domain | None by itself |
| Typical clients | Windows domains, HPC, databases, NFS | Applications, appliances, Linux, VPNs |
| Encryption | Built into the protocol | Requires TLS (LDAPS or StartTLS) |
Why Active Directory blurs the line
AD DS is a package: Kerberos for authentication, LDAP for directory access, DNS for locating domain controllers, Group Policy for configuration. That is why "AD authentication" can mean either:
- Kerberos logon for domain-joined machines and services.
- LDAP bind for applications that speak LDAP, which AD also accepts.
An application that supports "LDAP" can usually talk to AD; an application that supports "Kerberos" can accept AD tickets. The two integrations have different operational requirements: LDAP needs a bind account and a base DN, Kerberos needs a keytab and clock synchronization.
Where web SSO fits
Neither Kerberos nor LDAP is a web single sign-on protocol. Browsers do not speak Kerberos natively outside of Windows integrated authentication, and LDAP has no concept of a browser session.
For browser-based applications, the SSO protocols are SAML 2.0, OpenID Connect and, in older estates, CAS. An identity provider can sit in front of the directory:
- Users sign in to the identity provider with a password, passkey or MFA.
- The identity provider reads profile data from LDAP or AD when it needs attributes.
- Applications get SAML assertions or OIDC tokens — never direct directory access.
That separation is also a security improvement: applications stop holding directory credentials.
When to use which
- Windows domain with domain-joined machines: Kerberos, managed by AD. Do not reimplement it.
- Application that needs user attributes: LDAP against AD or OpenLDAP.
- Browser SSO for SaaS and internal apps: SAML or OIDC through an identity provider.
- Legacy appliance that only speaks LDAP: expose an LDAP endpoint from the identity provider rather than giving the appliance a domain account.
Casdoor follows that last pattern: it can sync users from LDAP and Active Directory, and it can act as an LDAP server for tools that have no other option, while web applications use OIDC, SAML or CAS. See LDAP vs Active Directory for the directory side.
Related reading: SAML vs OIDC and SSO vs OAuth.
Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.
Sources
- RFC 4120: The Kerberos Network Authentication Service (V5)
- RFC 4511: Lightweight Directory Access Protocol (LDAP)
- MIT Kerberos documentation
- Microsoft Learn: Active Directory Domain Services overview
Product names are trademarks of their respective owners.