Rules and Procedures for Using Special Kerberos Principals

sidemenu

Restricted Access

Sharing the password for a Kerberos principal is a policy violation (see Important! Please Read!). Shared or group access accounts are usually best handled by a local user account with .k5login or .k5user files to control account access (see 9.3 Account Access by Multiple Users) from a specific list of Kerberos principals. These Special Principals are for authenticating automated processes that are not initiated by the super-user (root) account. Frequently these automated processes run on remote systems or under other accounts on the local system and can use the Special Principal in a .k5login or .k5user file to control this access.

Requesting a Special Kerberos Principal

When the shared access account method discussed above is not adequate, a Special Kerberos Principal may need to be requested. Special Kerberos Principals are named with muliple fields separated by slashes ("/") similar to the per-user /cron principals setup by kcroninit (see 10.3.1 Specific-User Processes (cron jobs) in the Strong Authentication Guide. Some discussion about one type of Special Kerberos Principals can be found in section 10.3.3 Non-root, Non-specific-user Processes in the Strong Authentication Guide. Commonly, Special Principals are used for behind-the-scenes access (like by web servers) to helper accounts or to remote computer systems. Examples of some Special Principals used for these situations:

enstore/cd/stkenmvr31a.fnal.gov@FNAL.GOV
postgress/nimisrva.fnal.gov@FNAL.GOV
lsf/fsui03.fnal.gov@FNAL.GOV

Requests for Special Kerberos Principals should be made to the HelpDesk. The request should include an explanation of how this Principal will be used and the special local user accounts to be using the Principal. In particular, an explanation of why the standard shared access account method is inadequate will speed the approval process. If necessary, the HelpDesk will forward the request on to the Computer Security Team for approval before the Principal is created.

How To Setup and Use Special Principals

Once your request is approved and the Special Principal is created, you have to prepare the system in order to use it. Normally, you are going to install a key for the Special Principal in a keytab file and use it from that keytab file to get Kerberos tickets. The rules for creating and administering this keytab file are:

Do not put the key for your Special Principal in the system keytab file which is only accessible by root (/etc/krb5.keytab is where the host and ftp principals for system are installed).
The keytab file you create must be accessible from the account(s) that uses the Special Principal. Depending upon your setup this might entail changing the group of the keytab file and adjusting group memberships.
The keytab file must be stored on the local system and not accessed or accessible over the network (this includes AFS space, NFS and Windows shares).
The keytab file is created by the account using the Special Principal (if not done from the account to use the file, then remember to fixup file and directory permissions and ownership so this account can access the keytab file).
Use kinit to access the Special Principal in the keytab file and get Kerberos tickets.
Remote computers and/or other helper accounts can be used via the standard mechanisms of using .k5login or .k5users file with the Special Principal listed in the file. It is strongly advised that the root account not be used as a helper account via a Special Principal.

You can create the keytab file and load the Special Principal with these commands:

% /usr/krb5/sbin/kadmin -p <SpecialPrincipal>
Enter password: Type password you were given by principal creator
kadmin: ktadd -k /path/to/your/file.keytab <SpecialPrincipal>
kadmin: exit

You can then use the Special Principal to get a Kerberos ticket in your scripts by:

% kinit -k -t /path/to/your/file.keytab <SpecialPrincipal>

Special Principals for Web Servers

If you are using the Special Principal with a web server, there are some additional items of note:

The keytab will be accessed by the apache account.
The keytab file MUST NOT be stored in the html directory tree. Place it somewhere else so that it is not possible for the web users to access the keytab file.
You will want to vet your CGI scripts carefully to avoid allowing inadvertent access to the keytab file or impermissible usage of Kerberos tickets acquired using the Special Principal.

For assistance contact helpdesk@fnal.gov.
Information compiled and maintained by Computer Security Team ; last modified by TR on July 13, 2006.
(Address comments about page to the Computer Security Team.)