You have probably come across LDAP in one way or another. In fact, LDAP has become a de facto standard for managing user credentials in the open world of Linux and Unix systems, as well as for application servers and other platforms - much like Active Directory has in the Windows world.
In a series of blog posts, I will explain how to configure and maintain one particular LDAP server in detail - OpenLDAP. I'll cover topics like server configuration, overlay modules, replication and clustering, debug logs, access control, Berkeley DB4 management and performance tuning.
But this is only the first article, where I will focus on the background - the LDAP protocol - and the very basics of OpenLDAP. So, first and foremost:
Most often, LDAP is used for storing and publishing user account and group information, and it does this in a hierarchical tree. LDAP is in part a network protocol standard, specifying how a client should access the LDAP server to store, modify or search information. This means that any client is able to connect to any LDAP server, but there are some potential pitfalls here. The use of encryption (TLS) may or may not be supported in the client, and to ensure maximum compatibility with different types of clients you should stick to the "simple" authentication, i.e. user name/password .
LDAP is also a structure for organising information - but there are almost as many ideas of how this information should be stored, as there are LDAP implementations. Should a user be identified by the login account name or by the person's full real name? Should the identification key be stored as uid or cn? Will we store group members in a group object, or groups in a member object? These are all implementation-specific choices. Linux and Unix operating systems tend to have similar ideas on how users and groups should be mapped out, but Windows is quite different and if you use software like Oracle Weblogic you'll discover even more variants.
The OpenLDAP project develops both server and client tools, but in this series of blog posts I will focus on the server part. It is installed through the openldap-servers RPM on Red Hat / CentOS, or the slapd package on Debian / Ubuntu. In fact, in both cases the actual binary that contains the OpenLDAP server is called slapd. I am not sure exactly why this is so, but the name can be traced back to the first LDAP implementation from University of Michigan.
The client-side tools in OpenLDAP can be used to manage the data managed not just by slapd, but more or less any LDAP server implementation because of the standardised over-the-wire protocol. There are several other LDAP servers from vendors like Red Hat, Oracle and Microsoft (Active Directory!), but if you want to set up an LDAP service on a Linux server I strongly suggest to take a look at OpenLDAP in the first place. It has grown to be both performant, flexible and secure, it is included for free in most Linux distributions and it has a huge user base. In my next blog post I will discuss how to configure it!