NotesOnOpenLDAP
From Sfvlug
Contents |
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.
