Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NET8 WcfClient (net-tcp binding) running on linux cannot be authenticated on WCF Server hosted on windows if UseManagedNtlm is set #99227

Closed
AlexanderUsmanov opened this issue Mar 4, 2024 · 18 comments · Fixed by #99909

Comments

@AlexanderUsmanov
Copy link

Description

Hello!
I found problem while trying to connect to WCF service hosted on Windows over net-tcp connection using WCF client on linux with windows local user credentials. Problem occurs just when switch System.Net.Security.UseManagedNtlm is set to true. Otherwise it working on ubuntu 20.04. On ubuntu 22.04 and higher there is known issue with OpenSSL 3+ (see #67353) and in this case it working just with workaround described here #67353 (comment).

I also tried to apply fix from #95725 but it doesn't work for me.
Is it any chance to get fix for this problem on net8?

Reproduction Steps

Here is repository with reproduction solution and steps: https://github.com/AlexanderUsmanov/WcfClientNet8-issue

Expected behavior

Managed NTLM working

Actual behavior

Managed NTLM failing

Regression?

No response

Known Workarounds

Use unmanaged implementation which working just in case of OpenSSL version < 3.0 (because in OpenSSL with version 3 and higher md4 was marked as deprecated).

Configuration

Client:

  • .Net version: Net8
  • OS: ubuntu 20.04
  • Architecture: x64

Server:

  • .Net version: Net Framework 4.7.2
  • OS: Windows 10
  • Architecture: x64

WCF binding: net-tcp

Other information

I have captures of traffic using both managed and unmanaged ntlm authentication over net-tcp
Captures.zip

@ghost ghost added the untriaged New issue has not been triaged by the area owner label Mar 4, 2024
@ghost
Copy link

ghost commented Mar 4, 2024

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

Issue Details

Description

Hello!
I found problem while trying to connect to WCF service hosted on Windows over net-tcp connection using WCF client on linux with windows local user credentials. Problem occurs just when switch System.Net.Security.UseManagedNtlm is set to true. Otherwise it working on ubuntu 20.04. On ubuntu 22.04 and higher there is known issue with OpenSSL 3+ (see #67353) and in this case it working just with workaround described here #67353 (comment).

I also tried to apply fix from #95725 but it doesn't work for me.
Is it any chance to get fix for this problem on net8?

Reproduction Steps

Here is repository with reproduction solution and steps: https://github.com/AlexanderUsmanov/WcfClientNet8-issue

Expected behavior

Managed NTLM working

Actual behavior

Managed NTLM failing

Regression?

No response

Known Workarounds

Use unmanaged implementation which working just in case of OpenSSL version < 3.0 (because in OpenSSL with version 3 and higher md4 was marked as deprecated).

Configuration

Client:

  • .Net version: Net8
  • OS: ubuntu 20.04
  • Architecture: x64

Server:

  • .Net version: Net Framework 4.7.2
  • OS: Windows 10
  • Architecture: x64

WCF binding: net-tcp

Other information

I have captures of traffic using both managed and unmanaged ntlm authentication over net-tcp
Captures.zip

Author: AlexanderUsmanov
Assignees: -
Labels:

area-System.Net.Security, untriaged

Milestone: -

@rzikm
Copy link
Member

rzikm commented Mar 5, 2024

cc: @filipnavara

@filipnavara
Copy link
Member

cc: @filipnavara

Thanks. I have the issue on my radar. I was just preoccupied with other stuff and didn't get to analyze the data yet.

@wfurt
Copy link
Member

wfurt commented Mar 5, 2024

So .NET 9, does not work either @AlexanderUsmanov e.g. #95725 is not sufficient?

@wfurt
Copy link
Member

wfurt commented Mar 5, 2024

Note that Ubuntu 23.10 should have updated gss-ntlmssp (1.2.0-1) e.g. the native layer should work again with OpenSLL 3.

@filipnavara
Copy link
Member

I tested the sample with .NET 9 (P3 daily build) and it's not resolved.

@AlexanderUsmanov
Copy link
Author

So .NET 9, does not work either @AlexanderUsmanov e.g. #95725 is not sufficient?

Unfortunately no. I tried to do following:

  1. Apply fix from this issue 95725, rebuild System.Net.Securtity.dll with this fix
  2. Built client as self-contained app
  3. Replaced System.Net.Security.dll in output by result of p.1
  4. Run client - it doesn't work.

@rzikm rzikm added this to the 9.0.0 milestone Mar 6, 2024
@ghost ghost removed the untriaged New issue has not been triaged by the area owner label Mar 6, 2024
@rzikm
Copy link
Member

rzikm commented Mar 6, 2024

Triage: Tentatively set to 9.0 milestone.

@filipnavara filipnavara self-assigned this Mar 6, 2024
@filipnavara
Copy link
Member

I'll have a look... but it may have to wait few days.

@rzikm
Copy link
Member

rzikm commented Mar 6, 2024

Thank you, I don't think this issue is immediately urgent. In the worst case I can dig in it once I run out of higher priority tasks.

@filipnavara
Copy link
Member

filipnavara commented Mar 18, 2024

I had a moment to analyze this in more detail. Turns out that the authentication succeeds with the Managed NTLM (verified both by Wireshark logs and Event Viewer) but the server replies with ERROR_TRUST_FAILURE. The MS-NNS specification states:

When the Handshake message has a MessageId of HandshakeError, the AuthPayload
field MUST have a length of 8 bytes, and contain either an HRESULT error code describing an error
encountered by the security package or the Win32 error code ERROR_TRUST_FAILURE
(0x000006FE) indicating that the security package was able to successfully authenticate, but the
negotiated security parameters were unacceptable to the remote side.

I will have to dig on the .NET Framework side to figure out what parameters does it expect. Notably, the negotiation did end up negotiating both signing and encryption, NTLMv2, and ended up doing message integrity check. Cursory look indicated that could be related to SPN (which would easily be mismatched in my local setup that uses IP addresses) or impersonation level:
https://github.com/microsoft/referencesource/blob/51cf7850defa8a17d815b4700b67116e3fa283c2/System/net/System/Net/SecureProtocols/_NegoState.cs#L505-L535

@filipnavara
Copy link
Member

filipnavara commented Mar 18, 2024

I got a bit further, the Windows side rejects the authentication because of confidentiality level. It thinks that the negotiate authentication doesn't have encryption. Plot thickens.

UPD: Upon re-reading the Wireshark trace, Negotiate Seal flag is indeed missing.

@filipnavara
Copy link
Member

I managed to get the handshake working by fixing the negotiation of the NegotiateSeal flag. Message send/receive also works with plain NTLM. Unfortunately, it still fails when SPNEGO is involved. I'll continue poking at this tomorrow.

@AlexanderUsmanov
Copy link
Author

I checked the fix on net8 and it works for me. Is it any chance to include it into net8?

@wfurt
Copy link
Member

wfurt commented Apr 16, 2024

That would be taking #99909, right? .NET 8 does not have UseManagedNtlm right? (but that possibility was discussed)

@filipnavara
Copy link
Member

.NET 8 does not have UseManagedNtlm right?

It doesn't have the SDK switch but it has all the functionality. The sample in the original post sets the switch at runtime through AppContext.

@AlexanderUsmanov
Copy link
Author

@wfurt what do you think about this fix being included in net8? I need this specifically in net8, since I can only use the LTS version of dotnet.

@karelz
Copy link
Member

karelz commented Jun 24, 2024

Fixed in main (9.0) in PR #99909 and in 8.0.7 in PR #102216 (July release).

@karelz karelz removed this from the 9.0.0 milestone Jun 24, 2024
@karelz karelz added this to the 8.0.x milestone Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants