My environment looks like this:
The IIS Server and clients all belong to the same AD domain. IIS Server is behind a load balancer appliance which is the HTTPS endpoint.
As many people, everything works well using IIS Express in Visual Studio 2022.
Windows authentication works well with IIS at previous development stage. I get user identity and set customs claims for granting actions in the app, by reading users rights in a backend database.
The plan is to use SignalR to notify rights updates and force claims to be reload. All works as expected with IIS express !
When I publish on IIS it failed at the call
await hubConnection.StartAsync();
with this error:
HttpRequestException: Response status code does not indicate success: 401 (Unauthorized)
After digging here https://github.com/dotnet/aspnetcore/issues/25000
and here https://github.com/dotnet/AspNetCore.Docs/issues/34618
I've tried the related docs prescription "impersonation when using Windows auth and SignalR" and so so many combination of options with no success.
Could anybody confirm that SignalR may works in my context, (see up there) ?
Added on 08/15/2025
Hello everyone. We've checked the load balancer configuration and there are no visible issues on that side: the websocket is correct and no traffic is being dropped.
The server-side Wireshark trace shows an issue during the negotiation phase. The domain/user is clearly lost during processing (see the line where user : ).
I've tried several combinations, but none work !
For the record, I'm using IIS behind a LB/proxy that terminates the SSL. My application is Blazor Server, DotNet 8.019, I'm using Windows authentication and I'm using user impersonation before processing the connection to the hub, as detailed in the documentation (see the link in the original post above).It's an intranet-only network.
I look forward to hearing from anyone who has successfully implemented a similar configuration or can point me to a solution to this problem.
Here's the anonymized Wiresharktrace. 192.168.2.50 is the IIS server address. The 192.168.1.x addresses are the load balancer interfaces.
The problem has finally been resolved.
The issue was related to the presence of load balancing equipment between the clients and the IIS server hosting the application, which implements the SignalR hub.
According to the classic architecture of SignalR hub implementation examples, when a new client connects to the hub, the server sends a request to the endpoint of the hub it hosts.
Without further precaution, the request cannot be successful because it is behind the LB, which cannot interpret these “client” requests on that side. The problem is solved by forging a URI that does not need to go back to the LB. It was also necessary to modify the connections at the IIS server level to accept this local request.
The whole story and the workaround applied are detailed here:
(https://github.com/dotnet/aspnetcore/issues/63412)
Regards