LDAP All

From Debian Clusters
Jump to: navigation, search

User Authentication: LDAP

About LDAP

Lightweight Directory Access Protocol (LDAP) is a network-based authentication system, similar to Active Directory or Kerberos. It is used in order to manage users in one centralized place rather than having to create a user account for each person on every single computer in a network or cluster. When installing and configuring LDAP, at least one computer is set up as the LDAP server. This is the computer that controls the configuration of LDAP for all the LDAP clients. (It is possible to have multiple LDAP servers assisting with the load, in which case one server acts as the master and the other as secondaries using slurpd. However, that is beyond the scope of this tutorial.) Clients are computers that use the authentication provided by LDAP. The server itself can also be a client, though it does not need to be. (In cases where LDAP users should not be logging into the LDAP server, the server should not be set up to authenticate using LDAP. This is generally the case.)

There are three values that need to be decided ahead of setting up LDAP. These are the Uniform Resource Identifier (URI) for the network, the administrative account, and the administrative password.

The base URI will be used in several prompts, including asking for the DNS domain name. If you have a domain name, that can be used. Otherwise, something .loc or .local may be preferred. In the examples given, raptor.loc will be used. In accordance with the X509 specification format, this will be specified with dc's (domain components). Raptor.loc would be given as dc=raptor,dc=loc. When specifying a user, cn (for common name) is appended to the front. kwanous@raptor.loc would be cn=kwanous,dc=raptor,dc=loc. kristina.wanous@raptor.loc would be cn=kristina,cn=wanous,dc=raptor,dc=loc.)

The administrative (or LDAP root) account needs to be decided on ahead of time because different defaults will be used in different packages. When installing the LDAP configuration package, migrationtools, the default for the account will be admin, but other packages will use manager as the default. Pay careful attention to this! Not matching the accounts will result in odd, non-functioning behavior. The adminstrative password is the password to this account. This also needs to match, of course.

As a side note, one alternative to LDAP is NIS (Network Information Service). However, unlike LDAP, NIS passes passwords as clear text over the network. This is far less secure than LDAP.

Setting up LDAP

The LDAP tutorial is broken into multiple parts. First, an LDAP server must be installed and populated with data. Then clients need to be configured to communicate with the LDAP server.

References

LDAP Server

This is the second page of a five-part tutorial on LDAP. The full tutorial includes

LDAP Server Overview

The steps involved in setting up an LDAP server consist of

  • installing slapd
  • installing migrationtools, configuring the migrationtools script, and running the script

slapd

Slapd is the LDAP server daemon - it's what runs in the background and answers when other computers ask for LDAP authentication. Install slapd with apt-get. The command should just be apt-get install slapd. The only prompt for this package will be to enter the adminstrative password.

Once it's installed, verify that slapd is running with the command ps aux | grep slapd. You should see something like this: 

openldap  9741  0.0  1.0  14456  2720 ?        Ssl  08:21   0:00 /usr/sbin/slapd -g openldap -u openldap

However, the initial configuration does not set up everything necessarily, and it will need to be reconfigured. Use dpkg-reconfigure slapd.

Omit OpenLDAP server configuration?

  • Choose no.

DNS domain name:

  • You'll use this value again later on. I entered raptor.loc for dc=raptor,dc=loc.

Name of your organization:

  • Mine is the University of Northern Iowa.

Admin password:

  • This is resetting the password you entered earlier. If you changed your mind about it, now's a good time to switch passwords.

Database backend to use:

  • Choose BDB, for Berkley Database. This is the preferred method.

Do you want your database to be removed when slapd is purged?

  • Keep the default of no.

Move old database?

  • Keep the default of yes.

Allow LDAPv2 protocol?

  • Since I'm reconfiguring this from scratch, I will not be using any of the old protocols. I kept the default of no.

Now it's time to start up slapd, if it isn't already running. Try ps aux | grep slapd, and if you only see your command running, it isn't running... 

eyrie:~# ps aux | grep slapd
root      4792  0.0  0.0   1784   524 pts/0    R+   13:56   0:00 grep slapd

Start it with

/etc/init.d/slapd start

and then issue the above command again.

migrationtools

Slapd should be running at this point to continue. Next, the migrationtools package will be used to take care of moving everything over from the default Unix password-based authentication to LDAP-based. After issuing the command apt-get install migrationtools, everything will be dumped into the directory /usr/share/migrationtools. Installing migrationtools will also install ldap-utils.

