Hi Amos,
>
> "Amos Jeffries" wrote in message
> news:b596a7df3abbf894689873c1a4bda57b_at_treenet.coz...
>
> 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.
I am pretty sure it is NTLM not Kerberos. ( The first characters in the
decoded string are NTLM )
>
> If this is solvable by Squid then it is likely also solvable in the
> wrapper helper and best experimented in that simpler code.
>
It would be possible in the wrapper if the wrapper would get the next auth
request. As far I could see from the log the wrapper did not get the next
auth token. I have the impression that the dispatcher has marked the
session as finished for authentication and does not send anything further to
the authentication wrapper.
> Amos
>
>
Received on Tue Feb 04 2014 - 23:58:33 MST
This archive was generated by hypermail 2.2.0 : Wed Feb 05 2014 - 12:00:04 MST