LDAP Notes

Well LDAP is such a PITA and apparently I wasn’t the only one to notice. It looks like Red Hat or somebody has spearheaded a big fancy dummy proof version called freeipa. I discuss it below, but I have confirmed that it does work on two CentOS 7 machines in March 2018.

So this is all getting to be ridiculous. So much so that getting all the parts to talk to each other correctly is extremely challenging thanks to the combinatoric explosion of possibilities (OpenSSL or GNUTLS? Port 636 or 398? sssd or nslcd?) Red Hat seems to have noticed this and, trying hard to compete with Active Directory, they’ve come up with a thing called "Red Hat Identity Management (IdM)" which "provides a centralized and unified way to manage identity stores, authentication, policies, and authorization policies in a Linux-based domain." IdM Documentation

There seems to be a free project called free-ipa. Here is its website.

This guide to installing Free-IPA seems ok. After following these instructions on a pristine install of CentOS 7 it pulled in 300 or so dependencies (no kidding) and then asked me a lot of questions eventually coming out with something like this.

Then the installer did some major BTC mining (or something) as it went through a 1000 step setup script. It finally spit out some more instructions that it might be wise to note.

How about this for those firewall changes?

Rebooting was required, but after I did that, I was able to go to https://auth-alab.ucex.edu in a browser. The certificates complained but screw that. Approving the exception shows that this certificate expires in 2 years (convenient!). Mine (SHA1) ends in 99:88.

Another guide.

See below for client setup.

Note that this Red Hat document says that openldap-server is deprecated. That’s ominous. They say use "Identity Management in RHEL". This is a good time to become aware of FreeIPA.

An ok simple guide. Similar.

Or how about one that addresses the problem with secure TLS connections using port 636. And another.

First make sure to yum install these.

Check that the server started up.

Note this is not the secure port which is 636.

Set a password for the LDAP root.

It will spit out a salted hash which needs to be noted somewhere for use in future steps.

Set up the database by making an ldif file containing this. I put all of these in /root but they can go anywhere sensible.

Apply this file with this.

Then the same with this which will limit monitor access to ldapadm which seems reasonable.

Apply it.

Now create a self-signed certificate.

Or look at this method which uses make files that are indeed on CentOS7 ready to go.

And make sure it’s owned by user ldap which should exist if everything is installed and running.

Create this LDIF to configure the system to use these.

Load this setting as before.

Try the following diagnostic command.

It should produce this.

Copy this template into the production place.

Everything but that file should be owned correctly, but just to be sure might as well hit everything.

Now add the normal LDAP schemas which are helpfully provided.

Create the main layout for the normal application (user log in).

Now apply that file with this.

It will prompt for the password that goes with the hash generated previously. It should then spit out these success messages.

Now normal ldif users can be added and used.

Having firewall annoyances? Or maybe just fending off the inevitable…

Make sure the ones you need come back with success.

First you need to get it. Best to go to OpenLDAP’s official home. Then you can find something like this for version 2.4.33.

To check to see what version you may already have try:

None of the packages for the distros are well-behaved. For this reason and because I’m not keen to get locked into a particular fragile distribution where the service works, I am trying to install from the latest sources and configure it generically.

The first problem is that OpenLDAP doesn’t put things neatly where they would go if they were integrated packages. Of course this may be helpful if you need to clear out an old OpenLDAP installation. I had to do things like:

Most of the stuff is in /usr/local by default.

Also you need to put a blank file in the db backend configuration directory or it will complain:

The OpenLDAP server can be configured in two ways. The first and the one I’ve been using is with a static configuration file. This file is sourced when the daemon starts and its settings are applied at that time.

Might want to sudo chmod 600 /etc/ldap/slapd.conf because of the password in there.

The other way to configure OpenLDAP is to store the configuration information in a directory that the LDAP server manages. Besides being a bit sketchy to configure a server with that running server, I found that some init scripts weren’t flexible with one’s choice of configuration strategies. The upside, in theory, to this strategy is that configuration settings can be adjusted in real time as the server runs and the new settings are applied immediately without any interruption.

Now the server can be started up. This is where it is possible to specify where the config file is. Also you can add some logging output (try slapd -d? for logging options).

