Home ›

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

Issue 140

From Issue #140
December 2005

Oct 27, 2005  By Ti Leggett
 in
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.
Wrapping Up

We certainly have covered a whole lot in a short time, but all this hard work has given you a secure and scalable corporate directory. We've just implemented a system that works for tens of users and hosts at one location all the way up to thousands spread all over the world. In my next article, we'll tackle tying Linux and Apple OS X clients into our system to see the fruits of our labor.

Acknowledgements

This work was supported by the Mathematical, Information and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, Office of Science, U.S. Department of Energy, under Contract W-31-109-ENG-38. Additional support has been provided by the Computation Institute at the University of Chicago and the National Science Foundation under Grant SCI: 0451491.

Resources for this article: /article/8581.

Ti Leggett (leggett@mcs.anl.gov) is a systems administrator for the Futures Laboratory of the Mathematics and Computer Science Division at Argonne National Laboratory. He also has a joint appointment with the Computation Institute at the University of Chicago.

______________________

Comments

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
Submitted by Marty Heyman (not verified) on Sat, 01/06/2007 - 20:45.

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
Submitted by Curtis Vaughan (not verified) on Tue, 12/13/2005 - 13:59.

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
Submitted by Ti Leggett on Tue, 12/13/2005 - 14:43.

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
Submitted by Anonymous (not verified) on Mon, 10/31/2005 - 03:14.

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
Submitted by Ahmed Alawy (not verified) on Mon, 11/28/2005 - 08:31.

Check out http://www.josso.org/ 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
Submitted by Ti Leggett on Sun, 11/06/2005 - 10:08.

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
Submitted by Anonymous (not verified) on Mon, 10/31/2005 - 06:42.

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
Submitted by Mark Smith (not verified) on Sat, 10/29/2005 - 21:27.

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
Submitted by Randal Hart (not verified) on Sun, 10/30/2005 - 13:19.

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
Submitted by Mark Smith (not verified) on Mon, 10/31/2005 - 15:55.

"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.

randal.hart.messaging
randal.hart.financials

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.

Passwords

randal hart's picture
Submitted by randal hart (not verified) on Tue, 11/01/2005 - 00:11.

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

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions