Centralized authentication using OpenLDAP
This guide introduces the basics of LDAP and shows you how to setup OpenLDAP for authentication purposes between a group of Gentoo boxes.
- 1 Getting Started with OpenLDAP
- 2 Configuring OpenLDAP
- 3 Replication
- 4 Client Configuration
- 5 LDAP Server Security Settings
- 6 Working with OpenLDAP
- 7 Acknowledgements
- 8 Acknowledgements
Getting Started with OpenLDAP
What is LDAP?
LDAP stands for Lightweight Directory Access Protocol . Based on X.500 it encompasses most of its primary functions, but lacks the more esoteric functions that X.500 has. Now what is this X.500 and why is there an LDAP?
X.500 is a model for Directory Services in the OSI concept. It contains namespace definitions and the protocols for querying and updating the directory. However, X.500 has been found to be overkill in many situations. Enter LDAP. Like X.500 it provides a data/namespace model for the directory and a protocol too. However, LDAP is designed to run directly over the TCP/IP stack. See LDAP as a slim-down version of X.500.
I don't get it. What is a directory?
A directory is a specialized database designed for frequent queries but infrequent updates. Unlike general databases they don't contain transaction support or roll-back functionality. Directories are easily replicated to increase availability and reliability. When directories are replicated, temporary inconsistencies are allowed as long as they get synchronised eventually.
How is information structured?
All information inside a directory is structured hierarchically. Even more, if you want to enter data inside a directory, the directory must know how to store this data inside a tree. Lets take a look at a fictional company and an Internet-like tree:
Since you don't feed data to the database in this ascii-art like manner, every node of such a tree must be defined. To name such nodes, LDAP uses a naming scheme. Most LDAP distributions (including OpenLDAP) already contain quite a number of predefined (and general approved) schemes, such as the inetorgperson, a frequently used scheme to define users.
Interested users are encouraged to read the OpenLDAP Admin Guide .
So... What's the Use?
LDAP can be used for various things. This document focuses on centralised user management, keeping all user accounts in a single LDAP location (which doesn't mean that it's housed on a single server, LDAP supports high availability and redundancy), yet other goals can be achieved using LDAP as well.
- Public Key Infrastructure
- Shared Calendar
- Shared Addressbook
- Storage for DHCP, DNS, ...
- System Class Configuration Directives (keeping track of several server configurations)
Let's first emerge OpenLDAP:
Now generate an encrypted password we'll use later on:
Now edit the LDAP Server config at /etc/openldap/slapd.conf . Below we'll give a sample configuration file to get things started. For a more detailed analysis of the configuration file, we suggest that you work through the OpenLDAP Administrator's Guide.
Next we edit the LDAP Client configuration file:
Now edit /etc/conf.d/slapd and set the following OPTS line:
Finally, create the /var/lib/openldap-ldbm structure:
You can test with the following command:
If you receive an error, try adding
-d 255 to increase the verbosity and solve the issue you have.
If you need high availability
If your environment requires high availability, then you need to setup replication of changes across multiple LDAP systems. Replication within OpenLDAP is, in this guide, set up using a specific replication account (
ldapreader ) which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secundary.
This setup is then mirrored, allowing the secundary LDAP server to act as a primary. Thanks to OpenLDAP's internal structure, changes are not re-applied if they are already in the LDAP structure.
Setting Up Replication
To setup replication, first setup a second OpenLDAP server, similarly as above. However take care that, in the configuration file,
- the sync replication provider is pointing to the other system
- the serverID of each OpenLDAP system is different
Next, create the synchronisation account. We will create an LDIF file (the format used as data input for LDAP servers) and add it to each LDAP server:
Migrate existing data to ldap
Configuring OpenLDAP for centralized administration and management of common Linux/Unix items isn't easy, but thanks to some tools and scripts available on the Internet, migrating a system from a single-system administrative point-of-view towards an OpenLDAP-based, centralized managed system isn't hard either.
Go to http://www.padl.com/OSS/MigrationTools.html and fetch the scripts there. You'll need the migration tools and the
Next, extract the tools and copy the
make_master.sh script inside the extracted location:
The next step now is to migrate the information of your system to OpenLDAP. The
make_master.sh script will do this for you, after you have provided it with the information regarding your LDAP structure and environment.
At the time of writing, the tools require the following input:
|LDAP BaseDN||The base location (root) of your tree||dc=genfic,dc=com|
|Mail domain||Domain used in e-mail addresses||genfic.com|
|Mail host||FQDN of your mail server infrastructure||smtp.genfic.com|
|LDAP Root DN||Administrative account information for your LDAP structure||cn=Manager,dc=genfic,dc=com|
|LDAP Root Password|| Password for the administrative account, cfr earlier
The tool will also ask you which accounts and settings you want to migrate.
First, we will configure PAM to allow LDAP authorization. Install
sys-auth/pam_ldap so that PAM supports LDAP authorization, and
sys-auth/nss_ldap so that your system can cope with LDAP servers for additional information (used by nsswitch.conf ).
Now add the following lines in the right places to /etc/pam.d/system-auth :
Now change /etc/ldap.conf to read:
Next, copy over the (OpenLDAP) ldap.conf file from the server to the client so the clients are aware of the LDAP environment:
Finally, configure your clients so that they check the LDAP for system accounts:
If you noticed one of the lines you pasted into your /etc/ldap.conf was commented out (the
rootbinddn line): you don't need it unless you want to change a user's password as superuser. In this case you need to echo the root password to /etc/ldap.secret in plaintext. This isDANGEROUSand should be chmoded to 600. What you might want to do is keep that file blank and when you need to change someones password thats both in the ldap and /etc/passwd , put the pass in there for 10 seconds while changing the users password and remove it when done.
LDAP Server Security Settings
If we take a look at /etc/openldap/slapd.conf you'll see that you can specify the ACLs (permissions if you like) of what data users can read and/or write:
This gives you access to everything a user should be able to change. If it's your information, then you got write access to it; if it's another user their information then you can read it; anonymous people can send a login/pass to get logged in. There are four levels, ranking them from lowest to greatest:
auth search read write .
The next ACL is a bit more secure as it blocks normal users to read other people their shadowed password:
This example gives root and John access to read/write/search for everything in the the tree below dc=genfic,dc=com . This also lets users change their own
userPassword's. As for the ending statement everyone else just has a search ability meaning they can fill in a search filter, but can't read the search results. Now you can have multiple acls but the rule of the thumb is it processes from bottom up, so your toplevel should be the most restrictive ones.
Working with OpenLDAP
Maintaining the directory
You can start using the directory to authenticate users in apache/proftpd/qmail/samba. You can manage it with phpldapadmin, diradm, jxplorer, or lat, which provide easy management interfaces.
We would like to thank Matt Heler for lending us his box for the purpose of this guide. Thanks also go to the cool guys in #ldap @ irc.freenode.net
We would like to thank the following authors and editors for their contributions to this guide:
- Benjamin Coles
- Brandon Hale
- Benny Chuang