I am cc'ing the [email protected] mailing list because this is really an OpenAFS discussion. [EMAIL PROTECTED] is meant to be a mailing list focused on development of the MIT Kerberos reference implementation.
The fundamental issue being discussed here is whether the Kerberos.App display of the Kerberos Credential Cache contents can be used as an indication by end users that the AFS kernel module contains tokens for that user. Hank is claiming that presence of an "afs/[EMAIL PROTECTED]" service ticket in the credential cache is an indicator that there are AFS tokens installed in the AFS kernel module. I believe that end users should be discouraged from checking the Kerberos credential cache to see if they have AFS tokens because doing so is fundamentally flawed. There are many reasons why tokens might be removed from the AFS kernel after their initial installation let alone reasons why tokens might not be able to be stored in the first place. Therefore, using the Kerberos credential cache as a replacement for the "tokens" command or a GUI token display will only make the lives of end users and those that support them more difficult. If there is a concern that the presence of the AFS service ticket will be misinterpreted as meaning that tokens are present then perhaps the thing to do is modify aklog and anything that derives from its code base to not use the default credential cache and instead use a local memory cache. We could make this the default behavior and allow the default credential cache be used when "-d" is specified on the command line to allow the presence of the service tickets to be used for debugging purposes. While not part of the same topic, Derrick Brashear spent time this week attempting to prepare a KFM KLL plug-in for aklog that would work on Tiger and discovered that under Tiger we will not be able to provide such functionality. We will work with Apple to try to make this happen in a future release. For those who are unaware, the KFM KLL plug-ins have been used in previous releases of MacOS X to allow the Kerberos initial ticket getting functionality to be extended such that whenever a new Kerberos 5 Initial Ticket is obtained a new AFS token would be acquired at the same time. Without this functionality it is not possible to provide a single sign-on experience for AFS on Tiger. Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
