Azure / go-ntlmssp

NTLM/Negotiate authentication over HTTP
MIT License
189 stars 70 forks source link

default negotiate flags aren't working for proxy server #23

Open eli-darkly opened 5 years ago

eli-darkly commented 5 years ago

Hi. I'm very new to using NTLM, so I'm sorry if my questions are misguided, but here's my situation:

I've been trying to use this package in combination with go-ntlm-proxy-auth to connect to an NTLM-authenticated proxy server (currently WinGate 9.4). What I'm seeing is that the proxy conversation (the part handled by go-ntlm-proxy-auth) works as expected, and the NTLM messages are well-formed, but WinGate always rejects the initial Negotiate message, saying that the flags are invalid (with no further explanation, unfortunately).

So I tried modifying the default flags in negotiate_message.go, and making them look more similar to what I saw when I connected to the server with other NTLM-enabled tools (e.g. the Windows version of curl). I found that it would only work if I added both negotiateFlagNTLMSSPNEGOTIATENTLM and negotiateFlagNTLMSSPNEGOTIATEALWAYSSIGN. Also, looking at NTLM implementations for other platforms (like Apache HTTPClient), it seems that it's pretty much universal to use those flags.

For now, I'm using a fork where I've added those flags, but I'm uncomfortable with my lack of understanding of all this. If it really is correct to send ALWAYSSIGN (which seems odd to me since it disables a security feature), then why hasn't this been a problem for any other users of this package? Maybe everyone else is authenticating direct requests instead of proxy connections?—but I can't think why that would make a difference.

Unfortunately the Microsoft docs about the protocol are somewhat vague as to which of the many optional flags should be used in any given situation. So I'd really appreciate any insights anyone might have.