Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers
-
Upload
ldapcon -
Category
Technology
-
view
503 -
download
3
description
Transcript of Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers
![Page 1: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/1.jpg)
Bridging the gap Adding missing client (security) features using OpenLDAP proxy servers
Mark Pröhl & Michael Weiser
![Page 2: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/2.jpg)
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)
![Page 3: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/3.jpg)
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)
![Page 4: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/4.jpg)
(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
![Page 5: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/5.jpg)
(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
![Page 6: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/6.jpg)
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
![Page 7: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/7.jpg)
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
![Page 8: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/8.jpg)
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
![Page 9: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/9.jpg)
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
![Page 10: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/10.jpg)
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
![Page 11: Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers](https://reader035.fdocuments.net/reader035/viewer/2022080209/546c2d86b4af9f752c8b4f2a/html5/thumbnails/11.jpg)
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