1. Bridging the gap
Adding missing client (security) features using OpenLDAP proxy servers
Mark Pröhl & Michael Weiser

2. Dumb clients

The world still is full of dumb legacy clients
– No SASL support / Support only simple binds
– No or weak TLS support
– Cannot be changed: closed source or unmaintained
in-house / external custom code
Client
(dumb)
389/ldap/StartTLS
636/ldaps
SASL
2
o=org

3. Dumb clients

The world still is full of dumb legacy clients
– may even expect specific directory structure
→ not subject of this talk → rwm

Especially in enterprise environments
– Notorious example: Oracle Software supports
strong TLS only with OAS which is 15kEUR per
CPU
Client
(dumb)
389/ldap/StartTLS
636/ldaps
SASL
3
o=org

4. (Start)TLS-wrapping proxy



Introduce proxy inbetween dumb client and actual
LDAP server that uses (Start)TLS towards the
backend
Straight-forward solution
Works remarkably OOB with OpenLDAP's ldap
backend
Client
(dumb)
389/ldap
simple bind
uid=user,o=org
secret
389/ldap/StartTLS
636/ldaps
simple bind
Proxy
uid=user,o=org o=org
secret
4

5. (Start)TLS-wrapping proxy

Even retains the client's bind identity

But not all directories support (Start)TLS

e.g.: Active Directory has SASL's GSSAPI-based
transport security enabled OOB which makes TLS
redundant
Client
(dumb)
389/ldap
simple bind
uid=user,o=org
secret
389/ldap/StartTLS
636/ldaps
simple bind
Proxy
uid=user,o=org o=org
secret
5

6. SASL/GSSAPI-wrapping proxy


OpenLDAP's ldap backend can use SASL binds
towards the backend servers
Using SASL/GSSAPI is just a matter of
– configuring the new auth mechanism and
– providing a ticket cache containing appropriate
Kerberos tickets
Client
(dumb)
389/ldap
simple bind
« anonymous »
Proxy
389/ldap
SASL/GSSAPI
proxy@ORG o=org
ldap/server
Kerberos ticket cache
6

7. SASL/GSSAPI-wrapping proxy

Client can only bind anonymously
– access restrictions have to be implemented some
other way (e.g. iptables owner rules for local
processes)

Client's bind identity is no longer retained
Client
(dumb)
389/ldap
simple bind
« anonymous »
Proxy
389/ldap
SASL/GSSAPI
proxy@ORG o=org
ldap/server
Kerberos ticket cache
7

8. SASL/GSSAPI-wrapping proxy ext.

Can be extended with local auth store
– either by adding a separate suffix with local
backend containing bind DNs
– or providing e.g. userPassword attributes to
existing backend DNs using translucent overlay
Client
(dumb)
389/ldap
simple bind
cn=pusr,
cn=pauth
proxysecret
389/ldap
SASL/GSSAPI
Proxy
proxy@ORG o=org
cn= ldap/server
pauth
8

9. SASL/GSSAPI-wrapping proxy ext.

Still : bind identity is lost and all users are able to
do what the GSSAPI backend bind user is
allowed to do → local ACLs
Client
(dumb)
389/ldap
simple bind
cn=pusr,
cn=pauth
proxysecret
389/ldap
SASL/GSSAPI
Proxy
proxy@ORG o=org
cn= ldap/server
pauth
9

10. What others are doing

Various commerical AD-integration solutions
provide LDAP proxies that do „full service‟:
2.) acquire tickets
user@ORG
Kerberos secret
1.) determine user's Kerberos principal:
KDC
389/ldap, SASL/GSSAPI, proxy@ORG
→ user@ORG
Client
(dumb)
389/ldap
simple bind
uid=user,o=org
secret
Proxy
3.) 389/ldap
SASL/GSSAPI
user@ORG o=org
ldap/server
Kerberos ticket cache
10

11. What others are doing

Various commerical AD-integration solutions
provide LDAP proxies that
– convert frontend simple binds to SASL/GSSAPI
backend binds by
– looking up/constructing the Kerberos principal
corresponding to the bind DN,
– requesting a TGT with that principal and the bind
password and
– using this Kerberos ticket to access the backend
11

12. Thanks!
Mark Pröhl & Michael Weiser
info@science-computing.de