Or this is more comprehensive:

The d option has logging levels.

Now the server is running and you can prepare LDIFs to populate it. Here’s an LDIF that prepares the base of the tree, the admin account, the users list, and the groups list.

This can be added with:

Here’s a sample LDIF that includes a couple of groups and a comprehensive entry for a user. .u+g.ldif

This can be added with:

You can test to see if that all worked well with this:

Some more examples of populating users: First add the users ou:

Now you can add users:

This is the traditional way to configure an OpenLDAP server using a straight forward configuration file. The main problem with this approach is that Ubuntu 9.10 wants to move on to using the directory based configuration system. This means that the start up scripts (/etc/init.d/slapd) won’t work and the server has to be started manually. Another problem is that perhaps in a few years OpenLDAP will cut off this way of configuration.

First of all OpenLDAP needs to be present. Turns out that it’s almost impossible to compile it from source because of the mystical BerkeleyDB requirement. It’s ok then to just use the Ubuntu binary installed in the normal way.

Now that it’s installed, it’s probably running and this is actually not what you want. So stop it.

Also you need to put a blank file in the db backend configuration directory or it will complain:

This is the "new" way to configure slapd which involves configuring the LDAP server by storing the configuration information in the LDAP server. Let’s repeat that for clarity: use slapd to configure slapd. Obviously this invites some chicken and egg problems. Also there is not as much reasonable information on-line about how to use this kind of configuration system. The Ubuntu start up scripts (/etc/init.d/slapd) uses this system.

Install LDAP related packages.

Note that server runs immediately upon installation. Start by adding the necessary schemas to the directory:

Note that the password is in plain text here. Best use:

And fix that. This can be done later with ldapmodify.

Create the following ldif files.

Note that there is sometimes confusing syntax in examples one can correct order of option execution. database?). The special frontend database = {-1}, and the config Or something like that.

Check your work.

Should show you everything above as the server knows it. If this produces this warning:

Then just:

and

again a couple of times.

This is my attempt to get a Gentoo server working as an LDAP server using emerge and the full Gentoo way.

/etc/init.d/slapd start /etc/openldap/slapd.conf ←-- Gentoo /etc/conf.d/slapd ←-- Gentoo /usr/lib/openldap/slapd ←-- Gentoo executable lives here

/etc/openldap/slapd.d - This is the place that the alternate configuration style is specified. It is generated using this command:

Seems Ubuntu uses this by default. The problem is that the /etc/init.d/slapd mechanism doesn’t use the -F <dirname> but rather the old -f <slapd.conf>. Don’t know how important it is to make the config file LDAPable.

Maybe you can use Access Control Lists to control things. Here’s a rough outline of an example to stimulate creativity.

In this example organizationalStatus=0 means active:

Here is the client setup guide for using the free-ipa system.

The system seems to be very fussy about authentic FQDN (domain names). If you don’t have such a setup, well, that could be problematic.

Once everything is prepared for installation, installing is pretty easy.

I did the --force-ntpd to suppress a warning and it seemed like the way I would want to do things anyway. When answering questions, it asks for the domain name of the server but I gave it the actual hostname. This means that if you have a tld of thebig.com and your server is at ipa-mygroup.thebig.com, then having failovers muck with thebig.com might be messy. What they’re envisioning, and I am an enthusiastic supporter of doing it this correct way, is something like ipa.mygroup.thebig.com which would allow you to have mygroup.thebig.com be the domain (which won’t mess with higher level thebig.com business) and ipa be the host in that domain. C’est la vie.

Once it all completes, you can check to see if it’s working. Here I check the password list generally. This should not contain nemo, my test user that only the ipa server knows about. Then I specify nemo and if I get back the uid and not an error, we know that the client has received that information from the ipa server. Yea!

Finally try logging in. There will be a password harangue and the weirdest thing to me is that the password has a minimum change default of 1 hour. The maximum of 90 days is totally ridiculous. I changed it to 730 (2 years) by going to Policy→Password_Policies→Max_lifetime on the server control.

Install necessary things.

Do the authconfig. Note I also used an IP address for the ldapserver.

Previous attempt…

Client LDAP partially working:

After running that, getent passwd and id ${USER} worked.

