Paranoid Penguin - Single Sign-on and the Corporate Directory, Part I

Author Ti Leggett presents the first in a series of articles focused on building a secure corporate directory, including support for single-sign-on that's scalable up to thousands of users.
Securing LDAP

Even though passwords aren't stored in the LDAP directory, a lot of sensitive information is. Your users probably don't want the whole Internet to know their phone numbers, e-mail addresses or employee IDs. Once you've read “OpenLDAP Everywhere” and have a working LDAP server, you need to secure the information transportation and access to the directory.

The first step is to secure the data transport using OpenSSL. First, let's copy our certificate and key we signed previously to /etc/openldap/ssl/slapd-cert.pem and /etc/openldap/ssl/slapd-key.pem, respectively. We need to provide five options in slapd.conf: TLSCipherSuite (optional), TLSCACertificatePath, TLSCertificateFile, TLSCertificateKeyFile and TLSVerifyClient. The slapd.conf(5) man page has good definitions of these options.

Having secured the data on the wire, we now secure authentication using the Kerberos KDC. OpenLDAP is Kerberized and uses SASL for authentication negotiation. We first must tell slapd how to find its Kerberos keytab file. We do this by editing /etc/conf.d/slapd or by defining KRB5_KTNAME prior to starting slapd in its init script. Two options in slapd.conf also must be defined: sasl-secprops and sasl-regexp.

Right now, TLS and SASL can be used but aren't required. Two more options in slapd.conf, security and allow, are used to specify the security methods and encryption strength needed for certain operations to take place. And, be sure to set up access control lists (ACLs) properly—refer to slapd.access(5).

Securely Replicating Kerberos

We start by replicating our Kerberos database from to, so that if fails, will pick up the slack. One important fact to remember is that only one kadmin server can be on the network for a realm at any time. Otherwise, there is no authoritative source for updates to the database. Kerberos comes with kprop and kpropd to propagate the Kerberos database securely. First we must identify kpropd as a known service. Add the following to /etc/services:

krb5_prop             754/tcp

We need to define an ACL file, /etc/krb5kdc/kpropd.acl, that tells kpropd what hosts are allowed to propagate. All that is really needed in this file is the master KDC's principal name, but it doesn't hurt to have all KDCs in here so that if a failure occurs, we can choose a new master, start the kadmin service on it and propagate from that host to the other slaves.

We now create an xinetd service definition, /etc/xinetd.d/kpropd, on our slaves; (re)start xinetd; dump the database on; and propagate it to the slaves so they have an initial configuration:

# /usr/sbin/kdb5_util dump /etc/krb5kdc/slavedump
# /usr/sbin/kprop -f /etc/krb5kdc/slavedump \

Finally, we create a stash file on each slave using the master key defined when setting up's database, and then start the kdc service:

# /usr/sbin/kdb5_util stash
# /etc/init.d/mit-krb5kdc start

To propagate out the KDC database periodically, we define a cron job on Thanks to Jason Garman and the O'Reilly book Kerberos: The Definitive Guide for the original cron job.

A sensible time frame to run this script is hourly or from /etc/cron.hourly. Our Kerberos database is now being replicated securely from the master to any number of slaves. If the master fails, we have a way to switch to a slave machine quickly and with minimal data loss, if any. Now that we're propagating Kerberos changes, we can add the slave server to the krb5.conf file as a valid KDC.

Securely Replicating OpenLDAP

Enough critical information will be stored in your LDAP directory that you probably don't want a single point of failure. After all, if your LDAP directory is unavailable, your users won't be able to login, check e-mail or do numerous other daily tasks. Replicating your LDAP directory helps ensure there is no single point of failure.

Let's replicate the LDAP directory from to OpenLDAP has a dæmon called slurpd that is responsible for this. Unfortunately, slurpd has no configuration directive telling it which Kerberos keytab to use, so there's a bit of work required. First, we edit slapd.conf on, adding the options replogfile and replica, and then we restart slapd.

