Oops, I accepted this message from the moderation queue before checking there is already a
duplicate on the list..anyway, the previous thread is
On 13 Jan 2016, at 00:59, Eric Aiken
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
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.
P Respectons ensemble l'environnement. N'imprimez ce message que si nécessaire.
Let's respect the environment together. Only print this message if necessary.
sssd-users mailing list