Kerberos ticket has wrong impersonationlevel after the calling application upgraded from .NET 4.7

Question

A web app "A" is calling a Web API "B" which is calling a Sharepoint site "C". All authenticates with Windows authentication.

When "A" is targeting .NET 4.7.2, it works. The Sharepoint site "C" correctly authenticates the user and the kerberos ticket shows "Impersonation Level: Delegation".

When "A" is targeting .NET 8 (tried with .NET 5 as well) and IISSettings are moved into startup.cs, the kerberos ticket shows "Impersonation Level: Impersonation" and the Sharepoint site "C" throws a http 401 (since there's no user, the request is anonymous).

So in the .NET 8 scenario, Windows authentication works in "A". The impersonation call to the Web API "B" works, but the impersonation level is wrong.

I have also tried creating a simple console application with the following code. Note that the URL is the same as before, a call to the Web API "B".

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://b.domain.com/resource");
request.ImpersonationLevel = TokenImpersonationLevel.Delegation;
request.UseDefaultCredentials = true;

try
{
    using (var response = (HttpWebResponse)request.GetResponse())
    using (var reader = new StreamReader(response.GetResponseStream()))
    {
        var c = reader.ReadToEnd();
        Console.WriteLine(c);
    }
}
catch (WebException e)
{
    Console.WriteLine(e.Message);
}

Again, targeting .NET 5 and running this locally with IISExpress results in http error 401, but targeting .NET 4.7.2, it works and I get my user specific data.

Other notes: when testing the change of what version of .net "A" is targeting, I'm reusing the same appool IIS-site which means they have the same configuration for AppPool accounts, SPNs, Windows authentication and more. It really seems that the only thing changing is the .net version target.

What could be the issue? Any suggestions on what to try next?

UPDATE

I did some network sniffing on the first server where "A" is hosted and found something interesting.

• For the non working request with .NET 8, one kerberos request is made with these flags: (forwardable, renewable, canonicalize)

• For the working request with .NET Framework, two kerberos requests are made, the first one with these flags (forwardable, renewable, canonicalize) and the second on with these flags (forwardable, forwarded, renewable, canonicalize, renewable-ok)

The first kerberos request in both instances have 2 "SNameString"-properties

• "HTTP"
• "b.domain.com" (the url to Web API "B")

The second request in the second instance have

• "krbtgt"
• "domain.com" (The wider domain of which B and many other things is part of)

So the question now is, why isn't .NET 8 making the second "krbtgt"-request?

Answer 1

The reasons might be:

• On Host B, the application on IIS might have 'Anonymous Authentication' enabled. Even though Windows Authentication is checked 'Anonymous Authentication' takes precedence. Pls also check that Negotiate protocol is on top in the Windows Authentication providers. If the issue still continues pls chk the following:
• Is the newer IIS application assigned to an App Pool with Application Pool Identity as a domain user or a built-in user? The existing delegations may be checked with the command for HostA and HostB as setspn -L Since your working application has domain-wide ticket, the domain user assigned to its AppPool identity should have delegation delegation defined in AD as:
• Go to Active directory Users and Computers.
• Click on Users. Search for your domain user account (the domain user assigned to working application's AppPool identity) and go to its properties.
• Select the delegation tab and verify that (unconstrained delegation) ‘Trust this account for delegation to any service’.

In summary: Pls check Anonymous Authentication, your AppPool Identity, and your connection URL FQDN are the same as the working application.

Ref: https://techcommunity.microsoft.com/t5/iis-support-blog/setting-up-kerberos-authentication-for-a-website-in-iis/ba-p/347882