[
https://issues.apache.org/jira/browse/HTTPCLIENT-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339834#comment-14339834
]
Karl Wright commented on HTTPCLIENT-1624:
-----------------------------------------
Jason,
Part of the problem with working with NTLM is that there is no real public
specification for NTLM, since it is a proprietary protocol. The only way we
can work with it at all is by looking at what Microsoft publishes, and also
doing experimentation against existing Windows machines of different vintages
that we can get access to. To clarify my position -- in *your* case, you've
found a specific Windows configuration that does not work, and you have
effectively requested a logic change. I'm happy to commit a logic change, but
before I can do that in good faith, we need to be reasonable sure we do not
break other Windows configurations. Since you seem to have access at least to
a Windows instance that you can play with, you are in a far better situation
than we are as far as exploring what the right combination of flags are to
signal NTLM, NTLM 2 Session, vs. NTLMv2. This may take you a bit of time, and
I don't expect you to try every different variant of Windows, but we *do* need
you to try out your variant under multiple different configurations thoroughly
enough to recommend logic that at least works in all cases that Windows 7
supports.
Thanks!
> 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
> 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]
