LDAP Authentication

Authentication is the basic building block of the entire modern computer world. User locks there computer using passwords. Interesting thing is all about authentication mechanism developed by Operating System developer over the period of time. Kerberos, Plugable Authentication Module (PAM), LDAP so on and so forth is in the list.
This document revolves around LDAP.

LDAP (Lightweight Directory Access Protocol) authentication means simply issuing LDAP bind operation in which client trying to authenticate to centralized LDAP server for authentication and bind the client to server as an authorized or un-authorized user.
LDAP is highly modular and configurable or we may say like it is flexible, so that we have wide range of variety of forms of authentications such as:

•Clear text passwords over the wire
•Choosing not to authenticate
•Authentication with a certificate
•Authentication using some custom method

In a very traditional forms for authentication where a user sends username and password directly to the system or across the wire using LAN or WAN, if its about sending password across the wire, the password is encrypted using private/public key before sent it on wire to protect the password.

Microsoft Active Directory supports all the LDAP standard authentication mechanisms, as well as a few more.

The LDAP standard introduces the various forms of authentication by first categorizing them as authentication methods, with various authentication mechanisms underlying each method.

Authentication Methods

•Simple, password-based authentication – When this method of authentication is used, the DN (distinguished name) and password are sent over the network in clear text (not encrypted). It should be noted however, that even with the inherent security vulnerabilities, it is possible to use Simple authentication with transport layer security (like TLSv1/SSL or IPSec) in a secure manner.

Anonymous Authentication Mechanism of Simple Bind:
a simple LDAP bind operation with a name and password value of zero length. NIX based system doesn’t support such mechanism while Windows do.
Unauthenticated Authentication Mechanism of Simple Bind:
a simple LDAP bind operation with a non-zero length name that corresponds to a valid user entry and a password value of zero length. NIX based system doesn’t support such mechanism while Windows do.

•SASL authentication mechanisms – The Simple Authentication and Security Layer
•(SASL) is a specification and method used by the LDAPv3 protocol to support what is known as pluggable authentication. This mechanism is used by the directory server (LDAPv3) and directory client (LDAPv3) to identify the user, authenticate this user to the directory server (LDAPv3), and finally to negotiate an optional security layer for subsequent protocol interactions. The SASL (RFC 2222) mechanism is covered in more detail later in this chapter.
Note – The LDAP v2 protocol does not support the Simple Authentication and
Security Layer (SASL).

•Certificate-based authentication – Using this method, it is possible with the Sun ONE Directory Server 5.2 software to require that when the client connects to the directory server, the client provides a digital certificate to the directory server as identification. Authenticating a client using a client certificate really falls under the SASL category because a client certificate will only be used to authenticate the client if that client performs a bind operation using the SASL EXTERNAL mechanism.

Fast Bind for Authentication Only
In addition to authentication methods and mechanisms, there is one noteworthy LDAP session option that may be of interest. The Concurrent bind or Fast Bind session option can be used by applications to authenticate users, assuming that only authentication is needed, and no subsequent LDAP operations requiring authorization are needed. A Fast Bind does not build a user token; it only verifies the username and password so subsequent LDAP operations that would require the authorization information in that token are not allowed. The LDAP Fast Bind requires that the Simple Authentication Method be used, and so TLS or IPsec must be used in association with making use of this option. Sample code and more information are available on MSDN.

SASL Authentication Method
The SASL authentication method is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. The SASL standard (RFC4422) only defines one such mechanism, the EXTERNAL authentication mechanism; however the SASL standard expects many authentication mechanisms to be defined to work within its framework.
LDAP based Directories supports four SASL authentication mechanisms:

•GSSAPI Authentication Mechanism
The GSSAPI authentication mechanism (RFC2743) allows the client to pass GSSAPI tokens to the server to establish their credentials. In this case, valid GSSAPI tokens are a Kerberos TGT or NTLM token. A confidentiality feature can be employed as part of GSSAPI to encrypt the token and authentication exchange.
A SASL GSSAPI LDAP bind operation with a name that corresponds to a valid user entry and the password value corresponding to that user entry. The password is not sent over the wire at all, instead the token representing the user is sent.

•GSS-SPNEGO Authentication Mechanism
The GSS-SPNEGO authentication mechanism (RFC4178) is actually the GSSAPI authentication mechanism but with a client-server negotiation mechanism that provides for selection of the preferred security mechanism that both client and server support. In this case, the server will prefer Kerberos then NTLMv2. For that reason, refer to the GSSAPI authentication mechanism for further details.

•EXTERNAL Authentication Mechanism
The EXTERNAL authentication mechanism allows the client to request that the server use credentials established by a means external to the mechanism to authenticate the client. The external means might be via information in IPsec or TLS or some other other means. What means are used depends on the server, and there is no negotiation of what those means are, so the client must know beforehand what the means are, and provide them.

A SASL EXTERNAL LDAP bind operation is issued with either:
- a non-zero length name that corresponds to the valid user entry desired
- a zero length name if the client wants the server to map the results of the external mechanism to the appropriate user entry.

Active Directory supports the SASL EXTERNAL authentication mechanism via TLS and user certificates that are mapped onto user accounts. This is considered a very strong authentication mechanism.

•DIGEST-MD5 Authentication Mechanism
The DIGEST-MD5 authentication mechanism (RFC2831) provides a mechanism for the HTTP Digest authentication (RFC2617) challenge/response paradigm to be used within the SASL framework. Because this mechanism relies on HTTP 1.1, it has a smaller set of uses.

This mechanism sends a MD5 checksum of the password over the wire without encryption. This is superior to sending a cleartext password with a simple bind, but is not considered strong authentication.

Which Method and Mechanism Should I Use?
•Simple Authentication Method, using the Name/Password Authentication Mechanism of Simple Bind, having first initiated session-level encryption
•SASL Authentication Method, using the GSSAPI Authentication Mechanism, employing Kerberos, NTLMv2, or NTLM
Which method/mechanism you choose, will likely be dependent on which method and mechanism is supported by your operating system and application. Since passwords are sensitive data, you should choose the strongest method and mechanism available. The strongest possible method and mechanism is SASL using Kerberos and employing session-level encryption.
From strongest to least, the possible combinations are:
•SASL, using GSSAPI, employing Kerberos and session-level encryption
•SASL, using GSSAPI, employing NTLMv2 and session-level encryption
•SASL, using GSSAPI, employing Kerberos
•SASL, using GSSAPI, employing NTLMv2
•SASL, using GSSAPI, employing NTLM and session-level encryption
•Simple Authentication, using name/password and employing session-level encryption.
•SASL, using GSSAPI, employing NTLM