one.beat.consumer
one.beat.consumer

Reputation: 9504

Kerberos authenticated MVC App inside an anonmyous access Site

Goal

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.

Symptoms

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.

Details

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.

Question(s)

  1. Is there anything special I need to do to get NTLM and Kerberos working on an App inside an anonymous auth Site?

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

Answers (1)

one.beat.consumer
one.beat.consumer

Reputation: 9504

After working on this a bit more, I found the answer:

  1. 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

Related Questions