Chapter 6. Authentication using LDAP
I want to centralize authentication on my network, I therefore install LDAP, and use this to authenticate users.
6.1. Installing LDAP
Add the following packages:
slapd ldap-utils |
That should make it almost ready to go...
6.2. Installing system packages for LDAP
Besides installing LDAP, we also need to install a few packages to make the system able to authenticate against LDAP, and to retrieve information from LDAP
As this is the local server, we don't use TLS for this, but if this was a client system on the network, we would want to enable TLS/SSL in the packages being installed here.
apt-get install libpam-ldap apt-get install libnss-ldap |
6.3. Configuring system to use LDAP
You will need to alter some files in order for the system to be able to look up entries in the LDAP database.
The file /etc/nsswitch.conf controls where we find system entities such as passwords and groups. It needs to be updated to take our new LDAP server into account.
Change the entries with "passwd", "group" and "shadow" to reflect that we want to make a LDAP lookup besides the normal "file" or "compat" lookup.
passwd: compat ldap group: compat ldap shadow: compat ldap |
 | It is possible to change the order of the lookups by putting "ldap" before "compat". This will however screw up Your shutdown, since LDAP is going to be used for almost any kind of lookup situation. If we have shut down the localhost interface (lo), these lookups will take forever. Immediately affected is the shutdown of "network". I recommend the "compat ldap" sequence to be preferred over the "ldap compat" sequence. |
That in itself is of course NOT enough. The services on a Unix system does not per default request information from a LDAP server. On most recent Unixes - Debian included - authentication is done by something called PAM (Pluggable Authentication Modules), which makes it easy for services to take advantage of new methods of doing authentication.
We will attempt to setup the login service to take advantage of LDAP.
The login service uses the configuration file /etc/pam.d/login to specify what is neede for a user to login.
| Never change an essential service file without making a backup, and ensuring Your access to the system. I recommend the following:
|
Now we change the file, so that the following are in the file:
auth sufficient pam_ldap.so auth required pam_unix.so nullok try_first_pass account sufficient pam_ldap.so session sufficient pam_ldap.so |
We have added the try_first_pass option on the line with pam_unix.so. This is done, so that we do not need to enter the password again if the LDAP authentication fails, which it will on users not in the LDAP database.
Save Your file, and check if You can still log in as root. If everything is in order, then we did not screw up to badly. :-)
The above excersize should be repeated for each and every service needing to authenticate against LDAP.
6.4. Configuring LDAP
I have had somewhat limited luck with the LDAP configuration files, and therefore prefer to configure some of the things directly in the /etc/init.d/slapd script.
What wants changing in this script is the fact that we don't want ldap to listen to all interfaces. This is done by changing the slapd init-script to reflect the following in the start section:
start-stop-daemon --start --quiet -pidfile "$pf" --exec /usr/sbin/slapd \ -- -h "ldap://localhost ldap://ldap.abode.dk" |
In the above, localhost can be exchanged for the localhost IP (127.0.0.1), and ember.abode.dk can be changed to the responding IP (192.168.228.14).
It is possible to enable more IP's, if it is needed. All that is needed is that You add the IP that should be be listened to, to the line.
And then we restart the LDAP service:
/etc/init.d/slapd restart |
6.5. Testing LDAP
It's almost enough to just install the things, configure them and seing that the things start without errors.
NOT!!!
When changing or installing something always test that the changes was successfull. There is way to much complexity that You will be able to do a full system test, but at least ensure that the things works as they are basically supposed to.
For us to fullfill that requirement, we need to test 2 things:
ldap://localhost responds to requests
ldap://ember.abode.dk responds to requests
This is tested by the following:
ldapsearch -x -b "dc=abode,dc=dk" -H ldap://localhost ldapsearch -x -b "dc=abode,dc=dk" -H ldap://ldap.abode.dk |
It is of course implicit in the above that the names can be resolved (translated to IP addresses).
You should get a sane response from the above commands, which shows that access to the LDAP database can be achieved.
6.6. Populating the LDAP database
6.6.1. Getting the LDAP database ready
As this LDAP database is used to authenticate users, we need to add users and groups to the database. Before that can happen, we need to add some records to the database.
To make it easier, I have done this by reading an ldif file into the database, that looks like the following:
------------< groupinit.ldif start >----------------- dn: ou=Group,dc=abode,dc=dk objectClass: organizationalUnit ou: Group ------------< groupinit.ldif end >------------------- |
This file can be added to the database by the following command:
ldapadd -x -W -D cn=admin,dc=abode,dc=dk -f groupinit.ldif |
And we should now be ready to add users and groups to the database.
6.6.2. Adding groups
A group can be added by reading a ldif file into the database. A typical ldif file for a group could look something like this:
------------< groupdef.ldif start >------------------
dn: cn=test,ou=Group,dc=abode,dc=dk
objectClass: posixGroup
objectClass: top
cn: test
userPassword: {MD5}x
gidNumber: 3000
memberUid: <user1>
memberUid: <user2>
------------< groupdef.ldif end >--------------------
|
If this is the default group for a user (e.g. the test user), this user does NOT have to be specified in the memberUid section of the group.
The group ldif file can be added to the database the same way as the groupinit.ldif file in the previous chapter:
ldapadd -x -W -D cn=admin,dc=abode,dc=dk -f groupdef.ldif |
6.6.3. Adding users
Adding users to the LDAP database is much the same as adding groups, and can be done the same way.
A normal user ldif file can look something like this:
------------< userdef.ldif start >-------------------
dn: uid=test,ou=People,dc=abode,dc=dk
uid: test
cn: LDAP test user
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {MD5}eq8MpLTjTf2zChVCZG+XuQ==
loginShell: /bin/bash
uidNumber: 3000
gidNumber: 3000
homeDirectory: /home/test
gecos: LDAP test user (jailed account)
------------< userdef.ldif end >---------------------
|
As with the group ldif file, the user ldif file can be added to the LDAP database with the following command:
ldapadd -x -W -D cn=admin,dc=abode,dc=dk -f userdef.ldif |
One little thing: The password...
In the above example, the password can be generated by issuing the following command:
slappasswd -h {MD5} -s test
|
The output from the slappasswd command can be redirected if this is what You want.
6.6.4. Adding users to groups
In the example, we created a user named test. The default group for the test user is the test group, as can be seen by the gidNumber.
Imagine we had added another group (test2), and wanted our user to be added to this group.
This can be done by modifying the LDAP database via a ldif file:
------------< ugadd.ldif start >--------------------- dn: cn=jailuser,ou=Group,dc=abode,dc=dk changeType: modify add: membuerUid memberUid: ltj ------------< ugadd.ldif end >----------------------- |
This ldif file can be read by the command:
ldapmodify -x -W -D cn=admin,dc=abode,dc=dk -f ugadd.ldif |
And the test user should now also be a member of the test2 group.
6.6.5. LDAP user/group manipulation tools
Doing user add/delete/change, can be a bit of an experience when all You have is ldif files. I therefore looked around for some tools to help me in my tasks of User manipulation.
The normal tools to add/change/delete users and groups does not really go well with LDAP. As I looked around, I did not find anything that made me totally happy, and I ended up creating some of them on my own.
To use the scripts some additional perl-modules are needed:
apt-get install libgetopt-mixed-perl apt-get install libnet-ldap-perl |
Which installs a perl-modules that read the command-line options, and a module that is used to interface with the LDAP database.
The collection of scripts is as follows:
As can be seen in the above list, I have yet to do the modify scripts that would make the collection complete.
The scripts can be downloaded from here.
It's up to You to experiment further with the scripts, maybe correct errors or make them work the way You want them to.