S 4.388 Secure authentication to OpenLDAP

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

To use OpenLDAP, it is generally necessary that the directory service can assign the identity of a user to a session. Only then it is ensured that the directory service can be used reasonably, for example to manage operating system resources, and only then it is ensured that the defined access rights are effective (see S 4.387 Secure assignment of access rights to OpenLDAP). Within the framework of the "bind" on the slapd server, the user's identity information is thus provided. If this is not the case, this type of access is referred to as anonymous access (anonymus). If the identity information is provided within the framework of the "bind", then the user should prove that he actually has the identity he claims to have. If such a proof is not required, each user can log in using any identity; this is considered to be an unauthenticated use.

Anonymous users

If it was not decided during the planning phase of OpenLDAP (see S 2.484 Planning OpenLDAP) that the directory service can be used anonymously, anonymous usage must be disabled using the "disallow bind_anon" configuration directive.

If the directory service is to distinguish between different users, authentication is also required. Logging in without proof of identity should not be allowed outside test runs. Authentication must be forced using the "require authc" configuration directive.

Authentication using a password

The general method provided by OpenLDAP for the authentication of a user is the combination of a user ID and a password, which is referred to as "simple bind". This authentication method is considered to be secure when the password used is only known by the respective user.

Communicating the password

According to the specifications of the LDAPv3 standard, the password is communicated to the server for authentication as plain text. Therefore, the communication connection between client and server must be encrypted (see S 5.170 Secure communication connections when using OpenLDAP) to ensure that the password cannot be tapped by an attacker.

It is urgently recommended not only to offer the possible encryption of the communication connection by the slapd server, but to force it as a prerequisite for a "bind" operation. Otherwise, the security of a connection depends on the user's decision and technical knowledge as well as on the capabilities of the client software. Using the "security" directive, global or database-specific requirements for the existing connection security can be defined via the encryption level for different operations, for example using "security simple_bind=XYZ". The placeholder XYZ must be replaced by a security strength factor (SSF). The SSF is a figure representing the encryption procedure and used key length which are used to encrypt the actual messages with a symmetric cipher, for example 56 for DES, 112 for Triple DES and 128, 192 or 256 for AES. This cipher should be set to at least 112. If necessary, current results of research and the recommendations of the BSI must be taken into account. Operations listed in the directive are denied in the event of a lower connection security level.

Storing the password

If it is ensured that the password is communicated only in a secure manner, the password may still be at risk on the server side. If a server is compromised or if, for example, a data backup of the directory service objects is successfully accessed, an attacker could obtain knowledge of the users' passwords. Thus, only the checksums (hash values) of passwords must be stored. However, the LDAP standard does not support hashed passwords. OpenLDAP stores the hashed passwords on the server side and supports a number of different hashing algorithms. An algorithm from the secure hash algorithm (SHA) group in the version SSHA, i.e. "salted", should be used. "Salted" means that the password is supplemented by another value before creating the hash value to make dictionary attacks on the password more difficult. Under no circumstances should CRYPT be selected as hashing algorithm. CRYPT is implemented specifically to the operating system, which is why authentication to OpenLDAP might no longer work properly following a migration to another operating system.

Using the "password-hash {algorithm}" directive, the slapd server is instructed to only store the hash value of a password generated with the provided algorithm in the directory. Here, the curly brackets are part of the syntax; thus, SSHA is defined using "password-hash {SSHA}". The directive applies whenever passwords are set up or changed using the slapd server, i.e. using the "ldappasswd" application or another client application.

If LDIF files are created and imported, then the contents of the "userPassword" field stated in the file must already be available as hash values provided that a hash value is to be used. The same applies to the rootDN password data in the configuration (see S 4.384 Secure configuration of OpenLDAP). For the generation of hash values of passwords, the slap* tool "slappasswd" must be used. Using the "-h" parameter, the hashing algorithm to be used is specified; the recommended value SSHA corresponds to the default setting. After the "-s" parameter, the password is stated as plain text. The version of the tool must then be integrated into the LDIF or configuration file using a prefixed {SSHA}. If the tool is used in the command line, the entry history which is set up in general, must be turned off beforehand, since otherwise the password is stored as plain text.

Quality of the password

Even if passwords are communicated in encrypted form and stored as hash values, there is still a risk that users use passwords that are too weak. They can be determined easily, for example, by means of dictionary attacks. There should be organisational specifications to ensure that users do not select passwords which are too weak (see S 2.11 Provisions governing the use of passwords). OpenLDAP supports such specifications technically using the "ppolicy" (password policy) overlay. The overlay implements provisions such as the minimum length of a password or a minimum and maximum age to the possible or necessary change to the password. In addition, it can perform various quality tests of passwords and maintains for each user a list of previous passwords to avoid using them again. Using password provisions, the "ppolicy" overlay blocks the password attribute after several failed authentication attempts for a specified period of time for any access, in order to protect the password against brute force attacks. The respective specifications, for example how long a password has to be or after how many attempts entering incorrect passwords the password is blocked can be defined in detail in policies. Policies can be assigned specifically to the users or for the entire directory as well as for subtrees. The rootDN is not restricted by the "ppolicy" overlay.

Other authentication mechanisms

OpenLDAP is able to use functions of other applications for user authentication. For example, authentication mechanisms whose security exceeds the security of user ID and password (strong bind) can also be used. For this purpose, the layer of abstraction, simple authentication and security layer (SASL), is required. Using mechs, SASL supports a number of different authentication and encryption mechanisms and can, in turn, use external procedures itself. Among other things, users can be authenticated, for example, using SSL/TLS certificates (see S 5.66 Use of TLS/SSL) or the Kerberos procedure. OpenLDAP delegates the authentication to SASL. If the information system has high or very high protection requirements or if an authentication infrastructure already exists outside OpenLDAP, the connection should be established via SASL.

Review questions:

© Federal Office for Information Security. All rights reserved.