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.
Configuring the Postfix MTA

We'll be using the Postfix mail transport agent (MTA) v2.1.5. Postfix has well-established support for SASL authentication as well as LDAP support for features such as aliases. Because configuring Postfix from the ground up is beyond the scope of this article, we deal with how to enable Postfix to use SASL and TLS. For information on setting up Postfix, see Resources.

Postfix has two main configuration files, /etc/postfix/ and /etc/postfix/ The file is primarily responsible for how to accept incoming mail, and is primarily responsible for defining mail delivery agents.

An example is included in the on-line Resources, but to understand the directives in this file fully, you should refer to the Postfix documentation and Web site.

Three main directives define how our SMTP server interacts with other SMTP servers: smtp_sasl_auth_enable, smtp_use_tls and smtp_tls_note_starttls. If your SMTP server will be exposed to the Internet at large, you should set these as flexibly as possible to ensure all other SMTP servers can talk to yours. If it's an internal-only SMTP server, however, you can make it more secure by strengthening these directives.

The more interesting part is how we specify how our users and machines connect to our MTA to send mail. A few more directives are of concern here: smtpd_sasl_auth_enable, smtpd_sasl_security_options, smtpd_sasl_tls_security_options, smtpd_use_tls, smtpd_tls_cert_file, smtpd_tls_key_file and smtpd_tls_auth_only.

If you'll be using IMAP for mail delivery, make sure to set the mailbox_transport directive and the smtp and cyrus transports mechanism in

Like OpenLDAP, Postfix is kerberized, uses SASL for authentication negotiation and can use SSL to secure the data transport. To secure Postfix and configure it to use SASL, we need to do a few tasks in addition to modifying First we create an SSL certificate/key pair and place the two parts in /etc/ssl/postfix/smtp-cert.pem and /etc/ssl/postfix/smtp-key.pem, making sure that they're owned by the user postfix and group mail, and that the key is readable only by user postfix. Next, we create a host principal for and save it to the normal place. We also create a service principal, smtp/ and save it to /etc/postfix/smtp.keytab. This file should be owned by root and have the same permissions as the smtp-key.pem file. In addition, we create a SASL configuration file named /etc/sasl2/smtpd.conf and also edit /etc/conf.d/saslauthd. Postfix uses the saslauthd dæmon to get information about authentication mechanisms, and these two files tell SASL how to check passwords, what mechanisms are supported and the minimum security layer to use. Values for minimum_layer are equivalent to the security strength factors (SSFs) in OpenLDAP. Finally, we tell Postfix where its Kerberos keytab file is by creating /etc/conf.d/postfix or by making sure the KRB5_KTNAME environment variable is set in the init script prior to starting Postfix. Once all these tasks have been done, we can start the saslauthd and Postfix init scripts.

LDAP is useful not only for identity management and authorization but also for storing alias maps for Postfix. It's simple to use and maintain, and it removes the need to rebuild the alias database every time there is a change to it. The first step is to make our directory aware that we want to store alias maps in it. We do this by adding the misc.schema to the slapd configuration. Next, we create a branch in the directory for the aliases. We'll use ou=aliases,o=ci,dc=example,dc=com. The last piece is to tell Postfix to use LDAP as a source for aliases by adding ldap:/etc/postfix/ to the alias_maps directive in and creating the /etc/postfix/ file that specifies how to connect to LDAP and where the aliases are in LDAP. We restart slapd and then Postfix; we're now ready to add a mail alias. We create an LDIF file called alias.ldif and add it to the directory. That's it!

Configuring the cyrus IMAP MDA

We'll be using the cyrus IMAP mail delivery agent (MDA) v2.2.10. Complete configuration of the cyrus IMAP server is beyond the scope of this document, but example working configuration files are provided. The cyrus IMAP server is developed by the same group who developed cyrus SASL, so SASL and single sign-on support work as expected.

Like Postfix, cyrus IMAP has two configuration files: /etc/imapd.conf and /etc/cyrus.conf. We'll be dealing only with /etc/imapd.conf. Again there are a few prerequisites: SSL certificate/key pair, host principal and service principal. The service principal should be called imap/ and stored in /etc/imap.keytab. To enable SSL, we define tls_ca_path, tls_cert_file and tls_key_file options accordingly. To use SASL, we define sasl_pwcheck_method, sasl_mech_list and sasl_minimum_layer options. The values for these options are identical to those set in /etc/sasl2/smtpd.conf for Postfix. Like Postfix, cyrus IMAP needs to be told where its keytab file is. We do this by editing /etc/conf.d/cyrus or making sure the KRB5_KTNAME environment variable is set in the init script prior to starting the IMAP dæmon. Once all this has been done, we should make sure saslauthd is running and then start the imap init script.



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