Search squid archive

Re: Re: Question about changing authentication in a http session.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx...

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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux