Yes - and more information too:
(1) I need to know some details about how jcifs is being used when it
is successful. Specifically, the question is whether you supply any
-D jcifs configuration switches. If *no* switches or system property
overrides are being supplied, that is also useful. Specifically, I'm
looking for this one:
LM_COMPATIBILITY = Config.getInt("jcifs.smb.lmCompatibility", 3);
(2) I have tested the HttpClient NTLM code with all the local and
domain security policies available on an Windows 2008 R2 setup, and
found that it works on all. I will need to know what domain
controller authentication policies have been selected to produce a
failure.
Karl
On Fri, Feb 15, 2013 at 7:58 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> Karl
>
> Do you think these captures could be useful? It appears we have another
> case where JCIFS works while our internal NTLM engine does not.
>
> Oleg
>
> -------- Forwarded Message --------
> From: Jason Millard <jsm...@gmail.com>
> Reply-to: "HttpClient User Discussion" <httpclient-us...@hc.apache.org>
> To: HttpClient User Discussion <httpclient-us...@hc.apache.org>
> Subject: Re: NTLM issues with 4.2.3
> Date: Thu, 14 Feb 2013 11:44:44 -0500
>
> On Thu, Feb 14, 2013 at 10:00 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>> On Wed, 2013-02-13 at 16:15 -0500, Jason Millard wrote:
>>> Hello.
>>>
>>> I've been using previous versions of HttpClient forever using the
>>> JCIFSEngine. I wanted to give 4.2.3 a try to see if it solved my
>>> issues, but unfortunately I'm having the same problems.
>>>
>>> I was able to turn on debug logging and compare outputs. It's almost
>>> identical except for my final 200 vs 401 status code. Of course the
>>> type 1, 2, 3 messages have different signatures.
>>>
>>> Since the messages have addresses that I don't really want public, I
>>> was wondering the best way to get help debugging.
>>>
>>> 2013/02/13 16:09:22:817 EST [DEBUG] headers - >> User-Agent:
>>> Apache-HttpClient/4.2.3 (java 1.5)
>>> 2013/02/13 16:09:22:817 EST [DEBUG] headers - >> Authorization: NTLM xxxxxx
>>> 2013/02/13 16:09:22:928 EST [DEBUG] wire - << "HTTP/1.1 401
>>> Unauthorized[\r][\n]"
>>> 2013/02/13 16:09:22:929 EST [DEBUG] wire - << "Content-Length: 1539[\r][\n]"
>>> 2013/02/13 16:09:22:929 EST [DEBUG] wire - << "Content-Type:
>>> text/html[\r][\n]"
>>> 2013/02/13 16:09:22:929 EST [DEBUG] wire - << "Server:
>>> Microsoft-IIS/6.0[\r][\n]"
>>> 2013/02/13 16:09:22:929 EST [DEBUG] wire - << "WWW-Authenticate: NTLM
>>> xxxxxx"
>>> 2013/02/13 16:09:22:929 EST [DEBUG] wire - <<
>>> "MicrosoftSharePointTeamServices: 12.0.0.6520[\r][\n]"
>>>
>>>
>>> Thanks,
>>> -- Jason
>>>
>>
>> Hi Jason
>>
>> Only Wireshark packet captures would be meaningful given Wireshark's
>> ability to decompose NTLM messages into more readable data structures.
>> If you are not willing or able to publish those there is not really much
>> we can do just having wire logs with all NTLM blobs stripped away.
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>>
>
>
> Hello.
>
> Thanks for the response. I understand. I'm not "not willing", just unable.
>
> Attached are edited Wireshark packet dissections (one with and one
> without JCIFS) with the NTLM information. I'm guessing this might not
> be enough information.
>
> -- Jason
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
