[SSSD] sssd and sub-domains

Jan Zelený jzeleny at redhat.com
Tue May 24 13:02:31 UTC 2011


> On 05/24/2011 04:18 AM, Jan Zelený wrote:
> >> ----- 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.
> > 
> > I'm no expert on this matter, but isn't there a way to store information
> > about all trusted domains (including those trusted "transitively") on
> > the primary server, for example somewhere in LDAP? Here I assume that
> > cross-domain trust will only be available when using IPA and AD and they
> > both have LDAP as a part of the server. That way we wouldn't have to
> > worry about slow link between clients and some trusted domains.
> 
> That would work if the server would keep the whole tree of the domains.

Yes, that was basically what I meant.

> Say the server is the IPA and there is a new trust just established with
> an AD domain.
> But AD domain has complex trust relationships with other AD domains, A,
> B and C.
> So if the IPA domain resolves all this complexity behind the AD domain
> and stores in the LDAP it would be able to serve the clients quickly.
> However then the question comes when and how frequently the server needs
> to rebuild and refresh the list.
> 
> I wonder how MSFT solves this problem.
> 
> > Also I have another question: what will be the approach when two domains
> > will offer the same subdomain but one of them will have it as "direct
> > trust" and the second as "transitive trust"? Here I have to admit that I
> > don't know how will auth of these trusted users work - whether their KDC
> > will be queried by SSSD directly or via primary domain KDC. If the
> > trusted user's KDC will be queried directly, please ignore this
> > question.
> 
> I do not know but it seems that whichever relation is listed first would
> be used to communicate to the domain.
> Both paths should work in general case so IMO it is just a question of
> the ordering.

Yes, both paths should work, I was just wondering if (and how) it is possible 
to evaluate which one is better (for example better connectivity). But this 
applies only in case SSSD will ask the primary domain server which will then 
ask the trusted domain and so on. As I wrote before, if SSSD asks directly the 
trusted KDC, my question is pointless and can be ignored.


Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110524/b4319b81/attachment.sig>


More information about the sssd-devel mailing list