LDAP Security Features

Remote Communications : Remote communication security may or may not be an issue. If you provide unlimited (anonymous) access to non-sensitive LDAP data then the security issue is moot. Caution: In these circumstances you potentially become vulnerable to DoS/DDoS attacks through malicious LDAP query loads - so even this apparently trivial environment may need careful consideration. If all LDAP communications can be guaranteed to occur within a trusted network then you may elect to operate with simple cleartext passwords without additional security. However even in these cases it may be a simple matter, depending on the trusted network topology, to sniff traffic and either inspect sensitive data or obtain passwords sent in the clear.
When communication occurs across an untrusted network then snooping, sniffing, man-in-the-middle and other possibilities provide endless hours of fun for wannabee attackers. Also bear in mind that the growing emphasis on run-time configuration (RTC) (a.k.a cn=config) and monitoring (cn=monitor) it may become increasingly the norm that LDAP browsers become the remote consoles for administering LDAP servers. This traffic is, by its very nature, highly sensitive.
Assuming that some level of security is required the first question to be addressed is - do I need to protect only passwords or do I need to protect data and passwords ? Depending on the answer to that question will determine the next step.

Passwords : Securing passwords during communications should not be confused with securing them within configuration files or DITs. Even if you have secured all passwords within the configuration file or the DIT using a hash-method, such as {SSHA}, when a password is sent from a client to the server it is sent in the clear, hashed at the server and compared with the stored contents. Without any further action it can therefore be snooped (or sniffed depending on your predilection for these terms). Note: When an entry containing, say, a userPassword attribute stored using, say, {CRYPT} is requested by a client it is not sent in cleartext but in its hashed (stored) form. However when access to that same entry is required the client sends the authenticating password in cleartext and clearly if the login is successful the snooper can reasonably assume the cleartext password was correct!
When hashed passwords are sent in a snoopable data stream they can become vulnerable to a dictionary attack - the attacker has the hashed form and runs a list of passwords (a dictionary) through the hashing algorithm until a match is found. Using salt (one or more octets - depending on the implementation - are added to the password before hashing and removed before comparison) significantly improves the security of hashed passwords and unless there are good reasons for not doing so the salted form of any hashing algorithm should always be used. ACLs should be used to limit access to passwords other than specifically authorized users. For example assuming a userPassword attribute the following ACL will only allow the attribute to be sent to the owner of the entry or a specific (admin) group of users. if only sswords require to be safeguarded then the solution is to use SASL with an ALGORITHM such as CRAM-MD5 which performs a secure handshake (using a shared secret) and during which dialog the password never appears in cleartext ( SASL configuration examples). The alternative is to use SSL/TLS (with or without SASL) or Kerberos 5/4. In this case simple password mechanisms can be used since the whole communication stream is encrypted and therefore snoop-proof.
Finally overlay policy provides features to control aging, complexity and mandatory resets as well as other characteristics of the passwords being used.

Data : If the data originating from an LDAP server needs to kept snoop-proof then the only solution is to encrypt the entire data stream using SSL/TLS (with SASL or without SASL) or Kerberos (SASL). The down-side to this approach is that encryption is a CPU intensive process and if resource usage or performance is a major consideration then the choice of bulk encryption methods available within the SSL/TLS suite becomes very important (configure SSL/TLS and configure SSL/TLS via SASL). It is possible to mix and match communication. If, for example, it is deemed adequate to use simple cleartext passwords (or even run anonymously) for normal remote LDAP access but additional protection is required when running certain classes of users (configuration samples for mixed SSL/TLS/ and SASL access).

While the discussion so far has concentrated on merely gaining access to data - what about changes and modifications to that data? OpenLDAP provides two capabilities to generate audit information. The overlay auditlog (more info use 'man slapo-auditlog') and overlay accesslog both provide features to log changes to the underlying DIT and accesslog even provides capabilities to record binds and read/search access as well as save previous contents of entries or attributes.

Local Access : Local access is defined to be any event that occurs within the LDAP server or server cluster (or through secured remote access such as provided by ssh) and includes most obviously config files and locally issued commands .

Config Files : There are two components to be considered here:
Ownership and permissions: By default modern LDAP systems run with low privilege user/group accounts (normally ldap:ldap). OpenLDAP does an excellent job with its config file, slapd.conf which can contain some highly sensitive data. OpenLDAP loads with root permissions (to allocate privileged ports) before dropping down quickly to its normal (low) operational privileges: before doing so it ensures (changing if necessary) that slapd.conf is owned by ldap:ldap (or the user:group it is running under) and has permissions of 0600. This prevents the worst excesses of accidental disclosure.

Passwords: Passwords that appear in the config files and slapd.d directories (for cn=config use) tend to be especially sensitive such as rootpw. Consideration can be given to removing them completely once a DIT has been established or at the very least storing them as hashed values to prevent trivial disclosure. Unfortunately using an include file to store the most sensitive data with very tight permissions (such as root read-only) and which can be used with a number of other systems offers no benefits since OpenLDAP has already dropped to its low operational privilege before assembling slapd.conf. However as described above OpenLDAP already has an excellent file permission modification mechanism so this wheeze is superfluous.

Commands (: Historically LDAP was administered using a local, mostly command line, interface. It was also reasonable to assume that local (in-server) traffic was not snooped making simple (cleartext) password protection to most administrative services an adequate security measure. However, as noted above, the increasing emphasis on run-time configuration (RTC) (a.k.a cn=config) and monitoring (cn=monitor) may mean that remote LDAP Browsers become the norm for LDAP system administration. In this case access to these services will transmit highly sensitive data which should be protected using data security techniques such as SSL/TLS.

Finally, since the RTC stores everything in a DIT (cn=config) it may be worth considering the use of the powerful features of overlay accesslog as tool to generate audit logging of changes to this DIT.

DIT : DIT security is defined with the LDAP Security model and is implemented exclusively through the use of the access to directive of slapd.conf or the olcAccess attribute when using run-time configuration (RTC) (a.k.a cn=config).

Replication : Even if normal client access to an LDAP system has a low security requirement the same may not be true for replication of that same DIT. During a replication cycle at some point or another all the data in a DIT (user and operational attributes) will be exposed on the communication network. Of necessity some of this information is very sensitive. Replication communications connections merit separate consideration. You can provide mixed SSL/TLS and other secure (or even insecure) connections in a single server (configuration samples for mixed SSL/TLS and SASL access).