[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: OpenLDAP 2.1 Released

> -----Original Message-----
> From: Frank Swasey [mailto:Frank.Swasey@uvm.edu]

> Today at 10:08am, Kurt D. Zeilenga wrote:
> > {KERBEROS} is a OpenLDAPism.  I would be fine with removing
> > support for both...

> Before you remove something that people are using, shouldn't you provide
> a working replacement?

First we had to know that people actually are using this. I guess we do now.

> Please provide information on how to allow a stupid application that
> only does a simple bind against the ldap server to have that
> password/userid validated against my kerberos server (by the ldap
> server) and I'll gladly support you getting rid of {KERBEROS}.  However,
> that ability is the primary reason I chose OpenLDAP over both iPlanet
> and IBM's Secureway.  Neither of those products can do what OpenLDAP
> does right out of the box simply because of the {KERBEROS} construct.

This depends on the degree of control you have on those "stupid
applications". If you have the ability to replace the libraries they're
linked with, then we can easily change things transparently, through the
existing ldap_bind() APIs. In case you're skeptical, you might like to know
that in the OpenLDAP libldap library, ldap_simple_bind() has just been a
front-end to SASL bind since mid-1999.

For example, we could preserve the existing ldap_simple_bind signature, but
use a separate config setting (e.g. from ldap.conf) that says to really
perform SASL bind instead. Then in the bind arguments (ld, dn, passwd) the
dn would be used as the SASL authcid. (This is just a suggestion, would work
fine for SASL DIGEST-MD5.)

In the case of Kerberos/GSSAPI the dn and passwd arguments are irrelevant,
since SASL (actually GSSAPI) will use the name carried in your TGT, and uses
the TGT to get an ldap service ticket, so you don't have to pass in a valid
dn or passwd at all.

If your apps are dynamically linked, they could be migrated with just the
installation of one new library and the addition of one config keyword to a
system config file, with no other client-side changes needed. On the slapd
server, you would have to set up a mapping rule to map Kerberos names back
to user DNs. In your case that would be pretty easy to set up, since you
already have the corresponding usernames embedded in the userPassword

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