I'd like to discuss a project that the Fedora people are currently working on.
It's called System Security Services Daemon (SSSD,
) and tries to address some problems that exist
with NSS and PAM today (mostly when using LDAP or other network based account
Here's a list of problems they're trying to solve:
- offline/cached authentication and name service e.g. for Laptop Users
- Each application opens separate connections to the remote datastore
(e.g. LDAP Server), by that way a single machine might open several dozens
of network connections taking up too much resources from the server
- NSS/PAM modules that can make use of authenticated connections to their
backend DB need to provide the authentication token (username/password,
Clientcert+Key, kerberos keytab) for that authentication be available in a
world-readable place on the filesystem
Most of the above problem can be solved by splitting the nss-Module into a
client/server architecture (e.g. like it is done with samba-winbind).
Having a small nss-Module talking through a unix domain socket to the daemon
that's doing the real request against the remote database source. The problem
is that you end up with a different daemon for every NSS module that you want
The SSSD project now tries to implement a somewhat similar but more generic
approach, it provides have a daemon (sssd), NSS (nss_sss) and a PAM (pam_sss)
Moduleas well. The difference now is, that this daemon doesn't talk to the
remote datasource directly but acts mostly like a caching proxy i.e. it hands
over incoming NSS or PAM requests to other NSS/PAM module (e.g. by calling
directly into nss_ldap or nss_winbind) and caches the results for later reuse,
e.g. when the machine is disconnected from the network.
SSSD is also used to introduce a multi domain concept for PAM. E.g. usernames
can have the from of user@DOMAINNAME and sssd allows to configure a specific
PAM stack for every different domain. That should create less complex
PAM configuration files.
Additionally to the PAM and NSS service the daemon will provide a DBUS
interface that can be used to get addtionaly user information for the
underlying databases which one currently can't get through NSS. E.g. user
photos for Display Managers, preferred language settings and stuff like that.
I think the project took a pretty intersting approach to solve some of the
issues with how NSS and PAM integrate to remote account sources. It of cause
has some downsides (yet another level of indirection, another system daemon
that needs to run on the machine), but as SSSD is purely optional we could
live with that I guess.
Does somebody alread have experiences with SSSD? What do you thing about the
Is anybody interested in creating a Fate-Request or packages in the
buildservice for testing purpose/integration into Factory?
I'd also like to mention exist some alternative approaches that aim to solve
the above listed problem especially for the nss_ldap/pam_ldap case:
- nss-ldapd (http://ch.tudelft.nl/~arthur/nss-ldapd/
): a reimplementation of
nss_ldap and pam_ldap (PAM support is still in development) in a client
server model. They currently don't do any caching/offline support
(Packages for 11.1 and Factory are available in the buildservice)
- nssov: A plugin (overlay) for the OpenLDAP server that the NSS and PAM
modules from nss-ldapd can directly talk to. That means instead of running
nss-ldapd on the client machine you setup a special OpenLDAP server
configuration. It can e.g. just act as a (caching) proxy to the real backend
server, or can be a (partial) replica.
- use the original nss_ldap/pam_ldap modules talking via ldapi (LDAP over Unix
Domain Socket) to a locally configured OpenLDAP proxy/replica.
(BTW, running an LDAP Server on the client sounds scarier that it is, you can
create pretty lightweight OpenLDAP setups ;) )
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org