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
- Creating the keytab file
- Obtaining new ticket-granting tickets for principals in the keytab file
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.
- Open the Windows Services dialog box.
- Click Start.
- In the Search field, type services.msc. Then, press Enter.
- In the details pane, find the service, right-click it, and click Properties.
- On the Log On tab, specify the user account and password for the service to use.
- 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.
- 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_passwordThe example includes these parameters:
To list the contents of a keytab file, use the IBM JRE klist utility, as shown in the following example:
-k path_to_keytabspecifies the keytab file name and path.
-a user_principaladds a principal to the keytab file.
user_principalis the principal name.
user_passwordis the password that is associated with the principal name.
klist -t -e path_to_keytabThe example includes these parameters:
-tdisplays the keytab entry time stamps.
-edisplays the encryption type.
path_to_keytabis 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_keytabThe example includes these parameters:
-princ user_principalspecifies the principal name.
-pass user_passwordspecifies the password that is associated with the principal name.
-crypto encryption_typespecifies the encryption type to use.
-ptype ptypesets the principal type.
-out path_to_keytabspecifies the name and path of the key table file to generate.
- 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.
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.
kinit -k -t path_to_keytab user_principal
-t option is used without specifying
the keytab file name and path, the default path name is used.