Sub-Domains in SSSD

Currently SSSD assumes that each domain configured in sssd.conf represents exactly one domain in the backend. For example if only the domains DOM1 and DOM2 are configured in sssd.conf a request for a user for DOMX will return an error message and no backend is queried.

In an environment where different domains can trust each other and SSSD shall handle user from domains trusting each other every single domain must be configured in sssd.conf. Besides that this is cumbersome there is an additional issue with respect to group memberships. SSSD by design does not support group memberships between different configured domains, e.g. a user A from domain DOM1 cannot be a member of group G from domain DOM2.

It would be nice if SSSD can support trusted domains in the sense that

• only one domain has to be configured in sssd.conf and all trusted domains are available through SSSD
• a user can be a member of a group in a different trusted domain

To achieve this SSSD must support the concept of domains inside of a configured domain which we like to call sub-domain in the following. Instead of creating a list of know domains from the data in sssd.conf the PAM and NSS responder must query each backend for the names of the domains the backend can handle. If the backend does not support the new request the domain name from sssd.conf must be used as a fallback.

If a request for a simple user name (without @domain_name, i.e. no domain name is know) is received the first configured domain in sssd.conf and all its sub-domains is queried first before moving to the next configured domains and its sub-domains.

If a request with a fully qualified user name is received the backend handling this (sub-)domain is queried directly. If the requested domain is not know the configured domains are asked again for a list a supported domains with a

• force flag to indicate the the backed should try to updated the list of trusted domains unconditionally
• the name of the unknown domain which can be used as a hint in the backend to find the specific domain and see if it is a trusted domain (the backend may pass this hint on to a configured server and let the server do the work)

This process might take some but since it will only happen once for each unknown domain and there may be environment where it is only possible to find a trusted domain with the help of the domain name this is acceptable. Nevertheless, since a search for an unknown domain will lead to some amount of network activity and system load there should be some precaution implemented to avoid attacks based on random domain names (maybe blacklists and timeouts).

With these considerations three development tasks can be identified to add sub-domain support to SSSD

• new get_domains method: a new method to get the list of supported domains from the backend must be defined so that the responders and providers can use them
• add get_domains to providers: providers which can handled trusted domains, currently IPA and winbind, must implement the new method
• add get_domains to the responders: the responders must call get_domains to get a list of supported domains and use the configured domain name as a fallback (this might be split into two task, first call get_domains once at startup without force flag and name of searched domain; second call get_domains if domain cannot be found with force flag and name of searched domain)

The first task must be solved first but is only a minor effort. The other two must wait for the first but also require some more work.

For the first implementation it is sufficient that sub-domains work only if the user name is fully qualified and that the domain name has to be given in full and that short domain names are not supported. But it should be kept in mind user names in general are not fully qualified and that there are trust environments where short names are available to safe some typing for the users.