Open marcino239 opened 3 years ago
thanks @marcino239. Can you post your code? As I was thinking about it I think neither NTLM nor the wrapper handles CredentialCache e.g. it expect NetworkCredentials. That is probably not hard to fix. the fact that the NetworkCredentials does not work is more concerning.
Actually, you can also set Diag=true on the NTLM class and it will print useful info to console. That may be easier than packet capture.
I've used stock HttpClient from runtime when testing using @JeroenBer test harness. Interestingly I did manage to get this repo working (server was IIS, don't remeber which version) for NTLM when NegotiateOEM was used. I had to modify few string copy functions. I couldn't get Negotiate to work.
Working code I am using in my current software looks more or less like this:
// in main
AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
// in some helper
var handler = new HttpClientHandler()
{
UseDefaultCredentials = false,
AutomaticDecompression = DecompressionMethods.GZip,
PreAuthenticate = true,
};
handler.Credentials = new CredentialCache
{
{
new Uri(url),
"NTLM",
new NetworkCredential(username, password, domain)
}
};
I was comparing how curl does NTLM auth and it was more efficient in terms of calls to the server. My plan was to use this repo with DelegatingHandler like @JeroenBer was trying to use in his version however base of Delegating handler was not playing nicely which means setting up new HttpClient instead of reusing existing one.
This plus time constrains meant I went with stock HttpClient. I don't know the dotnet runtime internals unfortunately.
Ah. The whole recent discussion on dotnet/runtime#887 is about alternative managed implementation of NTLM. The ask was to test that implementation and provide feedback. If that work, it would be considered for inclusion in 6.0. It seems like your setup is somehow different and it may be interesting test case.
If you want to investigate the stock behavior, I would suggest to open separate issue as it had nothing to do with macOS (or this effort)
Note that System.Net.Http.UseSocketsHttpHandler does nothing in 5.0. Old curl handler was removed and will not be back. I assume you have default version of the gss-ntlmssp package?
Referencing issue dotnet/runtime 887 I've used test repo from @JeroenBer and the conclusions are:
3.1 works with AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false). If this flag is set to true then nothing works either on 3.1 or 5.0
I'll add wireshark dumps over the next few days
Thanks!