Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have .htaccess on our site

AuthType Kerberos
AuthName "Internet ID"

require valid-user

order deny,allow
deny from all
allow from all

On a sub directory of the site, we have an .htaccess:

AuthType none
Satisfy any 

The reason is that on this subdirectory/ we have a different authentication mechanism and do not want to use kerberos as authentication. The problem though is that in chrome the .htaccess authentication still pops up but firefox, opera, IE do not prompt for this authentication before loading the page.

I am having trouble understanding how a server side configuration could be presented to the end user differently depending on the browser? Is there something in my subdirectry .htaccess that I am missing ?

share|improve this question
up vote 5 down vote accepted

I just reproduced this. Chrome is requesting /favicon.ico and gets a HTTP/1.1 401 Authorization Required. Other browsers ignore it. Chrome presents a auth dialog box. Try adding this to your .htaccess on your site

<Files "favicon.ico">
    AuthType none
    Satisfy any

Here is the bug... ...pretty bad.

share|improve this answer
Thanks for finding this. I have not tested yet but you appear to have hit the nail right on the head. Many many many thanks. – Chris Sep 17 '10 at 18:45
This does not seem to resolve the issue. Any suggestions ? – Chris Sep 20 '10 at 17:59
You could look in your apache logs to make sure it isn't still 401'ing favicon.ico. – Mark Wagner Sep 20 '10 at 20:20
This solution works IF and ONLY IF you place that in the root directories .htaccess. I have this in /subdirectory/.htacces and it was not working but when I placed it in /.htaccess it worked great. – Chris Sep 22 '10 at 18:56

When using chrome, you have to pass arguments to it on the command line to get www-negotiate to work. Specifically, you have to whitelist the hostname(s) (FQDN(s)) of the kerberos-enable webserver(s). From :

google-chrome --auth-server-whitelist="*,*,*baz"

If you want force only gssapi and not use basic auth:

google-chrome --auth-schemes="negotiate"

See the above link for more info.

share|improve this answer
I cannot accept a solution that requires specific client side operation. – Chris Oct 13 '10 at 23:56

At a guess, the most likely reason is that Chrome does not support Kerberos, or does not support it in the same way as the other three browsers do. Likely all users are being authenticated, the server is still requiring authentication (not doing what you think it is exactly) - but the browsers that support kerberos are doing it transparently.

I'd say set apache to log usernames in the access log, and see if the hits from the other browsers are being allowed in by username or not... and go from there.

share|improve this answer
This is not regarding kerberos and kerberos is not a client side application. Additionally, we want to override kerberos authentication in subdirectory. The subdriectory is where the authentication is being presented in chrome and it is not supposed to. If you press escape or cancel it goes away and you can continue without authenticating but I do not understand why it appears at all only in chrome. – Chris Sep 17 '10 at 17:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.