This site requires JavaScript to be enabled
Knowledge Home|Create Incident|Print
How To > Rules and Procedures for Using Special Kerberos Principals
Rules and Procedures for Using Special Kerberos Principals
Article: KB0011011 Published: 2013-09-23 Last modified: 2016-07-20

Rules and Procedures for Using Special Kerberos Principals

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 from a specific list of Kerberos principals (see 9.3 Account Access by Multiple Users).  Special Kerberos 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 Kerberos Principal in a .k5login or .k5user file to control access to a local account files or for script execution under that local account.


Requesting a Special Kerberos Principal

When the shared access local account method discussed above is not adequate, a Special Kerberos Principal will 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. Special Kerberos Principals can be used as /cron principals for shared accounts, see Create and use a group cron or project Kerberos principal for details (also available in Sharepoint). 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 are shown below:

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


Note that Special Kerberos Principals always include the fully qualified domain name (FQDN) of the host system (where the keytab file will be resident).

Requests for Special Kerberos Principals should be made to the Service Desk via the General Request from the ServiceNow Catalog. 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 up the approval process.  If necessary, the Service Desk will forward the request on to the Authentication Group 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 a 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 fix up file and directory permissions and ownership so this account can access the keytab file).   If you create the keytab file on a separate system (like on a Linux system with ultimate home on a Windows system), then remember to use secure means to transfer the keytab file (e.g., manually with a USB flash drive or using scp).
  • 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/kerberos/sbin/kadmin -r FNAL.GOV -p <SpecialPrincipal>
Enter password:
Type password you were given by principal creator
kadmin: ktadd -k /path/to/your/file.keytab <SpecialPrincipal>
kadmin: exit

Or, on older systems with Fermi Kerberos installed:

% /usr/krb5/sbin/kadmin -r FNAL.GOV -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.

 

 

 

 

 

 

 

 

 

 


:      Views: 24
Was this helpful?
YesNo
Rate this article