Hi,
I wrote up a design page for ticket #2486: https://fedorahosted.org/sssd/wiki/DesignDocs/ActiveDirectoryFixedDNSSite
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 =
Related ticket(s): * https://fedorahosted.org/sssd/ticket/2486
=== 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` option instead.
=== 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@redhat.com
sssd-devel@lists.fedorahosted.org