dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

Home Page:https://docs.microsoft.com/dotnet/core/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

NTLM does not always work properly on all platforms with MAUI with SocketsHttpHandler

JeroenBer opened this issue · comments

Description

We recently ported our app from Xamarin to MAUI and run into some NTLM network issues on Android and iOS, on UWP it works fine.
This is a major problems for some of our clients.

Steps to Reproduce

I wrote a small MAUI testprogram. It is located here:
https://github.com/JeroenBer/MauiTestNltm

If you run this on UWP NTLM test 1, 2 and 3 will all succeed.

If you run this on Android or iOS only NTLM test 1 will succeed and NTLM test 2 and 3 will fail.

On Xamarin using the old System.Net.Http.MonoWebRequestHandler this used to work fine for all 3 cases. So this seems to be a bug.

Link to public reproduction project repository

No response

Version with bug

8.0.20 SR4

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android, macOS

Affected platform versions

No response

Did you find any workaround?

No

Relevant log output

No response

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

Can repro this issue at Android platform on the latest 17.10 Preview 7(8.0.14&8.0.20&8.0.21).Only NTLM test 1 will succeed and NTLM test 2 and 3 will fail.
22533

I have some doubts that this actually originates from within .NET MAUI but rather a layer deeper.

If you look through these issues, is there anything there that describes what you're seeing? Since you didn't include any details about the errors you're seeing with the message details I can't really determine if any of those issues might describe what you see there.

When you create a iOS/Android app without .NET MAUI, does that show the same behavior or does it work there?

Please file these NTLM issues on dotnet/runtime. At best someone will move them, and you will get worse response time. At worst they will get lost and ignored.

I'm fairly sure that the individual issues have already been discussed, addressed, or explained. You may be running into issue with "Extended Authentication" enabled on the Exchange server. It's hard to judge based just on the sample code. I fixed it for .NET 9 but it was not backported to .NET 8 (yet).

Hi @JeroenBer. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

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

I assume this could have been fixed in .NET 9 for Android by #95898. On iOS we also unconditionally switched to use managed NTLM in .NET 9 so it would be affected by the same fix. While the root cause may be different on .NET 8 / iOS (which relies on GSSAPI system library) the behavior would be aligned now.

I have long intended to push for backporting #95898 to .NET 8, so additional data to support it would be nice. This needs confirmation that the "Extended Authentication" option is really the root cause.

Is it possible to test this with .NET 9 preview? If it is the same issue as filipnavara references, then we may be able to make case for servicing and backporting the fix.

As a response to your questions, this is not MAUI specific but is more at the dotnet ios/android runtime level. The errors it gives are just 401 Unauthorized.

I will try to test .NET 9 this week to see if Extended Authentication is causing the issue.