Eugene M. Zheganin wrote: > > > > I am attaching a traffic dump. > > > > Please look at Frame No. 36, where a ticket is requested for > > "HTTP/proxy.sibptus.transneft.ru", and then at Frame No. 39, where > > the ticket is granted, but for the wrong principal name. > > > The thing is, valid exchange should not and does not contain the > KRB5KRB_AP_ERR_MODIFIED error, and yours does. I thought as much. This error seems suspicious. But why does a second request not cause the same error? > This indicates something > is wrong between these two hosts (as I understand, 10.14.134.4 is a > Windows Server, and .122 is a workstation). Correct. > You need to investigate on > your DC what's happening, Probably these are the etype errors (may be > not). I will ask our Windows admin to enable Kerberos event logging. Maybe we'll find something there. The huge problem is the absence of legible diagnostics on the squid's side (the helper or the Heimdal library produce very hard-to-interpret and too generic debug output). > If your DC is really w2k (not w2k3 or w2k8) Unfortunately, it is really w2k. > and the workstation is > of different generation, this can happen. The workstations are Windows XP and Windows 7, both giving mixed results. > Also, lots of howtos spread > around the Internet, make an engineer believe that he should kreate the > keytab with only one encryption type for squid, insted kreating the > keytab with all of available on the DC ciphers, This can also lead to > complicated situations. 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@xxxxxxxxxxxxxxxxxxxx Which of the ways is correct, in your opinion? Could you repeat? > > There's also a decent article there: > http://blogs.technet.com/b/askds/archive/2008/06/11/kerberos-authentication-problems-service-principal-name-spn-issues-part-3.aspx Thanks for the link. I guess it boils down to two possibilities: 1. There is a duplicate SPN somewhere in the forest, or 2. Replication problem between the DCs, the principal's passwords don't match. > > Could help you as it did help me one day. Which was your situation when the article helped? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@xxxxxxxxxxxxxxxx _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
