Why is authentication needed in an LDAP directory? Remember that LDAP is a connection-oriented, message-based protocol. The authentication process is used to establish the client’s privileges for each session. All searches, queries, etc. are controlled by the authorization level of the authenticated user.
Figure 2-8 describes the person
object class and gives you an idea of what other attributes are
available for the cn=gerald
carter
entry in Figure 2-1. In
particular, you will need to define a userPassword
attribute value to further explore LDAP authentication.
The LDIF representation for the expanded version
cn=gerald
carter
is:
dn: cn=gerald carter,ou=people,dc=plainjoe,dc=org objectClass: person cn: gerald carter sn: carter telephoneNumber: 555-1234 userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ= =
We have added an attribute named userPassword
.
This attribute stores a representation of the credentials necessary
to authenticate a user. The prefix (in this case,
{MD5}
) describes how the credentials are encoded.
The value in this case is simply the Base64 encoding of the MD5 hash
of the word “secret.”
RFC 2307 defines prefixes for several encryption algorithms. These
are vendor-dependent, and you should consult your
server’s documentation to determine which are
supported. Generating userPassword
values will be
covered in more detail in the context of various programming
languages and APIs in later chapters. Some common encoding types are:
{CRYPT}
The password hash should be generated using the local
system’s crypt( )
function, which
is normally included in the standard C library. The
{CRYPT}
prefix will be seen quite a bit in Chapter 6 when we discuss using LDAP as a replacement
for NIS.
{MD5}
The password hash is the Base64 encoding of the MD5 digest of the user’s password.
{SHA}
(Secure Hash Algorithm)The password hash is the Base64 encoding of the 160-bit SHA-1 hash (RFC 3174) of the user’s password.
{SSHA}
(Salted Secure Hash Algorithm)This password-hashing algorithm developed by Netscape is a salted
version of the previous SHA-1 mechanism. {SSHA}
is
the recommended scheme for securely storing password information in
an LDAP directory.
The act of being authenticated by an LDAP directory is called
binding. Most users are accustomed to providing a username and
password pair when logging onto a system. When authenticating an LDAP
client, the username is specified as a DN—in our example,
cn=gerald
carter,ou=people,dc=plainjoe,dc=org
. The
credentials used to authenticate this entry are given by the value of
the userPassword
attribute.
The LDAPv3 specifications define several mechanisms for authenticating clients:
Anonymous Authentication
Simple Authentication
Simple Authentication over SSL/TLS
Simple Authentication and Security Layer (SASL)
Anonymous Authentication is the process of binding to the directory using an empty DN and password. This form of authentication is very common; it’s frequently used by client applications (for example, email clients searching an address book).
For
Simple Authentication, the login
name in the form of a DN is sent with a password in clear text to the
LDAP server. The server then attempts to match this password with the
userPassword
value, or with some other predefined
attribute that is contained in the entry for the specified DN. If the
password is stored in a hashed format, the server must generate the
hash of the transmitted password and compare it to the stored
version. However, the original password has been transmitted over the
network in the clear. If both passwords (or password hashes) match,
the client is successfully authenticated. While this authentication
method is supported by virtually all existing LDAP servers (including
LDAPv2 servers), its major drawback is its dependency on the client
transmitting clear-text values across the network.
If sending usernames and passwords over the network is not particularly tasty to you, perhaps wrapping the information in an encrypted transport layer will make it more palatable. LDAP can negotiate an encrypted transport layer prior to performing any bind operations. Thus, all user information is kept secure (as well as anything else transmitted during the session).
There are two means of using SSL/TLS with LDAPv3:
LDAP over SSL (LDAPS - tcp/636) is well supported by many LDAP servers, both commercial and open source. Although frequently used, it has been deprecated in favor of the StartTLS LDAP extended operation.
RFC 2830 introduced an LDAPv3 extended operation for negotiating TLS over the standard tcp/389 port. This operation, which is known as StartTLS, allows a server to support both encrypted and nonencrypted sessions on the same port, depending on the clients’ requests.
With the exception of the transport layer security negotiation, the binding process is the same as for Simple Authentication.
Designers of LDAPv3 defined two pieces of functionality, Extended Operations and Controls, to allow for additions to the original protocol without requiring a new version to be standardized. LDAP Controls apply only to individual requests and responses, similar to the way an adjective extends a noun. Depending on the client’s needs, if a server does not support a specified Control, the request may fail, or the Control may simply be ignored and the request will continue normally. An Extended Operation is the equivalent of defining a new word that must be understood by both the client and server.
SASL is an extensible security scheme defined in RFC 2222 that can be used to add additional authentication mechanisms to connection-oriented protocols such as IMAP and LDAP. In essence, SASL supports a pluggable authentication scheme by allowing a client and server to negotiate the authentication mechanism prior to the transmission of any user credentials.
In addition to negotiating an authentication mechanism, the communicating hosts may also negotiate a security layer (such as SSL/TLS) that will be used to encrypt all data during the session. The negotiation of transport layer security within SASL is not related either to the StartTLS Extended Operation or to LDAPS.
RFC 2222 defines the several authentication schemes for SASL, including:
The
Generic Security Service
Application Program Interface, Version 2 (GSSAPI
),
which is defined in RFC 2078
The S/Key mechanism
(SKEY
), which is a one-time password scheme based
on the MD5 message digest algorithm
The External (EXTERNAL
)
mechanism, which allows an application to make use of a
user’s credentials provided by a lower protocol
layer, such as authentication provided by SSL/TLS
In addition to these, RFC 2831 has added an SASL/DIGEST-MD5 mechanism. This mechanism is compatible with HTTP/1.1 Digest Access Authentication.
During the binding process, the client asks the server to authenticate its request using a particular SASL plug-in. The client and server then perform any extra steps necessary to validate the user’s credentials. Once a success or failure condition has been reached, the server returns a response to the client’s bind request as usual, and LDAP communication continues normally.