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@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.