Re: [squid-users] Re: Question about changing authentication in a http session.

On 2014-02-05 10:06, Markus Moeller wrote:
> Hi Amos,
>
> I tried 3.4.3 and it didn't change. I attach a access.log cache.log
> and a wireshark capture file. You will see the first Negotiate/NTLM
> authentication attempt is declined and the Negotiate/Kerberos attempt
> is not processed by the auth helper ( I assume because it is on the
> same session as I get successful authenticated when I wait a bit )
>
> Is there a way in the dispatcher to check the auth method has
> changed despite being the same session ? I know it is more difficult
> for
> Negotiate/NTLM to Negotiate/Kerberos as you need to check the token.
>

Tricky. Squid is only concerned with the scheme label to identify the
difference in the current code. For the Negotiate that does not change
naturally.

I think even looking deeper than the token type will be necessary. What
I see in that cache.log trace is a normal NTLM sequence of type 1, type
2, type 3 ... except the type 1 & 2 are NTLM and the type 3 format
appears to be in Kerberos or maybe NTLMv2 with security extensions.

If this is solvable by Squid then it is likely also solvable in the
wrapper helper and best experimented in that simpler code.

Amos

> Thank you
> Markus
>
> "Amos Jeffries" wrote in message
> news:611078a64927db3a27e7bee1924693d2_at_treenet.co.nz...
>
> On 2014-02-03 12:06, Markus Moeller wrote:
>> Hi,
>>
>> I am testing authenticating a XP machine with Kerberos, but the
>> client tries Negotiate/NTLM first after which squid does not accept
>> the change to Negotiate/Kerberos anymore.
>>
>> If you look at the wireshark log you authentication attempts at
>> 20:44:20 for Negotiate/NTLM and at 22:44:30 the client changed to
>> Negotiate/Kerberos, but the cache.log file does not get any request
>> after the 20:44:20 NTLM request. I can only see the deny entries in
>> the access.log.
>>
>> I use squid 3.4.1 from the repository from 24 Dec 2013.
>>
>> Is this an expected behavious ?
>
> Depends. Is this renegotiation being done on the same connection as
> NTLM
> was begun? (sorry cant view the packet trace right now).
>
> Do you get the same results with 3.4.3?
> It could be related to the helper decoding or external ACL loops bugs
> fixed in 3.4.2 and 3.4.3.
>
> Amos
Received on Tue Feb 04 2014 - 22:40:32 MST