On Wed, Jan 13, 2016 at 12:02:56AM -0000, eric.aiken(a)capitalstream.com wrote:
I’ve been beating my head over this. After upgrading RHEL5 systems
to RHEL6, the kerberos/ldap services quit working correctly. I’ve resolved most of the
issues. I also embraced SSSD.
My remaining challenge is to disable the SSSD Discovery service. Authentication and
authorization works, it’s just DNS round-robins DC’s that are not reachable and this
ultimately causes failures (and latency)
In short I need to hard code who the client talks to. Inevitably I keep finding the
client doing a DNS lookup for domaindnszones.<domain>. Due to limitations in MS
windows DNS, This returns IP’s for DC’s in VLANs not accessible to certain subnets.
Round-Robin DNS with subnet masking doesn’t work for clients that are not AD CSE capable.
(eg AD client side extension). Even if I could get the net masking to work, I don’t
believe it would work for our IP space as the necessary netmask would need to be a class A
, thereby getting all the DC’s again.
For the record AD (and our IP subnets) are configured properly for sites and services.
I’ve tried lots of variations and configurations of:
dns_lookup_realm = false
dns_lookup_dc = false
I tried working with sssd-ad as it allows you to define ad_server and
ad_enable_dns_sites. Again the sssd discovery service continues to try and “control”
where to look.
From my research I’m not alone, there are others with similar challenges, but I’ve yet to
find someone with an “old-school” configuration.
Is there a way to tell sssd use “ these and only these” DC’s for Kerberos and LDAP on a
client? I’ll manage HA and load balancing.
Thanks for your thought and advise.
For AD, the recommended configuration is to use sssd-ad:
which required joining the client to domain. If you don't want to or
can't join the client to the domain, you can still use the old ldap
With the sssd-ad provider, I could see it performing DNS resolution with
the 'sudomains provider', but you can disable that one if needed
If you set the ldap_uri and krb5_server (not kdc as you had above..) all
queries should go to the hardcoded servers. If not, then we need to see