[squid-users] Squid, Kerberos and FireFox (Was: Re: leaking memory in squid 3.4.8 and 3.4.7.)

[Eugene M. Zheganin]

Hi.

On 18.10.2014 16:11, Victor Sudakov wrote:
> I thought as much. This error seems suspicious. But why does a second
> request not cause the same error?
No idea.
> We have tried both ways (enabling all ciphers and enabling only
> arcfour-hmac-md5), but it made no difference. Currently we are using
> the keytab with one arcfour-hmac-md5 key only:
>
> Vno  Type              Principal
>    1  arcfour-hmac-md5 HTTP/proxy.sibptus.transneft.ru at SIBPTUS.TRANSNEFT.RU
>
> Which of the ways is correct, in your opinion? Could you repeat?
To my knowledge, RC4 should fit, because newer versions add only aes 
cipher suites.
> Which was your situation when the article helped?
I had a situaltion when there were lots ot e-types errors between non-R2 
w2k3 and w7 workstations. Plus, my keytab was only for RC4 only. Plus, I 
had duplicate SPNs and wrong understanding about how the kerberos 
exchange is working and what principal name is requested when (yours 
seems to be correct, though). I played with "use only DES" setting for a 
troubled user in AD, played with msDS-SupportedEncrytionTypes in AD, but 
due to all the complications this didn't help. So, I eliminated  w2k3 by 
changing it to the w2k3r2 dc, - this didn't help by itself, so I had to 
clear out other errors. Then my setup started to work. Unfortunately, I 
don't have an answer to the question "what is needed for squid to work 
in a kerberos environment with different generation OSes". I also didn't 
get KRB5KRB_AP_ERR_MODIFIED error. I can say that if we talk about w7 
coexistance with the w2k3 domain controller - no critical errors were 
seen, so workstations could log in to the AD domain just fine.

I would propose to you to conduct some tests pointing your squid setup 
to some modern DC, if you have one, and see if this error would disappear.

Eugene.