Re: {KERBEROS} userPasswords

[Allan Streib <astreib@indiana.edu>]

Frank Swasey <Frank.Swasey@uvm.edu> writes:

> If I'm going to all that trouble, I might just as well write
> something that accepts a simple bind and does a kerberos password check
> because the attribute the applications have is the kerberos userid....
> At this time, they also don't use LDAP for anything else :(

I'd like to weigh in with my vote to preserve the {KERBEROS}
userPassword notation.  We've spent considerable effort here trying to
get people away from maintaining local passwords if Kerberos is an
option.  Unfortunately, we've found that a *lot* of LDAP clients only do
simple authentication.  Rather than store credentials in the directory
for those, we've been able to use {KERBEROS} to transparently pass the
authentication through to Kerberos.  We've so far been able to mandate
use of SSL/TLS for that, fortunately.

I don't know about the others on this list, but I've found that the
number of clients that can actually *do* SASL/GSSAPI authentication is
small.  Outside of the OpenLDAP command-line utilities, I've only seen
it work with perl-ldap and the Authen::SASL::GSSAPI module from
http://www.sxw.org.uk/computing/software/.  Our enterprise application
folks (Java) were not able to get it working, although they thought it
would be easier with the Java 1.4 release.  We also have started
accessing the directory from Oracle PL/SQL functions using Oracle's
DBMS_LDAP API.  This is very convenient for application development
since it wraps LDAP (which is new to our developers and therefore viewed
with fear and suspicion) in Oracle PL/SQL functions (which are
comfortable old friends).  Unfortunately DBMS-LDAP will only do simple
binds unless you buy the Oracle Advanced Security option, which is
*very* expensive.

I agree that SASL/GSSAPI is the way to go when clients can do it, but to
keep me out of the business of managing and securing passwords,
{KERBEROS} is clearly something I'd like to see stay.

Allan