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.
Is there an option in adcli join and the sssd startup to CLDAP ping all DCs? Like the commercial product's behaviour?
Obviously, I could hard-code the KDCs in /etc/krb5.conf. But there's multiple downsides to that: 1. AD team switches out DCs w/o notice. 2. Hard to programmatically script out for new builds, as the list of DCs would vary according to each firewalled-off segment.
Spike
... perhaps configure an AD site specifically for the DMZ contsining the reachable DCs and reference it in the SSSD config for those hosts ?
-- lawrence
On Mon, May 11, 2020, 10:20 AM Spike White spikewhitetx@gmail.com wrote:
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.
Is there an option in adcli join and the sssd startup to CLDAP ping all DCs? Like the commercial product's behaviour?
Obviously, I could hard-code the KDCs in /etc/krb5.conf. But there's multiple downsides to that:
- AD team switches out DCs w/o notice.
- Hard to programmatically script out for new builds, as the list of
DCs would vary according to each firewalled-off segment.
Spike _______________________________________________ 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.o...
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
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.o...
sssd-users@lists.fedorahosted.org