We have the most strange situation here when IE7 clients try to authenticate on an IIS6-based intranet application. I hope somebody can help me explain.
Our .asp application is running in domain "belgium.local". Integrated Windows authentication works fine for users in that domain. Users in domain "holland.local" however get a 401 error after a loooong timeout when trying to access the app. Their event logs show LsaSrv errors 40960 and 40961, which tells me it's a Kerberos-thing. There's a mutual trust between belgium.local and holland.local.
We've been troubleshooting in all directions and installed Firefox. Firefox showed us a login box, which told us it was failing over to Basic Authentication. That seemed right since it doesn't use Integrated Authentication until you tell it to. So we told it to use Kerberos by adding domain "belgium.local" to network.negotiate-auth.trusted-uris (which is about the same as enabling Integrated Windows authentication in IE7 and adding the site to my Local Intranet Zone. Cfr. http://grolmsnet.de/kerbtut/firefox.html for example.)
Now here's the odd part. After making this configuration change in Firefox, IE7 running on the same client computer will work too.
"Ah, but that's normal" I hear you say, "because the Kerberos ticket is still there and valid."
The strange thing is it will continue to work after I use Kerbtray to purge the tickets. My ticket for HTTP/app.belgium.local will show up again as soon as I visit the site with IE7. It is as if IE7 uses the Firefox configuration in some way to retrieve a ticket.
The really scary part is this: after I restore the Firefox configuration back to normal (e.g. delete all domains from the network.negotiate-auth.delegation-uris setting), IE7 will continue to work!? It is as if somehow I showed it how to get at ticket when I configured Firefox, and it "remembers" this now.
Can somebody tell me what is happening? I would like to get this to work without installing and removing Firefox on all my clients ;)