Scripted authentication for Kerberos/SPNEGO SSO in ELM

If you run background applications such as build agents, it is not practical to be prompted for logon credentials. Instead, a keytab file can be used to authenticate scripts with valid Kerberos credentials.

Running as a Windows service

If your background application is running on a Microsoft Windows Server system, it is best to run the application as a Windows service. Then, you can configure the application to authenticate with a valid user account in Microsoft Active Directory.

To configure a Windows service application to authenticate with a user account, complete the next steps.
  1. Open the Windows Services dialog box.
    1. Click Start.
    2. In the Search field, type services.msc. Then, press Enter.
  2. In the details pane, find the service, right-click it, and click Properties.
  3. On the Log On tab, specify the user account and password for the service to use.
  4. Click OK.

Windows stores the logon credentials securely on the local computer and allows their use only for this service.

Creating the keytab file

A keytab is a key table file that contains pairs of Kerberos principal names and encrypted keys that are derived from the Kerberos password. This file can be used to authenticate with Kerberos without being prompted for a password.

A keytab file must be created before it can be used. There are several ways to create this file.
  • The IBM JRE includes a Kerberos key table manager utility, ktab.

    By default, the ktab command generates a file that is named krb5.keytab in the Windows home directory. You can adjust the file name and path by using the -k option.

    The ktab command generates keys in the file by using the encryption algorithms that are specified in the user's krb5.ini or krb5.conf file.

    The following example shows how to use the ktab command.

    ktab -k path_to_keytab -a user_principal user_password
    The example includes these parameters:
    • -k path_to_keytab specifies the keytab file name and path.
    • -a user_principal adds a principal to the keytab file.
    • user_principal is the principal name.
    • user_password is the password that is associated with the principal name.
    To list the contents of a keytab file, use the IBM JRE klist utility, as shown in the following example:
    klist -t -e path_to_keytab
    The example includes these parameters:
    • -t displays the keytab entry time stamps.
    • -e displays the encryption type.
    • path_to_keytab is the name and path of the keytab file.
  • Microsoft Windows Server includes the ktpass utility.

    The following example shows how to use this command.

    ktpass -princ user_principal -pass user_password -crypto encryption_type -ptype ptype -out path_to_keytab 
    The example includes these parameters:
    • -princ user_principal specifies the principal name.
    • -pass user_password specifies the password that is associated with the principal name.
    • -crypto encryption_type specifies the encryption type to use.
    • -ptype ptype sets the principal type.
    • -out path_to_keytab specifies the name and path of the key table file to generate.
    Notes:
    • Ensure that only one encryption algorithm is specified for a principal; avoid specifying -crypto all. The IBM JRE kinit utility does not support multiple entries for the same principal.
    • While Microsoft Active Directory supports Rivest Cipher 4 (RC4), Advanced Encryption Standard 128-bit (AES-128), Advanced Encryption Standard 256-bit (AES-256), and Data Encryption Standard (DES) encryption, it is best to avoid DES, which is considered unsecure.
  • UNIX systems include the ktutil command to create and manage keytab files.

    The ktutil command starts a command-line interface where an administrative user can read, write, or edit entries in a keytab file.

    The following example session shows how to use the ktutil command to add an entry to the current keylist and write the keylist to a keytab file. Then, the klist command is run to display the resulting entries in the keytab file.
    [user@linux]$ ktutil
    ktutil:  addent -password -p USER_PRINCIPAL -k 1 -e aes128-cts-hmac-sha1-96
    Password for USER_PRINCIPAL: <ENTER_PASSWORD>
    ktutil:  wkt /PATH/TO/YOUR/KEYTAB
    ktutil:  l
    slot KVNO Principal
    ---- ---- ---------------------------------------------------------------------
       1    1       USER_PRINCIPAL
    ktutil:  q
    [user@linux]$ klist -ek /PATH/TO/YOUR/KEYTAB
    Keytab name: FILE:/PATH/TO/YOUR/KEYTAB
    KVNO Principal
    ---- ---- ---------------------------------------------------------------------
       1 USER_PRINCIPAL (aes128-cts-hmac-sha1-96)
    [user@linux]$

A keytab file is self-contained and can be transferred between computers. Also, a keytab file does not expire. The file becomes invalid only if the principal is locked out or the principal's password is changed. However, the kinit -k command must be run regularly to refresh tickets, which do expire.

Obtaining new ticket-granting tickets for principals in the keytab file

With keys in the keytab file, it is always possible to obtain a new ticket-granting ticket (TGT) for the stored principals. This TGT mechanism can be used on both Microsoft Windows and UNIX systems; however, it requires that the kinit -k command is run to obtain a fresh TGT. Because tickets expire, the command must be run regularly and always before a ticket expires. To automate running the kinit -k command, an administrative user can set up a task on the Windows system or a cron job on the UNIX system.

Important: Because the keytab file contains encrypted passwords, the file is powerful. Anyone with read permission on the keytab file can run a command in the Kerberos realm on behalf of the contained principals. Therefore, it is important to restrict and monitor permissions on the keytab file so that only the principal whose credentials the application is authenticating with has read-access to the file.

On Windows computers, the administrative user can run the IBM JRE kinit utility to obtain a fresh TGT. On UNIX computers, the user can run either the IBM JRE kinit utility, or the kinit command that is included with the operating system.

The -t option of this utility is used to specify the file name and path of the keytab file. The principal name must always be specified because a keytab file can contain more than one principal, as shown in the following example:
kinit -k -t path_to_keytab user_principal

If the -t option is used without specifying the keytab file name and path, the default path name is used.