We need to create a Kerberos ldap service principal and SSL certificate and key for, as we did for We also must create a slapd.conf file for This file is almost identical to the one on, with a few key differences. For the same reason we have only one Kerberos admin server, we want only one LDAP directory being updated and changed. The only user who should be able to write to the slaves' directory should be uid=host/,cn=GSSAPI,cn=auth or the Kerberos principal of the master, so our ACLs on the slaves are much more restrictive. Also, slapd needs to know who will be sending updates via slurp as defined by the updatedn and updateref options.

Now we switch our focus back to for a bit. We need to create an /etc/conf.d/slurpd or make sure that KRB5CCNAME is set before slurpd is started from the init script.

Next, we get some initial Kerberos credentials:

# KRB5CCNAME=/var/run/slurpd.krb5cache /usr/bin/kinit -k

And then we dump the directory to a file:

ldap# /etc/init.d/slapd stop
ldap# /usr/sbin/slapcat -l /tmp/slavedump.ldif
ldap# /etc/init.d/slurpd start

Because slurpd transfers changes only in the master directory, we need to populate the slave directory with the current state of the master directory. We do this by copying a dump of the master we created above, /tmp/slavedump.ldif, to and import the dumped directory and start slapd:

kdc# /usr/sbin/slapadd -l slavedump.ldif
kdc# /etc/init.d/slapd start
ldap# /etc/init.d/slapd start

We need to test that the slave has a sane directory:

# ldapsearch -H ldap:// -ZZ

To test that replication is happening, we can make a modification or addition to the directory on and then search on to make sure that change propagated.

Once we've verified that slurpd is working, we create a cron job on to keep the credentials from expiring. The default time limit for credential validity is ten hours, so if we define a cron job to run every eight hours, we should be safe.

Last, we add into our rotation of valid LDAP servers for nss_ldap. That is, we append to the list of servers specified by the host option in /etc/ldap.conf.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Nice but please use recent code

Marty Heyman's picture

It's a nice article. Thanks for writing it up. It would be better for you and your readers to use more recent bits (2.1.x is now historical) as the latest releases address hundreds of problems, dramatically improve directory performance, and add important features.

Incomplete instructions

Curtis Vaughan's picture

Being interested in implementing SSO per your article I went through the articles pertaining to Kerberos and OpenLDAP and got them working fine. Then I started on your article and got up to the section "Securing LDAP" and am totally lost. Instructions for everything so far have been rather detailed and where they differed from my distro (Debian) I was able to figure it out. But suddenly here we get very general instructions about providing options (TSLCipherSuite, TLSCACertificatePath, etc.) and then telling slapd how to find its Kerberos Keytab. etc. I've looked at the man pages for slapd.conf and slapd.access but am not sure I am doing it right. In fact I can't firgure out what I'm supposed to do with KRB5_KTNAME. Would really appreciate more information on this part.

Re: Incomplete instructions

Ti Leggett's picture

The TLS options are explained in slapd.conf(5) in the TLS OPTIONS section, but for the two you listed here's some brief explanation:

TLSCipherSuite: Specify the list of OpenSSL ciphers you will accept. More info can be obtained from the ciphers(1) man page.

TLSCACertificatePath: Specify the path where you keep the CA certificates you accept

As for the KRB5_KTNAME environment variable, this is set prior to running slapd. A lot of distributions have a way to set environment variables prior to starting an SysV init script. Under Gentoo these files are in /etc/conf.d, under Red Hat and SuSE they are kept in /etc/sysconfig. Under debian these are kept in /etc/default. So if you edit /etc/default/slapd and add the line:

export KRB5_KTNAME=

And then restart slapd you'll be on your way.

Hope that helps.

SSO vs. Unified Login

Anonymous's picture

