Thanks to the authors of Fedora 7 Unleashed, and to Vincent Danan, who wrote an excellent LDAP Howto for Mandriva. Neither had every piece of information I needed, so this document was created. This document is intended to give you everything you need to convert your Centos 5.1 box to LDAP authentication.
First, we'll configure our LDAP server and start it. Then, we'll add data from our existing user and group database. Then, we'll alter our system so that login attempts will be authenticated against LDAP as well.
If you have not already done so, fire up a terminal, and install the following packages: openldap-servers, openldap-clients. You can do this using root account or using sudo, with the command
yum install openldap-servers openldap-clients.
Since LDAP uses dc (domain components) to define our organization, we'll need to make some minor changes to our /etc/openldap/slapd.conf file.In that file, look for the line that says suffix. By default, it probably says something like "dc=my-domain,dc=com". Since our organization isn't called my-domain.com, we'll want to alter that. For this tutorial, I changed it to be linuxclass.com. Using vi, the following string will do a file-wide search-and-replace, replacing every instance of my-domain with linuxclass:
[esc]:%s/my-domain/linuxclass/g
After verifying that the above trick worked, we'll want to alter the rootdn line. This line is used to define the administrator account for ldap. Since this is a unix box, let's stay with unix nomenclature and alter Manager to be root . After that, we'll want to set the rootpw (or root password). While we COULD put the password in plaintext in this file, it's generally considered bad form. The least we can do is encrypt our admin password, right? In another terminal, run the slappasswd command. It will ask you for a password, and after you enter it twice, it'll spit out a line like this:
{SSHA}HyMgSuXVuN6lrm+tncgAqhw0idejW/5t.
copy that text into your /etc/openldap/slapd.conf file, and prepend 'rootpw ' to it. That is, make sure there is a line in your file which looks like this:
rootpw {SSHA}nkQugpCsVCR6BL66RhnliAmUA039AmQr
So far, that's all we need to do for our server. Save and exit the file, then test your configuration by running the slaptest -u command. You can ignore any errors about 'No DB_Config file found...', as we'll fix those in a bit.
In review, we have so far installed our server and client software, altered the server to refer to our very own domain, and established the administrator password for the server
First, let's start the server:
/sbin/service ldap start
Once that's completed successfully, let's set it to run at boot with:
/sbin/chkconfig ldap on
I'd love to stop there, but if you do, you'll get a system which won't boot again! You see, in the default CentOS 5.1 configuration, the messagebus daemon is going to try to talk to the LDAP server, but will be started BEFORE the LDAP server. This means that system boot halts while the messagebus daemon waits for the LDAP server. Unfortunately, since boot has effectively halted, it'll wait until the end of time. To prevent this, we alter the activation order of services in our default runlevel. Since we want to make sure that we can start at runlevel 3 or 5 successfully, we'll run these command:
mv /etc/rc.d/rc3.d/S27ldap /etc/rc.d/rc3.d/S17ldap
mv /etc/rc.d/rc5.d/S27ldap /etc/rc.d/rc5.d/S17ldap
Now, the server will start at boot properly.
To actually enable LDAP auth, we can use a console tool called authconfig, a graphical tool called authconfig-gtk, or we can manually muck about with PAM files and /etc/nsswitch.conf. In this case, it's simplest to use the authconfig-gtk tool if we have a gui. Run the command
sudo /usr/sbin/authconfig-gtk
In the User Information tab, check the box for 'Enable LDAP Support', and click the 'Configure LDAP' button. For now, leave the 'Use TLS' button UNchecked. We'll worry about that after everything is working. We need to enter our LDAP Search Base DN, which should be dc=linuxclass,dc=com if you're keeping to my example. For LDAP server, we'll enter ldap://127.0.0.1, since we are our own LDAP machine. Click OK, and do the same thing for the Authentication tab. 
Now, lets setup our base, authentication and group files. That is, we'll establish our basic parameters for the LDAP server, then migrate over (most of) the user accounts, and (most of) the group accounts.
First, our base parameters. In the /usr/share/openldap/migration directory, there are some scripts which we can use to save ourselves a lot of typing. cd to that directory, and run
./migrate_base.pl > base.ldif
This will create the file base.ldif in the current directory. Now, we'll edit that file, to ensure that our LDAP server isn't filled with lots of extraneous information.
If you're using vi (which I am), it's easy to change all the occurences of padl to linuxclass:
[esc]:%s/padl/linuxclass/g
Now we can remove that which we do not need, such as the Hosts, Rpc, Services, netgroup.byuser, Mounts, Networks, Netgroup, Protocols, Aliases, and nisMapName definitions. We're left essentially with the basic, People and Group organizational unit definitions.
Now, we can import that information into our LDAP database using this command:
ldapadd -x -W -D "cn=root,dc=linuxclass,dc=com" -f ./base.ldif
This will set us up for the next two steps: importing the user and group databases.
We need to tell the script where to find password information. We do that by setting the shell variable ETC_SHADOW to be /etc/shadow. This command will do just that:
export ETC_SHADOW=/etc/shadow
. Then, we can run ./migrate_passwd.pl /etc/passwd people.ldif
.
We need to replace all instances of padl with linuxclass again. We also want to trim out system accounts like root, bin, daemon, since we'll likely have local copies of those accounts on each of the unix boxes, and there is no point in cluttering the LDAP database with unnecessary information (also, different distros may assume different UIDs for accounts such as daemon or mail, so keeping the UID for those accounts in LDAP could cause compatibility problems). Remove the unnecessary accounts from the people.ldif file. How should you do this? By editing the file with your favorite editor and deleting those unnecessary entries.
Using the ./migrate_group.pl /etc/group group.ldif command, we can set up our groups database. Again, replace instances of padl with linuxclass, and remove extraneous groups. After you've done that, it's time to import the two files to ldap:
ldapadd -x -W -D "cn=root,dc=linuxclass,dc=com" -f people.ldif
ldapadd -x -W -D "cn=root,dc=linuxclass,dc=com" -f group.ldif
Now, we have our database populated with info. It's time to test our work. First, you can use the ldapsearch command to look for your username:
ldapsearch -x 'cn=MYUSERNAME'
This should return a fair amount of information about you. If it doesn't return anything, go back and make sure the user account information includes your account!
You can also test logging the configuration by adding an account into LDAP which doesn't exist in the local databases. You cannot do this with useradd. Instead, you must use the ldapadd command
Here's a sample text file for adding a user:
dn: uid=mschwarz,ou=People,dc=linuxclass,dc=com
uid: mschwarz
cn: Mike Schwarz
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {SSHA}XHpKJYOSw4J4gUqJJzD5cCjwz2ShuZHv
shadowLastChange: 13832
loginShell: /bin/bash
uidNumber: 550
gidNumber: 550
homeDirectory: /home/mschwarz
the password was set using the slappasswd command, and I'll have to manually create and chown the user's home directory after adding them. Is this more work than using passwd and useradd? Yes. It does, however, mean that Mr. Schwarz now has a valid login account on every unix box which listens to this ldap server. To be honest, however, you can auto-create his home directory on login by adding the following login to /etc/pam.d/login:
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0077
So far, we're in good shape -- we can authenticate nicely. Unfortunately, we can't change our own passwords: we don't have permission. We need to fix that. Into a file named /etc/openldap/slapd.access.conf, put:
access to attrs=userPassword by dn="cn=root,dc=linuxclass,dc=com" write by self write by anonymous auth by * none access to dn.base="" by * read access to * by dn="cn=root,dc=linuxclass,dc=com" write by * read
Those tabs in the file above are actually important, too. If you don't have them in, slapd won't like your file, and won't start properly. Seriously.
Next, add the following line somewhere in your /etc/openldap/slapd.conf file:
include /etc/openldap/slapd.access.conf
Restart your server, and users can change their passwords.
Ideally, you want to customize your DB_CONFIG file, and put it in /var/lib/ldap. You can get a sample config file from /etc/openldap/DB_CONFIG.example . I just copied mine in with the command: cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/DB_CONFIG. Customize to your heart's content.
TODO
This document copyright 2007, Jeremy Anderson