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 ...
Dumb clients


The world still is full of dumb legacy clients
– may even expect specific directory structure
→ not subjec...
(Start)TLS-wrapping proxy





Introduce proxy inbetween dumb client and actual
LDAP server that uses (Start)TLS toward...
(Start)TLS-wrapping proxy


Even retains the client's bind identity



But not all directories support (Start)TLS



e....
SASL/GSSAPI-wrapping proxy




OpenLDAP's ldap backend can use SASL binds
towards the backend servers
Using SASL/GSSAPI ...
SASL/GSSAPI-wrapping proxy


Client can only bind anonymously
– access restrictions have to be implemented some
other way...
SASL/GSSAPI-wrapping proxy ext.


Can be extended with local auth store
– either by adding a separate suffix with local
b...
SASL/GSSAPI-wrapping proxy ext.


Still : bind identity is lost and all users are able to
do what the GSSAPI backend bind...
What others are doing


Various commerical AD-integration solutions
provide LDAP proxies that do „full service‟:

2.) acq...
What others are doing


Various commerical AD-integration solutions
provide LDAP proxies that
– convert frontend simple b...
Thanks!
Mark Pröhl & Michael Weiser
info@science-computing.de
Upcoming SlideShare
Loading in …5
×

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

1,047 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,047
On SlideShare
0
From Embeds
0
Number of Embeds
50
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Bridging the gap Adding missing client (security) features using OpenLDAP proxy servers Mark Pröhl & Michael Weiser
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Thanks! Mark Pröhl & Michael Weiser info@science-computing.de

×