You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ofcurl
). I found that it would only work if I added bothnegotiateFlagNTLMSSPNEGOTIATENTLM
andnegotiateFlagNTLMSSPNEGOTIATEALWAYSSIGN
. 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.
The text was updated successfully, but these errors were encountered: