Re: {KERBEROS} userPasswords

[Paul M Fleming <pfleming@siumed.edu>]

I agree. While SASL is an excellent idea adoption has been slow in the
Windows application arena and unfortunately most of the the client
applications used in environments like ours are Windows based. The
{KERBEROS} user password attribute also allows for selective storing of
passwords in different places -- we have some accounts that actually
have a {SHA} password in the directory but most of our users come from
Kerberos it allows for a good mix and allows an easy SASL/Strong
Authentication migration path.



Allan Streib wrote:
> 
> 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