* Howard Chu (hyc@highlandsun.com) wrote: > In those cases, it would probably be best to create a client cert for the > apps in question and just skip the password issue altogether. Back in > OpenLDAP 2.0 beta, before we started working with SASL, I added a hack to do > exactly this - when receiving a Simple Bind over SSL, if no bind password was > provided, and a valid client cert was provided whose DN matched the Bind DN, > we allowed the authentication. (This hack is no longer present now that > SASL/EXTERNAL exists, but I believe it may still be useful in situations like > these.) We also required client cert usage in general, which made the issue > of leaking a password in the clear a moot point. Just a note to those of you using the Debian packages: SASL/EXTERNAL using client certs is not currently supported in the Debian slapd packages in Debian/unstable (as of 2.1.21-2). This is because we are using GNUTLS in place of OpenSSL due to licenseing issues with OpenSSL and no one has written the code to handle using client certs for authentication. If anyone has experience in this area and would like to work on adding support for this we'd be more than willing to accept patches. We're also looking at doing this ourselves but unfortunately it's somewhat involved due to having to decode the X509 cert, parse the DN and compare it against the LDAP DN (as I recall). Thanks, Stephen
Attachment:
pgpSMQE7E5dRU.pgp
Description: PGP signature