runtime: UseManagedNtlm in NET8 cannot authenticate NTLM on IIS with Extended Protection Accept & Required
Description
I have the same error issue with this issue #19366 And I used UseManagedNtlm in the csproj file to solve it but I encountered another problem when using UseManagedNtlm on NET 8.
On ews on-premise with IIS, windows extended protection (WEP) have 3 level include Off, Accept, Required.
At NET 7, i have successfully authenticated with NTLM authentication when setting all 3 levels on IIS Server
After upgrading to NET8 with config
<ItemGroup>
<RuntimeHostConfigurationOption Include="System.Net.Security.UseManagedNtlm" Value="true" />
</ItemGroup>
I only successfully authenticated with NTLM authentication when setting level 1 (Off) with level 2 & 3 (Accept, Required) when I perform NTLM authentication, I receive an error message that is “Unauthorized” I want to be able to successfully authenticate at level 2 & 3 on IIS Server, what should I do?
Reproduction Steps
Send request NTLM authenticate to server ews on-premise
Expected behavior
none
Actual behavior
none
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
Project sample: SocketRequestSample-Net8.zip
About this issue
- Original URL
- State: closed
- Created 7 months ago
- Comments: 24 (12 by maintainers)
@rzikm I have implemented the System.Net.Security.dll (modified) in my iOS application. It is now possible to use UseManagedNtlm on SocketsHttpHandler to send NTLM authentication requests with the options: Off, Accept and Required. I think it has been able to solve this issue.
Technically it’s not a regression. The same problem exists on .NET 7 but managed NTLM is used only for Android there. On .NET 8 you have to opt-in with an undocumented switch on any non-Android platform.
That said, backport would be nice since .NET 8 is LTS and the fix is quite small and self-contained.
Steve is right that extended authentication and some types of proxies don’t mix well. The point of the extended authentication is to prevent man-in-the-middle attack by binding the authentication to some TLS token of the HTTPS transport. It may work if the TLS connections are pass-through but it certainly won’t work for intercepting proxies. I specifically tested the intercepting proxy scenario with Fiddler and the authentication is (correctly) rejected even after the fix is applied.
Thanks for the additional testing. I plan to look into this in more detail, but I have been preoccupied with other issues until now.