Richard A Nelson <[EMAIL PROTECTED]> writes: > Here is a fragment of what I was attempting to accomplish: > AuthType Basic > AuthName "w3" > AuthBasicProvider ldap file > AuthUserFile /etc/apache2/htpasswd > AuthzLDAPAuthoritative off > AuthLDAPURL ldapi:///ou=bluepages,o=ibm.com?mail?sub? > AuthType Kerberos > KrbAuthRealms COBPLI.SVL.IBM.COM SVLDEV.SVL.IBM.COM > KrbAuthoritative off > KrbDelegateBasic on > Krb5Keytab /etc/apache2/apache.keytab > require valid-user > > So, the goal was to first do KRB, and if that failed, drop back to > LDAP, and if that failed, check the htpasswd file. > > All that worked fine until I added Kerberos (LDAP falling back to file). > > No, if KRB auth works, everything is fine, but KRB failures are *not* > being delegated to lower levels: > [error] [client 9.30.102.134] Specified realm `us.ibm.com' not allowed by > configuration
I'm afraid that you're probably running into a fundamental limitation in the HTTP protocol here. I don't think it's possible to do what you want. The problem is that HTTP doesn't have a full-fledged SASL implementation with multiple retries of mech negotiation. It only does essentially one round of negotiation. When the browser connects and asks for a page, mod_auth_kerb sends a Negotiate-Auth challenge asking whether it can do SPNEGO. If the browser can, it starts an SPNEGO exchange; if it can't, it does Basic authentication. The problem with your situation is that the browser *can* do SPNEGO and *does* have Kerberos tickets, so at the initial challenge, it selects the SPNEGO route since to the best of its knowledge that's correct. It then does an SPNEGO->GSSAPI->Kerberos v5 authentication, and then the server rejects it at the point when that negotiation is complete due to a bad realm. What you're asking for is to make the browser fall back to password at that point, but there isn't any way, so far as I know, to do that in the HTTP protocol. You only get one shot at picking an authentication mechanism, you didn't pick Basic, so now either the one you picked works or you lose. It's yet another problem caused by the fact that HTTP was designed as a stateless protocol and therefore implements all stateful things such as proper authentication very poorly. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