Everything was working great in CentOS 5 and then 6 comes along and LDAP is completely a show stopper. It turns out that the main reason for this is that the way the distro is organized to deal with topics like authentication has completely changed. CentOS (and obviously a well-known upstream vendor) decided to add SSSD or System Security Services Daemon. This was intended to simplify some things in some situations but for my set up it just cause a complete failure. To learn more about sssd you might want to look over the SSSD FAQ.

A good diagnostic to run on a clean system is:

See what’s going on there.

The first and obvious step is probably to install the packages pertinent to LDAP client behavior:

Maybe even:

Some people believe a step like this is necessary:

Or, try this:

Or try this which really works:

Note the --enableldaptls option should not be in here now. Amazingly this causes it to not authenticate the first time you enter the password; it authenticates on the second attempt! How messed up is that?

I did that step but I’m not 100% sure if it was absolutely necessary. I don’t think it was necessary for the ldapsearch command that worked.

What if SELinux or an iptables firewall is in the way? Disable them and get things working. Later you can put them back carefully.

Edited my /etc/openldap/ldap.conf to be this:

Put the TLS cert in the places specified by TLS_REQCERT.

Here’s a way to test LDAP server receptiveness:

THIS WORKED!

However, id user did not.

Maybe something called "nslcd" is needed. Apparently this package provides for it:

It also installs nscd as a dependency.

Edit the /etc/nslcd.conf to be something like this:

It does seem that this file is the one that causes trouble. Even when I can get a clean connection and the user database can be dumped with ldapsearch, the id and getent commands don’t work. Here is what eventually worked for me on CentOS 6.4.

Don’t forget to run the

Now I was able reduce this command to:

This allowed a system where ldapsearch worked but not id ${USER} t start working.

Now fire that up with:

And now keep an eye on tail -f /var/log/debug and try id user and see if any action happens.

WORKS! Holy shit!

Trying to repeat this on a fresh install of Server CentOS 6.2 it didn’t work. I noticed that there was some messy stuff with sssd which was not present when things worked. So I got rid of it:

And then it seemed to make contact with the ldap-server (or try). Still not working though.

Install the client stuff:

This installs these packages too:

Maybe consider the nscd package. Upon installation, configuration questions will be asked that will help set things up. You can redo this (and some more) with:

First thing is the URI of the LDAP server:

Next is the ldap-auth-config dn of the LDAP search base.

Next the version, why not:

Make local root Database admin:

Probably ok for simple things, but no generally (central admin) Does LDAP database require login? I guess this is about the ACL setup. I think in normal cases, anyone can try their luck authenticating and so it’s a:

LDAP account for root (bind dn):

LDAP root account password (password for bind dn):

Then fix up the nsswitch.conf and pam configuration files. This command seems possibly handy:

Here’s it’s format:

I think that this basically means switching the /etc/nsswitch.conf entries to be these:

And adding a "pam_ldap.so" entry to the "/etc/pam.d/common-*" files. For example, here’s /etc/pam.d/common-password:

Here’s /etc/pam.d/common-auth:

Here’s /etc/pam.d/common-account:

Make sure pam is 100% happy by doing this:

Create or modify /etc/ldap.conf file to be:

Now to get a remote client working, you need to set up its /etc/ldap/ldap.conf file which controls client things:

Also copy ldapscert.pem over and make sure it’s world readable.

A preliminary test useful for troubleshooting:

To actually test the remote clients:

A similar test can be used on the server itself if it’s not responding to ldaps:

To test if TLS is working, check that the secure port (636) is ok with:

Then try to connect with openssl’s tester client:

On client config:

This allows your OpenLDAP or OpenLDAP-based client software (for example, gq) to accept self-signed server certificates.

And in /etc/ldap.conf:

Maybe need these:

Where "change.ldif" is something like:

This replaces the uid and the employeeNumber. Here’s how to do it on the secure server setup:

On the server itself, try this:

Create example.ldif

Use ldapadd to add schemas too:

This can be used to test to see things are working:

Example, find the user xed’s record:

To get rid of an entire record in the directory:

