S 4.310 Setting up LDAP access to directory services

Initiation responsibility: Head of IT, IT Security Officer

The Lightweight Directory Access Protocol (LDAP) is a protocol used to access the data of a directory service. LDAP was originally developed as an alternative to DAP (Directory Access Protocol), which was defined within the framework of the X.500 directory standard. The underlying data model and the operations possible using the protocol were taken from the X.500 standard for the most part. In the meantime, the current version of the protocol, LDAP version 3, has become the dominant standard for accessing directory services.

Almost all directory services provide an LDAP interface. Amongst others, this allows the following operational scenarios:

In both cases, the LDAP access must be configured according to the directory service security policy defined in advance (see S 2.405 Drawing up a security policy for the use of directory services).

In principle, directory services allow LDAP clients to log in anonymously. The default settings specify that the LDAP client has the access rights entered in the directory service for the object. This object is a virtual object that is only used to assign rights in the directory service. Every access to objects in the directory tree is automatically granted the rights assigned to this "public" object at a minimum.

If anonymous users should be granted more advanced access rights to individual sub-areas of the directory tree, a separate user account for anonymous LDAP access - a so-called proxy user - should be created for this purpose. Authentication is not required for anonymous access and it is therefore not necessary to assign a password to this account. It should be ensured that a user logged in to this anonymous user account cannot create a password for the account because otherwise anonymous access could be blocked by a client. In addition, the access rights for this proxy user should be assigned restrictively, or they should be completely removed if the account is not needed any more.

The search possibilities via LDAP accesses should be limited particularly in connection with anonymous access. For example, if the server delivers the corresponding e-mail address after entering a name, or the corresponding certificate for an e-mail address, then the use of search filters should be allowed only to a limited extent. Only the e-mail address (but not the corresponding distinguished name) should be provided to the requesting person after entering the complete name or a sufficient part of the name. A certificate should only be provided after entry of a complete e-mail address. Not enabling wild cards should be considered, so that such enquiries cannot be used to create a complete lists of all e-mail addresses of the organisation. Alternatively, the number of displayed results can be limited. A limit of 1 to 5 results is recommended. Otherwise, anonymous users will be able to read the whole directory service or at least large parts of it; this way they will receive valuable information that can be used as basis for spam or social engineering attacks (see T 3.89 Errors in the configuration of LDAP access to directory services).

When planning the use of a directory service, it is necessary to decide which data should be allowed to be accessed via anonymous login (see also S 2.405 Drawing up a security policy for the use of directory services).

Use of the directory service as an LDAP server in the Internet

If the directory service is used as an LDAP server in the Internet, then the corresponding servers should be protected by a security gateway. This gateway should be configured so that only the data packets needed for the operation of the LDAP server are forwarded to the LDAP servers. These data packets are usually TCP packets on ports 389 and 636, which are the default port numbers for LDAP and/or LDAP via SSL.

The respective LDAP client must be authenticated in order to access data not allowed to be accessed anonymously. The corresponding client authenticates itself as a user entered in the directory in this case.

To prevent passwords from being transmitted as plain text over the Internet, it is necessary to specify the corresponding settings. However, anonymous LDAP connections and user logins with LDAP via SSL are still possible even when the passwords are not transmitted as plain text.

It is generally recommended to use SSL for communication and transmission. The options for one-factor and two-factor authentication are supported in this case. Two-factor authentication means that the client also needs to possess a valid certificate and that a session key will be generated based on the corresponding private key. This is the most secure configuration. Alternatively, it is also possible to authenticate the client using a password. The use of an encrypted SSL connection to the server guarantees the confidentiality of the password during transmission. The user always needs to import the CA root certificate into their LDAP client, for example a browser, so that the trust relationships set up can also be set up locally (see S 5.66 Use of TLS/SSL).

If SSL is not used, then the user passwords are transmitted over the Internet to the directory service as plain text (see also S 5.147 Protection of communications with directory services). This should be avoided as a general rule, though.

A directory service offers capabilities for mapping the standardised object classes used internally in LDAP to other object classes used internally in the directory service. This capability becomes relevant if LDAP clients use standardised LDAP object classes in searches, but the corresponding data is stored in the attributes of directory service object classes with different names. For this reason, it is necessary to examine if the LDAP object classes are mapped logically to directory service object classes and if the LDAP applications used function properly with this mapping the first time the LDAP clients are used and after making changes to the directory service schema.

Review questions:

© Federal Office for Information Security. All rights reserved.