Hi Markus, thank you for your response. It seemes that I've solved it fir myself with keep very long trying.... I would have done your debugging questions if I had read your answer sooner. Well, What do you mean with clearing cache on Windows client? Do you mean the AD Server Win2k8 or a normal Windows browser cache? I havent' read anywhere that the client cache has something to do with it... (but maybe - because on one domain the auth worked and at the other domain not) Your kinit line never worked for me, as I can remind. Only >kinit administrator< did. I tested with klist, ktab, kvno and looked to have the versions coherent and after using kinit I had to do an net ads join again becaue wbinfo -t check failed afterwards and this changes the version of the host prinical ticket sometimes... It was really a trial and error with destroying the computer account, using kdestroy on squid and do ktpass or msktutil again... But in the end where kvno and klist say that they have the same version - it seemed that I just had to wait that the message "key version incorrect" disappeared in cache.log. Maybe the client cache is really important.... Regards Andrew Am Dienstag, 22. September 2009 22:33:48 schrieb Markus Moeller: > Can you send me the cache.log entries ? > > Can you do a kinit -kt /etc/squid/HTTP.keytab HTTP/fqdn@DOMAIN ? > > Can you capture with wireshark the traffic on port 88 on the kdc when doing > kinit ? > > Did you clear the cache on the Windows client using the Windows klist or > kerbtray from the resource kit ? > > Regards > Markus > > "Mrvka Andreas" <mrv@xxxxxx> wrote in message > news:200909221022.00697.mrv@xxxxxxxxx > Hi again, > > now I created the HTTP.keytab file on Win2k8 server and actually > the apps "klist -ke" and kvno say the key versions are VALID. > > but squid is of the opion that they differ. > > # klist -ke > Keytab name: FILE:/etc/squid/HTTP.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 5 HTTP/fqdn@DOMAIN (DES cbc mode with CRC-32) > 5 HTTP/fqdn@DOMAIN (DES cbc mode with RSA-MD5) > 5 HTTP/fqdn@DOMAIN (ArcFour with HMAC/md5) > 5 HTTP/fqdn@DOMAIN (AES-256 CTS mode with 96-bit SHA-1 HMAC) > 5 HTTP/fqdn@DOMAIN (AES-128 CTS mode with 96-bit SHA-1 HMAC) > > # kvno -k /etc/squid/HTTP.keytab HTTP/fqdn@DOMAIN > HTTP/fqdn@DOMAIN: kvno = 5, keytab entry valid > > > From where does squid get his wrong impression? > > My squid.conf > auth_param negotiate program squid_kerb_auth -d -s HTTP/fqdn@DOMAIN > > > Maybe I can support anyone by my detailed described errors. :-) > > > Regards > Andrew > > Am Dienstag, 22. September 2009 08:48:28 schrieb Mrvka Andreas: > > Hello, > > > > on the next day, I also get my "Key Version number"-problem on the same > > domain > > > > What is the best way to keep the versions in sync? > > I already erased the computer account and did msktutil again. > > I believe that for a short time the versions were correct (said klist and > > kvno) but during tests with squid they differed.!? > > > > I only use one KDC Win2k8 (configured in krb5.conf). > > > > Does anybody has a clue? > > > > Thanks > > Andrew > > > > Am Dienstag, 22. September 2009 00:33:13 schrieb Mrvka Andreas: > > > Hi list, > > > > > > does anybody know what to do againg different key version numbers using > > > squid_kerb_auth? > > > > > > I created HTTP.keytab from the msktutil and works great. > > > In fact in this domain where squid lives this internet explorers has no > > > problem using squid_kerb_auth. > > > > > > On other domains I get > > > "Unspecified GSS failure. Minor code may provide more information. Key > > > version number for principal in key table is incorrect" > > > > > > Via "klist -ke" and "kvno HTTP/fqdn" I am able to can compare these > > > keys and they differ. > > > > > > "kinit -R" doesn't work...: "KDC can't fulfill requested option while > > > renewing credentials" > > > > > > Can anybody shine me a light? > > > > > > Thanks you very much. > > > Andrew >