LDAP events on the OpenLDAP server generally go to syslog. Watching tail -f /var/log/syslog should tell you if a connection attempt was even made at all. It might also hint at other problems. If no connection attempt was even recorded at the server then it’s not worth trying to debug problems with certificates or other details of that nature.

If you really want to see everything happening on the port, dump those packets with something like this:

Of course all that logging will do no good if it is too cryptic to comprehend. This list of LDAP error codes was to the point and exactly what you’d hope to find when trying to decode something like err=49.

Often the output of slapd verbose logging will contain awful things like this:

"These are not intended to be displayed to users," says the incredibly optimistic RFC2252. That document has a list with some of these things, but it looks like they can be whimsically made up by application programmers. To figure out what these crazy strings are trying to say, I had to go to the source code.

Not exactly helpful but much more helpful than before.

There is a mysterious mode of failure where the LDAP server stops working. It seems like sometimes it comes back from the dead after a long while but maybe not always. I have tracked it down to very aggressive jobs making tons of requests. The answer in the past has been to manually restart the server.

Further investigation has shown that in /var/log/syslog there will be some stuff like warning: cannot open /etc/hosts.allow: Too many open files. I can’t quite figure out exactly what that means or how to properly cure it but it’s known and discussed here.

I think I’ll try setting up a monitor that uses a simple ldapsearch and when it fails, trigger a restart of the server automatically.

If the passwd command doesn’t work look here:

and remove this:

Make sure there is an open port on the LDAP server. This will be 389 for LDAP and 636 for LDAPS. Try nmap -p 389,636 ldap.example.com.

Here is how to make a dump of the directory database contents. Remember that these files contain password hashes and are therefore kind of sensitive. Ideally you should turn off the server to ensure consistency, but as long as no one is actively modifying the directory (no admin activity or passwd commands) you should be ok.

Here is a complete routine I used to restore a directory from a backup LDIF. Shut down the server and do this:

TLS SETUP Place the certificate and key where they can be found. See TLS on how to use openssl to generate these certificates.

Now prepare a /etc/ldap/slapd.conf file containing as described in the server set up section.

Now the server can be started up. This is where it is possible to specify where the config file is. Also you can add some logging output (try slapd -d? for logging options, or slapd -d0123 to run in the terminal and not fork).

Start by generating a cert and a key:

Note the default expiration is 30 days, so setting to 20 years is about as trouble free as it’s going to get.

Note the certificate is the public key and the key is the private key. This is self-signed so this avoids any certificate authority annoyances.

Need this too?

Edit:

or mabye (?)

Specifies the file that contains the slapd server certificate.

Specifies the file that contains the slapd server private key that matches the certificate stored in the TLSCertificateFile file. Currently, the private key must not be protected with a password, so it is of critical importance that it is protected carefully.

This is to disable the "NULL" ciphers (NULL-SHA and NULL-MD5). You can double check that this value is sensible with $ openssl ciphers -v TLSv1+RSA:!NULL This should produce the list of various encryption methods available. I think that’s what it’s doing. If it doesn’t fail, it’s probably ok.

Default. Is this necessary?

http://www.openldap.org/doc/admin24/tls.html

To use OpenLDAP in TLS or SSL mode you will need to generate a PEM format SSL key.

From this helpful web site:

Note that this command creates an RSA key and then self-signs that key. Self-signed keys are not usual in (for example) HTTPS communications, as the keys are generally signed by a third party known as a Certification Authority. In this case, however, a self-signed key is perfectly okay, as most LDAP clients do not check the signature of the key.

Do these certificates work? With the server turned on try this:

This web site has good information on using OpenSSL. It discusses how to use s_server and s_client to test the certificates as well as check to see that they’re not expired.

Place the certificate and key where they can be found. See TLS on how to use openssl to generate these certificates.

Now prepare a /etc/ldap/slapd.conf file containing:

Might want to sudo chmod 600 /etc/ldap/slapd.conf because of the password in there.

Another Useful LDAP Glossary: link

slapd - OpenLDAP server (slapd) Contains these useful things:

ldap-utils - OpenLDAP utilities Contains these useful things:

ldapscripts - Add and remove user and groups (stored in a LDAP directory) Contains these useful things:

python-ldap - An LDAP interface module for Python Contains these useful things:

Also notice: