Cron jobs on systems with kerberized storage, like DartFS and AFS, present challenges. The problem is that the cron daemon, even running as root, has no privilege to "become you" as far as the filesystem is concerned. If the command to run lives in your home directory, cron cannot get to it, and if the command is local, but it needs to read or write files in DartFS storage, it will fail at that point. The account running cron must also have a local home directory, as cron will switch to that directory before even looking at the command to run.
Cron must be provided with some form of "saved password". The mechanism for this is called a keytab file, which contains an encrypted password, and can be used to obtain and renew a credential for the storage. It is usually used with a service account which has the minimum permissions needed to run the cron job. This is to avoid putting your personal NetID password at risk by storing it (encrypted) in a keytab.
Create a keytab file (see Related Articles), then use the k5start tool to gain and keep (as long as needed) the credential, until the specified program has completed.
e.g. hourly run "myscript", as service account "d123abc"
0 * * * * /usr/bin/k5start -f /usr/local/private/d123abc/key -- d123abc@KIEWIT.DARTMOUTH.EDU sh -c '/dartfs-hpc/rc/home/..../myscript args'
The path to the keytab (e.g. /usr/local/private/d123abc/key) must be accessible to the account running the cron job, not in kerberized storage, and should be readable only by that account. Everything passed in quotes to "sh -c" is the script to run, which can live in kerberized space and reference files in kerberized space.
Cron must switch identities and change directories to the account running the job, before it has a chance to authenticate with the keytab. This means the service account must be defined as a valid account on the system. The password may be locked and the home directory must be on local (or at least, non-kerberized) storage. The home directory can be in /tmp
To give the owner of the service account control over the cron job, local sudo privileges can be given to the owner.
e.g. if the real owner is d000123, in sudo config.
d000123 ALL=(d123abc) /bin/crontab -e
d000123 ALL=(d123abc) NOPASSWD: /bin/crontab -l
Then user d000123 runs e.g. sudo -u f004jk4 crontab -e
If the program or script started by k5start needs to connect to a remote system (e.g. using rsync, scp, ssh, sftp), then you must use the appropriate options to forward the credential to the remote system. This permits passwordless remote login, and access to resources on the remote system. The SSH options needed are "GSSAPIAuthentication" and "GSSAPIDelegateCredentials". These can be set as defaults in a configuration file, or passed each time as command line options. The syntax varies for different tools, but for example, scp would use:
scp -o GSSAPIAuthentication -o GSSAPIDelegateCredentials /path/to/sourcefile remoteuser@remotehost:/path/to/destination'