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(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...