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...@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.
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
