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 -- Jorge Armando Medina Computación Gráfica de México Web: www.e-compugraf.com Tel: 55 51 40 72 email: jmedina@e-compugraf.com GPG Key: 1024D/28E40632 2007-07-26 GPG Fingerprint: 59E2 0C7C F128 B550 B3A6 D3AF C574 8422 28E4 0632
Attachment:
signature.asc
Description: This is a digitally signed message part.