Reputation: 9504
I am trying to deploy an MVC3 application that requires Windows Authentication (specifically Kerberos) as an Application within an older asp.net Anonymous Authentication Website.
In IIS 7.5 Express on my box it works perfect, obviously. When I deploy it to IIS 7.5 as its own site I get challenged for domain credentials, though none are accepted. When I deploy it as an application I get the custom error page back from the hosting site. To confirm - Kerbtray shows no ticket in either scenario.
Both the Site and the new child Apps run on the same application pool, and the application pool runs as AppPoolIdentity. That built-in IIS app pool account (IIS AppPool\MyAppPoolName
) has full Read/Execute permissions down both the Site's and the App's folder trees. No impersonation is used.
If not, any advice on things/places to look would be great - the ApplicationHost.config
and the app's web.config
files look fine.
EDIT: For clarification, this is all on a corporate network that uses Kerberos extensively for other purposes. "Site" refers to an IIS Website and is distinguished from an "Application" that must be hosted within an IIS Site.
Upvotes: 2
Views: 1723
Reputation: 9504
After working on this a bit more, I found the answer:
Nothing special is needed to host a Windows (Kerberos) authenticated IIS App within an Anonymous authenticated IIS Site on IIS 7.5 so long as:
a. Kernel Mode Authentication is On - No SPNs required. b. The application uses the same App Pool Identity as the hosting parent. Different App Pools and their identities can be used, but this does require further NTFS permissions and is beyond the scope of this particular issue.
The issue with my error was something much more simple yet elusive... the parent Site had a custom set of error pages defined in <HttpErrors>
including pages for 401 and 403.
This was the error page returned when the user requested a page from the nested Application because Kerberos sends a 401 first, to challenge the user for credentials and ask/him her to get and provide a Kerberos ticket... but because the parent Site returned a 200 response (the custom error page) the user never got a Kerberos ticket.
With these off, the user is now appropriately getting a Kerberos ticket and falls back to NTLM as by default.
Upvotes: 2