Sometimes having fortune at your side can really save you the day (to say the least), and in developer support it can save you hours (of not days) of troubleshooting... With this premise, a couple of weeks ago I was helping a colleague from the Sql Server support team whom was struggling with an authentication problem one of his customers was having with Reporting Services: basically IIS was prompting them to login to access the application, but even entering the correct credentials those were refused, and after three strikes they were redirected to the standard 401 (unauthorized) page.
While waiting for some logs I requested to the customer, I was building a repro for another customer I had at the same time (with a completely different problem, that was a weird runtime exception I'll likely write about in another post), and one of the requisites was to have the application pool running under a domain account instead of the default NETWORK SERVICE: well... I got the same problem reported by the first customer! It worth mentioning that I was also using Integrated Authentication for the virtual directory, and interestingly, the problem disappeared if I was using a local account for the application pool.
To kill two birds with one stone, I opened WFETCH to understand what was going wrong.
First fact: if you are running with a local account, you'll use NTLM and not Kerberos, and NTLM was working fine.
Second fact: using WFETCH to access the same URL (with the app pool running as domain account) returned 0x80090322 (The target principal name is incorrect.): “Unable to InitializeSecurityContext”
The error means that the account used to run the process does not have permission to log-in as a service; in my repro I found a domain policy was setting that value, and the customer told me they had the same. So, to resolve the problem I run the following command:
cscript C:\inetpub\AdminScripts\adsutil.vbs set w3svc/NtAuthenticationProviders "NTLM" (you may also want to have a look at this KB)
Note that this will prevent you from using delegation (which is possible only using Kerberos), but the customer didn't need it so he was happy with this solution and the story stopped here...
Carlo
Your post just saved me a ton of grief! I was preparing a monster request to our IT group to get a service principal name, a new DNS alias, etc., as in http://msdn2.microsoft.com/en-us/library/ms998297.aspx, until I saw your post and realized I don't need delegation for my app. Thanks!