WindowsIdentity.RunImpersonatedAsync sending wrong credentials

[daniilzaonegin]

Description

Hi!

This issue is the continuation of issue #58033.

I've made a sample project to reproduce the error https://github.com/daniilzaonegin/ImpersonationTest.
WindowsIdentity.RunImpersonatedAsync reuses the credentials of previous api call.

            var result = await WindowsIdentity.RunImpersonatedAsync(windowsIdentity.AccessToken,
                async () =>
                {
                    HttpClient? client =
                        _clientFactory.CreateClient(ServiceConsts.ImpersonateClientName); 
                    var result = await client.GetAsync("http://localhost:5246/api/User");

                    return await result.Content.ReadAsStringAsync();
                });

Reproduction Steps

To reproduce. Clone and run https://github.com/daniilzaonegin/ImpersonationTest:

1. Call GET http://localhost:5086/api/UserRightsDelegating under windows account (1) -> user login name;
2. Call GET http://localhost:5086/api/UserRightsDelegating under ANOTHER windows account (2) -> (1) user login name, not second.

If you disable connection pooling, when adding HttpClient (PooledConnectionLifetime = TimeSpan.Zero), then everything works as expected:

builder.Services.AddHttpClient(ServiceConsts.ImpersonateClientName)
    .ConfigurePrimaryHttpMessageHandler(_ =>
        new SocketsHttpHandler()
        {
            UseProxy = false,
            Credentials = CredentialCache.DefaultCredentials,
            PreAuthenticate = false,
            PooledConnectionLifetime = TimeSpan.Zero
        });

Expected behavior

WindowsIdentity.RunImpersonatedAsync should use credentials of the user, that is calling api right now, not the credentials of a previous api call.

Actual behavior

WindowsIdentity.RunImpersonatedAsync reuses the credentials of a previous api call.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Hi!

This issue is the continuation of issue #58033.

I've made a sample project to reproduce the error https://github.com/daniilzaonegin/ImpersonationTest.
WindowsIdentity.RunImpersonatedAsync reuses the credentials of previous api call.

            var result = await WindowsIdentity.RunImpersonatedAsync(windowsIdentity.AccessToken,
                async () =>
                {
                    HttpClient? client =
                        _clientFactory.CreateClient(ServiceConsts.ImpersonateClientName); 
                    var result = await client.GetAsync("http://localhost:5246/api/User");

                    return await result.Content.ReadAsStringAsync();
                });

Reproduction Steps

To reproduce. Clone and run https://github.com/daniilzaonegin/ImpersonationTest:

1. Call GET http://localhost:5086/api/UserRightsDelegating under windows account (1) -> user login name;
2. Call GET http://localhost:5086/api/UserRightsDelegating under ANOTHER windows account (2) -> (1) user login name, not second.

If you disable connection pooling, when adding HttpClient (PooledConnectionLifetime = TimeSpan.Zero), then everything works as expected:

builder.Services.AddHttpClient(ServiceConsts.ImpersonateClientName)
    .ConfigurePrimaryHttpMessageHandler(_ =>
        new SocketsHttpHandler()
        {
            UseProxy = false,
            Credentials = CredentialCache.DefaultCredentials,
            PreAuthenticate = false,
            PooledConnectionLifetime = TimeSpan.Zero
        });

Expected behavior

WindowsIdentity.RunImpersonatedAsync should use credentials of the user, that is calling api right now, not the credentials of a previous api call.

Actual behavior

WindowsIdentity.RunImpersonatedAsync reuses the credentials of a previous api call.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	daniilzaonegin
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[geoffkizer]

@wfurt can you take a look?

[wfurt]

sure. I'm not sure how Kestrel and factory plays into this but having specific example should be sufficient to see what is going on.

[wfurt]

I could not get the demo working. It is failing with

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.InvalidOperationException: No authenticationScheme was specified, and there was no DefaultChallengeScheme found. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action<AuthenticationOptions> configureOptions).
         at Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, String scheme, AuthenticationProperties properties)
         at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResul

This is not my area and perhaps @Tratcher would have some insight.

I modified it to use Negotiate scheme:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-6.0&tabs=visual-studio

With that I can access the UserRightsDelegating url and based on the user I pass in I get

curl -v --negotiate -u test:* http://localhost:5086/api/UserRightsDelegating
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 31 Dec 2021 21:41:33 GMT
< Server: Kestrel
< Transfer-Encoding: chunked
<
WOKNA10\test* Closing connection 0

or

curl -v --negotiate -u test1:* http://localhost:5086/api/UserRightsDelegating

< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 31 Dec 2021 21:42:17 GMT
< Server: Kestrel
< Transfer-Encoding: chunked
<
WOKNA10\test1* Closing connection 0

e.g. the response content does respect the used user for first service. (I did not change the timeout)

[ghost]

This issue has been marked needs more info since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[daniilzaonegin]

@wfurt, this solution works only on IIS/IIS Express. I had an issue on IIS and posted same code that is used in our application. So when you run it from visual studio 2022 on IIS Express, there will be no errors.

[daniilzaonegin]

I tested it with curl, it really respects the credential change. I think you can close the issue, everything works as expected.
The problem was, that before I tested it with Postman and there's an issue there (by default it doesn't close the connection and reuses the credentials).
https://community.postman.com/t/postman-ntlm-authentication-with-different-users-credentials/2452

[wfurt]

Good to know. I have no experience with Postman. I tried it, but eventually fall-back to tools I'm familiar with.