[SSSD] sssd and sub-domains

Simo Sorce ssorce at redhat.com
Mon May 23 22:27:04 UTC 2011



----- Original Message -----
> On 05/23/2011 08:40 AM, Simo Sorce wrote:
> > On Mon, 2011-05-23 at 08:27 -0400, Stephen Gallagher wrote:
> >> On Fri, 2011-05-20 at 11:22 +0200, Sumit Bose wrote:
> >>> Hi,
> >>>
> >>> with this email I would like to start some discussion and collect
> >>> ideas
> >>> and use-cases about a new concept for sssd, namely sub-domains.
> >>>
> >>> Currently in sssd a domain is like a single namespace which has to
> >>> be
> >>> defined in sssd.conf and only users from explicitly known domains
> >>> are
> >>> supported. E.g. if you have only domains A and B configured then
> >>> every
> >>> request for a user from domain C is already rejected by the nss
> >>> responder.
> >>>
> >>> But what if, e.g. the server for domain A is an Active Directory
> >>> server
> >>> and the AD admin decides to create a trust to a new Active
> >>> Directory
> >>> domain C? Since the server trust domain C every member of his
> >>> domain
> >>> should trust members from domain C as well. Currently we have to
> >>> add
> >>> domain C to sssd.conf to allow users from domain C to access
> >>> services on
> >>> the client running sssd.
> >>>
> >>> But this will get cumbersome if domain C already trusts other
> >>> domains
> >>> like D and E and if the admin of domain E decides later on to
> >>> create a
> >>> new trust do domain F. Wouldn't is be nice if user and groups from
> >>> these
> >>> domains can be accessed by sssd without being configured
> >>> explicitly?
> >>>
> >>> Currently there is work in progress to solve
> >>> https://fedorahosted.org/sssd/ticket/364 . A winbind based
> >>> provider
> >>> would be able to enumerate and authenticate users and groups from
> >>> trusted AD domains, but as mentioned earlier a request for a user
> >>> from
> >>> domain F (user at F) will be rejected by the nss responder, because
> >>> it is
> >>> not configured explicitly and so sssd does not know anything about
> >>> domain F.
> >>>
> >>> So it would be nice if sssd can handle the domains C, D, E and F
> >>> as
> >>> sub-domains of the configured domain A without an explicit
> >>> configuration.
> >>>
> >>> To solve this we might need to implement a new method to the
> >>> providers
> >>> to return the names of the domains the backend can handle. Then
> >>> the
> >>> frontends (pam and nss) can query the backends for the list of
> >>> supported
> >>> domains and can decided which backend shall handle the request.
> >>>
> >> Let's assume that we do this. We have to consider how to handle
> >> configuration for these subdomains now.
> >>
> >> I see two options.
> >> 1) All subdomains inherit any other settings in the sssd.conf from
> >> the
> >> primary SSSD domain.
> >> 2) Back-ends need an interface to create new confdb entries on the
> >> fly.
> >>
> >> I also see two different possibilities for how to handle dynamic
> >> creation of subdomains in the system.
> >> 1) The first time we see a domain that we don't currently
> >> recognize, we
> >> query each SSSD domain for whether it's supported by that backend.
> >> Pros: Minimal effort on the backend side
> >> Cons: Potential for great waste if a misconfigured client starts
> >> hammering the SSSD with requests for an unknown domain (can be
> >> mitigated
> >> by extending the negative cache with domain wildcards)
> >>
> >> 2) Alternately, we could create an interface in the responders that
> >> the
> >> backends would signal if a new domain became available or
> >> disappeared.
> >> Pros: the responders would always have a definitive list from the
> >> back-ends and would not need to query it. Very fast.
> >> Cons: More work for the back-end to identify if and when a new
> >> domain
> >> has become available. Some back-ends may not be able to identify
> >> this
> >> information without directly querying for a domain name.
> >>
> >> Related to 2), I don't think we can necessarily assume that the
> >> backend
> >> MUST have a complete list of the domains that it can handle (i.e.
> >> it
> >> might not maintain a list; it could just try the domain and see if
> >> it
> >> works). So we probably need to take approach 1) here.
> >>
> >>> If you have different ideas about how to handle sub-domains or can
> >>> think
> >>> of different use-cases other then the Active Directory one
> >>> mentioned
> >>> above, please let me know. I would like to collect the ideas and
> >>> write
> >>> up a design for sub-domains based on your input.
> >>>
> >>> Thank you very much for your help.
> > To mitigate one we could have a mark that tells us which backends
> > actually do understand the concept of subdomains. The classic ldap
> > backend and the proxy one would probably not. This woulc cut
> > unnecessary
> > roundtrips (with double switching context and messages going back
> > and
> > forth).
> >
> > Also I think we should provide for active filtering of subdomain,
> > both
> > and negative. Ie, if we know domain X has 2 subdomains we are
> > interested
> > in and we do not want, in any case to allow the backend to handle
> > any
> > other domain we should be able to set that list in the configuration
> > in
> > the form of a filter. Same if we want to blacklist just one
> > subdomain
> > but let the backend find out if there are new ones.
> >
> > A syntax may be something like this:
> > DEfault subdomain filter = +*
> > 1. positive filtering: subdomain filter = +FOO +BAR -*
> > 2. negative filtering: subdomain filter = -FOO -'FOO-BAR' +*
> >
> > quotes may be necessary if domain names use -/+ in the name which is
> > possible with some non-DNS names (REALM names, NETBIOS names, etc..)
> >
> > Simo.
> >
> For filter you can use '!' to denote exclusion. I do not think any
> name
> can contain a '!'.
> 
> So filter
> filter = FOO BAR !*
> will restrict to only two domains
> while
> filter = !FOO !BAR *
> to all domains except FOO and BAR
> 
> But IMO each back end that is marked as the one that supports trusted
> domains should refresh the list of the subdomains by querying the
> server
> asynchronously every half an hour (by default). This means that any
> new
> domain info would be available within half an hour of the moment the
> trust was established. These are rare operations usually done during
> the
> maintenance windows so there is no harm in the delay (should be
> fetched
> on restart).
> The question is does it get just the ones trusted by the server
> connected to back end or the query would follow the whole tree?

Constant refreshing could become very soon very expensive if you have many
clients and a slow link between them and some of these domains.
We need to just do that on demand, polling is way too onerous.

Simo.

-- 
Simo Sorce * Red Hat, Inc. * New York



More information about the sssd-devel mailing list