Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers

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


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


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


simple binduid=user,o=org

secret

389/ldapsimple bind


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/ldapsimple bind

« anonymous »


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/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/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


1.) determine user's Kerberos principal:389/ldap, SASL/GSSAPI, proxy@ORG

→ user@ORG


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]

Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers

Technology

Transcript of Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers