CredentialCache.DefaultNetworkCredentials always authorizes request-CodePudding

I have a Winforms app that sends request to an ASP.NET app that is hosted on IIS.

I have Windows authentication enabled and authorization given to a specific domain group.

When I send requests from the browser I'm prompted to login. If I supply a user that is not in the group, then the prompt just comes up again. If I use a different method of sending requests like httprepl or with python, I get 401 Unauthorized.

My Winforms app will get 401 Unauthorized if either I don't supply credentials or supply incorrect credentials.

However when I use CredentialCache.DefaultNetworkCredentials, the request from my Winforms returns success with the correct returned content.

But the user I am using is not in the group. Why is it authorizing? Furthermore when I look at the CredentialCache object, I see no values for user or password. The PreAuthenticate setting seems to not matter either when I use CredentialCache.DefaultNetworkCredentials

HttpClient client = new HttpClient(new HttpClientHandler()
                                       { 
                                           Credentials = CredentialCache.DefaultNetworkCredentials, 
                                           PreAuthenticate = true 
                                       });

And if it matters, the application pool identity is not a part of the group either.

It's possible that I ran the application once when the user was in the group, but why would subsequent attempts work even after I removed the user from the group?

I'm using ASP.NET Core 6.0, IIS 7.5, and .NET 7.0 for the Winforms app.

CodePudding user response：

The issue here was that the authorization to the ASP.NET app is dependent on a specific AD group.

Since the original Kerberos ticket does not have this new group membership information, the membership changes I was making didn't have any effect.

For the user group membership to be correctly communicated to the server, a new Kerberos ticket needs to generated. This can happen if the user were to logoff and log back in, or after the ticket expires (8 hours in my case).

So I just logged off and logged back in.