El Monday 02 February 2009 05:41:32 Jarbas Peixoto Júnior escribió:
Tanks Dieter,
You are right. Its libraries GnuTLS with not working very well. If I use OpenSSL works fine.
I found the following open bug in Debian:
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505191
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477396
I will wait for close this bug.
I think this is related to a Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/249881
I will extract some text "
Section 15.2.1.8 of the openldap admin guide states the following :
Note: The server must request a client certificate in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default TLSVerifyClient setting must be configured before SASL EXTERNAL authentication may be attempted, and the SASL EXTERNAL mechanism will only be offered to the client if a valid client certificate was received.
According to your slapd.conf file, you're using:
TLSVerifyClient try
which means that if your client doesn't send its certificate, the connection proceeds anyway. And thus the EXTERNAL mechanism will not be available.
Try setting TLSVerifyClient to demand, so that the connection won't proceed if the client doesn't send a certificate. That may be your actual problem."
They solved the problem with the correct configs.
best regards.
Tanks again!
2009/1/30 Dieter Kluenter dieter@dkluenter.de:
Jarbas Peixoto Júnior jarbas.junior@gmail.com writes:
I have two servers:
Server A: Debian Etch - Works Fine
Server B: Debian Lenny - Do not Works supportedSASLMechanisms
EXTERNAL
In Server A I have:
# ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Etch ) SASL/EXTERNAL authentication started SASL username: emailAddress=jarbas.peixoto@previdencia.gov.br,CN=jarbas.peixoto,OU=DATA PREV,O=Previdencia Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR SASL SSF: 0 filter: (objectclass=*) requesting: supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL
In Server B I have:
# ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Lenny:389/??base ) ldap_start_tls: Connect error (-11
# ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ -d 1 ldap_url_parse_ext(ldap://server-Lenny)
[...]
Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 closed (TLS negotiation failure)
This is very important for use openldap with user certificates.
This is most likely not an OpenLDAP issue but a Debian issue. Probably OpenSSL vs. GnuTLS. Check the linked libraries.
-Dieter
-- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html sip: +49.180.1555.7770535 GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E