Just to complete the list of wrong ways to do this. There is the SLAC way. We cheat and use the afs service key on the cron machine to either create afs service tokens from whole cloth or to decrypt the token and update the expire time(batch jobs).
This only gets you an AFS token, not a full kerberos tgt. I haven't yet seen a "right way" to do this in kerberos. Ideally you'd like an alternate key that can only be used from certain machines, to run certain programs. You can sort of get there with ssh keys, but that also has problems. The difficulty is that kerberos isn't an authorization service and you need a tightly coupled fine grained authorization service to do this "right". Ultimately trust can only be extended, not created. And any cron system needs the ability to trust cron to assume the privileges of any id that it wants to run the job as. In other words, you have to trust root on that machine with the keys to the kingdom. Or a least the keys of everybody that wants to run a cron job. Renewable and long life tickets can solve the batch problem with enough support. K5start is suitable for daemons, but cron is very difficult. The closest to "right" that I've seen is to create an alternate principal, user/[email protected], stuff the key into a keytab and then keep tweaking acl's until the cron job can do everything it needs to. Secure, but inflicts a lot of user pain. - Booker C. Bense _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
