Hi Amos,
"Amos Jeffries" wrote in message
news:b596a7df3abbf894689873c1a4bda...@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
