Jan-Piet Mens

On May 17th "I posted a bug":https://bugzilla.mozilla.org/show_bug.cgi?id=294457 in Mozilla's bugzilla trouble ticket system, regarding X.509 certificates which aren't retrieved via LDAP on a connection which requires credentials. This has been biting me quite a bit and I've finally found a solution.

h2. Background

I offer limited LDAP directory services to clients who connect over SSL. The service is limited in as much as the number and types of attributes which are returned to the clients are limited as well as the number of entries. To this effect, an "OpenLDAP":http://www.openldap.org proxy server with a back-ldap backend fronts the connections from the Internet as proxies them in to an internal directory server (also _OpenLDAP_).

h2. The proxy

The configuration of the proxy is quite simple and well documented in slapd-ldap. Here is my configuration:

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/custom.schema

pidfile         /var/run/slapd.pid
argsfile        /var/run/slapd.args

loglevel 256

allow bind_v2
TLSCACertificateFile /usr/local/etc/openldap/chain.pem
TLSCertificateFile /usr/local/etc/openldap/pub.crt
TLSCertificateKeyFile /usr/local/etc/openldap/priv.key

TLSVerifyClient   never

database        ldap
uri             "ldap://in1.example.com/ ldap://in2.example.com/"
suffixmassage   "ou=People,o=EXT"  "ou=People,dc=example,dc=com"
suffix          "ou=People,o=EXT"
map             attribute "display-name" "displayname"
map             attribute uid           *
map             attribute cn            *
map             attribute sn            *
map             attribute givenname     *
map             attribute mail          *
map             attribute telephonenumber *
map             attribute usercertificate;binary *
map             attribute *
map             objectclass person      *
map             objectclass inetorgperson       *
map             objectclass *
lastmod         off

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

access to attrs=userpassword
        by anonymous auth

# Allow anon access to the usercertificate. The attrs= must
# contain the entry!

access to dn.children="ou=People,o=EXT"
        attrs=entry,objectclass,usercertificate;binary
        by anonymous read
        by users read
        by * none

access to *
        by users read
        by anonymous auth

h2. The Queries

When an authenticated client performs an LDAP search, all works well. This can be tested with the _ldapsearch_ utility (do remember to use -H ldaps://hostname) or by configuring Mozilla _Thunderbird_ appropriately and setting credentials for the bind (DN of the user and password).

Upon performing address-book queries, _Thunderbird_ contacts the server, binds as the user and does it search. Upon composing a new message in _Thunderbird_, the logs on the LDAP proxy show the request:

conn=43 op=0 BIND dn="cn=smith,ou=people,o=ext" method=128
conn=43 op=0 RESULT tag=97 err=0 text=
conn=43 op=0 BIND dn="cn=smith,ou=people,o=ext" mech=SIMPLE ssf=0
conn=43 op=0 RESULT tag=97 err=0 text=
conn=43 op=1 SRCH base="ou=people,o=ext" scope=2 deref=0 filter="(|(cn=smith*)(mail=smith*)(sn=smith*))"
conn=43 op=1 SRCH attr=cn mail
conn=43 op=1 SEARCH RESULT tag=101 err=0 nentries=2 text=

Iff the user now chooses to encrypt that message, upon hitting the Security button in the compose window, _Thunderbird_ tries to fetch the userCertificate for that address. Notice how the LDAP server logs an anonymous bind!

conn=57 op=0 BIND dn="" method=128
conn=57 op=0 RESULT tag=97 err=0 text=
conn=57 op=1 SRCH base="ou=people,o=ext" scope=2 deref=0 filter="(mail=smith@example.com)"
conn=57 op=1 SRCH attr=usercertificate;binary
conn=57 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=57 op=2 UNBIND
conn=57 fd=10 closed

In order for this anonymous bind to get through, I've added an ACL to the proxy configuration as seen above; this allows the proxy to return the binary userCertificate to the client.

Voila!