I think creating a new AD site and setting 'ad_site' in /etc/sssd/sssd.conf is reasonable. Hopefully, initial build can work and then this is an optimization.

Does sssd cache something to assist in sssd restart? For example, preferred servers associated with this new site? Or the AD DC it last spoke to? So that on restart, it doesn't have to scour DNS SRV records and see which ones are open, so that it can discover it's in this new site and the preferred servers for this new site?

From looking at the sssd-ad man page, I think there's an entire sssd feature I'm not understanding. Which might be useful here.

SERVICE DISCOVERY
The service discovery feature allows back ends to automatically find the appropriate servers to connect to using a special
DNS query. This feature is not supported for backup servers.

Configuration
If no servers are specified, the back end automatically uses service discovery to try to find a server. Optionally, the user
may choose to use both fixed server addresses and service discovery by inserting a special keyword, “_srv_”, in the list of
servers. The order of preference is maintained. This feature is useful if, for example, the user prefers to use service
discovery whenever possible, and fall back to a specific server when no servers can be discovered using DNS.

The domain name
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.

For these restricted (firewalled-off) network segments, i'd like sssd to attempt to discover AD DCs for this site and then fall back to maybe a couple of hard-coded DCs.

As far as using a new adcli, the adcli version in RHEL7 is 0.8.1-13.el7.x86_64 and the adcli version on RHEL8 is 0.8.2-3.el8.x86_64. So I don't think we'll see acli 0.9.0 until RHEL9 -- circa 2025?

Spike

On Mon, May 11, 2020 at 9:27 AM Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:

On Mon, 2020-05-11 at 09:19 -0500, Spike White wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

All,

sssd migration has been working very well for us -- except in the DMZs and heavily-restricted firewalled network segments.

For those network segments, the AD site is the same as the equivalent corporate location. So the typical DNS SRV record lookup reports a wealth of AD controllers -- most of which are blocked. (not LDAPS traffic allowed).

A couple of AD DCs are in the DMZ, etc.

The old commercial product appears to CLDAP ping every single AD controller it finds (via DNS SRV lookup). And when one responds, it queries that DC to get site, preferred DCs, etc. So the commercial product work, even in the face of most AD DCs blocked.

adcli join and sssd appears to CLDAP ping only 4-5 AD DCs. If they don't get a response back, you get an error. If it's lucky enough to CLDAP ping an unblocked AD DC -- life is good, otherwise not so much.

Old adcli, use 0.9.0

_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org