Greetings, I'm testing an installation of openldap 2.4.9. I want to enforce TLS for all access to the directory. My problem is that I cannot get the client to meet the ssf restictions I have in place. The documentation I've seen on ssf and tls_ssf is very sparse so I don't really understand what it does. I'm using self signed cert created using the openssl CA.sh script. Relevant portions of the slapd.conf... TLSCACertificateFile /etc/ldap/ssl/cacert.pem TLSCertificateFile /etc/ldap/ssl/servercrt.pem TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem ... access to * by tls_ssf=128 ssf=128 anonymous auth by tls_ssf=128 ssf=128 self write Relevant portions of the lapd.conf... TLS_CACERT /etc/ldap/ssl/cacert.pem With those ACLs in place I get the following error: $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b "uid=jake,ou=people,dc=example,dc=com" ldap_bind: Invalid credentials (49) And slapd in debug mode shows me that I didn't meet the ssf requirments... connection_read(15): unable to get TLS client DN, error=49 id=0 conn=0 fd=15 TLS established tls_ssf=32 ssf=32 ... <= check a_authz.sai_tls_ssf: ACL 128 > OP 32

Openssl 0.9.8g-4ubuntu3.3 Thanks, -Jake On Wed, Jul 30, 2008 at 12:02 PM, Buchan Milne <bgmilne(a)staff.telkomsa.net&gt; wrote: On Wednesday 30 July 2008 15:59:52 J Davis wrote: > Greetings, > > I'm testing an installation of openldap 2.4.9. I want to enforce TLS for > all access to the directory. > My problem is that I cannot get the client to meet the ssf restictions I > have in place. The documentation I've seen on ssf and tls_ssf is very > sparse so I don't really understand what it does. > > I'm using self signed cert created using the openssl CA.sh script. > > Relevant portions of the slapd.conf... > > TLSCACertificateFile /etc/ldap/ssl/cacert.pem > TLSCertificateFile /etc/ldap/ssl/servercrt.pem > TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem > ... > access to * > by tls_ssf=128 ssf=128 anonymous auth > by tls_ssf=128 ssf=128 self write > > Relevant portions of the lapd.conf... > > TLS_CACERT /etc/ldap/ssl/cacert.pem > > With those ACLs in place I get the following error: > > $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b > "uid=jake,ou=people,dc=example,dc=com" > ldap_bind: Invalid credentials (49) > > And slapd in debug mode shows me that I didn't meet the ssf > requirments... > > connection_read(15): unable to get TLS client DN, error=49 id=0 > conn=0 fd=15 TLS established tls_ssf=32 ssf=32 > ... > <= check a_authz.sai_tls_ssf: ACL 128 > OP 32 What ssl implementation is your slapd using ?

Hello On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com&gt; wrote: > Greetings, > > I'm testing an installation of openldap 2.4.9. I want to enforce TLS for > all access to the directory. > My problem is that I cannot get the client to meet the ssf restictions I > have in place. The documentation I've seen on ssf and tls_ssf is very sparse > so I don't really understand what it does. > > I'm using self signed cert created using the openssl CA.sh script. > > Relevant portions of the slapd.conf... > > TLSCACertificateFile /etc/ldap/ssl/cacert.pem > TLSCertificateFile /etc/ldap/ssl/servercrt.pem > TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem > ... > access to * > by tls_ssf=128 ssf=128 anonymous auth > by tls_ssf=128 ssf=128 self write > > Relevant portions of the lapd.conf... > > TLS_CACERT /etc/ldap/ssl/cacert.pem > > With those ACLs in place I get the following error: > > $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b > "uid=jake,ou=people,dc=example,dc=com" > ldap_bind: Invalid credentials (49) > You may want to try adding -q as one of the options to your ldapsearch. It appears that the tls_ssf turns on STARTTLS, instead of LDAP over SSL and in order to use that, you need to tell the client to use starttls as well, which is what (if I read the man page correctly), -q does. Have fun. -- Personal Mail from Patrick Patterson No company affiliation

Patrick Patterson writes: >On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com&gt; wrote: Pet peeve: While it doesn't help your problem, you should in addition to this: >> access to * >> by tls_ssf=128 ssf=128 anonymous auth >> by tls_ssf=128 ssf=128 self write use something like 'security simple_bind=128 update_ssf=128'. This gives the result code confidentialityRequired instead of invalidCredentials when the ssf is insufficient. Thus users who did not use TLS don't get the impression that they just sent the wrong password - and maybe then send the unprotected password again