AspNetCoreModuleV2: Windows Authentication (IIS, NTLM) not working when TokenImpersonationLevel is "Identification"

[etemi]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We run some ASP.NET Core services using In-process hosting with IIS and we use Windows Authentication.
We also use CoreWCF because we have some legacy clients that we still need to support.

It seems that old clients using .NET Framework cannot authenticate anymore. I found this comment that describes the same issue.

I analyzed the issue and it seems that it is caused by using GetPrimaryToken here. GetPrimaryToken() is also used in Out-of-process hosting.

I don't know if this is really an issue but shouldn't GetImpersonationToken be used instead? GetPrimaryToken() returns 0 when authenticating with TokenImpersonationLevel.Identification. It is not 0 when TokenImpersonationLevel.Impersonation is used.
GetImpersonationToken() seems to return a handle to a token of the user making the HTTP request.

Expected Behavior

Client applications that use .NET Framework must not be changed in order for Windows Authentication to work.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

• We don't have this problem when we use HTTP.sys web server
• As we have to use IIS, I developed a native IIS module (as a workaround) that sets the IHttpUser and forwards the calls of GetPrimartyToken() to GetImpersonationToken() for WCF calls.

[leonverschuren]

@etemi I'm running into the same issue. Your native IIS module workaround sounds interesting, can you share how you did it?

[etemi]

@leonverschuren You can find the IIS module workaround here.

[stcpottdav]

A response from a support case opened to Microsoft. This behavior is apparently by design.

Sent: Tuesday, September 3, 2024 12:14 PM
Subject: RE: [EXTERNAL] RE: AspNetCoreModuleV2: Windows ... - TrackingID#2408080040007701

Hello team,

Sorry for the delay, I had been sending emails to Fernando and didn’t notice I was not including David.

Thank you for bringing this issue to our attention and for your patience. After reviewing the details, it appears that this behavior is not a bug, but rather a design choice in ASP.Net Core, which does not support Impersonation. You can find more information on this in the official documentation in the link below.
Configure Windows Authentication in ASP.NET Core | Microsoft Learn
Given this limitation, the current workaround in place seems to be the appropriate solution. This appears to be more of a compatibility issue between the original implementation of the client code and CoreWCF.

Please let me know if you have any further questions or if there's anything else I can assist with.

Thank you

Best regards,
Emmanuel Gutierrez Calderon
Support Engineer Web Apps Developer
For Microsoft Customer Support

[etemi]

Thanks for sharing the response!

I still think that this is an issue in AspNetCoreModuleV2 because it only doesn't work when using AspNetCoreModuleV2.
As already stated, when HTTP.sys and Windows Authentication is used, HttpContext.User is set as expected to the user making the request (without making any changes to the app targeting .NET Framwork 4+).

I understand that ASP.NET Core doesn't implement impersonation and apps run with the app's identity for all requests, using app pool or process identity. But this is not the issue here as we don't want to perform any action on behalf of the user.
We just expect that HttpContext.User is set to the authenticated user making the request, which in turn can be used by apps to make authorization decisions based on the identity/groups of the user.

IIS Failed Request Tracing shows that the WindowsAuthenticationModule succeeds in authenticating and setting the user.
But when accessing HttpContext.User in ASP.NET Core the user is null. For example, the user is null here:

aspnetcore/src/Servers/IIS/IIS/src/Core/IISServerAuthenticationHandlerInternal.cs

Line 27 in 3586ac9

var user = _iisHttpContext.WindowsUser;

It would be really helpful for me if someone could explain the difference between IHttpUser::GetPrimaryToken and IHttpUser::GetImpersonationToken. What is the user primary token used for? What does it represent? How does it differ from the impersonation token?