Check the lifetime of the afs entry in your Authentication Database.
When a token is issued, all three parties (client, service,
ticket-granter) using the token get to influence the lifetime of the
token. In your case, the 3 parties are
1. client is the user
2. service is afs
3. ticket granter (kbrtgt.CELLNAME in your Auth DB)
Defaults are
1. users get 25 hours
2. service (afs) gets 100 hours
3. ticket granting service gets 720 hours.
When the ticket is granted, the most paranoid party in the trio sets
the lifetime. So if you increased the users lifetime to 720 hours,
the service (afs) is now the most paranoid and the token granted has a
lifetime of 100 (or so) hours. (Check the table in your Command
Reference Manual to understand the "or so".)
Make sure you increase the service's lifetime to be at least as high
as the higest lifetime you have assigned to a user.
On a different note, if users are needing the tokens to survive beyond
720 hours, they will have to "boost" the existing token before it
expires. They must actually replace the dying token with a brand new
720 hour token sometime before the old one takes its final breath.
All they need to do is klog. It should not disrupt any processes that
are using the token.
Pierette VanRyzin
AFS Training
