I'm attempting to enable LDAP server TLS certificate validation with "ldap_tls_reqcert = demand". However, when I set that value to anything other than "never", sssd does not work. By that I mean sssd will start as normal but no ID lookups are successful and I see "Input/output error" in the log. This occurs regardless of what CA certificate chain I give it (via ldap_tls_cacert). I have even tried using a known working chain that I use to access yum repos which uses TLS certificates from the same CA as our Active Directory.
Any ideas?
libsss_sudo-1.14.0-43.el7_3.11.x86_64 libsss_autofs-1.14.0-43.el7_3.11.x86_64 sssd-proxy-1.14.0-43.el7_3.11.x86_64 sssd-ad-1.14.0-43.el7_3.11.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 libsss_nss_idmap-1.14.0-43.el7_3.11.x86_64 sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 sssd-ldap-1.14.0-43.el7_3.11.x86_64 libsss_idmap-1.14.0-43.el7_3.11.x86_64 python-sssdconfig-1.14.0-43.el7_3.11.noarch sssd-client-1.14.0-43.el7_3.11.x86_64 sssd-common-pac-1.14.0-43.el7_3.11.x86_64 sssd-krb5-1.14.0-43.el7_3.11.x86_64 sssd-ipa-1.14.0-43.el7_3.11.x86_64 sssd-common-1.14.0-43.el7_3.11.x86_64
On Mon, Oct 02, 2017 at 11:01:14AM -0700, Jeff White wrote:
I'm attempting to enable LDAP server TLS certificate validation with "ldap_tls_reqcert = demand". However, when I set that value to anything other than "never", sssd does not work. By that I mean sssd will start as normal but no ID lookups are successful and I see "Input/output error" in the log. This occurs regardless of what CA certificate chain I give it (via ldap_tls_cacert). I have even tried using a known working chain that I use to access yum repos which uses TLS certificates from the same CA as our Active Directory.
Any ideas?
I usually find it easiest to debug TLS issues with ldapsearch -ZZZ (just make sure to set up the right environment variables to point to the same certs as sssd is using)
LDAP is working fine. I can query no problems with ldapsearch search, sssd just won't accept the exact same certificate.
On Mon, Oct 02, 2017 at 11:39:05AM -0700, Jeff White wrote:
LDAP is working fine. I can query no problems with ldapsearch search, sssd just won't accept the exact same certificate.
Sorry, I should have read the logs before replying.
Try adding: ldap_referrals = false to the domain section, please.
That seems to fix the issue. I'm not sure why, but it does. I guess the LDAP server could refer to another server or domain by a name not included in the cert? Even with logging turned way up I could not find any entry that said that though. I may be stuck with using this and other kludge in sssd.conf since it doesn't appear to log what actually happened to cause the failure.
On Mon, Oct 02, 2017 at 07:14:53PM +0000, Jeff White wrote:
That seems to fix the issue. I'm not sure why, but it does. I guess the LDAP server could refer to another server or domain by a name not included in the cert? Even with logging turned way up I could not find any entry that said that though. I may be stuck with using this and other kludge in sssd.conf since it doesn't appear to log what actually happened to cause the failure.
AD uses referrals quite aggressively and at the same time, the referral handling in openldap is not super-fast. I don't know exactly why the referrals would cause a TLS failure, I suspect some of the servers an entry referred to were simply not reachable from your client.
btw disabling referrals is also suggested in our upstream documentation: https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html
Jakub Hrozek wrote:
AD uses referrals quite aggressively and at the same time, the referral handling in openldap is not super-fast. I don't know exactly why the referrals would cause a TLS failure, I suspect some of the servers an entry referred to were simply not reachable from your client.
btw disabling referrals is also suggested in our upstream documentation: https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html
Yes, in general client-side chasing of LDAPv3 referrals does not make sense. AFAICS the referrals returned by MS AD are of no use for sssd.
Wouldn't pointing SSSD to global catalog port make more sense? Depending on the client-side attribute mapping this might need tweaking of the attribute set replicated to global catalog though.
Ciao, Michael.
In my experiences, TLS failures are almost always due to a small handful of problems. Two that come to mind immediately are 1. Common name matching. Check the common name for the cert and make sure your requests are going to that name. 2. Not including certs. Make sure you are including all certs needed to validate your server's SSL endpoint. Make sure you are pointing to the correct directory that includes these certs i.e. ldap_tls_cacertdir Dan On Mon, 2017-10-02 at 11:01 -0700, Jeff White wrote:
I'm attempting to enable LDAP server TLS certificate validation with "ldap_tls_reqcert = demand". However, when I set that value to anything other than "never", sssd does not work. By that I mean sssd will start as normal but no ID lookups are successful and I see "Input/output error" in the log. This occurs regardless of what CA certificate chain I give it (via ldap_tls_cacert). I have even tried using a known working chain that I use to access yum repos which uses TLS certificates from the same CA as our Active Directory.
Any ideas?
libsss_sudo-1.14.0-43.el7_3.11.x86_64 libsss_autofs-1.14.0-43.el7_3.11.x86_64 sssd-proxy-1.14.0-43.el7_3.11.x86_64 sssd-ad-1.14.0-43.el7_3.11.x86_64 sssd-1.14.0-43.el7_3.11.x86_64 libsss_nss_idmap-1.14.0-43.el7_3.11.x86_64 sssd-krb5-common-1.14.0-43.el7_3.11.x86_64 sssd-ldap-1.14.0-43.el7_3.11.x86_64 libsss_idmap-1.14.0-43.el7_3.11.x86_64 python-sssdconfig-1.14.0-43.el7_3.11.noarch sssd-client-1.14.0-43.el7_3.11.x86_64 sssd-common-pac-1.14.0-43.el7_3.11.x86_64 sssd-krb5-1.14.0-43.el7_3.11.x86_64 sssd-ipa-1.14.0-43.el7_3.11.x86_64 sssd-common-1.14.0-43.el7_3.11.x86_64
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.o rg
The common name is correct and the exact same CA chain works with yum on a server signed by the same CA our Active Directory servers are signed with. So we know the CA chain file includes everything it needs.
sssd-users@lists.fedorahosted.org
-
Dan Corrigan -
Jakub Hrozek -
Jeff White -
Lukas Slebodnik -
Michael Ströder