[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Kerberos/GSSAPI issues

On Wed, Dec 29, 2010 at 10:21:28AM -0800, Russ Allbery wrote:
> > 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.

Have you got the one-line patch? Is there a ticket open for it upstream?

> > 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.

I don't mind SASL using the hostname (I'd expect olcSaslHost to take
preference, but haven't tested this (*)).  It bothers me a bit that it
ignores the olcSaslRealm and just picks the default realm instead.

What bothers me greatly is that when a client connects the Kerberos realm is
lost, and olcSaslRealm is being pasted in unconditionally for authorization. 
This to me seems like a huge security hole: superuser@FOREIGN.REALM is
currently treated the same as superuser@LOCAL.REALM in ACLs.

Regards,

Brian.

(*) But testing does suggest that clients canonicalise the hostname.  I have
pointed them to ldap.ws.nsrc.org, but they get a ticket for noc.ws.nsrc.org
(which is the name which the reverse DNS points to)