Moving into that directory with the command cd /usr/share/migrationtools and viewing the code will show all the files commonly used by the Linux/Unix environment that LDAP will need to integrate with. These include items like group, hosts, passwd, fstab, et cetera. The .pl files are Perl scripts; the .ph is a Perl header. The files should look something like this: 

peregrine:/usr/share/migrationtools# ls
migrate_aliases.pl              migrate_group.pl
migrate_all_netinfo_offline.sh  migrate_hosts.pl
migrate_all_netinfo_online.sh   migrate_netgroup_byhost.pl
migrate_all_nis_offline.sh      migrate_netgroup_byuser.pl
migrate_all_nis_online.sh       migrate_netgroup.pl
migrate_all_nisplus_offline.sh  migrate_networks.pl
migrate_all_nisplus_online.sh   migrate_passwd.pl
migrate_all_offline.sh          migrate_profile.pl
migrate_all_online.sh           migrate_protocols.pl
migrate_automount.pl            migrate_rpc.pl
migrate_base.pl                 migrate_services.pl
migrate_common.ph               migrate_slapd_conf.pl
migrate_fstab.pl

The migrate_all files will run all the scripts, ensuring that they don't need to be run individually. migrate_all_online should be used if the LDAP system is running (which it should be, if slapd is installed), or migrate_all_offline if it is not. However, before running this script, the migrate_common.ph file should be modified.

migrate_common.ph

Migrate_common has all the flags and settings important for configuring the scripts. Most of the defaults should be fine, with a few exceptions. PADL, the implementer of LDAP, by default inserts its own domain name in some areas if the script is not changed. A quick search in a text editor like vi or nano should help locate any instances of "padl" that need to be changed. These include (but may not be limited to): 

# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "padl.com";

# Default base
$DEFAULT_BASE = "dc=padl,dc=com";

Use the URI name for the cluster, in DNS form for $DEFAULT_MAIL_DOMAIN and in X509 form for $DEFAULT_BASE. I'll use the name dc=raptor,dc=loc. These are the values I used:

  • $DEFAULT_MAIL_DOMAIN = "raptor.loc";
  • $DEFAULT_BASE = "dc=raptor,dc=loc";

migrate_all_online.sh

Now we're ready to run the setup script. Since slapd is already running, we'll use migrate_all_online.sh (otherwise, it would be migrate_all_offline.sh). Run this with the command ./migrate_all_online.sh and follow along with the prompts below:

Enter the X.500 naming context you wish to import into: [dc=raptor,dc=loc]

  • The value you entered for $DEFAULT_BASE in migrate_common.ph should be here. If not, specify it.

Enter the hostname of your LDAP server [ldap]:

  • This should be the hostname of the machine you're currently setting up as the LDAP server. I'm on the machine eyrie, so I typed eyrie.

Enter the manager DN: [cn=admin,dc=raptor,dc=loc]:

  • This is the adminstrative user name for LDAP. The default is fine, otherwise you can change it. Even if you keep the default, you'll need to remember the name of this account!

Enter the credentials to bind with:

  • This is the adminstrative account password, as entered for slapd earlier.

Do you wish to generate a DUAConfigProfile [yes|no]?

  • Type no.


After this prompt, the script should begin to go to town and finish with 

/usr/bin/ldapadd: succeeded

Authentication Failure?

If you get a message about authentication failing, you need to run dpkg-reconfigure slapd (see above). If you have to cancel the script, or in other special circumstances, the script will exit with a message like this: 

ldap_add: Already exists (68)
/usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to /tmp/nis.10513.ldif

To get around this, the configuration needs to be set to continue in the presence of errors. Take the temporary file specific to your system and continue running the rest of the script with this command:

ldapadd -x -c -D "<adminstrative account>" -f <temp file> -W

  • -x specifies to use simple binding credentials
  • -c specifies to continue the script in the presence of errors
  • -D specifies to use the following domain
  • administrative account - Mine was cn=admin,dc=raptor,dc=loc - yours should be specific to your domain, as set up earlier
  • -f means using the following file:
  • temp file - This the file specified in the error. /tmp/nis.10513.ldif is the file specific to the system I'm running on - yours will probably be something else.
  • -W tells it to prompt for the password

After you enter this, you'll be prompted for the LDAP password again. Enter it and continue. If the script exits without an error message, you're ready to continue.

Sanity Check

