Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation
--On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller heller@deepsoft.com wrote:
OK, I have narrowed things down to slapd and sssd not playing nice with each other. slapd is able to listen on ldaps (port 636) and accept SSL connections (eg from openssl s_client and other applications using straight SSL). slapd will also listen on ldap (port 389), but refuses to negotiate a TLS connection on port 389. It also refuses to negotiate TLS connection on port 636. sssd seems to *insist* on negotiating a TLS connection on port 636 or port 389 and won't just connect using ssl to port 636. (At least that is what I *think* is going on.)
So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL.
You're using a bit of a confusing word soup.
ldaps == Deprecated, non-standard way of securing connection to LDAP. Usually on port 636 startTLS == RFC standard way of securing connections to LDAP. Usually on port 389
If you are using ldaps, then you want startTLS to be disabled if you are using startTLS, then you want it enabled.
Your SSD config has:
ldap_id_use_start_tls = false
so this would be correct with use with ldaps:///
You don't provide any error messages or other useful information, so one can only specualte what issues you may be having.
I would note that most versions of openssl s_client do not support startTLS with LDAP (Thus you cannot use it to test port 389). That feature was only recently added to OpenSSL.
If you want to test startTLS on port 389, your best bet is to use an ldap client utility such as ldapwhoami, like:
ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
At Thu, 28 Sep 2017 10:19:43 -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller heller@deepsoft.com wrote:
OK, I have narrowed things down to slapd and sssd not playing nice with each other. slapd is able to listen on ldaps (port 636) and accept SSL connections (eg from openssl s_client and other applications using straight SSL). slapd will also listen on ldap (port 389), but refuses to negotiate a TLS connection on port 389. It also refuses to negotiate TLS connection on port 636. sssd seems to *insist* on negotiating a TLS connection on port 636 or port 389 and won't just connect using ssl to port 636. (At least that is what I *think* is going on.)
So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL.
You're using a bit of a confusing word soup.
Well, yes...
ldaps == Deprecated, non-standard way of securing connection to LDAP. Usually on port 636 startTLS == RFC standard way of securing connections to LDAP. Usually on port 389
If you are using ldaps, then you want startTLS to be disabled if you are using startTLS, then you want it enabled.
Your SSD config has:
ldap_id_use_start_tls = false
so this would be correct with use with ldaps:///
But SSSD does not work with ldaps:///... It *wants* startTLS over ldap:///, which does not *seem* to work.
You don't provide any error messages or other useful information, so one can only specualte what issues you may be having.
Slapd is reporting TLS Negotiation failure when SSSD tries to connect to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess something is wrong with slapd's TLS configuration -- it is failing to do TLS Negotiation, either it is just not doing it or it is doing it wrong (somehow). Unless SSSD is not configured properly.
I would note that most versions of openssl s_client do not support startTLS with LDAP (Thus you cannot use it to test port 389). That feature was only recently added to OpenSSL.
If you want to test startTLS on port 389, your best bet is to use an ldap client utility such as ldapwhoami, like:
ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Robert Heller heller@deepsoft.com writes:
R> At Thu, 28 Sep 2017 10:19:43 -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller heller@deepsoft.com wrote:
OK, I have narrowed things down to slapd and sssd not playing nice with each other. slapd is able to listen on ldaps (port 636) and accept SSL connections (eg from openssl s_client and other applications using straight SSL). slapd will also listen on ldap (port 389), but refuses to negotiate a TLS connection on port 389. It also refuses to negotiate TLS connection on port 636. sssd seems to *insist* on negotiating a TLS connection on port 636 or port 389 and won't just connect using ssl to port 636. (At least that is what I *think* is going on.)
So, I either need to get slapd to do TLS negotiation on port 389 OR port 636, or get sssd to NOT do TLS negotiation on port 636 and just connect with SSL.
You're using a bit of a confusing word soup.
Well, yes...
ldaps == Deprecated, non-standard way of securing connection to LDAP. Usually on port 636 startTLS == RFC standard way of securing connections to LDAP. Usually on port 389
If you are using ldaps, then you want startTLS to be disabled if you are using startTLS, then you want it enabled.
Your SSD config has:
ldap_id_use_start_tls = false
so this would be correct with use with ldaps:///
But SSSD does not work with ldaps:///... It *wants* startTLS over ldap:///, which does not *seem* to work.
You don't provide any error messages or other useful information, so one can only specualte what issues you may be having.
Slapd is reporting TLS Negotiation failure when SSSD tries to connect to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess something is wrong with slapd's TLS configuration -- it is failing to do TLS Negotiation, either it is just not doing it or it is doing it wrong (somehow). Unless SSSD is not configured properly.
I would note that most versions of openssl s_client do not support startTLS with LDAP (Thus you cannot use it to test port 389). That feature was only recently added to OpenSSL.
OK, back to basics, 1. check whether sssd is compiled with openssl's libcrypto: ldd sssd which should present something like libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 2. check whether slapd has been build with openssl ldd slapd, which should present: libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 3. verify your certificates: openssl verify -CAfile <file> <hostcert> 4. run slapd -h ldaps:///; than test connection: openssl s_client -connect host:636 -CAfile <file>
-Dieter
If you want to test startTLS on port 389, your best bet is to use an ldap client utility such as ldapwhoami, like:
ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
[...]
At Fri, 29 Sep 2017 19:52:05 +0200 =?UTF-8?Q?Michael_Str=c3=b6der?= michael@stroeder.com wrote:
Robert Heller wrote:
But SSSD does not work with ldaps:///...
This is simply not true.
Maybe it is better to say SSSD does not seem to be woring for me with ldaps:///...
Ciao, Michael.
Robert Heller wrote:
At Fri, 29 Sep 2017 19:52:05 +0200 =?UTF-8?Q?Michael_Str=c3=b6der?= michael@stroeder.com wrote:
Robert Heller wrote:
But SSSD does not work with ldaps:///...
This is simply not true.
Maybe it is better to say SSSD does not seem to be woring for me with ldaps:///...
As Quanah pointed out this has to do with the signature algorithm used in your server certs. You should better fix that root cause.
Ciao, Michael.
openldap-technical@openldap.org
-
Dieter Kluenter -
Michael Ströder -
Quanah Gibson-Mount -
Robert Heller