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=DATAPREV,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) ldap_create ldap_url_parse_ext(ldap://server-Lenny:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-Lenny:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.82.0.234:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x9d73280 msgid 1 wait4msg ld 0x9d73280 msgid 1 (infinite timeout) wait4msg continue ld 0x9d73280 msgid 1 all 1 ** ld 0x9d73280 Connections: * host: www-mmldap port: 389 (default) refcnt: 2 status: Connected last used: Thu Jan 29 18:17:22 2009
** ld 0x9d73280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9d73280 request count 1 (abandoned 0) ** ld 0x9d73280 Response Queue: Empty ld 0x9d73280 response count 0 ldap_chkResponseList ld 0x9d73280 msgid 1 all 1 ldap_chkResponseList returns ld 0x9d73280 NULL ldap_int_select read1msg: ld 0x9d73280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x9d73280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x9d73280 0 new referrals read1msg: mark request completed, ld 0x9d73280 msgid 1 request done: ld 0x9d73280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Connect error (-11)
In the /var/log/syslog I have: Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 ACCEPT from IP=10.82.0.234:50441 (IP=0.0.0.0:389) Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 STARTTLS Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 RESULT oid= err=0 text= 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.
Anybody have a help for me?
Tanks!
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=DATAPREV,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
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.
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=DATAPREV,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
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
openldap-technical@openldap.org
-
Dieter Kluenter -
Jarbas Peixoto Júnior -
Jorge Armando Medina