S 4.158 Setting of the LDAP access to Novell eDirectory
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
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.
eDirectory has an LDAP interface. This makes the following operational scenarios possible, for example:
- eDirectory is placed on the internet, e.g. as a so-called eBusiness platform or simply as certificate database. The users access it using the internet with the help of suitable LDAP-enabled software clients.
- eDirectory is used in the intranet of an organisation for administrating user accounts or resources in the network. In this case, network applications may also access the directory service in addition to the direct user access via LDAP clients. In addition to the Novell protocols, these accesses may also be performed using the LDAP interface.
In both cases, the LDAP access must be configured according to the previously defined security policy (see S 2.238 Specification of security guidelines for Novell eDirectory).
Anonymous LDAP access
In principle, eDirectory allows LDAP clients to log in anonymously. The default settings specify that the LDAP client has the access rights entered in the eDirectory for the [public] object. The [public] object is a virtual object that is only used to assign rights in the eDirectory. Every access to objects in the directory tree is automatically granted the rights assigned to this object at a minimum.
In the default configuration, [public] has the browse privilege for the entire tree.
If anonymous users are to be granted more advanced access rights to individual sub-areas of the directory tree, a separate user account should be created for this purpose. This user account must then be entered as a so-called proxy user for anonymous LDAP access. This account must not require any password in order to allow for anonymous access. It must furthermore be ensured that this user account cannot create a password either, since anonymous access could be blocked by a single client otherwise.
When planning the use of a directory service, it is already necessary to decide which data should be allowed to be accessed via anonymous login (see also S 2.238 Specification of security guidelines for Novell eDirectory). The access rights for the proxy user to this data in the eDirectory must be configured corresponding to this decision.
Figure: Access rights for proxy users
Use of Novell eDirectory as LDAP server in the internet
If eDirectory is used as an LDAP server in the internet, the corresponding server should be protected by a firewall. This should be configured in such a way 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 if it wants to access data not allowed to be accessed anonymously. The result of successful authentication is an NDS user bind of the LDAP client to the eDirectory. Therefore, the respective client authenticates itself as a user entered in the eDirectory directory.
In order to prevent passwords from being transmitted in plain text via the internet, the allowing cleartext passwords option should be enabled for the corresponding LDAP group (see also S 5.97 Protection of communications with Novell eDirectory). This also corresponds to the default configuration of eDirectory. Anonymous LDAP connections and user logins with LDAP via SSL are still possible with this setting.
It is generally recommended to use SSL for communication and transmission. The options for one- 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 users always need 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.
If SSL is not used, the user passwords can be transmitted in plain text to the eDirectory using the internet (see also S 5.97 Protection of communications with Novell eDirectory). This should be avoided, though. In order to prevent it expressly, the allowing cleartext passwords option must be set to disabled.
Configuration of LDAP access after changing the scheme
eDirectory offers capability for mapping the standardised object classes used internally in LDAP to other object classes used internally in the eDirectory. This capability becomes relevant if LDAP clients use standardised LDAP object classes in searches, but the corresponding data is stored in the attributes of eDirectory object classes with different names. For this reason, it is necessary to examine whether the LDAP object classes are mapped logically to eDirectory object classes and whether the LDAP applications used work properly with this mapping the first time the LDAP clients are used or after having made changes to the eDirectory scheme.
Figure: Features of the LDAP group
Review questions:
- Has the "allowing cleartext passwords" option been disabled for the LDAP group so that passwords are not transmitted in plain text?
- Are all eDirectory servers that can be accessed using the internet with the help of LDAP protected by a firewall?
- Has it been ensured that proxy users (account for anonymous LDAP access) are not able to configure a password using their user accounts?