A Windows XP system reporting a downgrade attack is unrelated. It means that either you have created a "cifs/a...@domain" SPN or you are experiencing a bug in XP.
All rxkad errors are reported as "No Kerberos Key" to Windows applications. On Windows, what is the process that is using 100% CPU and what version of OAFW are you running? Of course, /etc/krb5.keytab is not used for OpenAFS on Linux. Does "bos listkeys -localauth" report the correct kvno? Did you flush all of the credential caches and "unlog" to get rid of the the inconsistent keys? Ted Creedon wrote: > I've installed 1.4.10 on a linux afs server geronimo and linux client ookpik > > the client works on geronimo but uses 96% of 8 cpu's on ookpik which > also has a kernel message rxaderrror > > An untouched previously working XP client also hangs at 100% CPU but > eventially carps "attempt to compromise security" when the afs shares > are selected. > > Some key ot cc file may have been munged on geronimo but /tmp/krb5_cc0 > /etc/krb5.keytab appear to be consistent now - checked with > asetkey > klist > kvno > > They wern't consistent previously.. > > Any testing I can do I will.. > > On Tue, Apr 21, 2009 at 8:32 AM, Jeffrey Altman > <[email protected] <mailto:[email protected]>> wrote: > > Mircea Ciocan wrote: > > > IMHO, no matter what kerberos key b..s is happening this should not > > produce this miserable kernel loop that kills the most powerful > machines > > available today, it either should have some slower cadence so that > > eventually some could stop the AFS processes or it should give up > after > > some time, I this regard I consider this behavior a bug. > > > > Cheers, > > Mircea > > In the good old days when server-A reported "bad kvno" the cache manager > would discard the token even though it was possible that the token was > in fact valid and would work on every other server in the cell. This > is frequently a problem when a cell contains a mixture of pre-OpenAFS > 1.2.8 or Transarc/IBM servers and post-OpenAFS 1.2.8 servers. > > A few releases ago a modification was made to prevent the token from > being discarded and in the case of a replicated volume, to permit fail > over to an alternate copy. > > I suspect the issue is somehow related to this because now the afs > client will return a bad kvno error to the application instead of > access denied. If the application repeatedly retries the request > the kernel module will just ask the file servers again and produce the > same result. If the application asks again, .... > > It would be helpful to know if the infinite loop is being driven by > the application or is strictly within the kernel module. > > Jeffrey Altman > >
smime.p7s
Description: S/MIME Cryptographic Signature
