[SSSD-users] Unable to get ldap_tls_reqcert to work

[Jeff White]

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

[Jakub Hrozek]

Post by Jeff White
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)
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@

[Jeff White]

LDAP is working fine. I can query no problems with ldapsearch search,
sssd just won't accept the exact same certificate.

--
Jeff White
HPC Systems Engineer
Information Technology Services - WSU

Post by Jakub Hrozek

Post by Jeff White
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)
_______________________________________________

_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leav

[Jakub Hrozek]

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.
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email

[Jeff White]

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.

--
Jeff White
HPC Systems Engineer
Information Technology Services - WSU

Post by Jakub Hrozek

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.
ldap_referrals = false
to the domain section, please.
_______________________________________________

_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-lea

[Jakub Hrozek]

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
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email to sssd-u

[Michael Ströder]

Post by Jakub Hrozek
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
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.

[Lukas Slebodnik]

LDAP is working fine. I can query no problems with ldapsearch search, sssd
just won't accept the exact same certificate.

Which command did you use for testing ldapsearch?
What is a content of ldap.conf?

LS
_______________________________________________
sssd-users mailing list -- sssd-***@lists.fedorahosted.org
To unsubscribe send an email t

[Dan Corrigan]

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

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
_______________________________________________
rg

[Jeff White]

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.
--
Jeff White
HPC Systems Engineer
Information Technology Services - WSU

Post by Dan Corrigan
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

Post by Jeff White
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
_______________________________________________

_______________________________________________