At this point, everything *should* be up and running on the LDAP server. To do a sanity check, check if you can find the user information for a user already on your system. Use the line

  • ldapsearch -x uid=<an existing ID on the system>

or, for more information, do it as the root LDAP user, specifiying your root user name and domain after the -D. -W specifies that you'll be prompted for the LDAP administrative password.

  • ldapsearch -x uid=<an existing ID on the system> -D "<your administrative account>" -W

I searched for kwanous. You should get results like this: 

eyrie:/usr/share/migrationtools# ldapsearch -x uid=kwanous -D "cn=admin,dc=raptor,dc=loc" -W
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: uid=kwanous
# requesting: ALL
#

# kwanous, People, raptor.loc
dn: uid=kwanous,ou=People,dc=raptor,dc=loc
uid: kwanous
cn: KWanous
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fTdVN1cxRWxCL0FtY0E=
shadowLastChange: 13689
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/kwanous
gecos: KWanous,,,

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

The reason you're able to search for an existing user is because the migration script put all of the current users into LDAP. You're still able to become that user (su - kwanous) like normal.

LDAP Client

This is the third page of a five-part tutorial on LDAP. The full tutorial includes

LDAP Client Overview

The steps involved in setting up an LDAP client consist of

  • configuring NSS
  • configuring PAM

NSS

libnss-ldap

Libnss-ldap is a Name Switch Service (NSS) module that allows LDAP to authenticate users. First, apt-get install libnss-ldap.

LDAP server Uniform Resource Identifier:

  • You'll want to enter the IP address of the computer you set up to act as the LDAP server. If you're setting up a client on the same machine as the server, that be the default, ldap://127.0.0.1, for the localhost. In my case, the IP is 192.168.1.254, so I entered ldap://192.168.1.254.

Distinguished name of the search base:

  • This is the same URI as specified when setting up the client. Mine was dc=raptor,dc=loc.

LDAP version to use:

  • Keep the default of 3.

LDAP account for root:

  • This is the account set up earlier. If you used the default earlier, cn was equal to admin, not manager. Mine is cn=admin,dc=raptor,dc=loc.

LDAP root account password:

  • Enter the same password as setup for LDAP root.


If you later run dpkg-reconfigure libnss-ldap, you'll get a few more options, but all of these should keep their default values. The extra options are

Does the LDAP database require login?

  • Keep the default of No.

Special LDAP privileges for root?

  • Keep the default of Yes.

Make the configuration file readable/writeable by its owner only?

  • Keep the default of No.

ldap.conf

Finally, the file /etc/ldap/ldap.conf needs to be configured. This file specifies where the computer running the LDAP services can be reached at. It should currently contain the lines 

#BASE   dc=example, dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

The BASE needs to be replaced with the values for your set up that you specified when configuring the LDAP Server. URI needs to be changed to point to that specific computer via its IP or hostname. IP is preferable since if there are problems with DNS, it will still function. Both these lines need to be uncommented. For instance, my values are 

BASE    dc=raptor, dc=loc
URI     ldap://192.168.1.254

nsswitch.conf

/etc/nsswitch.conf is the file responsible for the order of where files should be checked to authenticate a user. Right now it should have values something like these, as well as many others: 

passwd:         compat
group:          compat
shadow:         compat

The compat specifies that the system should first and only check the compat files - the default Unix files. So, for passwd check /etc/password, for group check /etc/group, and for shadow check /etc/shadow. We need to change these so that LDAP is checked as well. We'll also change compat to files, which is another way of saying the default files. Change the nsswitch.conf values for the following: 

passwd:         files ldap
group:          files ldap
shadow:         files ldap

Notice that files is first. This gives precendence to the local users on the machine before checking LDAP. This is especially important for when the LDAP server may be down.

PAM

PAM, or Pluggable Authentication Module, provides the backend for nsswitch.conf to communicate with other authentication implementations such as LDAP. This isn't necessary on the LDAP server (unless the LDAP server is also an LDAP client), because the LDAP server isn't authenticating LDAP users to that machine. PAM is responsible for accepting the password for a user when they log in as well as changing the password. Without PAM configured correctly, you'll see errors like the following. 

gyrfalcon:~# passwd mycooluser
passwd: User not known to the underlying authentication module
passwd: password unchanged

Your users also won't be able to log in. Kind of a problem!

libpam-ldap

These are the modules to allow PAM to talk to LDAP. Install with apt-get install libpam-ldap. For most prompts, keep the default settings.

