[Date Prev][Date Next]
RE: OpenLDAP 2.1 Released
On Jun 14 at 6:54pm, Howard Chu wrote:
> 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.
No control. These applications do not know Kerberos, cannot
authenticate their end users via Kerberos. Our path has been to allow
them (in a secured network) to do their stupid stuff of "authenticating"
against the ldap server. Unbeknownst to the application, the password
is really being validated by our Kerberos server.
We have yelled and screamed that these applications are stupid, but
the people in charge keep purchasing them because it's too expensive to
move to something that is secure. (No, I don't personally believe that,
it's just the party line.)
> 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.)
What I need is for the simple bind that is performed by the proprietary
application that I have no control over and am not allowed to muck with
its libraries to be able to do what it thinks is a simple bind to the
ldap server and have it translated at the ldap server into a kerberos
authentication -- or some method of intercepting the bind and performing
the kerberos calls via a "man in the middle" setup.
Frank Swasey | http://www.uvm.edu/~fcs
Systems Programmer | Always remember: You are UNIQUE,
University of Vermont | just like everyone else.
=== God Bless Us All ===