[
https://issues.apache.org/jira/browse/HTTPCLIENT-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14340639#comment-14340639
]
Jason Forand commented on HTTPCLIENT-1624:
------------------------------------------
Hi Karl,
Let me know how best I can help you. I can tell you that if you are only using
NTLM authentication, the code in the NTLMEngineImpl works as is. I have two
guesses as to why this might be. The first guess is that the windows host
doesn't actually check the contents of the ntlm response. The second guess is
that if you have a windows host that requires sealed messages (which at present
isn't supported), then that host will send the
NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag.
I have tested on two windows hosts (windows 7 and windows 8), and when the
flags
NEGOTIATE_UNICODE = 1
REQUEST_TARGET = 1 << 2
NEGOTIATE_SIGN = 1 << 4
NEGOTIATE_SEAL = 1 << 5
NEGOTIATE_NTLM = 1 << 9
NEGOTIATE_ALWAYS_SIGN = 1 << 15
TARGET_TYPE_SERVER = 1 << 17 (or TARGET_TYPE_DOMAIN = 1 << 16)
NEGOTIATE_NTLM2_KEY = 1 << 19
NEGOTIATE_TARGET_INFO = 1 << 23
UNKNOWN_4 = 1 << 25
NEGOTIATE_128 = 1 << 29
NEGOTIATE_KEY_EXCHANGE = 1 << 30
NEGOTIATE_56 = 1 << 31
are received in the type 2 message, then the value that is placed in the
ntlmresponse field is rejected by the host. Unfortunately I don't have access
to a wide variety of windows machines. I'm trying to get my hands on a few
more, and I will update you as I get results. At the moment, I can provide you
with wireshark files of both successful and unsuccesful connections.
I think that the ntlmresponse needs to change when
NEGOTIATE_SIGN = 1 << 4
NEGOTIATE_SEAL = 1 << 5
NEGOTIATE_NTLM2_KEY = 1 << 19
NEGOTIATE_KEY_EXCHANGE = 1 << 30
are present. Since you guys don't support sealing, NEGOTIATE_KEY_EXCHANGE would
never have appeared in your testing.
> NTLMresp in type3message is being generated wrong when using
> NEGOTIATE_NTLM2_KEY
> --------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1624
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1624
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpAuth
> Affects Versions: 4.3.6, 4.4 Final
> Environment: Running from a linux box, connecting to a windows 7
> machine.
> Reporter: Jason Forand
> Assignee: Karl Wright
> Attachments: wireshark_400.pcapng
>
>
> When connecting to a windows host using NTLM authentication, if the windows
> host passes back the
> NEGOTIATE_UNICODE
> REQUEST_TARGET
> NEGOTIATE_SIGN
> NEGOTIATE_SEAL
> NEGOTITATE_LAN_MANAGER_KEY
> NEGOTIATE_NTLM
> NEGOTIATE_ALWAYS_SIGN
> TARGET_TYPE_DOMAIN
> NEGOTIATE_NTLM2_KEY
> NEGOTIATE_TARGET_INFO
> UNKNOWN_4
> NEGOTIATE_128
> NEGOTIATE_KEY_EXCHANGE
> NEGOTIATE_56
> flags, (in this case the offending flag is NEGOTIATE_NTLM2_KEY) the type3
> message is generating an ntresp using
> http://davenport.sourceforge.net/ntlm.html#theNtlmv2Response when it should
> be generating according to
> http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