Make local root Database admin.

  • Keep the default of Yes.

Database requires logging in.

  • Keep the default of No.

Root login account

  • Change this to the root user at your domain. Mine is cn=admin,dc=raptor,dc=loc.

Root login password

  • Put in the password for the account you used in the previous step (the "LDAP root password").

PAM Files

Now that the files for PAM to talk to LDAP are in place, you'll need to update the PAM files themselves. All four are located in /etc/pam.d/. These next couple changes are important - if done incorrectly, they can make your system unbootable. It's a good idea to make a backup at this point, such as running rsync -plarv /etc/pam.d/ /etc/pam.d.orig/.

common-account

This is responsible for accounts - who is and who is not allowed on the system. The file should currently consist of a line like this: 

account required        pam_unix.so

This line specifies that the system should check for an account with the default UNIX files. You'll want to change it to these two lines: 

account sufficient      pam_ldap.so
account required        pam_unix.so try_first_pass

With this configuration, the system will first try to verify an account with ldap (using pam_ldap.so). If it finds one, that is sufficient for the account to be verified - it doesn't need to have an entry on the local machine as well. However, if that fails, the account must exist on the local machine (pam_unix.so). try_first_pass specifies that the password originally entered by the user should be checked against pam_unix.so after it fails against pam_ldap.so - this prevents the user from having to enter his/her password twice.

common-auth

The file should currently consist of a line like this: 

auth    required        pam_unix.so nullok_secure

We want to change this file also to look at LDAP first. nullok_secure specifies that logging in without a password is all right if authentication is accomplished another way, such as with ssh keys. Add the LDAP line before the existing line, and add try_first_pass to the second line, like this: 

auth    sufficient      pam_ldap.so
auth    required        pam_unix.so nullok_secure try_first_pass

common-password

These are the files involved with changing and manipulating password tokens. The only uncommented line in the file should look like this: 

password   required   pam_unix.so nullok obscure min=4 max=8 md5

We want to add the LDAP line before it: 

password   sufficient   pam_ldap.so
password   required   pam_unix.so nullok obscure min=4 max=8 md5

This file doesn't need the tag try_first_pass.

common-session

common-session refers to the files responsible for what a user can/cannot do - it controls the limits of the environment. For instance, it can be used to limit how many processes a user can create. It is generally used to diminish users' capability on the system. The file should look like this: 

session required        pam_unix.so

Again, we need to add the LDAP line, so the file looks like this: 

session sufficient      pam_ldap.so
session required        pam_unix.so

Sanity Check

At this point, everything *should* be up and connected to the LDAP server. Without having installed ldap-utils, you won't have ldapsearch, but that's fine unless you specifically want it. (If you do want it, apt-get install ldap-utils.)

You should be able to change users passwords as root, as the user, and also be able to become

su - mycooluser

and id

id mycooluser

your LDAP users. Congratulations!

Using LDAP

This is the fourth page of a five-part tutorial on LDAP. The full tutorial includes

Using LDAP

For any of these tutorials, you'll need to have ldap-utils installed on whatever machine you're trying to adminster LDAP with. This is done with an easy apt-get install ldap-utils.

There are a few common tasks you'll probably become quite familiar with while using LDAP:

Changing an Entry

To update one of the entries, use the utility ldapmodify. Ldapmodify can be used a number of different ways: from the command line, interactively, or taking data from a file. In most small changes, it's easiest to use the interactive mode.

If I do an ldapsearch -x uid=kwanous, I get back these results: 

# kwanous, People, raptor.loc
dn: uid=kwanous,ou=People,dc=raptor,dc=loc
uid: kwanous
cn: KWanous
...snipped...
homeDirectory: /home/kwanous
gecos: KWanous,,,

Unfortunately, the homeDirectory is incorrect. It should use my NFS mount, not the local hard drive. I'm going to walk through correcting this. This same process of starting up LDAP and modifying a field will work for other fields, too.

Ldapmodify

First, start up ldapmodify with the credentials to bind with. In my case, this is

ldapmodify -x -D cn=admin,dc=raptor,dc=loc -W
  • -x specifies to use simple authentication
  • -D is used to specify the LDAP administrative user's credentials
  • -W will cause you to be prompted for the password for the LDAP administrative user

If you enter the password correctly, you'll see an error message like below. 

