Each system that will use Kerberos authentication must have a keytab file installed. This file essentially contains a username+password for a “machine” account, and allows the host to validate that the Kerberos server it is talking to is not being spoofed. The principal (“username” in Kerberos speak) stored in the keytab is of the form host/<FQDN>@UMD.EDU e.g. host/linuxrocks.cs.umd.edu@UMD.EDU.

Requesting Access to Create Keytabs

DIT can configure delegated access to allow departmental IT to create and manage their own keytab files without having to involve DIT. Access will be configured on a per-domain basis, for example allowing computer science administrators to manage keytabs for hosts in the .cs.umd.edu domain.

If you need such access, please email request@umd.edu with your request to create Kerberos principals and keytabs for your department. Please include, if applicable, the subdomain e.g. cs.umd.edu or naming pattern e.g. engr-blahblah.umd.edu you use for your hosts. Please also include any other folks on your team that would need to be able to create or delete principals for your department.

Once your request is approved and implemented, you can use dept_mk_keytab to create keytabs for your hosts.

Creating Keytabs via dept_mk_keytab

The dept_mk_keytab script is available on glue.umd.edu (or any DIT-managed system with the glueadmin profile) and can be used to create keytab files. Follow the instructions below to create a keytab interactively:

1. Run the mk_keytab script:
   /usr/glue/scripts/dept_mk_keytab

   The script then prompts you for input. 

2. The script first prompts you for the principle name. The default value, "host", should be used. Just press return: 
   Name [host]: <PRESS RETURN TO SELECT DEFAULT>

3. The script then prompts you for the instance aka hostname to associate with this principle. Enter the fully-qualified domain name of your host:
   Instance (e.g. foo.math.umd.edu): somehost.cs.umd.edu

4. The script then prints the full principle name and asks for confirmation. Type "y" to confirm the principle is correct. Otherwise, type "n".
   New principal: host/somehost.cs.umd.edu@UMD.EDU
   Is this correct? (y,n) [y] y

5. At this stage, the script will create the new principle and keytab and drop the keytab into the /tmp directory by default:
   Setting key for host/somehost.cs.umd.edu@UMD.EDU...
   Adding principal to keytab /tmp/krb5.keytab.somehost.cs.umd.edu.XYbxHd...
   Done. keytab left in file /tmp/krb5.keytab.somehost.cs.umd.edu.XYbxHd.
   

6. Done! The principle and keytab have now been created.

Using dept_mk_keytab Non-interactively

You can also specify all of the required information via commandline parameters as seen below rather than enter them interactively:
z.glue:~: dept_mk_keytab -f krb5.keytab.anotherhost.cs.umd.edu -n host -i anotherhost.cs.umd.edu -y
New principal: host/anotherhost.cs.umd.edu@UMD.EDU
Setting key for host/anotherhost.cs.umd.edu@UMD.EDU...
Adding principal to keytab krb5.keytab.anotherhost.cs.umd.edu...
Done. keytab left in file krb5.keytab.anotherhost.cs.umd.edu.

This also allows one to process a file containing a list of hosts in an automated fashion:
# process all hosts in a file
foreach host (`cat ~/myhostlist`)
  dept_mk_keytab -f "krb5.keytab.${host}" -n host -i "${host}" -y
end

where the myhostlist file simply contains a list of hosts:
host1.umd.edu
host2.umd.edu
host3.umd.edu
[...]

Listing the Contents of a Keytab File

Securely Transferring Keytab Files

Keytabs should be handled like passwords. Once created, be sure to transfer it securely to the actual host it belongs to. For example, via scp:
# At this point we need to treat the keytab file as a secret, and 
# securely transfer it to the destination machine 
scp /tmp/krb5.keytab.somehost.cs.umd.edu.XYbxHd somehost.cs.umd.edu:/etc/krb5.keytab 
rm /tmp/krb5.keytab.somehost.cs.umd.edu.XYbxHd