RE: Mapping userPassword to Kerberos 5

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Frank Swasey

> Today at 9:55am, Paul M Fleming wrote:
> > --enable-kpasswd is a viable option in some environments.
> We don't allow
> > users to directly bind to LDAP BUT we have some commercial
> applications
> > that don't understand Kerberos directly but DO understand
> LDAP + SSL/TLS
> > for authentication.
>
> This is pretty much the same boat I'm in.  I have the added
> requirement
> to allow people (users) to directly bind to LDAP, but I require they
> have an SSL connection to do so (yes, I'm aware that they can try and
> send their password in the clear across the net even though
> it won't be
> successful).

In those cases, it would probably be best to create a client cert for the
apps in question and just skip the password issue altogether. Back in
OpenLDAP 2.0 beta, before we started working with SASL, I added a hack to do
exactly this - when receiving a Simple Bind over SSL, if no bind password was
provided, and a valid client cert was provided whose DN matched the Bind DN,
we allowed the authentication. (This hack is no longer present now that
SASL/EXTERNAL exists, but I believe it may still be useful in situations like
these.) We also required client cert usage in general, which made the issue
of leaking a password in the clear a moot point.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support