[SSSD] could SSSD provide better integration with backends that PAM?

Jakub Hrozek jhrozek at redhat.com
Tue Feb 11 13:52:55 UTC 2014


On Tue, Feb 11, 2014 at 01:23:26PM +0100, Nikos Mavrogiannopoulos wrote:
> On Mon, 2014-02-10 at 14:22 -0500, Dmitri Pal wrote:
> 
> > >> So I'd still be interested whether the extra attributes will contain
> > >> some consistent set of attributes across different SSSD installations,
> > >> or they would be system-specific.
> > > The extra attributes are defined in sssd.conf, which is per-client, so
> > > the set would only be consistent if the sssd.conf is consistent across
> > > client installations. In your case you'd have to add something like:
> > >   [ifp]
> > >   user_attributes = +sshPublicKey
> > >
> > > We simply can't expose all the attributes on the bus, you don't want to
> > > expose the cachedPassword for example.
> > Nikos?
> > How else can you do it?
> > We see it this way: your LDAP has some attribute that you want to expose 
> > so you tell SSSDs in your deployment to fetch it and expose it. What is 
> > wrong with this approach?
> 
> Hello,
>  My main concern is what happens when SSSD is configured with an
> alternative id provider to LDAP. Will SSSD ensure that the additional
> attributes have the same names and format, or are these attributes only
> available when the backend is LDAP?
> 
> regards,
> Nikos

Yes, the SSSD (or rather the provider in particular) will ensure the
entries have the right attributes. Maybe it would be useful to briefly
explain how the responder-provider interaction works within SSSD.

The responder is a process that receives queries from the system and checks
if the cache contains the required result. If the cache is populated,
the results are just returned, if not, the responder asks the provider to
populate the cache and then checks again. The responder has no knowledge
of what provider type is configured, so all provider types use the same
cache layout and attributes.

So the provider is the piece that is responsible for storing the entries
in the right format and with the right attributes.

Currently three provider types are supported with SSSD - LDAP[1], proxy
and local. LDAP is what we use mostly. The local provider is mostly a test
provider at the moment, although we have plans on extending it with the
ability to store custom attributes[2] and much more grand plans towards
the future[3]. The proxy provider by definition only wraps an NSS
module, so the proxy provider is not capable of handling any attributes
outside the standard "struct passwd", "struct group" and similar.

Much more involved internals document is here:
https://fedorahosted.org/sssd/wiki/InternalsDocs

Does this explanation help?

[1] IPA and AD are more or less extensions of the LDAP provider
[2] https://fedorahosted.org/sssd/ticket/2182
[3] https://fedorahosted.org/sssd/ticket/2228



More information about the sssd-devel mailing list