[
https://issues.apache.org/jira/browse/HTTPCLIENT-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339268#comment-14339268
]
Jason Forand commented on HTTPCLIENT-1624:
------------------------------------------
I have created my own HttpRequestExecutor in order to be able to
inject/retrieve values from the request/reponses in order to implement NTLM
message sealing. In the type 1 message I have added the following flags
NEGOTIATE_KEY_EXCHANGE
NEGOTIATE_SEAL
NEGOTIATE_SIGN
On the windows machine, I have set the AllowUnencrypted=false for the WSMAN
service calls.
When the type2 message comes back, if it has the NEGOTIATE_NTLM2_KEY (known by
microsoft as NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY) the NTLMEngineImpl
does not check this flag. As a result, the ntlm response being included in the
type3 header is wrong. When I manually change the ntlm response in my request
executor to follow the specification found at
http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse the windows
host accepts the message. I have attached an erroneous wireshark trace as an
exact replica of the error.
> 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
>
> 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]