I wrote up a design page for ticket #2486:
For your convenience, the text is also copied inline. I think the most
important part of implementing the feature is actually to work a bit
with the user who requested the feature to make sure they are not
actually tripping over authentication of users from trusted AD domains.
= Fix DNS site a client is using =
=== Problem statement ===
Even though the Active Directory provider is able to leverage DNS sites,
the site discovery is always automatic. There is now way to `pin` a
particular client into a particular site. This design document describes
a way to do so.
=== Use cases ===
The site discovery relies on client being part of subnet. It is not
always practical or even possible to assign Linux machines to the right
subnet. Still, these clients should be able to leverage the nearest AD
site, even at the expense of manual configuration in `sssd.conf`.
=== Overview of the solution ===
The SSSD will gain a new AD provider option that would, if AD sites are
enabled, override any dynamically discovered sites. This option would pin
the client to a particular site not only for primary domain but also for
subdomains. The discovery search would only be used to find the forest
we are enrolled with.
For Global Catalog service discovery of the primary and secondary
domains would then be defined as follows:
* primary domain - `$HARDCODED_SITE._sites.$FOREST`
* backup domain - `$FOREST`
For pure LDAP searches, the domains would then be defined as:
* primary domain - `$HARDCODED_SITE._sites.$DOMAIN`
* backup domain - `$DOMAIN`
Above, $FOREST is auto-discovered and $DOMAIN is either the SSSD domain name
as defined in the config file (for the main SSSD domain) or autodiscovered
from object of class `trustedDomain`.
In both cases, the full DNS search consists of `_$service._$port.$domain`.
Especially for trusted domains, the overriden search domain might not
return anything, but the DNS resolver code is built such that it iterates
over search domains until the search yields some result.
=== Authentication against trusted domains ===
For trusted domains, we currently always talk to a local DC which
gives libkrb5 a referral to a trusted-domain specific DC that handles
authentication against a KDC from the trusted domain. This process is
completely opaque to SSSD, which means that Kerberos authentication doesn't
take the sites into account at all.
=== Implementation details ===
The SSSD AD provider would gain a new option called `ad_site_override`.
This option would be unset by default.
The SRV initialization function `ad_srv_plugin_ctx_init()` needs to be
adjusted to accept a site override as a `const char *site_override`
since the site name is just a string. In the default case, where the
option is unset, this option would be set to NULL. In any case, the
`ad_get_client_site_send()/recv()` request would run to completion since we
need to learn the forest name anyway. If the new option is set, then the
caller of `ad_get_client_site_recv()` would still read the forest value,
but ignore the site value and use the value of the `ad_site_override`
=== Configuration changes ===
A new option `ad_site_override` as described above. The option would be
both described in man pages and implemented in the configAPI.
=== How To Test ===
The best testing would be performed using an AD test environment consisting
of at least two servers in the same domain. To test, join both DCs to the
same domain. Create two sites such that the IP address of your SSSD client
would set you in one of them.
Make sure that, by default, SSSD creates the kdcinfo file using the DC in the
autodetected site and authenticates you against the DCs from the autodetected
site. The latter can be verified using i.e. tcpdump and krb5_child log files.
Set the `ad_site_override` option to a non-default site. Verify, using
tcpdump, kdcinfo file contents and SSSD debug logs that SSSD redirects
communication to DCs in the non-default site.
=== Authors ===
* Jakub Hrozek <jhrozek(a)redhat.com>