I can see how this docuement covers Unified Login (one username, one password), I cannot see how it covers Single Sign-on (One sign-on - enter username and password once). Microsoft Products utilize SSO very well... but the Open Source world has not.

I would LOVE to see a way for Open Source to access the MS Authenication Credentials.

Also, I would LOVE to see a true SSO for Open Source Systems.

Maybe I'm missing something with the KRB5 implementations, but too many programs require individual logon.

Java Open Single Sign-On.

Ahmed Alawy's picture

Check out for more information about open source SSO. It is a very good start, take it from an SSO expert ;)

Re: SSO vs. Unified Login

Ti Leggett's picture

Since Microsoft Active Directory is essentially Kerberos and LDAP squashed together with some special RPC calls, what we're doing is implementing our own open source AD. But this article was just laying the groundwork for really getting SSO off the ground. The next articles in this series will deal with actually making use of this infrastructure and getting SSO really working. Many applications are now supporting GSSAPI which is the underlying protocol needed for SSO in the open source world (Microsoft uses GSS-SPNEGO).

It is possible to authenticate against a Microsoft AD server using Samba and pam/nss_ldap, though I'm not sure how much SSO you can get out of it with Linux and Mac clients.

Kerberos is SSO

Anonymous's picture

I haven't read the article but Kerberos is SSO, and has been for many years.

On the other way MS Authentication is now Kerberos (slightly modified), and they are now quite interoperable, but not so easy to configure as, f.e., Apple's Open Directory 2 (which is, of course, also Kerberos and LDAP).

Then again, what I would love to have is having all webservers and browsers support OpenPGP cyphersuites on TLS so I can have real unified and secure login on the internet.

DITCH X.509 !!

Single sign-on may decrease security

Mark Smith's picture

The advantage of single sign-on is that it makes it more convenient for users to login, as they now only have to remember a single username and a single password.

Unfortunately, any time convenience is increased, security usually decreases. If a user only has a single username and single password, that also means that an adversary only has a single username and single password to discover to then be granted full and complete access to all systems this single sign-on user has access to.

As much as multiple user accounts and multiple passwords, which implies multiple challenges for passwords, is sometimes frustrating to deal with, it creates a level of defense in depth, if passwords (and even usernames) are different for each system. Single sign-on can remove that depth.

Single sign-on can be useful, just be aware of its limitations. Measures such as two-factor authentication, or implementing multi-level security and then only permitting single sign-on to grant access to resources only within the authorised level can help address the security weaknesses that single sign-on can introduce.

Single sign-on may increase security

Randal Hart's picture

That truely depends on how you implement it.

There is nothing stopping you from using multiple accounts for different priveledges.
randal.hart (Normal user)
randal.hart.adm (Administrator)

There are programs like sudo to help upgrade and downgrade the permissions of programs you run on your local machine.

All you need to do is understand what you're doing. Then set up your system according to your needs.

I think my might have missed my point

Mark Smith's picture

"There is nothing stopping you from using multiple accounts for different priveledges.
randal.hart (Normal user)
randal.hart.adm (Administrator)"

Certainly, that was my point about implementing multi-level security.

The problem is that before SSO, randal.hart had a number of different logins to different systems, and had a different passwords e.g. email verses accounting system.The different passwords were in place because being authorised to access email is a different security level priviledge than being able to acces the accounting system.

If you naively then implemented SSO, granting a single user account access to email and accounting, you've now removed the security boundary between email and accounting, that may be necessary.

You could achieve that by having e.g.


That is fine and obvious, of course it removes one of the major username/password benefits that SSO is sold as providing.

My point is this. Don't get so excited by the convenience of a SSO system and end up removing necessarly security barriers between systems/applications without realising it.


randal hart's picture

Single sign-on will never lose the need for multiple passwords.

And I bet 99/100 people will have the same password for both accounts!

You'll either need to associate accounts so they can't pick the same passwords, or force different rules on all the different types of accounts.

How does to IA department sleep at night? :)