Fastream Technologies wrote:
> In the direct connection logs, if you look at the first request that
> returns 401, its response has connection: close, 

That's totally ok since at that time the auth-type is not yet negotiated.
However when the NTLM message type 1 is sent from the client to the server
Keep-Alive must be ON.

--
Arno Garrels


rather strange it
> worked that way. Anyway, I think this link I posted is the closest I
> have as a clue... 
> 
> On 3/15/08, Arno Garrels <[EMAIL PROTECTED]> wrote:
>> 
>>> I asked the customer to enable
>>> keep-alive and hope that it will work without any modification.
>> 
>> Sure, NTLM auth requires Keep-Alive. However, in your log Keep-Alive
>> is already used correctly, so what will that change?
>> 
>> --
>> Arno Garrels
>> 
>> Fastream Technologies wrote:
>>> Hi Guys,
>>> 
>>> I found this on my research:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=39673
>>> 
>>> Seems that NTLM is crap since it assumes statefulness on a stateless
>>> protocol (HTTP). Shame on M$. I asked the customer to enable
>>> keep-alive and hope that it will work without any modification. FYI.
>>> 
>>> Best Regards,
>>> 
>>> SZ
>>> 
>>> On 3/15/08, Fastream Technologies <[EMAIL PROTECTED]> wrote:
>>>> 
>>>> Yes you are probably right--but the code is so simple and I checked
>>>> the header sent with socketspy and it is the same size (208 bytes
>>>> after "Authorization: NTLM ") in both direct and non-direct! As I
>>>> said it is just a tunnel. Is there a way to decrypt the header with
>>>> some ready tool? I do not want to waste time with complex ntlm code
>>>> with as you suggested. But will look into structures now....
>>>> 
>>>> Regards,
>>>> 
>>>> SZ
>>>> 
>>>> 
>>>>  On 3/15/08, Arno Garrels <[EMAIL PROTECTED]> wrote:
>>>>> 
>>>>> Fastream Technologies wrote:
>>>>>> When I trace the code, it seems that your web server side NTLM
>>>>>> code is not called at all.
>>>>> 
>>>>> So, that is your implementation! If you do not call my code it
>>>>> can hardly be the reason for the problem.
>>>>> 
>>>>>> It just tunnels the www-authenticate headers
>>>>>> to/from the web server.
>>>>> 
>>>>> It's your application that is tunneling.
>>>>> 
>>>>>> Can you suggest me some URLs so that I can
>>>>>> read and understand what the eath is wrong with NTLM handshake?
>>>>> 
>>>>> http://davenport.sourceforge.net/ntlm.html
>>>>> 
>>>>>> You
>>>>>> told me all is well in one of your first mails. However, there
>>>>>> must be something wrong. For example, is the domain info
>>>>>> embedded in the hashed ntlm handshake?
>>>>> 
>>>>> If you ever want to know exactly what is included in the NTLM
>>>>> messages you need to write a parser, basic info from NTLM message
>>>>> type 2 can be viewed with a function from Francois' unit
>>>>> OverbyteIcsNtlmMsgs.pas, it also includes the structures and shows
>>>>> how to parse NTLM messages.
>>>>> 
>>>>> --
>>>>> Arno Garrels
>>>>> 
>>>>> 
>>>>> --
>>>>> To unsubscribe or change your settings for TWSocket mailing list
>>>>> please goto
>>>>> http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit
>>>>> our website at http://www.overbyte.be
>> --
>> To unsubscribe or change your settings for TWSocket mailing list
>> please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
>> Visit our website at http://www.overbyte.be
-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to