UseManagedNtlm in NET8 cannot authenticate NTLM on IIS with Extended Protection Accept & Required

[weedcry]

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

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

Issue Details

---

Description

I have the same error issue with this issue UseManagedNtlm
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

Author:	weedcry
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[wfurt]

Did you use managed NTLM in 7 @weedcry? And for 8, what makes you to use it?
Could this be related to token binding @filipnavara?

[filipnavara]

And for 8, what makes you to use it?

Same question here. The default in .NET 7 and 8 seems to be the same. If it worked for you, why change it?

Furthermore, on my project we connect to EWS on iOS and we have used NSUrlSessionHandler instead of SocketsHttpHandler precisely due to all the issues with NTLM. It has its own NTLM implementation and it's the same one that Apple uses in the Mail app.

Could this be related to token binding @filipnavara?

Yes, seems so. That said, token binding in general should be implemented.

• The binding token is passed in SocketsHttpHandler from the underlying connection to NegotiateAuthentication here
• SslStream seems to implement ChannelBindingKind.Endpoint here
• Managed NTLM writes the binding here and here

The fact that even the Accept option fails suggests that a wrong value is written in there instead of writing no value at all.

[filipnavara]

I found some of the channel binding code that looks fishy:

runtime/src/libraries/System.Net.Security/src/System/Net/Security/Pal.Managed/SafeChannelBindingHandle.cs

Lines 21 to 44 in b2f371d

	internal void SetCertHash(byte[] certHashBytes)
	{
	Debug.Assert(certHashBytes != null, "check certHashBytes is not null");
	Debug.Assert(certHashBytes.Length <= CertHashMaxSize);
	int length = certHashBytes.Length;
	Marshal.Copy(certHashBytes, 0, CertHashPtr, length);
	SetCertHashLength(length);
	}
	internal unsafe SafeChannelBindingHandle(ChannelBindingKind kind)
	{
	Debug.Assert(kind == ChannelBindingKind.Endpoint || kind == ChannelBindingKind.Unique);
	ReadOnlySpan<byte> cbtPrefix = kind == ChannelBindingKind.Endpoint ?
	"tls-server-end-point:"u8 :
	"tls-unique:"u8;
	_cbtPrefixByteArraySize = cbtPrefix.Length;
	handle = Marshal.AllocHGlobal(s_secChannelBindingSize + _cbtPrefixByteArraySize + CertHashMaxSize);
	IntPtr cbtPrefixPtr = handle + s_secChannelBindingSize;
	cbtPrefix.CopyTo(new Span<byte>((byte*)cbtPrefixPtr, cbtPrefix.Length));
	CertHashPtr = cbtPrefixPtr + _cbtPrefixByteArraySize;
	Length = CertHashMaxSize;
	}

The first constructor is the one used on macOS/iOS with the Pal.Managed implementation. Compared to the other one it's missing the prefix.

Nevermind, I misread that.

[weedcry]

@wfurt @filipnavara Thank you for your response.

Did you use managed NTLM in 7? And for 8, what makes you use it?

In Net 7, I did not use managed NTLM but just only used SocketsHttpHandler to send requests.
Although I could authenticate NTLM with all 3 levels on the IIS Server (Off, Accept, Required),
but I could not authenticate NTLM with the username format user@domain.com as in issue #94303.

I was forced to upgrade the system to NET 8 and use the configuration UseManagedNtlm and I encountered the error as described in this issue.

The reason I used SocketsHttpHandler instead of NSUrlSessionHandler on iOS is due to the server proxy issue.
I wanted to be able to constantly change the server proxy in the application for the outgoing request, so I chose SocketsHttpHandler.
And to be able to authenticate NTLM with the username format user@domain.com, I used UseManagedNtlm on NET 8.

[vinhdp195]

@filipnavara

Same question here. The default in .NET 7 and 8 seems to be the same. If it worked for you, why change it?
Furthermore, on my project we connect to EWS on iOS and we have used NSUrlSessionHandler instead of SocketsHttpHandler precisely due to all the issues with NTLM.

I use SocketsHttpHandler instead of NSUrlSessionHandler because on the iOS platform, NSUrlSessionHandler does not support custom proxies.
https://github.com/xamarin/xamarin-macios/blob/xamarin.ios-15.10.0.1/src/Foundation/NSUrlSessionHandler.cs#L625

		// We dont support any custom proxies, and don't let anybody wonder why their proxy isn't
		// being used if they try to assign one (in any case we also return false from 'SupportsProxy').
		[UnsupportedOSPlatform ("ios")]
		[UnsupportedOSPlatform ("maccatalyst")]
		[UnsupportedOSPlatform ("tvos")]
		[UnsupportedOSPlatform ("macos")]
		public IWebProxy? Proxy {
		...
		}

[weedcry]

@filipnavara
I have tried using NSUrlSessionHandler instead of SocketsHttpHandler as you suggested.
But currently, I can only authenticate NTLM at the Off & Accept option.
When I setting the Required option, NSUrlSessionHandler fails to authenticate with the returned message being “Unauthorized”