[SSSD] sssd and sub-domains

Jan Zelený jzeleny at redhat.com
Tue May 24 08:18:47 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.

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.

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.

Thanks
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/61207e06/attachment.sig>


More information about the sssd-devel mailing list