4.1.2 - SASL Authentication¶
- 126.96.36.199 - SASL PLAIN text Authentication
- 188.8.131.52 - SASL CRAM-MD5 Authentication
- 184.108.40.206 - SASL DIGEST-MD5 Authentication
- 220.127.116.11 - SASL GSSAPI Authentication
- 18.104.22.168 - SASL EXTERNAL Authentication
- 22.214.171.124 - SASL NTLM Authentication
SASL authentication is based on a standard described in RFC 4422. SASL means Simple Authentication and Security Layer.
It extends the Simple authentication, by allowing the LDAP server to authenticate the user by various mechanisms.
The SASL* Authentication is used when a simple user/password authentication is not enough, or when one want to delegate authentication to another system. Many other systems exist, and may take many parameters to authenticate a user. With SASL**, a challenge/response system is used to get the needed information from the client, up to the point the authentication is either successful or fails.
As ApacheDS is based on Java, we only support the SASL mechanisms the JDK supports :
* PLAIN : cleartext user/password authentication * CRAM-MD5 : IMAP/POP authentication * DIGEST-MD5 : Http Digest authentication * GSSAPI : Kerberos authentication * EXTERNAL : External authentication * NTLM : NTLM authentication * GSS-SPNEGO : The SPNEGO authentication
It's important to notice that some of those mechanisms are either useless (PLAIN) or obsolete (DIGEST-MD5).
It's of course possible to modify the list of supported SASL mechanisms, by updating the server's configuration. The list of mechanisms is stored as entries under the following DN :
One can also check the configured SASL mchanisms on the server by sending a SeachRequest to the server, on the RootDSE, looking for the supportedSASLMechanisms. Here is the esult on ApacheDS 2.0.0 :
Configuring this list can also be done using Studio ApacheDS Configuration plugin :
Usage and security¶
Most of the existing SASL mechanisms are just either useless (PLAIN, ANONYMOUS) or too weak to be used in a secured environment (DIGEST-MD5 or CRAM-MD5).
A new SASL mechanism has been designed to replace the last two mechanisms : SCRAM (RFC 5802).
In any case, if you are using one of those mechanisms, be sure to activate TLS.
The SASL specifications are defined by an IETF Working Group which has published the following proposed standards :
* [RFC 4013](http://www.ietf.org/rfc/rfc4013.txt) : SASLprep: Stringprep Profile for User Names and Passwords * [RFC 4422](http://www.ietf.org/rfc/rfc4422.txt) : Simple Authentication and Security Layer (SASL) * [RFC 4505](http://www.ietf.org/rfc/rfc4505.txt) : Anonymous Simple Authentication and Security Layer (SASL) Mechanism * [RFC 4616](http://www.ietf.org/rfc/rfc4616.txt) : The PLAIN Simple Authentication and Security Layer (SASL) Mechanism * [RFC 4752](http://www.ietf.org/rfc/rfc4752.txt) : The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism * [RFC 5801](http://www.ietf.org/rfc/rfc5801.txt) : Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family * [RFC 5802](http://www.ietf.org/rfc/rfc5802.txt) : Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
Some other RFCs have been published, for each specific mechanisms, some of them are obsoleted by more recent RFCs :
* [RFC 2595](http://www.ietf.org/rfc/rfc2595.txt) : Using TLS with IMAP, POP3 and ACAP (updated by RFC 4616) * [RFC 2195](http://www.ietf.org/rfc/rfc2195.txt) : IMAP/POP AUTHorize Extension for Simple Challenge/Response * [RFC 2831](http://www.ietf.org/rfc/rfc2831.txt) : Using Digest Authentication as a SASL Mechanism (obsoleted by RFC 6631) * [RFC 2222](http://www.ietf.org/rfc/rfc2222.txt) : Simple Authentication and Security Layer (SASL) (obsoleted by RFC 4422)