Chapter 7. Designing a secure directory

Protecting the directory from unauthorized access may seem straightforward, however implementing a secure solution may be more complex than it first appears. The directory information delivery path has a number of potential access points where an unauthorized client may gain access to data.

The following scenarios describe just a few examples of how an unauthorized client might access the directory data:

The authentication methods, password policies, and access control mechanisms provided by the Directory Server offer efficient ways of preventing unauthorized access.

If intruders gain access to the directory or intercept communications between Directory Server and a client application, they have the potential to modify or tamper with the directory data. The directory service is useless if clients do not trust the data or if the directory itself can not trust the modifications and queries it receives from clients.

For example, if the directory can not detect tampering, an attacker can change a client request to the server, or not forward it, and change the server response to the client. TLS and similar technologies can solve this problem by signing information at either end of the connection.

In a denial of service attack, the attacker goal is to prevent the directory from providing service to its clients. For example, an attacker might use all of the system resources, therefore preventing anyone else from using these resources. Directory Server can prevent denial of service attacks by setting limits on the resources allocated to a particular bind DN. For more information about setting resource limits based on the user bind DN, see the User management and authentication guide.

The data analysis identifies what information users, groups, partners, customers, and applications need to access the directory service. Access rights can be granted in one of two ways:

Regardless of the method used to determine access rights, create a simple table that lists the categories of users in the organization and the access rights granted to each. Consider creating a table that lists the sensitive data held in the directory and, for each piece of data, the steps taken to protect it.

When using the directory to support exchanges with business partners over an extranet or to support e-commerce applications with customers on the Internet, ensure the privacy and the integrity of the exchanged data.

Use the following ways to ensure data privacy and integrity:

As an extra security measure, conduct regular audits to verify the efficiency of the overall security policy by examining the log files and the information that SNMP agents record.

The examples show how the imaginary ISP company example.com analyzes its security needs. The example.com offers web hosting and Internet access. Part of example.com activity is to host the directories of client companies. It also provides Internet access to a number of individual subscribers. Therefore, example.com has three main categories of information in its directory:

The example.com needs the following access controls:

Anonymous access provides the easiest form of access to the directory. With anonymous access, anyone who connects to the directory can access the data.

When you configure anonymous access, you cannot track who performs what kinds of searches, only that someone performs searches. You 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.

You can limit anonymous access. Usually, directory administrators only allow anonymous access for read, search, and compare privileges, not for write, add, delete, or self-write privileges. Often, administrators limit access to a subset of attributes that contain general information, such as names, telephone numbers, and email addresses. You should never allow anonymous access to more sensitive data, such as government identification numbers, for example, Social Security Numbers in the US, home telephone numbers and addresses, and salary information.

You can disable anonymous access entirely if you need to tighten 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)"

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, you can disable unauthenticated binds to increase security by limiting access to the database. In addition, you can disable unauthenticated binds to prevent silent bind failures for clients. Some applications may believe that it authenticated successfully 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.

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, which 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 prefer to bind as an organizational entry rather than as a person. The directory requires the entry used to bind to have 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 the following bind algorithm:

Simple password authentication offers an easy way to authenticate users, however it requires extra security methods. Consider restricting its use to the organization 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.

Use the nsslapd-require-secure-binds configuration attribute to turn on a secure connection by using TLS or the Start TLS. The SASL authentication or certificate-based authentication are also possible. When Directory Server and a client application establish a secure connection with each other, the client performs a simple bind with an extra level of protection by not transmitting the password in plaintext.

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 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 certificate to a directory DN. The directory allows or denies access based on the directory DN identified during this authentication process.

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 permissions to perform the operation the user requests. When a person or an application receives proxy permissions, they can specify any DN as a proxy DN, with the exception of the Directory Manager DN.

One of the main advantages of proxy permissions is that an LDAP application can use a single thread with a single bind to service multiple users making requests against 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 the client application submits. For example:

ldapmodify -D "cn=Directory Manager" -W -H ldap://server.example.com -X "dn:cn=joe,dc=example,dc=com" -f mods.ldif

With this command, the manager entry cn=Directory Manager receives permissions of a user cn=joe to apply the modifications to the mods.ldif file. The manager does not need to provide the user password to make this change.

Pass-through authentication (PTA) is when Directory Server forwards any authentication request from one server to another server.

For example, when Directory Server stores all configuration information for an instance in another directory instance, Directory Server uses pass-through authentication for the User Directory Server to connect to the Configuration Directory Server. PTA plug-in handles Directory Server-to-Directory Server pass-through authentication.

Many systems already have authentication mechanisms for Unix and Linux users, such as Pluggable Authentication Modules (PAM). You can configure a PAM module to tell Directory Server to use an existing authentication store for LDAP clients. Directory Server interacts with the PAM service to authenticate LDAP clients by using PAM Pass-through Authentication plug-in.

With PAM pass-through authentication, when a user attempts to bind to Directory Server, Directory Server forwards the credentials 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.

You can configure the PAM service by using the System Security Services Daemon (SSSD). Simply point the PAM Pass-through Authentication plug-in to the PAM file that SSSD uses, such as /etc/pam.d/system-auth by default. 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.

An authentication attempt first evaluates if the user account can authenticate. The account must fall under the following criteria:

Sometimes a client application needs to perform the authentication of a user account when the user should not or cannot bind to Directory Server for real. For example, a system may be using PAM to manage system accounts, and you configured PAM to use the LDAP directory as its identity store. However, the system uses passwordless 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 extension for LDAP searches. This extension returns an extra line for each returned entry that gives the account status and some information about the password policy for that account. A client or application can then use that status to evaluate authentication attempts made outside Directory Server for that user account. Basically, this control signals whether a user should be allowed to authenticate without having to perform an authentication operation.

In addition, you can use this extension with system-level services like PAM to allow passwordless logins which still use Directory Server to store identities and even control account status.

Directory Server supports fine-grained password policies, which means Directory Server defines a password policy at any point in the directory tree. Directory Server defines password policies at the following levels:

By default, Directory Server includes entries and attributes that are relevant to the global password policy, meaning the same policy is applied to all users. To set up a password policy for a subtree or user, add additional entries at the subtree or user level and enable the nsslapd-pwpolicy-local attribute of the cn=config entry. This attribute acts as a switch turning fine-grained password policy on and off.

You can change password policies by using the command line or the web console. In the command line, the dsconf pwpolicy command changes global policies and the dsconf localpwp command changes local policies. You can find the procedures for setting password policies in the Configuring password policies section.

When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user entry. Directory Server checks policy settings in the following order:

In addition to bind requests, password policy checking also occurs during add and modify operations if the userPassword attribute is present in the request.

Modifying the value of userPassword checks two password policy settings:

Both adding and modifying the value of userPassword checks password policies set for the password syntax:

Learn about the attributes that you can use to create a password policy for the server. Directory Server stores password policy attributes in the cn=config entry, and you can change these settings by using dsconf utility.

Directory Server has two ways to count login attempts and lock an account when login attempts reach the limit:

For example, if the failure limit is three attempts, the account can be locked at the third failed attempt (n) or at the fourth failed attempt (n+1). The n+1 behavior is the historical behavior for LDAP servers, so it is considered as legacy behavior. Newer LDAP clients expect a stricter hard limit. By default, Directory Server uses the strict limit (n), but you can change the legacy behavior in the passwordLegacyPolicy configuration parameter.

If you configure this setting for the password policy, users are required to change their password even if user-defined passwords are disabled. If the password policy does not require or does not allow the password change by a user, administrator-assigned passwords should not follow any obvious convention and should be difficult to discover.

The default configuration does not require that users change their password after it has been reset.

Setting passwords by administrators for users has the following disadvantages:

By default, user-defined passwords are allowed.

By default, user passwords never expire.

Directory Server displays the warning when a user binds to the server. If password expiration is enabled, by default, Directory Server sends a warning to a user, by using an LDAP message, one day before the user password expires. The user client application should support this feature.

The valid range for a password expiration warning is from one to 24,855 days.

By default, Directory Server does not permit grace logins.

The default password syntax requires a minimum password length of eight characters and that no trivial words are used in the password. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mailattributes of the user entry.

Additionally, you can use other forms of password syntax enforcement, providing different optional categories for the password syntax:

The more categories of syntax required, the stronger the password.

By default, password syntax checking is disabled.

By default, the server does not have a minimum password length.

The valid range of values for the passwordMinAge attribute is from zero to 24 855 days. A value of zero (0) indicates that the user can change the password immediately.

The passwords remain in history even if the password history is off. If the password history is turned back on, users cannot reuse the passwords that were in the history before you disabled the password history.

The server does not maintain a password history by default.

By default, the server does not store the password last change time.

Directory Server enforces password and account lockout policies in a replicated environment as follows:

Directory Server replicates password policy information in the directory, such as password age, the account lockout counter, and the expiration warning counter. However, Directory Server does not replicate the configuration information, such as the password syntax and the history of password modifications. Directory Server stores this information locally.

When configuring a password policy in a replicated environment, consider the following points:

When designing the security policy, you need to understand how ACIs are represented in the directory, and what permissions you can set.

Directory ACIs use the following general form:

target permission bind_rule

The ACI variables have the following description:

Therefore, for the directory object target, ACIs allow or deny permission if a bind rule is true.

Permission and a bind rule are set as a pair, and every target can have multiple permission-bind rule pairs. You can set multiple access controls for any given target effectively. For example:

target (permission bind_rule)(permission bind_rule) ...

By default, Directory Server denies access of any kind to all users, with the exception of the Directory Manager. Consequently, you must set ACIs for users to be able to access the directory.

Get effective rights (GER) is an extended ldapsearch command which returns the access control permissions set on each attribute within an entry. With this search, an LDAP client can determine what operations the server access control configuration allows a user to perform.

The access control information is divided into two groups of access: entry rights and attribute rights. Entry rights are the rights, such as modify or delete, that are limited to that specific entry. Attribute rights are the access rights to every instance of that attribute throughout the directory.

Such a detailed access control may be necessary in the following situations:

The following tips can help to lower the administrative burden of managing the directory security model and improve the directory performance characteristics:

Normally, access control rules do not apply to the Directory Manager user. The Directory Manager is defined in the dse.ldif file, not in the regular user database, and ACI targets do not include that user.

The Directory Manager requires a high level of access in order to perform maintenance tasks and to respond to incidents. However, you can grant a certain level of access control to the Directory Manager to prevent unauthorized access or attacks from being performed as the root user.

Use the RootDN Access Control plug-in to sets certain access control rules specific to the Directory Manager user:

You can set only one access control rule for the Directory Manager. It is in the plug-in entry, and it applies to the entire directory.