Hi, after updating to openldap-2.4.18, tls enabled sasl external mechanism seems to be disabled, but it is still enabled via ldapi://
:~> ldapwhoami -Y external -ZZ -H ldap://localhost SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7)
Is this a bug, or has something changed which I haven't noticed?
:~> ldapsearch -x -LLL -H ldap://localhost -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5
:~> ldapsearch -x -ZZ -LLL -H ldap://localhost -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN
:~> ldapsearch -x -LLL -H ldapi:/// -b "" -s base supportedSASLMechanisms dn: supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: EXTERNAL
-Dieter
On Mon, 28 Sep 2009, Dieter Kluenter wrote:
after updating to openldap-2.4.18, tls enabled sasl external mechanism seems to be disabled, but it is still enabled via ldapi://
...
Is this a bug, or has something changed which I haven't noticed?
Hard to say whether this is a change when you don't say what version you updated from...
The SASL EXTERNAL mechanism is only availible to ldap or ldaps connections if 1) the server requests a certificate (TLSVerifyClient option is set to something other than "never"), 2) the client provides a certificate (TLS_CERT and TLS_KEY settings are used), AND 3) the server can verify the client's cert (the cert is under a CA available to slapd via TLSCACertificateFile or TLSCACertificatePath and passes the various validity checks, etc)
Do those options all still look correct in your configs and are the CAs still where you expect? Did you switch from building against OpenSSL to GNUtls or make any other build-time configuration changes?
Philip Guenther
Philip Guenther guenther+ldapsoft@sendmail.com writes:
On Mon, 28 Sep 2009, Dieter Kluenter wrote:
after updating to openldap-2.4.18, tls enabled sasl external mechanism seems to be disabled, but it is still enabled via ldapi://
...
Is this a bug, or has something changed which I haven't noticed?
Hard to say whether this is a change when you don't say what version you updated from...
The SASL EXTERNAL mechanism is only availible to ldap or ldaps connections if
- the server requests a certificate (TLSVerifyClient option is set to something other than "never"),
- the client provides a certificate (TLS_CERT and TLS_KEY settings are used), AND
- the server can verify the client's cert (the cert is under a CA available to slapd via TLSCACertificateFile or TLSCACertificatePath and passes the various validity checks, etc)
Do those options all still look correct in your configs and are the CAs still where you expect? Did you switch from building against OpenSSL to GNUtls or make any other build-time configuration changes?
The update was from 2.4.17 to 2.4.18 build with openssl.
,----[ ldaprc ] | BASE o=avci,c=de | TLS_CACERT /home/dieter/certs/avciCA.pem | TLS_CERT /home/dieter/certs/dkluenter.pem | TLS_KEY /home/dieter/certs/dkluenter-key.pem | TLS_CIPHER_SUITE HIGH | TLS_REQCERT demand `----
,----[ cn=config.ldif ] | olcTLSCACertificateFile: /etc/openldap/certs/avciCA.pem | olcTLSCertificateFile: /etc/openldap/certs/magenta.pem | olcTLSCertificateKeyFile: /etc/openldap/certs/magenta-key.pem | olcTLSCipherSuite: HIGH:MEDIUM | olcTLSVerifyClient: demand `----
-Dieter
Dieter Kluenter wrote:
The update was from 2.4.17 to 2.4.18 build with openssl.
,----[ ldaprc ] | BASE o=avci,c=de | TLS_CACERT /home/dieter/certs/avciCA.pem | TLS_CERT /home/dieter/certs/dkluenter.pem | TLS_KEY /home/dieter/certs/dkluenter-key.pem | TLS_CIPHER_SUITE HIGH | TLS_REQCERT demand `----
,----[ cn=config.ldif ] | olcTLSCACertificateFile: /etc/openldap/certs/avciCA.pem | olcTLSCertificateFile: /etc/openldap/certs/magenta.pem | olcTLSCertificateKeyFile: /etc/openldap/certs/magenta-key.pem | olcTLSCipherSuite: HIGH:MEDIUM | olcTLSVerifyClient: demand `----
Still works for me. Have your certificates expired?
Howard Chu hyc@symas.com writes:
Dieter Kluenter wrote:
The update was from 2.4.17 to 2.4.18 build with openssl.
[...]
Still works for me. Have your certificates expired?
No,
openssl x509 -in dkluenter.pem -text | grep -A3 Validity Validity Not Before: Oct 8 09:13:35 2008 GMT Not After : Oct 6 09:13:35 2018 GMT Subject: C=DE, O=AVCI, OU=Partner, CN=Dieter Kluenter
This is rather strange, the error happens on my laptop, I just ran ldapwhoami on my x64 server, same configuration, same openldap version, with no problems. I think I have to dig into this matter.
-Dieter
"Dieter Kluenter" dieter@dkluenter.de writes:
Howard Chu hyc@symas.com writes:
Dieter Kluenter wrote:
The update was from 2.4.17 to 2.4.18 build with openssl.
[...]
Still works for me. Have your certificates expired?
[...]
This is rather strange, the error happens on my laptop, I just ran ldapwhoami on my x64 server, same configuration, same openldap version, with no problems. I think I have to dig into this matter.
Found the culprit. For some unknown reason the openldap package update modified the init script to run slapd with flag -f /path/to/slapd.conf instead of -F, and slapd.conf indeed contained the line 'TLSVerfiyClient never'. Sorry for the noise.
-Dieter
openldap-software@openldap.org
-
Dieter Kluenter -
Howard Chu -
Philip Guenther