Adam Megacz wrote: > One other aspect of my goal is to effectively have aklog become > "automatic". That is, if a user's krb5 credentials cache has changed > in any way since the last time s/he accessed a particular cell, the > cache manager would ask afsd to run aklog (or perform equivalent > action) on behalf of that user.
> Is there a reason -- other than "nobody's had time to implement it" -- > that this is not already the case? Primarily because this would be the wrong behavior. First, you don't want new afs credentials to be obtained simply because the user obtained a new service ticket for SSH. Second, you don't want to obtain new tokens for AFS simply because the user chose to switch to her administrative principal OR a principal in another realm. The desired behavior is that which is implemented in the OpenAFS plug-in for the Network Identity Manager for Windows. For each Kerberos principal there is a configured set of cells for which AFS tokens are obtained. In addition, the tokens are refreshed whenever a new TGT is acquired for the user. The Network Identity Manager has the benefit of residing on a platform that supports the Kerberos CCAPI. As such, it can maintain multiple caches, one for each Kerberos principal. The UNIX-like operating systems other than MacOS X lacks the CCAPI at the current time. Since a file based ccache can only support a single principal, it is not possible at the current time to implement this multiple identification model. The UNIX-like platforms also have PAGs which means that the process obtaining the new AFS tokens must be in the process group for it to be effective. Russ Allbery has written a utility that obtains Kerberos tickets and then renews them before expiration that can be used to maintain current tokens within a PAG beyond the ticket lifetime. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
