A basic decision regarding the security policy is how users access the directory. Are anonymous users allowed to access the directory, or is every user required to log into the directory with a user name and password (authenticate)?
Directory Server provides the following methods for authentication:
The directory uses the same authentication mechanism for all users, whether they are people or LDAP-aware applications.
9.4.1. Anonymous and Unauthenticated Access
Anonymous access provides the easiest form of access to the directory. It makes data available to any user of the directory, regardless of whether they have authenticated.
However, anonymous access does not allow administrators to track who is performing what kinds of searches, only that someone is performing searches. With anonymous access, anyone who connects to the directory can access the data.
Therefore, an administrator may attempt to block a specific user or group of users from accessing some kinds of directory data, but, if anonymous access is allowed to that data, those users can still access the data simply by binding to the directory anonymously.
Anonymous access can be limited. Usually directory administrators only allow anonymous access for read, search, and compare privileges (not for write, add, delete, or selfwrite). Often, administrators limit access to a subset of attributes that contain general information such as names, telephone numbers, and email addresses. Anonymous access should never be allowed for more sensitive data such as government identification numbers (for example, Social Security Numbers in the US), home telephone numbers and addresses, and salary information.
Anonymous access can also be disabled entirely, if there is a need for tighter rules on who accesses the directory data.
An unauthenticated bind is when a user attempts to bind with a user name but without a user password attribute. For example:
ldapsearch -x -D "cn=jsmith,ou=people,dc=example,dc=com" -b "dc=example,dc=com" "(cn=joe)"
The Directory Server grants anonymous access if the user does not attempt to provide a password. An unauthenticated bind does not require that the bind DN be an existing entry.
As with anonymous binds, unauthenticated binds can be disabled to increase security by limiting access to the database. Disabling unauthenticated binds has another advantage: it can be used to prevent silent bind failures for clients. A poorly-written application may believe that it successfully authenticated to the directory because it received a bind success message when, in reality, it failed to pass a password and simply connected with an unauthenticated bind.
9.4.2. Simple Binds and Secure Binds
If anonymous access is not allowed, users must authenticate to the directory before they can access the directory contents. With simple password authentication, a client authenticates to the server by sending a reusable password.
For example, a client authenticates to the directory using a bind operation in which it provides a distinguished name and a set of credentials. The server locates the entry in the directory that corresponds to the client DN and checks whether the password given by the client matches the value stored with the entry. If it does, the server authenticates the client. If it does not, the authentication operation fails, and the client receives an error message.
The bind DN often corresponds to the entry of a person. However, some directory administrators find it useful to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to be of an object class that allows the
userPassword attribute. This ensures that the directory recognizes the bind DN and password.
Most LDAP clients hide the bind DN from the user because users may find the long strings of DN characters hard to remember. When a client attempts to hide the bind DN from the user, it uses a bind algorithm such as the following:
The user enters a unique identifier, such as a user ID (for example,
The LDAP client application searches the directory for that identifier and returns the associated distinguished name (such as
The LDAP client application binds to the directory using the retrieved distinguished name and the password supplied by the user.
Simple password authentication offers an easy way to authenticate users, but it requires extra security to be used safely. Consider restricting its use to the organization's intranet. To use with connections between business partners over an extranet or for transmissions with customers on the Internet, it may be best to require a secure (encrypted) connection.
The drawback of simple password authentication is that the password is sent in plain text. If an unauthorized user is listening, this can compromise the security of the directory because that person can impersonate an authorized user.
nsslapd-require-secure-binds configuration attribute requires simple password authentication to occur over a secure connection, using TLS or Start TLS. This effectively encrypts the plaintext password so it cannot be sniffed by a hacker.
When a secure connection is established between Directory Server and a client application using TLS or the Start TLS operation, the client performs a simple bind with an extra level of protection by not transmitting the password in plaintext. The
nsslapd-require-secure-binds configuration attribute requires simple password authentication over a secure connection, meaning TLS or Start TLS. This setting allows alternative secure connections, like SASL authentication or certificate-based authentication, as well.
9.4.3. Certificate-Based Authentication
An alternative form of directory authentication involves using digital certificates to bind to the directory. The directory prompts users for a password when they first access it. However, rather than matching a password stored in the directory, the password opens the user's certificate database.
If the user supplies the correct password, the directory client application obtains authentication information from the certificate database. The client application and the directory then use this information to identify the user by mapping the user's certificate to a directory DN. The directory allows or denies access based on the directory DN identified during this authentication process.
For more information about certificates and TLS, see the Administration Guide.
9.4.4. Proxy Authentication
Proxy authentication is a special form of authentication because the user requesting access to the directory does not bind with its own DN but with a proxy DN.
The proxy DN is an entity that has appropriate rights to perform the operation requested by the user. When proxy rights are granted to a person or an application, they are granted the right to specify any DN as a proxy DN, with the exception of the Directory Manager DN.
One of the main advantages of proxy right is that an LDAP application can be enabled to use a single thread with a single bind to service multiple users making requests against the Directory Server. Instead of having to bind and authenticate for each user, the client application binds to the Directory Server using a proxy DN.
The proxy DN is specified in the LDAP operation submitted by the client application. For example:
ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x
-Y "cn=joe,dc=example,dc=com" -f mods.ldif
ldapmodify command gives the manager entry (
cn=Directory Manager) the permissions of a user named Joe (
cn=joe) to apply the modifications in the
mods.ldif file. The manager does not need to provide Joe's password to make this change.
The proxy mechanism is very powerful and must be used sparingly. Proxy rights are granted within the scope of the ACL, and there is no way to restrict who can be impersonated by an entry that has the proxy right. That is, when a user is granted proxy rights, that user has the ability to proxy for any user under the target; there is no way to restrict the proxy rights to only certain users.
For example, if an entity has proxy rights to the
dc=example,dc=com tree, that entity can do anything. Therefore, ensure that the proxy ACI is set at the lowest possible level of the DIT.
For more information on this topic, check out the "Proxied Authorization ACI Example" section in the "Managing Access Control" chapter of the Administration Guide.
9.4.5. Pass-through Authentication
Pass-through authentication is when any authentication request is forwarded from one server to another service.
For example, whenever all of the configuration information for an instance is stored in another directory instance, the Directory Server uses pass-through authentication for the User Directory Server to connect to the Configuration Directory Server. Directory Server-to-Directory Server pass-through authentication is handled with the PTA Plug-in.
Figure 9.1. Simple Pass-through Authentication Process
Many systems already have authentication mechanisms in place for Unix and Linux users. One of the most common authentication frameworks is Pluggable Authentication Modules (PAM). Since many networks already have existing authentication services available, administrators may want to continue using those services. A PAM module can be configured to tell Directory Server to use an existing authentication store for LDAP clients.
PAM pass-through authentication in Red Hat Directory Server uses the PAM Pass-through Authentication Plug-in, which enables the Directory Server to talk to the PAM service to authenticate LDAP clients.
Figure 9.2. PAM Pass-through Authentication Process
With PAM pass-through authentication, when a user attempts to bind to the Directory Server, the credentials are forwarded to the PAM service. If the credentials match the information in the PAM service, then the user can successfully bind to the Directory Server, with all of the Directory Server access control restrictions and account settings in place.
The Directory Server can be configured to use PAM, but it cannot be used to set up
PAM to use the Directory Server for authentication. For PAM to use a Directory Server instance for authentication, the
module must be properly configured. For general configuration information about
, look at the manpage (such as http://linux.die.net/man/5/pam_ldap
The PAM service can be configured using system tools like the System Security Services Daemon (SSSD). SSSD can use a variety of different identity providers, including Active Directory, Red Hat Directory Server or other directories like OpenLDAP, or local system settings. To use SSSD, simply point the PAM Pass-through Authentication Plug-in to the PAM file used by SSSD,
/etc/pam.d/system-auth by default.
9.4.6. Password-less Authentication
An authentication attempt evaluates, first, whether the user account has the ability to authenticate. The account must be active, it must not be locked, and it must have a valid password according to any applicable password policy (meaning it cannot be expired or need to be reset).
There can be times when that evaluation of whether a user should be permitted to authenticate needs to be performed, but the user should not (or cannot) be bound to the Directory Server for real. For example, a system may be using PAM to manage system accounts, and PAM is configured to use the LDAP directory as its identity store. However, the system is using password-less credentials, such as SSH keys or RSA tokens, and those credentials cannot be passed to authenticate to the Directory Server.
Red Hat Directory Server supports the Account Usability Extension Control for
ldapsearches. This control returns information about the account status and any password policies in effect (like requiring a reset, a password expiration warning, or the number of grace logins left after password expiration) — all the information that would be returned in a bind attempt but without authenticating and binding to the Directory Server as that user. That allows the client to determine if the user should be allowed to authenticate based on the Directory Server settings and information, but the actual authentication process is performed outside of Directory Server.
This control can be used with system-level services like PAM to allow password-less logins which still use Directory Server to store identities and even control account status.
The Account Usability Extension Control can only be used by the Directory Manager, by default. To allow other users to use the control, set the appropriate ACI on the supported control entry,