NTLM authentication HttpClient in Core

I am trying to use the HttpClient to access a REST service which requires NTLM authentication. However I keep getting a 401 Unauthorized. My code looks like this

    private static void Main()
    {
        var uri = new Uri("http://localhost:15001");
        var credentialsCache = new CredentialCache { { uri, "NTLM", CredentialCache.DefaultNetworkCredentials } };
        var handler = new HttpClientHandler { Credentials = credentialsCache };
        var httpClient = new HttpClient(handler) { BaseAddress = uri, Timeout = new TimeSpan(0, 0, 10) };
        httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
        var response = httpClient.GetAsync("api/MyMethod").Result;
    }

My target framework is netcoreapp2.0. If I change to net461, it will work. Not sure what I am doing wrong?

[EDIT] Add C# syntax highlighting by @karelz

[davidsh]

Is this on Windows or Linux? Is there any redirection involved with your REST service? Can you attach a full repro of the problem including the code for the localhost server?

• It is Windows platform, or I could not verify that it works as net461
• No redirection is needed to reproduce the problem
• The attached solution can reproduce the problem. Run the host part on a different machine, as it cannot be reproduced on localhost.

Change the target framework of the client project to net461, and it will work

NtlmAuthentication.zip

[davidsh]

[Edit]

I think this is related to a problem that was supposedly fixed involving how default credentials are transmitted. (#8434).

However, you mention that this works on loopback (localhost) but doesn't work on remote servers. I think it is a problem with how .NET Core (Windows) sets the internal WINHTTP_AUTOLOGON_SECURITY settings for how/when to release default credentials to the remote server.

Since you are explicitly requesting DefaultCredentials, they should be sent. We will need to investigate and look at traces to root cause.

cc: @karelz

Ok. Thanks for the update.
I can see the issue has been added to the 2.1.0 milestone. ETA for that is Q2, right ?

[karelz]

Yes, ETA is currently Q2: https://github.com/dotnet/core/blob/master/roadmap.md#upcoming-ship-dates (it could change)

I set the milestone based on my best assessment of the impact (compat with .NET Framework and @davidsh's notes). It is however possible we may change it later and push it out of 2.1.

[karelz]

Triage: @FenrisWolfAtMiddleEarth we are confused - your repro uses localhost, but you mention it does not work on remote machines and works on localhost. Can you please clarify?
HttpClient policy would be to not send default credentials to non-intranet machines.

My client in the repro uses a make-up DNS-name "remotehost". Replace that with there host-name where you run the NtlmAuthenticationHost project:

        private static void Main()
        {
            CallService("http://remotehost:9876", "api/Hello");
            Console.ReadKey();
        }

That should reproduce the problem. I.e. it will fail.
If you change it to localhost and run both on the same machine it will not fail.

[karelz]

Thanks for clarification.

[Priya91]

That should reproduce the problem. I.e. it will fail.
If you change it to localhost and run both on the same machine it will not fail.

As @karelz mentioned in the previous comment, this is by design that the handlers don't send out default credentials to non-intranet machines. This is by design.

[karelz]

Closing per @Priya91's comment.

@FenrisWolfAtMiddleEarth if you believe there is still some issue lurking, it would help to be crystal clear and provide isolated repro with all details in a single post to avoid further confusion. Thanks!

We finally figured out a solution to this problem. The solution though indicates that there is a bug in .net Core.
What triggered the problem was that the http host accepted both kerberos and ntlm authentication.. Our host is Owin, and the code to accept both looks like this:

                listener.AuthenticationSchemes = AuthenticationSchemes.IntegratedWindowsAuthentication;

Even though I specifically set the client to use NTLM, it would not respond to a challange which took both kerberos and ntlm. My http client was created like this:

            var uri = new Uri("http://service-endpoint");
            var credentialsCache = new CredentialCache { { uri, "NTLM", CredentialCache.DefaultNetworkCredentials } };
            var handler = new HttpClientHandler { Credentials = credentialsCache };
            var httpClient = new HttpClient(handler) { BaseAddress = uri, Timeout = new TimeSpan(0, 0, 10) };
            httpClient.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

What solved the problem was to change the host to only accept ntlm

                listener.AuthenticationSchemes = AuthenticationSchemes.Ntlm;

That very much sounds like a bug in the .net core HttpClient

@karelz
Please consider opening this issue again.
Thanks

[karelz]

I don't think the code above specifically sets client to use NTLM. It just provides NTLM credentials, that is all.
Kerberos is more secure than NTLM and therefore picked as it is supported by both client and the server.

@davidsh @wfurt is that correct summary? Is there a way to force client to use specific authentication scheme?

[davidsh]

From the description above, this is a bug in our HTTP client stack.

The server can offer multiple schemes such as Negotiate (Kerberos) and NTLM. The client will pick the strongest but only if the credential can be used for that scheme.

When a NetworkCredential object is used on the client, that credential is valid for all schemes (Basic, Digest, NTLM, Negotiate). But when a CredentialCache is used, that credential is only valid for the scheme assigned to it in the cache.

In this issue, the server is presenting 2 possible schemes: Negotiate and NTLM. But the client is using a CredentialCache and only has a single credential with just NTLM. We did have a bug in our HTTP stack where we would first pick Negotiate because it is the strongest. But then fail to find a credential that can be used (since we're using CredentialCache) and result in no credential being used at all. Instead, we should fallback to another scheme (such as NTLM) that the server supports and find a matching credential in our cache.

I thought we fixed this bug at least in WinHttpHandler. See: PR dotnet/corefx#28105

Not sure if we fixed it in all handlers. @rmkerr might have more information. Either way, this issue should be re-opened but it might be fixed in .NET Core 2.1.