Create and use a group cron or project Kerberos principal

Regular Kerberos users (i.e. non-shared user accounts) can easily create
and use /cron principals to Kerberize their cronjobs or other repetitive
actions.  Such users have a Kerberos principal and can create their own
/cron principal (on a per-node basis) with the kcroninit utility and
remove it with kcrondestroy.  The kcron utillity is then used to
authenticate with the user's /cron principal and execute a command or
script within the context of that authentication.

Shared accounts such as local user accounts, group accounts and project
accounts cannot easily do this because these accounts can NOT get
a Kerberos principal as shared passwords are prohibited by policy.
However, an administrator of such an account can request a Special
Kerberos principal that corresponds to a /cron principal.  So for
the local oracle account on node flummox.fnal.gov, one would request
the creation of the principal "oracle/cron/flummox.fnal.gov@FNAL.GOV"
via a General Request in ServiceNow.  After approval, the Service Desk
will create the principal and communicate the password back to the
requestor.

What remains is to create a keytab file holding the key for this
principal such that kcron can find and use the keytab file.  This
is facilitated by using ssh to log into the shared account (NOTE:
you must use ssh and NOT ksu to login into the account).  Assuming
you have either the krb5-fermi-config or krb5-fermi-krb5.conf RPM
installed, you just call the make-cron-keytab script:

[oracle@flummox ~] /usr/bin/make-cron-keytab

The script will pick up the local hostname and user name to construct
the principal name.  You will be prompted to enter the password
for the principal that the Service Desk provided.  The script will
then create the keytab file such that the kcron utility can find
it and use the key to acquire Kerberos credentials.


A more general example of acquiring and using a Special Kerberos Principal


As an example consider a Special principal for ExptX control on FUZZY,
which might be named something like

control/exptx/fuzzy.fnal.gov@FNAL.GOV

A General Request made via ServiceNow to the Service Desk results in 
a Kerberos administrator basically creating the principal using kadmin:

add_principal -clearpolicy +requires_preauth  control/exptx/fuzzy.fnal.gov
Enter new password:

The system administrator of fuzzy.fnal.gov creates a special keytab file on a
LOCAL file system. In this case, it is suggested to create a /var/adm/krb5
directory to hold the keytab file and to make sure every local user can
access these directories:

cd /var
mkdir -p adm/krb5
chmod 711 adm/krb5
cd adm/krb5

Normally these directories are created (and their permissions set) by the
installation of the krb5-fermi-base RPM package for use by kcron for
storage of the keytab files for user's /cron principals.

Create the keytab file and load the special principal in it then change ownership
and protections so selected users can read the keytab file (normally keytab
is owned by and restricted to root):

kadmin -r FNAL.GOV -p control/exptx/fuzzy.fnal.gov -q "ktadd -k control.keytab control/exptx/fuzzy.fnal.gov"
chown root:specialgroup control.keytab
chmod 640 control.keytab

In the above case we have selected to create a new group, specialgroup, and
all the users will be in this group's access list (in /etc/group) and
able to READ the keytab file.

The users' scripts to use this will look something like this:

$!/bin/sh
KRB5CCNAME=FILE:/tmp/krb5cc_lsf_p$$#Special Kerberos cache
export KRB5CCNAME
PATH=/usr/bin:$PATH
export PATH
trap "kdestroy " 0
kinit -k -t /var/adm/krb5/control.keytab  control/exptx/fuzzy.fnal.gov
# do other stuff ...

WARNING: This keytab file should NOT be in a network accessible file system
such as AFS or NFS due to these protocols not being very secure.