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.

So you want a corporate directory, but you don't have a corporate budget. You want to reap the benefits of single sign-on, the ease of administration for yourself and the ease of use for your users. If you want all this, plus a secure and unified authorization and identity management system, read on. I'll start you down the path to sysadmin nirvana. In this series of articles, I'll show you how to build on pieces you may already have in place, add new pieces and make them all work together. Everything from the authentication servers, to mail delivery, to client integration (including Windows and OS X) will be discussed. We have a lot to cover, so let's get started!

Using Previous Building Blocks

We use MIT Kerberos V v1.4.1 and OpenLDAP v2.1.30 running on Gentoo Linux as our authentication and identity management systems, respectively. I assume you have three servers:, and Before we go any further, you should first read the Linux Journal articles “Centralized Authentication with Kerberos 5, Part I” and “OpenLDAP Everywhere” (see the on-line Resources). We build on where those articles leave off, but keep in mind that our Kerberos realm will be CI.EXAMPLE.COM, and our base DN will be o=ci,dc=example,dc=com. Also, all of the configuration files referred to in this article are available from the on-line Resources.

Setting Up an SSL Certificate Authority (CA)

This section is optional reading but is highly recommended for sites that will have many servers using SSL. Each server can self-sign its own certificate, but you lose unity and some of the power of running your own CA. If you're interested in the details of OpenSSL, I highly recommend the book Network Security with OpenSSL.

We start by choosing /etc/ssl/ as the base directory to store all the signed certificates, certificate revocation lists (CRLs) and accounting information. Once that directory is created, we then create the directories certs, crl, newcerts and private underneath the base. We create an empty file /etc/ssl/, and then create a file /etc/ssl/

# touch /etc/ssl/
# echo '01' > /etc/ssl/

Finally, we create the CA's OpenSSL configuration file, /etc/ssl/

To create a self-signed CA certificate, we must do the following as the user who owns the /etc/ssl/ directory and its children, which is probably root:

# export OPENSSL_CONF=/etc/ssl/
# openssl req -x509 -days 3650 -newkey rsa \
 -out /etc/ssl/ -outform PEM
# cp /etc/ssl/ /etc/ssl/certs
# /usr/bin/c_rehash /etc/ssl/certs

For more details on the openssl req command, view the req(1) man page.

It is important to keep the passphrase for the CA key in a very safe place, because if the CA private key is compromised, all previously signed certs cannot be trusted. It is also important to keep the actual CA machine and access to it secure. How secure you keep the machine is up to you and your actual security needs, but if unauthorized users gain physical or network access, they have access to the CA private key. As I mentioned above, compromise of the CA private key compromises the entire chain of trust, making all signed certificates suspect and untrustworthy. Some suggest that the CA machine be physically secured with no network access. In order to sign certificates in this environment, you use registration authorities (RAs) to receive certificate signing requests (CSRs). The CSRs are then transferred to some secure portable media that is taken to the CA where the CSRs are signed, and the certificates written back to the portable media to be placed back on the RA for the end user to retrieve. If you think your needs might require this, the OpenCA Project was designed with this type of security in mind. It also has support for storage of signed certificates in LDAP.

We have created an OpenSSL configuration file for our CA, but that describes only how to request and sign exactly one certificate. We still need to create an OpenSSL configuration to use from now on to request normal host and user certificates: /etc/ssl/example.conf/ssl.cnf. The client configuration is a little more complex than the CA's because more variations can occur for client certificates.

Now that we have a client configuration file, let's generate a host certificate for the LDAP server. Generating a CSR can be done as a normal user:

# export OPENSSL_CONF=/etc/ssl/
# openssl req -new -nodes -keyout ldap-key.pem \
 -out ldap-req.pem

The openssl options used are much the same as those used for generating the CA CSR. The only new option is the -nodes option, which creates an unencrypted private key.

Our next step is to have the CSR signed by the CA in order to get the public certificate. This, again, needs to be done as root:

# export OPENSSL_CONF=/etc/ssl/
# openssl ca -policy policy_anything -out \
 ldap-cert.pem -in ldap-req.pem

At this point, we have three files: ldap-cert.pem, the public certificate; ldap-key.pem, the private key; and ldap-req.pem, the CSR. The CSR can be thrown away once the certificate has been signed by the CA. Again, protecting the private key is important, especially because it is not encrypted. It probably should be owned by root and have permissions 0400.



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? :)