>While probably not the case I can only hope that the exclusion of the tools >is because they want to do a better job of inter operating with the KDC. >In my opinion that would mean dropping the need for aklog and asetkey. >After all aklog is basically a second authentication.
You are incorrect. Aklog is simply the program that takes your Kerberos tickets and makes them available to AFS (possibly getting a Kerberos ticket for AFS, but it doesn't ask for a password). In this sense, it behaves just like every other Kerberized application. If you arrange for aklog to be run at login time, it becomes an essential component of single sign-on (you don't have to use aklog per se, you can use a PAM module that does aklog-like things). >Why can't the >authentication >take place the same way as say, using an IMAP server?. You access the >server, >( cd to /afs ) and get asked for your credentials. If you can figure out how to make this happen in a portable manner, let me know. >And asetkey simply puts the principal afs into a keyfile that afs knows how >to read. Well, make afs read the kerberos key file where it is as it is. That's not unreasonable. I suspect sometime in the future someone will do that. But it's worth pointing out that you don't technically need asetkey; you can use klist to read the raw key data (-K in MIT Kerberos), and Heimdal already knows how to write a AFS KeyFile. I'm not saying asetkey won't get added, but there was a finite amount of time before the 1.4 branch was cut, and I only had the free time to do aklog. --Ken _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
