Bridging the gap: Adding missing client (security) features using OpenLDAP proxy servers
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 458 views

 

Statistics

Views

Total Views
458
Views on SlideShare
426
Embed Views
32

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 32

http://lanyrd.com 32

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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 Client (dumb) 389/ldap/StartTLS 636/ldaps SASL 2 o=org
  • 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
  • (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
  • (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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Thanks! Mark Pröhl & Michael Weiser info@science-computing.de