LDAP System Administration [Electronic resources] نسخه متنی

2.5 Authentication

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.

Figure 2-8. person objectClass

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 DNin 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)

2.5.1 Anonymous Authentication

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).

2.5.2 Simple Authentication

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.

2.5.3 Simple Authentication Over SSL/TLS

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.

2.5.4 Simple Authentication and Security Layer (SASL)

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:

Kerberos
v4 (KERBEROS_V4)

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.