Bridging the gap Adding missing client (security) features using OpenLDAP proxy servers
Mark Pröhl & Michael Weiser
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
2
o=org
389/ldap/StartTLS636/ldaps
SASLClient(dumb)
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
3
o=org
389/ldap/StartTLS636/ldaps
SASLClient(dumb)
(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) o=org
Proxy
389/ldap/StartTLS636/ldaps
simple binduid=user,o=org
secret
389/ldapsimple bind
uid=user,o=orgsecret
4
(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) o=org
Proxy
389/ldap/StartTLS636/ldaps
simple binduid=user,o=org
secret
389/ldapsimple bind
uid=user,o=orgsecret
5
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) o=org
Proxy
389/ldapSASL/GSSAPIproxy@ORGldap/server
389/ldapsimple bind
« anonymous »
Kerberos ticket cache
6
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) o=org
Proxy
389/ldapSASL/GSSAPIproxy@ORGldap/server
389/ldapsimple bind
« anonymous »
Kerberos ticket cache
7
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) o=org
Proxy
389/ldapSASL/GSSAPIproxy@ORGldap/server
389/ldapsimple bind
cn=pusr,cn=pauth
proxysecretcn=
pauth
8
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) o=org
Proxy
389/ldapSASL/GSSAPIproxy@ORGldap/server
389/ldapsimple bind
cn=pusr,cn=pauth
proxysecretcn=
pauth
9
What others are doing
Various commerical AD-integration solutions provide LDAP proxies that do „full service‟:
Client(dumb) o=org
Proxy
3.) 389/ldapSASL/GSSAPI
user@ORGldap/server
389/ldapsimple bind
uid=user,o=orgsecret
1.) determine user's Kerberos principal:389/ldap, SASL/GSSAPI, proxy@ORG
→ user@ORG
Kerberos ticket cache
KerberosKDC
2.) acquire ticketsuser@ORGsecret
10
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
1111
Thanks!
Mark Pröhl & Michael [email protected]
Top Related