[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Mapping userPassword to Kerberos 5
I'm not a user of the Debian packages (use custom Redhat rpms) -- but my
two cents.
--enable-kpasswd is a viable option in some environments. We don't allow
users to directly bind to LDAP BUT we have some commercial applications
that don't understand Kerberos directly but DO understand LDAP + SSL/TLS
for authentication. Technically, this isn't a truly "kerberos" solution
but we've decided that single signon is more important -- in our case we
can control which apps / networks the App -> LDAP -> Kerberos
authentication takes place. It isn't a perfect solution - I'd love to
have all my apps speak native kerberos or gssapi but that's just not
reality when you're trying to integrate a heterogeneous multi
application environment.
Stephen Frost wrote:
>
> * Benjamin Krein (superbenk@superk.org) wrote:
> > I've been working through the docs at www.bayour.com and have run into a
> > snag due to the fact they are so dated and still work with Kerberos 4 as
> > well as 5 (I'm working with 5 only). In his doc, he states that you can
> > make the users in LDAP force authentication with the KDC by using the
> > following for the attribute userPassword:
> >
> > userPassword: {KERBEROS}principal@REALM
> >
> > However, from the little bit I know and have been reading, this seems to
> > be a feature of OpenLDAP compiled with Kerberos 4 (please correct me if
> > I'm wrong). Is there another way to do this? I ask because even though
> > I've defined userPassword as above and all other tests outlined within
> > the www.bayour.com docs work with my configuration (binding tests), it
> > still doesn't work.
> >
> > I'm using Debian 3 sid with OpenLDAP 2.1.22, Kerberos 5, libsas2-gssapi
> > package 2.1.12, SASL 2.1.15.
>
> I've already talked to Ben about this on IRC but I'll paste my feelings
> here too.
>
> The Debian packages are no longer compiled with --enable-kpasswd which
> is necessary for the {KERBEROS} stuff. They are compiled with
> --enable-spasswd which means you should be able to use {SASL} instead
> (I've not tested this yet and would like to see it tested).
>
> For everyone reading through Turbo's docs and attempting to do that
> stuff *please* make sure to read the "Why SASL?" part near the end. In
> it he points out that a *MUCH* better approach is to use Kerberized
> binaries to begin with and to *not* pass the authentication through
> LDAP. There's really no good reason to do it and it pretty much defeats
> Kerberos. If you have applications and you want to use Kerberos I
> strongly encourage you to look for Kerberized (or SASL'd) versions of
> those applications. If you can't find those but there are PAM versions
> then you might use pam_krb5. It also defeats Kerberos by allowing the
> user to pass a password plaintext but at least it doesn't do it again
> when talking to slapd and it avoids the extra hop through LDAP.
>
> I'd love to get some feedback from people on this, perhaps there are
> other cases where authentication through LDAP to Kerberos makes some
> sense. Or perhaps there are other problems with pam_krb5 I've not run
> into. If there's enough demand for the Debian packages to be compiled
> with --enable-kpasswd we may be willing to do this in the future.
>
> Thanks,
>
> Stephen
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature