[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Kerberos/GSSAPI issues
Brian Candler <B.Candler@pobox.com> writes:
> Config 3
> --------
> olcSaslRealm: WS.NSRC.ORG
> krb5.conf default realm: FOO.NSRC.ORG
> result: auth fails!
> # ldapsearch
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Key table entry not found)
> Now this seems odd; presumably slapd is only trying to use a keytab entry of
> ldap/noc.ws.nsrc.org@FOO.NSRC.ORG (which doesn't exist)
> My understanding is that modern kerberos apps should just try all keys in
> the keytab until they find one which decrypts the ticket.
> http://mailman.mit.edu/pipermail/kerberos/2010-December/016797.html
Cyrus SASL doesn't. This is a long-standing bug in Cyrus SASL that we
patch locally at Stanford. (It's a simple one-line patch.) It really
needs to be fixed upstream in Cyrus SASL.
> But in any case, shouldn't it use olcSaslRealm in preference to the
> krb5.conf default realm? (I'd expect the default realm to be used if
> olcSaslRealm were empty though)
I don't believe there's any way to pass that information down into Cyrus
SASL, so there isn't anything OpenLDAP can do. Cyrus SASL forces using
the hostname unless you patch it to not be stupid.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>