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)