↓ Skip to main content
Le Site de François
  1. Index/

LDAP (Lightweight Directory Access Protocol)

Identity Networking Directory Authentication Standards Pki

LDAP (Lightweight Directory Access Protocol) is a client-server protocol for accessing and modifying a directory service: a specialised database optimised for read-heavy, hierarchically-organised identity data. It was derived from the X.500 directory standard in the early 1990s, stripping out OSI transport dependencies to run over TCP/IP, and standardised in its current form in RFC 4511 (LDAPv3, 2006). A directory in the LDAP sense is not a general-purpose database — it is a tree of entries (also called objects), each identified by a Distinguished Name (DN) that encodes its position in the hierarchy: cn=alice,ou=users,dc=example,dc=com. Each entry is an instance of one or more object classes (defined in a schema), and each object class defines a set of mandatory and optional attributes — typed, multi-valued fields such as uid, cn (common name), mail, userPassword, memberOf, sshPublicKey, objectClass, and userCertificate. The schema is extensible: LDAP servers ship with standard schema files (RFC 2307 for POSIX users and groups, RFC 4519 for person entries) and organisations add custom schema for application-specific attributes. The tree structure makes hierarchical policy delegation natural — all objects under ou=engineering,dc=example,dc=com can be administered by a different set of ACL rules than objects under ou=ops.

The LDAPv3 operation set covers the full directory lifecycle. Bind authenticates the client to the server using one of several mechanisms: simple bind (DN + password in cleartext — should only be used over TLS), SASL bind (pluggable authentication via GSSAPI/Kerberos, PLAIN, SCRAM, EXTERNAL for certificate-based auth), or anonymous bind (read-only access without authentication). Search is the dominant operation: the client specifies a base DN, a scope (base — only the base entry; one — direct children; sub — the entire subtree), a filter expression using a rich boolean syntax ((&(objectClass=posixAccount)(uid=alice)), (|(memberOf=cn=admins,...)(memberOf=cn=ops,...)))), and a list of attributes to return. Modify changes attributes on an existing entry; Add and Delete manage entries; ModifyDN renames or moves entries. All operations can be performed within a StartTLS or LDAPS (LDAP over TLS on port 636) session; LDAPv3 without TLS transmits bind credentials and search results in cleartext and must not be used on untrusted networks. LDAP referrals allow a directory to redirect a client to another server for entries outside its naming context, enabling multi-master and distributed directory deployments.

In the Linux infrastructure stack, LDAP is the data store that identity services query, but is rarely exposed directly to applications or users — SSSD provides the caching, reconnection, and NSS/PAM integration layer that translates LDAP directory data into the POSIX identity model (uid, gid, home directory, shell, group membership). Active Directory implements LDAPv3 as its directory protocol alongside Kerberos for authentication — AD’s LDAP schema is a superset of RFC 2307 with Microsoft-specific extensions (SIDs, msDS-* attributes, userAccountControl bitmask). FreeIPA (Red Hat Identity Management) provides an LDAP server (389 Directory Server) with a pre-configured schema combining RFC 2307, Kerberos integration, and HBAC/sudo rule storage. OpenLDAP is the dominant open-source standalone LDAP server on Linux, used as the backend for custom identity stores and for LDAP-enabled applications that require a directory without the full AD or FreeIPA stack. X.509 certificates can be stored in LDAP entries (the userCertificate attribute in the pkiUser object class), enabling certificate-based authentication flows where a client presents a certificate and the server validates it against the stored value. PBKDF2 and bcrypt password hashes stored in the userPassword attribute replace cleartext passwords in hardened LDAP deployments; the SSHA (salted SHA-1) scheme is legacy and should be migrated to stronger algorithms. Access Control Lists (ACLs) in OpenLDAP (olcAccess attributes in the cn=config DIT) govern which DNs may read, write, or authenticate which attributes — the most security-sensitive ACL being the restriction of userPassword reads to the entry’s own DN only (by self write by * none).

Related

AD (Active Directory)

Identity Authentication Microsoft Kerberos Ldap Pki Enterprise
Active Directory (AD) is Microsoft’s enterprise directory and identity platform, first released with Windows 2000 and now the dominant identity provider in enterprise environments worldwide. It combines four technologies into a single integrated system: LDAP as the directory access protocol for querying and modifying identity data; Kerberos 5 as the authentication protocol for issuing tickets that prove identity without transmitting passwords; DNS as the service location mechanism that clients use to discover domain controllers, Kerberos KDCs, and LDAP servers; and Group Policy as the configuration management system that pushes security settings, software installation, and policy enforcement to every joined machine. These four components are inseparable in practice: a Linux host joining an AD domain receives a Kerberos principal in AD’s KDC, a machine account object in the AD LDAP directory, a DNS record for its hostname, and (optionally) Group Policy Objects applied to it. The AD forest is the trust boundary: multiple domains can exist within a forest and all share a common schema, configuration, and Global Catalog, with transitive Kerberos trust between them.

OIDC (OpenID Connect)

Security Identity Authentication Sso Federation Kubernetes Standards
OpenID Connect (OIDC) is an authentication protocol built as a thin layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Where OAuth 2.0 defines how to delegate authorisation (granting access to resources), OIDC adds the missing authentication semantics: a standard ID token that proves who the user is, a UserInfo endpoint that returns standardised identity claims, and a discovery document that allows clients to configure themselves automatically from a single well-known URL. The separation is precise: OAuth 2.0 access tokens prove that a client is authorised to call an API; OIDC ID tokens prove that a specific user authenticated with a specific identity provider at a specific time. OIDC is the protocol behind virtually every “Sign in with Google / GitHub / Microsoft” flow, every SAML-to-modern-stack migration, and every Kubernetes service account token issued today — making it the dominant authentication federation standard in cloud-native infrastructure.

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.