[SSSD] Authenticating users who exist in multiple domains

Stephen Gallagher sgallagh at redhat.com
Mon Jul 25 11:25:54 UTC 2011


On Sat, 2011-07-23 at 16:00 -0400, Simo Sorce wrote:
> On Thu, 2011-07-21 at 18:51 -0400, Michael Fenn wrote:
> > Greetings,
> > 
> > We're currently in the process of evaluating RHEL6 and as part of that 
> > process, we're investigating using SSSD in our environment.  In the 
> > process, we've hit a little snag when it comes to authenticating users 
> > who exist in multiple domains.
> > 
> > First, a little background.  We have two groups of users, each 
> > authenticating against a different Kerberos domain.  However, both users 
> > exist in the same LDAP directory.  As such, I've set up SSSD with two 
> > domains, both with the same LDAP directory provider but with different 
> > Kerberos authentication providers. Let's call them A and B.  The domains 
> > key in my sssd.conf is set to A,B .
> > 
> > If a user X in domain A attempts to authenticate either as X or X at A, 
> > everything works as expected.  Similarly, if a user Y in domain B 
> > attempts to authenticate as Y at B, everything works.  However, if Y is not 
> > able to authenticate as simply Y .
> > 
> > In essence, it seems that if authentication fails for the first domain, 
> > then SSSD will not attempt to authenticate the user against any other 
> > domains.  For us, this represents a regression from the old way of doing 
> > things, i.e. pam_krb5, where such failover was possible.  Are there any 
> > plans to change this behavior in SSSD?
> 
> No, this is done by design. Each domain in SSSD represent a separate
> identity domain and sharing user names between domains is not allowed.

I'd like to expand on this to make the design decision more clear. One
of the classic problems of the old-style of PAM "try everything until
one works" approach is that it results in credential information
leakage.

In other words, if the user you're logging in with is authenticated by
the third auth mechanism in the list, then you've handed that user's
credentials (possibly a plaintext password) to the two auth mechanisms
that came before it. This triples the attack surface for this user,
because a vulnerability in either of those earlier mechanisms will
expose the password for the REAL auth mechanism.

We made a careful decision to "regress" this behavior with SSSD in the
name of safety over convenience.



There is an other alternative that you might follow. If all of your
users and groups in the second domain can be identified by a specific
LDAP filter, then you can split the two SSSD domains by adding:
ldap_user_search_filter = <filter>
ldap_group_search_filter = <filter>
into DOMAIN1
and 
ldap_user_search_filter = <negated filter>
ldap_group_search_filter = <negated filter>
into DOMAIN2.

This will allow you to use the same LDAP server, but maintain separate
SSSD domains. You can also do something similar with the
ldap_*_search_base options if your users and groups are in separate
branches of the LDAP tree. (i.e.
ou=domain1,cn=Accounts,dc=example,dc=com vs
ou=domain2,cn=Accounts,dc=example,dc=com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110725/c0eae3d6/attachment.sig>


More information about the sssd-devel mailing list