Problem solved. I finally decided to compare the module list side-by-side and there actually was one missing. It turns out that there are two Windows Authentication modules:
On the server, the managed WindowsAuthentication module was there, but not the native WindowsAuthenticationModule highlighted above. Why it was configured that way is anyone's guess, but apparently if the native module is not loaded, the managed module will cheerfully load and silently fail.
So for any future readers who encounter this problem, make sure you have both modules loaded, because IIS will not warn you if one of them is missing.
First, I would confirm that this is occurring from a client where IE shows that the site is in the Trusted Sites zone, and the Trusted Sites zone is configured for "Automatic logon with current username and password."
Next, I would suspect the http authorization header size may exceed the IIS limits. Integrated Kerberos authorization is quite susceptible to this issue due to the IIS limits are actually quite low, and it does not require that many group memberships to bloat the token over the limit.
Each and every request includes the user's Kerberos token in the http authorization header. Because the token is encoded, it is frequently much larger than the actual memory used.
You can increase the values using the following document:
Http.sys registry settings for Windows
http://support.microsoft.com/kb/820129
I would use the following values:
MaxRequestBytes - set to 1048576
MaxFieldLength - set to 65534
Another useful utility DelegConfig. You can drop this in as an application on any web site, and connect to get a nice useful report on how your Kerberos authentication is configured. This would need to be tested as the victim account (or a suitably configured test account taht is exhibiting the symptom in the victim's domain).
http://blogs.iis.net/brian-murphy-booth/archive/2007/03/09/delegconfig-delegation-configuration-reporting-tool.aspx
You may also need to review:
How to use SPNs when you configure Web applications that are hosted on Internet Information Services
http://support.microsoft.com/kb/929650
Specifically:
"In Active Directory, verify that the Account is sensitive and cannot be delegated check box is cleared for users who access the application."
"Verify that all computers that are part of the Kerberos process have consistent name resolution and are connected by Kerberos trust. For example, verify that the computers that are involved in the Kerberos process are in the same forest or are part of a cross-forest Kerberos trust."
"Verify that the token size does not exceed the value that is set for the MaxTokenSize property." (MaxTokenSize should be set to 65535).
Internet Explorer 6 cannot use the Kerberos authentication protocol to connect to a Web site that uses a non-standard port
http://support.microsoft.com/kb/908209
There are also some excellent tips in the following article.
https://blogs.msdn.com/b/friis/archive/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iis-ie.aspx
In particular, checking that the client is connect to the expected SPN, using NetMon or KerbSpy.
Best Answer
It's unclear why your "wwwroot" folder is shared with Windows File and Print Sharing (the service that is allowing you to access the server's hard disk drive with the UNC path
\\servername\wwwroot). It doesn't need to be shared with Windows File Print Sharing for IIS to server an application out of that directory.If the server is something that predates you then there may be some reason in the past and you should probably go digging for documentation.
If you want to live dangerously, remove the "Sharing" from the "wwwroot" folder. An easy way to do that is to right-click the folder in Windows Explorer, go to the "Sharing" tab, and disable sharing. (Depending on whether you left UAC enabled you may have to elevate.)