{scrollbar} Work in progress

This site is in the process of being reviewed and updated.


Apache Directory currently supports the CRAM-MD5, DIGEST-MD5, and GSSAPI SASL mechanisms. SASL is used during LDAP Binds to authenticate users. Additionally, with the DIGEST-MD5 and GSSAPI mechanisms, SASL can also provide message integrity (checksums) and, optionally, message privacy (encryption). When using SASL message privacy, connections do not need SSL to protect communications.


SASL workflow is implemented in the LDAP Protocol Provider's BindHandler. At the start of a Bind, the BindHandler handles SASL negotiation. During SASL negotiation, the LDAP client is first authenticated. After successful authentication, an LDAP context is established and a SUCCESS message is returned.

Inbound --> decoder --> BindHandler <--> Backend #1, #2 Outbound <-- encoder <------'

Backend #1 is a lookup to authenticate the user using an administrative (internal) directory context.
Backend #2 is an LdapContext establishment for the user that is stored in the user's MINA session.

The DIGEST-MD5 and GSSAPI SASL mechanisms can provide message integrity and, optionally, message confidentiality by "wrapping" or "unwrapping" data with a security layer. After the Bind has completed the BindHandler will insert a MINA filter that handles security layer processing into the IoFilterChain for the session that was SASL-authenticated. All subsequent LDAP operations will be wrapped or unwrapped by the SaslFilter (assuming message integrity or privacy are negotiated). For example, a subsequent search would arrive wrapped and thus must be unwrapped by the SaslFilter prior to being ASN.1 decoded into a SearchRequest. Similarly, all outbound responses, including errors and unbinds, will be wrapped by the SaslFilter.

Inbound --> SaslFilter --> decoder --> SearchHandler <--> backend Outbound <-- SaslFilter <-- encoder <-------'

Password must be stored as plaintext in the 'userPassword' attribute.
Username is matched to 'uid' under a base DN.


Password must be stored as plaintext in the 'userPassword' attribute.
Username is matched to 'uid' under a base DN.
Realm must match realms advertised by the LDAP server, but there is no multi-realm support yet.


Principal name is matched to the 'krb5PrincipalName' attribute under a base DN.
No multi-realm support yet.
Principal configuration (user, service, krbtgt) can all occur on LDIF load.

Anonymous queries

RootDSE queries will never require authentication.

$ ldapsearch -s base -LLL supportedSASLMechanisms -x supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5

When anonymous authentication is disabled, queries below the RootDSE will require authentication. The following command will fail if anonymous access is disabled.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -x
SASL queries

CRAM-MD5 is a username/password mechanism.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -U hnelson -w secret -Y CRAM-MD5

DIGEST-MD5 is a username/password mechanism. DIGEST-MD5 also supports the concept of "realm."

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -U hnelson -w secret -Y DIGEST-MD5 -R example.com

GSSAPI will use the Kerberos credentials of the current user. GSSAPI supports the concept of "realm," but the realm is part of the username, eg 'hnelson@EXAMPLE.COM'.

$ ldapsearch -b "dc=example,dc=com" "(uid=hnelson)" -Y GSSAPI

IMAP/POP AUTHorize Extension for Simple Challenge/Response

Using Digest Authentication as a SASL Mechanism

RFC 4422 - Simple Authentication and Security Layer (SASL)
This document obsoletes RFC 2222.

Lightweight Directory Access Protocol (LDAP): Directory Information Models

RFC 4513 - Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
This document obsoletes RFC 2251, RFC 2829, and RFC 2830.

Simple Authentication and Security Layer (SASL) Mechanisms

RFC 3829 - LDAP Authorization Identity Request and Response Controls

  • No labels