hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: [Fwd: Re: NTLM issues with 4.2.3]
Date Fri, 15 Feb 2013 14:58:00 GMT
Without the ability to duplicate the server-side setup here, the best
I can do is change what seems to be different and ask you to try it in
your environment, until it works there.

The flag differences seem unimportant at first glance, but that is
where I would start.  What I propose is that I create a number of
httpclient jars based on 4.2.3 and ask you to try each one of them in
turn.  You would be downloading these from
http://people.apache.org/~kwright .  Do you think this would work for
you?

Karl

On Fri, Feb 15, 2013 at 9:48 AM, Jason Millard <jsm174@gmail.com> wrote:
> On Fri, Feb 15, 2013 at 9:40 AM, Karl Wright <daddywri@gmail.com> wrote:
>> There's enough info in the capture data provided to tell me the answer
>> to the jcifs lmCompatibility question, I think.  I'd still like to
>> know the answer to question (2) though.
>>
>> Thanks!
>> Karl
>>
>> On Fri, Feb 15, 2013 at 8:53 AM, Karl Wright <daddywri@gmail.com> wrote:
>>> 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 <olegk@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 <jsm174@gmail.com>
>>>> Reply-to: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
>>>> To: HttpClient User Discussion <httpclient-users@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 <olegk@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-unsubscribe@hc.apache.org
>>>>> For additional commands, e-mail: httpclient-users-help@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-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: dev-help@hc.apache.org
>
>
>
>
> Hello.
>
> I am not providing any flags into JCIFS.
>
> It's pretty much:
>
>    DefaultHttpClient httpClient = new DefaultHttpClient();
>
>    String url = "http://servet.net/listfeed.aspx?List=xyz";
>
>    httpClient.getAuthSchemes().register("ntlm", new NTLMSchemeFactory());
>
>    httpClient.getCredentialsProvider().setCredentials(AuthScope.ANY,
>       new NTCredentials("UUUUUUUU", "PPPPPPPP", "WWWWWWWWWWWWW", "DDDDDDD"));
>
>    HttpResponse proxiedResponse = httpClient.execute(new HttpGet(url));
>
>    int statusCode = proxiedResponse.getStatusLine().getStatusCode();
>
>    System.out.println(statusCode);
>
> The following returns 3
>
>    int LM_COMPATIBILITY = Config.getInt("jcifs.smb.lmCompatibility", 3);
>
> For the heck of it, I tried
>
>    Config.setProperty("jcifs.smb.lmCompatibility", "0");  // SUCCESS WITH 200
>    Config.setProperty("jcifs.smb.lmCompatibility", "1");  // SUCCESS WITH 200
>    Config.setProperty("jcifs.smb.lmCompatibility", "2");  // FAILS WITH 401
>    Config.setProperty("jcifs.smb.lmCompatibility", "3");  // SUCCESS WITH 200
>    Config.setProperty("jcifs.smb.lmCompatibility", "4");  // SUCCESS WITH 200
>    Config.setProperty("jcifs.smb.lmCompatibility", "5");  // SUCCESS WITH 200
>
>
> As for domain security policies, I don't have access to the server. I
> could ask if necessary.
> It looks like its only doing NTLM authentication though.
>
>    HTTP/1.1 401 Unauthorized
>    Content-Length: 1656
>    Content-Type: text/html
>    Server: Microsoft-IIS/6.0
>    WWW-Authenticate: NTLM
>    MicrosoftSharePointTeamServices: 12.0.0.6520
>    X-Powered-By: ASP.NET
>    Date: Thu, 14 Feb 2013 15:25:53 GMT
>
> Thanks,
> -- Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message