gyrfalcon:~# ldapmodify -x -D cn=admin,dc=raptor,dc=loc -W
Enter LDAP Password: 
ldap_bind: Invalid credentials (49)

If you enter it correctly, though, you'll be greeted with a blank line. This confused me for quite a while the first time, but it just means that ldapmodify is in interactive mode and ready to have you update an entry.

First, specify which entry will be modified. This is taken from the second line, after the comments, of the LDAP search. In this case, I specified

dn: uid=kwanous,ou=People,dc=raptor,dc=loc

Once entering it, hit enter to get to a new line. Next, LDAP needs to be told what to do with this entry. I want to modify it, so I entered

changetype: modify

After that, LDAP needs to know which field to modify. I need to change the home directory, so on a new line, I entered

replace: homeDirectory

Finally, LDAP takes in the new value for the field. This is specified with the field name and then the new value (again on a new line). In my case, that means entering

homeDirectory: /shared/home/kwanous

Once you've entered the changes, it's time to exit ldapmodify and flush them. On the other hand, you can make more changes to that same entry by adding a hyphen on a new line and then entering the replace field and new values again. To exit ldapmodify and make the changes, press the keys CTRL and D at the same time.

Below is the full script for my changes: 

gyrfalcon:~# ldapmodify -x -D cn=admin,dc=raptor,dc=loc -W
Enter LDAP Password: 
dn: uid=kwanous,ou=People,dc=raptor,dc=loc
changetype: modify
replace: homeDirectory
homeDirectory: /shared/home/kwanous
-
modifying entry "uid=kwanous,ou=People,dc=raptor,dc=loc"

If I do another ldapsearch for kwanous, I see that the home directory has been changed: 

dn: uid=kwanous,ou=People,dc=raptor,dc=loc
uid: kwanous
cn: KWanous
...snipped...
gecos: KWanous,,,
homeDirectory: /shared/home/kwanous

References

Removing an Entry

ldapmodify can also be used to delete an entry by specifying changetype: delete instead of modify or add.

A shorter way uses the utility ldapdelete. Here, the LDAP entry to delete is specified on the command line. If you ran the migrate_all_online.sh script in the LDAP Server tutorial, all of the users from /etc/passwd now have corresponding entries in the LDAP system, including root. It's a good idea to take the root account out.

To delete the root account user from LDAP, run

ldapdelete -x -D "cn=admin,dc=your,dc=cluster" -W "uid=root,ou=People,dc=your,dc=cluster"
  • -x specifies to use simple credentials
  • -D is the LDAP administrative account. Be sure to change dc=your,dc=cluster to your actual domain name.
  • -W will cause it to prompt for the administrative password
  • uid=root,ou=People,dc=your,dc=cluster is the account to delete. Again, be sure to change this value to your actual domain name.

By replacing "root" in the above command to the one you want, you can delete any user from LDAP.

Adding Users to LDAP

Most of the time, many users need to be added at once. This is described below.

To add just one user, the utility ldapmodify is often more convenient to use. This uses the same process as changing an entry with ldapmodify, except the changetype should be add. See the two above sections for more information.

Adding Users in Bulk

First, create a list of new user names with one on each line in /tmp/users.

To add a user, you'll need to create the stats for them. The easiest way to do this is to pull off the information from an existing user and then change it for the new user. To get all the basic information and output it to a file, use the command

ldapsearch -LLL -x uid=<existing username> >> /tmp/template

Go through /etc/template and change all out instances of the old user with variables that will be replaced (USERID, UIDNUM, and GIDNUM). After editing, my file is shown below. Your dn should be specific to your domain, as should your homeDirectory! 

dn: uid=USERID,ou=People,dc=raptor,dc=loc
uid: USERID
cn: USERID
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: UIDNUM
gidNumber: GIDNUM
homeDirectory: /shared/home/USERID
gecos: USERID,,,

I'm going to be adding all my users to GIDNUM=100, which is the group users, and I'll be starting with the userid (UID) 1001. You can modify the following script to use something different. Paste the following script into a file and make it executable (chmod o+x <filename>), then run it. 

#!/bin/bash
# Short little LDAP-file creating script

GIDNUM=100
UIDNUM=1001

for x in `cat /tmp/users`
  do
    sed "s/USERID/$x/g" /tmp/template | sed "s/UIDNUM/$UIDNUM/g" | sed "s/GIDNUM/$GIDNUM/g" > /tmp/$x.ldif 
    UIDNUM=`expr $UIDNUM + 1`
  done

