[OpenAFS] Service principal ticket expiring (AD)

[John Tang Boyland]

Jeffry Altman writes:
] I assume that you are not regenerating a keytab and installing the new
] key with asetkey.   If that assumption is true, then there is something
] wrong because the key known to the file server will never expire unless
] you generate a afs/cs.uwm.edu@ADTEST.UWM.EDU key.

No, I am not generating a new key.  The key is fine; I don't think the key
is expiring.  Instead, I'm guessing (with flimsy evidence) the the TGT
that the fileserver is getting from the AD server has expired.  But it may
just be a fluke.

] If a file server restart permits the acceptance of an authenticated
] connection without obtaining a new token on the client, it means that
] there is most likely a memory corruption problem in the file server.

The client has a valid token I obtained shortly before trying to
access files.  A week later, I got a new token and then access wasn't
granted until I restarted the fileserver.

Jonathan Nilsson writes:
] > After aklog got me a token using AD (without error), the fileserver still
] > rejects it.
] >
] 
] how do you know that it is the fileserver reject the connection, and how do
] you know it is related to Kerberos? i guess what i'm asking is: when do you
] notice the error, what log file, and can you post a specific error message?

I'm guessing.  aklog -d completes without error:
% kinit demojb@ADTEST.UWM.EDU
Password for demojb@ADTEST.UWM.EDU: 
% aklog -d -c cs.uwm.edu -k ADTEST.UWM.EDU
Authenticating to cell cs.uwm.edu (server solomons.cs.uwm.edu).
We were told to authenticate to realm ADTEST.UWM.EDU.
Getting tickets: afs/cs.uwm.edu@ADTEST.UWM.EDU
Using Kerberos V5 ticket natively
About to resolve name demojb to id in cell cs.uwm.edu.
Id 58793
Set username to AFS ID 58793
Setting tokens. AFS ID 58793 /  @ ADTEST.UWM.EDU 

But if I try to go to a directory which has an ACL of "demojb rl",
it says permission denied.  There are no errors in FileLog.
If I restart the fileserver, then
after the volumes are reattached, the token works: I can get
access to the directory.  The file server is old:

% rxdebug filip.cs.uwm.edu -version
Trying 129.89.143.71 (port 7000):
AFS version:  OpenAFS 1.4.12 built  2010-03-09 

] > I needed to restart the fileserver and then it worked fine.  But a week
] > later,
] > I had to restart the fileserver again in order for AD Source AFS tokens.
] >
] 
] i just noticed that our BosConfig does still have "restarttime" defined for
] weekly on Sunday at 4am. I recall that being necessary in the past, but I
] thought it wasn't the case any longer. and I don't recall that the restart
] requirement was related to Kerberos.

I'm still have bos restart weekly too.  So I think it's something wrong
that I'm doing, or else a fluke.  Perhaps it was because no one used
the afs/cs.uwm.edu@ADTEST.UWM.EDU for a long time (we're still
testing the AD+AFS configuration) ?  I'm just guessing.

Best regards,
John