RE: {KERBEROS} userPasswords

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

Ok.... Are the web interfaces SSL-protected already? If not, I guess any
further thought in this direction is moot.

I'll guess that your apps don't use HTTP authentication, but you instead
have a special login form and then send a cookie back to the browser that is
used on subsequent accesses.

OK, your apps are performing simple binds and there's nothing you can do to
change that. I suggest setting up a "proxy" slapd on the same machines that
run your applications. If the apps support ldapi, use that for connecting
otherwise configure them to use localhost.

On the proxy, set up a back-shell backend to handle the incoming binds.
The back-shell "bind" script will have to do an ldapsearch to retrieve an
attribute of the provided DN, to extract the Kerberos username. This
transaction can be encrypted or not, depending on whether you think
usernames are sensitive data. Certainly they are not as sensitive as
passwords.

Then the script does a kinit to verify the password, and a kdestroy when
done. Assuming your web sessions themselves are encrypted, then your users'
passwords never traverse any network in the clear.

Of course, this solution might be slower than what you currently do, but you
can slap it together (no pun intended) immediately, without needing to
install anything new. A slightly faster way to go would be using back-perl
and the Net::LDAPapi module and a Kerberos module for perl (maybe Kclient).
Both of these approaches allow your current apps to continue working, but
will not expose your users' Kerberos passwords, and won't rely on slapd to
handle the {KERBEROS} userpassword scheme internally.

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

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

> The two I'm thinking of specifically are web interfaces

> On Jun 15 at 7:03pm, Howard Chu wrote:
>
> > I guess I'm missing a piece of the picture. How do your users reach and
> > activate these applications in the first place? Generally an app must
> > operate within some other environment, and these apps don't need to know
> > anything about Kerberos as long as some other piece of the
> environment can
> > authenticate the users.
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support
> >
> > > -----Original Message-----
> > > From: Frank Swasey [mailto:Frank.Swasey@uvm.edu]
> > > Sent: Saturday, June 15, 2002 7:23 AM
> > > To: Howard Chu
> > > Cc: Kurt D. Zeilenga; Turbo Fredriksson;
> openldap-software@OpenLDAP.org
> > > Subject: 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 ===
> >
>
> --
> 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 ===