I'd like to discuss a project that the Fedora people are currently working on. It's called System Security Services Daemon (SSSD, https://fedorahosted.org/sssd/) and tries to address some problems that exist with NSS and PAM today (mostly when using LDAP or other network based account database sources). 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 to use. 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 project? 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 ;) ) -- regards, Ralf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org