asp.netiiskerberosiis-10kerberos-delegation

ASP.NET : impersonation breaks on second website configured on same IIS server involving same "applications" & app pool identity

I have an intranet kerberos double-hop scenario configured for Client -> IIS -> SQL. It uses windows integrated authentication from end to end. It uses (unique) domain accounts for both IIS Application Pool Identity & SQL service accounts.

This setup has been working for ~10 years on Windows Server 2008 and was redone similarly on a new Windows Server 2022 / IIS and has been working there flawlessly for ~2 months both before and after these tests/actions.

At same time of this migration domain controllers were upgraded to Server 2022. The only required change of that migration was to move from unconstrained to constrained delegation. After that setup, this new IIS server has worked fine in it's "pre-production" status and tests same as the old iis server. But currently I'm trying to implement a Site 2 (test) for an improvement in cross environment access. The endgame is to eliminate this test and just implement this new approach in the site to be deployed.

For testing & simplicity, I'm re-using the "working" application pool identity for the secondary site frankly, because I know it's setup and configured correctly with spn's, etc.

The "Default Website" is and has remained stopped.

Site1 bindings (all working):

HostHeader is an alias address registered in dns that points to this IIS server.

I'm trying to create a second website in IIS (on the same server) that references a different root physical directory (1 level higher) than the working configuration & eliminate the binding to the IISNetBiosName:CustomPort and only use HostHeader on standard ports for access.

The "application" is actually the same physical directory/application in both Site 1 & Site 2. The point in this is to be able to access different environments from the same hostheader/binding/port.

Currently Site1 uses different custom ports to access different environments and it's a pain that I'm trying to eliminate before this server goes live.

Site2 bindings (none working):

HostHeader is an alias address registered in dns that points to this IIS server.

Although noted above, I just want to restate that ~/home in both Site1 (working) and Site2 (not working) are the same physical directory / application, Site2 just starts 1 level higher than Site1. Site1's root physical directory is actually the "Environment" level of Site2.

I've taken caution to not have both websites started at the same time while having duplicate bindings on each site. This is a pre-production environment anyways, so I have a lot of freedom to test/change at this time.

My issue is that this second site seems to refuse to delegate & impersonate the client user over to SQL. I get prompted for the users credentials, then error with the familiar NT AUTHORITY/ANONYMOUS rejection at the SQL server. When I stop site2 and start site1, everything resumes working. I've cleared the client's cache each time too in order to keep any cached content from loading.

Both sites have the following configured in IIS:

IIS => Authentication:

So far I've tried:

It sure feels like a configuration problem on the second site, but with there begin so much shared between the two, I've tried to list anything I'm aware of that might be different between the two sites.

Solution

  • I've found a workaround at least, if not solution.

    Given that Site 1 was setup and Kerberos delegation functional: Rather than trying to create an IIS Site 2 to the [new] physical path I wanted, I just modified Site 1's physical path and renamed it to what I was trying to achieve in Site 2 and updated the bindings of Site 1 to be the desired bindings I had in Site 2.

    After changing the physical root path of Site 1, I setup each environment level home application in their respective sub directory now within the Site 1 scope.

    This means that the same url that was failing when hosted by Site 2 would now be called again, but would be serviced by Site 1. This worked.

    But worth note: prior to trying the above, I completely removed the involved IIS SPN's, created new domain application pool accounts, new application pool, new SPN's & delegation settings only to find that the same exact symptoms existed where Site 1 worked and Site 2 did not (for delegation).

    As it pertains to the root question, I cannot rule out the following possibilities:

    1. An overlooked configuration issue. Given how closely I've worked with these setups, I am unsure where else to even look for differences in configuration beyond what has already been stated.
    2. Perhaps IIS failing to deliver the same code base through a secondary websites even though only 1 of these site were ever started at a time. If that is true, I find it odd that issues present as Kerberos delegation issue on Site 2 only. I struggle with seeing why delegation would play out in that 'first-in' kind of way, but am left with little else to consider.

    I will be proceeding with this workaround of reconfiguring the functional Site 1 in the way I was trying to configure the proposed Site 2.