It will generate one file for each new user name in /tmp/users, and replace the variables with correct values from the file with the list of user names. To see the files after they've been made, issue

ls /tmp/*.ldif

It's always a good idea to check a few one of them out and make sure the variables were replaced as you were expecting them to. Next, all of these files need to be added to the LDAP database. Again, copy and paste this script and make it executable. Change the part that says "<your credentials here"> to your fully qualified administrator user name (such as "cn=admin,dc=raptor,dc=loc"). With the current configuration, you'll be prompted for your password each time. If you'd rather, you can change

-W

to

-w "<your password here>"

Finally, run it. 

#!/bin/bash
# Short little ldapadd script

for x in `ls /tmp/*.ldif`
  do
   echo "Adding user file $x"
   ldapadd -x -D "<your credentials here>" -W -f $x
  done

Sanity Check

You should see an output like the following for each user as the script is running: 

Adding the user file /tmp/mycoolnewuser.ldif
Enter LDAP Password: 
adding new entry "uid=mycoolnewuser,ou=People,dc=raptor,dc=loc"

After the script finishes, make sure you can search for the user -

ldapsearch -x uid=<new username here>

and then from a machine acting as an LDAP client, id the user -

id <new username>

and become the user -

su - <new username>

Home Directories and Passwords

At this point, the users have been created, but none of them have home directories or passwords. (Since they don't have passwords, they won't be able to log in.)

First, you'll need to set a password for each user - from a machine that's an LDAP Client! - with

passwd <username>

If all goes well, you'll see 

gyrfalcon:/etc/pam.d# passwd mycooluser
New password: 
Re-enter new password: 
LDAP password information changed for mycooluser
passwd: password updated successfully

Next, to add the home directories... there are two options. First, one line can be added to PAM, the authentication mechanisms, to take care of this for you. On the other hand, you can manually add them yourself.

Permanent Solution

To have home directories automatically created for users the first time they log in, edit /etc/pam.d/common-session. Above the existing lines, add this

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

Replace /etc/skel/ with the location of your skeleton files, if you have them somewhere else. After making this change, users will have their home directories created for them from now on.

One-time Solution

To create the home directories manually, but in one fell swoop, use the following script. You'll need to create the file, make it executable, and again change it for your values before running it. Right now, I have the home directories being created on my NFS mount. 

#!/bin/bash
# Short little script to add home directories

for x in `cat /tmp/users`
  do
    rsync -plarv /etc/skel/ /shared/home/$x/          
    chown -R $x:100 /shared/home/$x/
  done

Again, keep in mind that this is a one-time fix. If you want a more permanent solution, see the section above.

Searching

Ldapsearch is the utility for searching the LDAP database. (It comes with the ldap-utils package.) It's a powerful and flexible interface to the LDAP database.

Ldapsearch supports a few different filters, but before we get into that, it's important to recognize there are two different ways of accessing the LDAP database:

  • anonymously: ldapsearch -x
  • with admin credentials, which will prompt for the password: ldapsearch -x -D "<adminstrative account>" -W
    • the administrative account should be something like "cn=admin,dc=raptor,dc=loc"

Administrative credentials will give slightly more information, such as showing the encrypted password field. I'll just be using anonymous authentication, but administrative authentication can be used for any of these examples, too.

Presence Filters

Presence filters use a wildcard character (*) to just see if something exists in the database. For instance,

ldapsearch -x "objectClass=*"

will search for every entry with any corresponding objectClass. To see everything that has an ipServicePort entry, use

ldapsearch -x ipServicePort=*

Exact Filers

Exact filters check to see if a value matches exactly. This can be used to search for a specific user,

ldapsearch -x "uid=kwanous"

to see the top level entry (the organization),

ldapsearch -x "objectClass=organization"

or even see a list of every account in the system, such as this line

ldapsearch -x "objectClass=account" | grep "dn: "

Substring Matching

Substrings can also be searched for with ldapsearch. For instance,

ldapsearch -x "uid=t*"

returns all the entries whose uid field starts with t. These might include tommy, tammy, tmitchel, etcetera. Using

ldapsearch -x "uid=*t*"

would find any entries with a t somewhere in the uid field. (A few you'll find for sure with this search are root, gnats, and statd.)

Approximate Filers

Approximate filters are in the implementation, but the specification of these are very vague. Your mileage may vary! Use ~= for an approximate filter. On my system, searching with

ldapsearch -x "uid~=kwanos"

did indeed return the same results as searching for "uid=kwanous".

References

Troubleshooting LDAP

This is the last page of a five-part tutorial on LDAP. The full tutorial includes

Updating after Changes

After making any change in an LDAP configuration, like the location of the LDAP server, multiple files need to be updated -

  • /etc/ldap/ldap.conf
  • /etc/pam_ldap.conf
  • /etc/libnss-ldap.conf

Changes to the administrative password for LDAP database need to be changed at

  • /etc/libnss-ldap.secret
  • /etc/pam_ldap.secret

Alternatively, dpkg-reconfigure for libnss-ldap and libpam-ldap will also work. Don't run dpkg-reconfigure for slapd, though, as this will erase the previous database (see below if this accidentally happens).

LDAP Checks

It's often helpful to have a non-LDAP user and an LDAP user account on a client system to test out.

  • First, can you log in at all as the non-LDAP user? If not, there's most likely a problem with the basic configuration of nsswitch.conf or the pam files.
  • Can you do an ldap search for the LDAP user? Use ldapsearch -x uid=<ldap user's ID>. This will determine whether the client can connect to the ldap server at all.
    • If not, check /etc/ldap/ldap.conf
  • Can you su - <ldapuser>, id <ldapuser>, and change the user's password (passwd <ldapuser>)? If not, then there's probably a problem with the nsswitch and pam talking to the ldap server. Double check the values for
    • /etc/nsswitch.conf
    • /etc/pam.d/common-account, /etc/pam.d/common-auth, /etc/pam.d/common-password, and /etc/pam.d/common-session
    • /etc/pam_ldap.conf

How to Fix an Accidental Dpkg-Reconfigure Slapd

If you run dpkg-reconfigure slapd on the LDAP server and go into the database configuration options, a new LDAP database will automatically be created for you and your old one purged. Yikes! Fortunately, dpkg creates a backup of your old database in /var/backups/. For instance, the directory automatically created for me after a dpkg-reconfigure was dc=raptor,dc=loc-2.3.38-1+lenny1.ldapdb. (My internal network is raptor.loc.)

To restore your previous slapd (LDAP server) database, first stop slapd with

/etc/init.d/slapd stop

Next, move the current LDAP server database - the one that was newly created for you, that you probably didn't really want - to a different location. You'll want to keep it in case something goes wrong. The current database is stored in /var/lib/ldap/. Make a folder in root's home directory and copy it to root's home directory with

mkdir ~/ldapempty
cp /var/lib/ldap/* ~/ldapempty/

Once it's been copied over, you can delete the contents of /var/lib/ldap using

rm /var/lib/ldap/*

Then copy over the files from the backup directory to the directory you just emptied. Yours will look similar to this, but of course, replace the directory name with your actual backup directory.

cp /var/backups/dc\=raptor\,dc\=loc-2.3.38-1+lenny1.ldapdb/* /var/lib/ldap/

If you do an ls on /var/lib/ldap, you'll see that all the files are currently owned by root. Failing to change then to openldap will cause an error like this in /var/log/syslog when you try to start the system back up: 

Feb  6 12:44:39 eyrie slapd[19570]: bdb_db_open: database "dc=raptor,dc=loc": alock package is unstable.
Feb  6 12:44:39 eyrie slapd[19570]: backend_startup_one: bi_db_open failed! (-1)

To prevent that, change all of the files to be owned by openldap using this command:

for x in `ls /var/lib/ldap`; do chown openldap:openldap $x; done

Finally, you'll want to copy your slapd.conf configuration file back. Again, make a copy of the new one in case something should go wrong:

cp /etc/ldap/slapd.conf ~

and then replace it with your backed up version, which will look something like this:

cp /var/backups/slapd-2.3.38-1+lenny1/slapd.conf /etc/ldap/slapd.conf

After you've done that, you should be able to start slapd back up again:

cp /var/backups/slapd-2.3.38-1+lenny1/slapd.conf /etc/ldap/slapd.conf
/etc/init.d/slapd start

It's wise to make sure the changes took affect as you expected by doing an LDAP search for a user account. If you can't connect to the LDAP server, double check everything started ok by tailing /var/log/syslog.

Retrieved from "http://debianclusters.org/index.php?title=LDAP_All&oldid=1716"
Personal tools
Namespaces
Variants
Actions
About
services
node images
clustering
web monitoring
Toolbox