Lightweight Directory Access Protocol

 LDAP has been positioned as an open standard for Directory Services. It is a standard way for client applications and Internet Web servers to access on-line directory services over the TCP/IP network. The main purpose is to allow users to have a quick and easy access directory of people and information such as user names, e-mail addresses, and telephone numbers.

LDAP Security Feature

LDAP and especially OpenLDAP have a number of security features which might seem to be a little daunting.

Diagram below provides a perspective of the problem before going into detail. It shows the different kinds of access interfaces and methods to an LDAP system and also, it describes some security issues and the availability of method to manage the risks involved. The reason of this exercise is to determine either a set of security policies or implementation priorities.

All numbers in the descriptions below refer to the Figure above:

1. Remote Communications (1): 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 undecided. 

If all LDAP communications can be guaranteed to happen within a trusted network then people may prefer to administer using a simple clear text password with no additional security.

The growing emphasis on run-time configuration (RTC) (a.k.a cn=config) and monitoring (cn=monitor) is increasingly becoming the norm that turning LDAP browsers into a remote consoles for administering LDAP servers due to their highly sensitivity of security.

2. Passwords (2):  When hashed passwords are sent in a snoop-able data stream they can become accessible to a dictionary attack where, the attacker has the hashed form and runs a list of passwords (a dictionary) through the hashing algorithm until it is found.

Using salt (one or more octets - depending on the utilization- are added to the password before hashing and hence, be removed before comparison) substantially increases the security of hashed passwords. ACLs should be used to restrict access to passwords other than accurately authorized users. An example, 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:

access to attrs=userpassword

 by self       write

 by anonymous  auth

 by group.exact="cn=admin,ou=groups,dc=example,dc=com" write

 by *          none

3. Data (3): The only way in keeping the data snoop-proof which comes from an LDAP server is by encrypting the whole data stream using SSL/TLS (with SASL or without SASL) or Kerberos (SASL). However, there is a disadvantage. Encryption, being a CPU’s comprehensive 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 vital (configure SSL/TLS and configure SSL/TLS via SASL).

OpenLDAP provides two capabilities to generate audit information; overlay auditlog (more info use 'man slapo-auditlog') and overlay access log, where both provide features to log changes to the underlying DIT. Access log even provides capabilities to record binds and read/search access as well as save earlier contents of entries and even attributes.

4. Local Access (4): Local access simply referring to any event that happened within the LDAP server or server cluster (or through secured remote access such as provided by the ssh) and including the config files(5) and locally issued commands (6).

References: http://www.tech-faq.com/ldap-security-issues.html