The Fedora Marketing team built this interview as part of their work promoting the latest and greatest free and open source software technologies that Fedora brings with each new release. If you're interested in participating in Fedora, visit http://join.fedoraproject.org to get started.
Feature Highlights
Interview Questions
Stephen, please tell us a bit about yourself. Who are you, and what do you do?
My name is Stephen Gallagher, and I'm a long-term open-source advocate. I've been using Red Hat Linux and its offshoots since 1999, and a few years ago they decided to start paying me to do what I love.
I joined Red Hat in June of 2008 as part of the development team for FreeIPA v2. I was hired to work on the client-side component of FreeIPA.
I'm here to talk to you today about the System Security Services Daemon (also known as SSSD). Can you give us a brief description of SSSD - what it is, and what it does?
The SSSD started life as the FreeIPA client bits. Its original intent was to provide advanced functionality beyond just username lookups and centralized authentication.
As we started developing it, we realized that there were a number of features that we were adding that would be useful even without FreeIPA, so we started branching out.
The modern SSSD is actually not a single daemon, but a collection of services that provides a common interface for user identity and authentication.
The SSSD provides user information through the standard NSS (name-service switch) interface used by traditional identity services like nss_ldap and nss_nis. We also provide a PAM (pluggable authentication module) module to perform authentication.
Okay. Let's talk about SSSD from a few different user angles. First - let's pretend that I am an average end user. How will SSSD be useful to me? How do I interact with it - if at all - and is its integration into my environment going to be transparent if I am a new user?
The end-user doesn't really interact with the SSSD in any direct way. The most visible user feature is the availability of cached credentials. What this means is that if you have your user account provided by a centralized authentication authority (LDAP and Kerberos are the most common examples), you will no longer be required to maintain a separate local account on your laptop for use when you're not connected to your primary network.
Let's assume a corporate environment that has centralized user identities provided by an LDAP server like OpenLDAP. This environment is also using Kerberos to provide two things: authentication and single-sign-on to network resources.
In a traditional deployment, this would mean that in order to log on as a user provided by LDAP and authenticated by Kerberos, you would have to be connected to the corporate network. Otherwise, the system would be unable to access the LDAP and Kerberos servers to verify your identity.
With the SSSD, once you have logged in online successfully at least once, your credentials are cached (securely) in the SSSD so that you can pick up your corporate laptop, shut it down, get on the train and log right back in.
This sounds great - but my site's system administrator doesn't know about SSSD. What are the reasons I should give to him or her about why SSSD is going to be great for my coworkers and me?
There are a few features here that administrators are going to love. One of the big ones is that it will reduce load on their identity servers. I'm going to have to describe a little bit how NSS works first.
NSS is a feature built into the standard system libraries. When a program requests information about a user (e.g. map a userid to a username, check the user's group memberships, default shell, full name, etc.) it makes a request to the system. Internally, this system call goes and looks at the list of NSS plugins that are available with that call. *Within the context of the original process*, it then will initiate a connection to the identity server to resolve the information. This means that on any given client machine, there could be dozens or more processes that are each initiating connections to the identity server to ask about users. Setting up a connection to an identity server is a very resource-intensive process, especially if the system is employing encryption (as it should!).
The SSSD behaves a little differently. We still have an in-process NSS plugin, but instead of communicating directly with the remote identity server, it sends the request to the SSSD. The SSSD then does a series of things.
First, it determines whether there is a fresh cache entry for the user or group being queried. If the cache entry exists and is not stale (configurable), it returns the result immediately without going out to the network server. This caching can result in dramatic speed increases in user lookups, as local replies are much faster than replies from a remote server.
If the cache entry did not exist or was stale, the SSSD will use a common connection to contact the remove server. So, instead of every process on the client machine opening its own connection to the remote server, there's now only one connection per machine. This will reduce resources on the identity server.
In terms of authentication, administrators also have the ability to configure the SSSD such that it will only allow users to log in using cached credentials for a fixed time. The idea behind this is to ensure that a laptop has to check in with the corporate network every so often, to guarantee that the user is still allowed access. The user will see a message at login time when logging in with cached credentials telling them how many days they have left before they can no longer log in offline.
One other feature that may aid administrators is the ability to set up multiple network domains in the SSSD. With traditional nss_ldap, it was only possible to request user information from a single LDAP domain. With the SSSD, it is possible to set up any number of identity domains, provided that the user/group ID ranges do not overlap.
Some other features that are coming soon involve more advanced central controls with FreeIPA. One of the most talked-about is the Host-Based Access Control (HBAC) feature, that will allow an administrator of a FreeIPA v2 server to set up groups of hosts and control permissible access times for groups of users. For example, it will be possible for an admin of a company that follow strict timekeeping procedures to restrict access to machines outside the schedules of their alotted time slots.
Alright -- let's switch gears a bit here and put me in the role of that system administrator. What types of authentication and identity servers are supported by SSSD? Can you talk briefly about each type?
Right now, the SSSD formally supports LDAP for identities, and LDAP or Kerberos for authentication. We also have a less-well-supported feature we call the 'proxy' backend that will allow an admin to wrap our caching features around an existing NSS plugin (like nss_nis).
Right now, to get the full effect of SSSD, you would want your network to be using LDAP for user identities and Kerberos for authentication and single-sign-on.
In SSSD 1.2, we'll have complete functionality for hooking SSSD up as a FreeIPA v2 client, however as FreeIPA v2 is still in alpha stages, it will be a while before this can truly be appreciated.
What kind of a process would a sysadmin have to go through to get SSSD working in their environment?
On Fedora, very little :) This is one place where Fedora shines through as being clearly the best place to work with SSSD. On Fedora 13, authconfig 6.1.3 is capable of configuring the SSSD through a newly-designed and much simpler UI than in previous versions.
The recommended way at this time is for administrators to prototype their SSSD configuration using authconfig, and then tweak individual settings as needed.
Another major advantage over the traditional NSS and PAM approach to identity and authentication is the availability of a single configuration file for all related settings. The file /etc/sssd/sssd.conf is a one-stop shop for this.
Once the administrator has an sssd.conf that meets their needs, all they need to do is distribute it to their clients, then run 'authconfig --enablesssd --enablesssdauth --update' and authconfig will do the rest for them, setting up the /etc/nssswitch.conf and the /etc/pam/* files as needed.
On Fedora, it couldn't be simpler to set up. We've gone to great lengths to make it as easy as possible. I'd like to publicly thank Tomas Mraz (authconfig) and Máirí n Duffy (user-experience design) for all the hard work they put in getting the new UI ready for general consumption.
I understand that SSSD had a test day in March. Can you tell me how that worked? What kinds of problems were you able to solve by having a lot of community members participating in testing all at once?
It worked fairly well. We were actually surprised (and pleased!) to discover very few bugs in the SSSD itself. Most of the issues we encountered came from the authconfig UI (and have since been fixed). The real benefit of having the Test Day was that it allowed us an opportunity to get a feel for a wider variety of deployments. We were very pleased to see that, for the majority of testers, we were meeting their needs.
This is how good software is written; it's not just about having clever coders, it's about the people who care enough about what you're doing to step in and help you cross that final mile.
Who else works on SSSD? Do you have code contributions coming from other people?
Right now, the majority of code written for the SSSD is coming in from Sumit Bose, Simo Sorce, Jakub Hrozek and myself at Red Hat. However, we have had patches proposed by developers from the Fedora ARM SIG, SUSE and Ubuntu (in descending order of level of contribution).
Tell me about the information that is available on SSSD. Do you have a wiki page, documentation, mailing list, or any other places people can go to find out more about SSSD?
We have a wiki page and bug tracker available at https://fedorahosted.org/sssd The bug tracker tends to be the most up-to-date method of following our development process. We'll create the occasional wiki page to describe a design we're working on when additional discussion and reference is needed.
Our development mailing list is sssd-devel@lists.fedorahosted.org (https://fedorahosted.org/mailman/listinfo/sssd-devel) This is a medium traffic list. If you ever doubt that we're working tirelessly on the next release, spend two weekdays on this list :)
We can also be found most of the time on #freeipa on irc.freenode.net. This is the best place to look for us if you want to have a conversation.