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/cron@realm.org,
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