NotesOnOpenLDAP

From Sfvlug

Current revision as of 03:23, 6 September 2009

Basic LDAP Queries

First of all, there are two files named ldap.conf. The first, which I'll cover in a moment, is /etc/ldap.conf, and it is used by pam_ldap and nss_ldap. It is described by the pam_ldap(5) and nss_ldap(5) man pages. In order to use the OpenLDAP command line utilities, you need to configure /etc/openldap/ldap.conf, which is described in the ldap.conf(5) man page.

There are only a few lines needed in /etc/openldap/ldap.conf. Here is a working example:

URI ldap://auth/
BASE dc=example,dc=com
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

Without this file, you would have to specify all these parameters on the command line when using ldapsearch and other tools. You can override the contents of /etc/openldap/ldap.conf in your $HOME/.ldaprc file. You can also specify alternative configuration files with the environment variables LDAPCONF and LDAPRC.

Adding Users With Migration Scripts

The migragion scripts are included in the openldap-servers package. They are initially located in /usr/share/openldap/migration/. I never edit anything installed via a package that resides in /usr, so I copied these scripts to /root/migration/. Then the path in the scripts needs to be edited to point to the new location, and organization specific information added to migrate_common.ph.

As root, do:

mkdir ~/migration
cd ~/migration
for FILE in /usr/share/openldap/migration/* ; do
    sed 's=/usr/share/openldap=/root=' $FILE > `basename $FILE`
done

cat <<EOF | ed migrate_common.ph
/DEFAULT_MAIL_DOMAIN/s/padl.com/example.com/
/DEFAULT_BASE/s/dc=padl,dc=com/dc=example,dc=com/
/EXTENDED_SCHEMA/s/0/1/
w
EOF

Now that you have this configured, you can begin adding users to LDAP.

Begin by adding a normal user with the regular shadow utilities. Note that if you do not include the GECOS information (with the -c flag) then a bunch of fields will not be filled in when we migrate to LDAP.

useradd -c 'Joe User' -s /sbin/nologin juser
passwd juser

Then use the migration tools to build an LDIF file of the user's data.

./migrate_passwd.pl <( grep juser /etc/passwd ) > juser.ldif
./migrate_group.pl <( grep juser /etc/group ) >> juser.ldif

Take a moment to look over the LDIF information you are about to import. If you are satisfied, go ahead and import it into LDAP. If the LDAP server is currently running, do the following:

ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f juser.ldif

Keep in mind, only migrate users corresponding to an actual employee (user ID should be 1000 or greater). Service accounts (like loguser) should exist only in the local passwd and group files.

Also, a note that the wheel group is granted elevated privilege via sudo. If a user needs to be able to gain root on one particular machine, just add that user to the wheel group on that particular box (use the vigr command to do this).

Authentication and Identification

Logins are handled by PAM (for Pluggable Authentication Modules), whereas user identification (and many other number-to-name resolutions) are handled by NSS (for Name Services Switching). PAM is configured via /etc/pam.conf and NSS is configured by /etc/nsswitch.conf. The LDAP settings for both these services are configured via /etc/ldap.conf.

On a typical RedHat system, /etc/pam.conf is not used, instead individual services are configured by files in /etc/pam.d. Within that directory, most services include the file system-auth to consolidate PAM configuration into a single point of modification. Curious individuals are directed to the pam(8) man page for further information.

If you look at /etc/nsswitch.conf, you will see the name of a lookup type service, followed by a list of sources from which translations can be made. We need passwd, shadow, and group to be looked up via files, followed by ldap. None of the other services need ldap.

To quickly configure a server to authenticate and identify with LDAP, use the following command:

authconfig --enableldap{,auth} --ldapserver=ldap://auth/ --ldapbasedn=dc=example,dc=com \\
           --enableldaptls --ldaploadcacert=file://`pwd`/cacert.pem --update

However, this will configure protocols, services, netgroup, and automount in /etc/nsswitch.conf to also use ldap for lookups. This may generate more network traffic than desired if you are not using LDAP for these services. Use the following to strip those entries:

sed -ri '/^(passwd|shadow|group):/s/(files) (ldap)/\\1 [UNAVAIL=return] \\2/;
         /^(protocols|services|netgroup|automount):/s/ ldap//' /etc/nsswitch.conf

Also, the default behavior is for the NSS libraries to continue trying to bind to the server indefinitely if it is unavailable. This means it can take up to half an hour before giving up. Add the following to make sure the libraries give up when the server is unavailable:

echo 'bind_policy soft' >> /etc/ldap.conf

And finally, to perform operations which require root access, such as getent shadow or passwd, the libraries can not bind anonymously. Include the manager password in /etc/ldap.secret (mode 0400), and use the following to bind as the administrator:

echo 'rootbinddn cn=Manager,dc=example,dc=com' >> /etc/ldap.conf

LDAP Replication

Configure another host as an LDAP server, but don't include any replication directives yet. Basically, you must at least specify the database location.

Before we begin replication, the slave server must contain a full replica of the current master server's data tree. You can do this with the master still running.

slapcat > /tmp/dump.ldif

Now copy this dump file over to the slave server and import it.

slapadd < /tmp/dump.ldif
chown -R ldap. ~ldap/

Now start the slapd daemon and it should start without error. You should be able to perform normal queries against it.

Return to the master server. Add the following information to slapd.conf.

replogfile      /var/lib/ldap/SUBDIRECTORY/replog
replica         host=SLAVEHOSTNAME
                suffix="dc=example,dc=com"
                binddn="cn=Replica,dc=example,dc=com"
                credentials=PASSWORDINPLAINTEXT
                bindmethod=simple
                tls=no

As you see, the replica user's password is included in plain text in this file, so it is critical that the slapd.conf file should only be readable by the ldap user. Restart the LDAP server. This time slurpd will also start.

Once again, return to the slave server. You must create the replica user. First generate the password.

openssl passwd -1

Then create the following ldif file.

dn: cn=Replica,dc=example,dc=com
objectClass: top
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: Replica
userPassword: {CRYPT}GENERATE_THIS_WITH_OPENSSL

And add it to the database on the slave.

ldapadd -x -W -D 'cn=Manager,dc=example,dc=com' -f replica.ldif

Finally, add the following to the slave server's slapd.conf.

updatedn                                cn=Replica,dc=example,dc=com
updateref                               ldap://MASTER_LDAP_SERVER

Restart the ldap service and now any changes made on the master server will be automatically pushed to the slave server. If someone attempts to write a change to a slave server, they will get redirected to the master. What If It Breaks?

Sometimes the network link between the master and slave goes down and it just so happens that an update was made when the link was broken. Well, it happens. Your slave is now out of sync with your master. Unfortunately, slurpd is not robust enough to catch the slave back up on its own. Well, you could go back to the beginning and rebuild the slave from the current master view. This works, except re-adding the replica user is difficult with that updateref directive in slapd.conf. So edit the file twice? Not necessary.

If you have a look at /var/lib/ldap on the master, you will see there is now a replica subdirectory. Inside it is a set of rej and rej.lock files for each of the slaves for any bit that the slave didn't successfully replicate. All you have to do is play back the rej file and the slave will catch up. You can't run two copies of slurpd so stop the ldap service and run slurpd in one-shot mode.

slurpd -o -r /var/lib/ldap/replica/SLAVE:389.rej

When it exits, restart the ldap service.

GUI Tools

libuser Tools

Jeff