Add a host or service principal to a keytab using MIT Kerberos
Content |
Tested on |
| Debian (Lenny, Squeeze) |
| Ubuntu (Lucid) |
Objective
To add a host or service principal to a keytab using MIT Kerberos
Background
A keytab is a file used to store the encryption keys for one or more Kerberos principals (usually host and/or service principals). Given one of these keys it is possible to obtain a ticket-granting ticket, so having an encryption key can be equated to having a password. Whenever a host or service principal is created it is normal practice to add it to a keytab.
Kerberos hosts usually have a default keytab with the pathname /etc/krb5.keytab. The host principal should be added to this keytab, but it is not necessarily suitable for use with service principals. The reason is that /etc/krb5.keytab should be readable only by root, whereas on modern systems it is common for network services to execute as a non-root user. The only secure solution to this issue is to have multiple keytabs, each owned by the user that needs access to it.
Scenario
Suppose you wish to allow authentication to the web site http://www.example.com/ using Kerberos. You have created a service principal called HTTP/www.example.com@EXAMPLE.COM for this purpose, and now need to add it to a keytab.
The web site is served using Apache running as the user www-data. The default keytab cannot therefore be used, and you have chosen to create a separate one for use by Apache at the pathname /etc/apache2/http.keytab.
Prerequisites
The method described here assumes that you already have:
- a Kerberos realm with an admin server and at least one KDC (Key Distribution Centre);
- the host or service principal that is to be added to the keytab; and
- an admin principal with at least the
getandchange-passwordcapabilities (iandcinkadm5.acl) in respect of the host or service principal to be added.
It is not necessary for the keytab file to exist beforehand because it will be created if necessary.
To create a service principal see the microHOWTO Create a service principal using MIT Kerberos.
Method
A host or service principal can be added to a new or existing keytab using the ktadd command of kadmin:
kadmin -q "ktadd -k /etc/apache2/http.keytab HTTP/www.example.com"
The -q option specifies a kadmin command to be executed, in this case ktadd.
The -k option of ktadd specifies the pathname of the keytab to which the host or service principal is to be added. If the absence of this option the default keytab at /etc/krb5.keytab is used instead. If the specified keytab does not exist then it will be created.
By default kadmin appends /admin to your default principal or username and attempts to authenticate to the admin server using that. You can specify an alternative admin principal using the -p option if required.
You do not need to be root to run kadmin, however if you are not root then it will probably not be on your path. A common location for the executable is /usr/sbin/kadmin.
It is often convenient to run kadmin on the machine for which the keytab is needed, however you should do this only if you are willing to trust that machine with administrative rights to the realm as a whole. Otherwise, choose a machine that you do trust (such as the KDC). If you transfer a keytab from one machine to another then you should use a secure method such as scp.
On Debian-based systems kadmin is provided by the krb5-user package, whereas on Red Hat-based systems it is provided by the krb5-workstation package.
Testing
List the content of the keytab
You can list the content of a keytab using the ktutil command:
ktutil
This will start an interpreter to which the following two commands should be issued:
ktutil: read_kt /etc/apache2/http.keytab ktutil: list
If the keytab exists and the host or service principal has been correctly added to it then you should see output similar to the following:
slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 3 HTTP/www.example.com@EXAMPLE.COM 2 3 HTTP/www.example.com@EXAMPLE.COM
Send an EOT character (control-D) to exit from ktutil.
Obtain a ticket-granting ticket using the keytab
You can check that the keytab contains the appropriate encryption key by attempting to use it to obtain a ticket-granting ticket. This can be done using the kinit command:
kinit -k -t /etc/apache2/http.keytab HTTP/www.example.com
If the keytab exists and the host or service principal has been correctly added to it then kinit should return immediately, without requesting a password and without printing a message. You can verify that a ticket-granting ticket was obtained using klist, which should product output similar to the following:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/www.example.com@EXAMPLE.COM
Valid starting Expires Service principal
12/04/11 19:46:39 12/05/11 05:46:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 12/05/11 19:48:24
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Once you are satisfied that the keytab is working you should destroy the ticket using the kdestroy command.
Note
The act of creating a keytab has the side effect of setting a new encryption key for the host or service principal. This will cause any keytab that may previously have been created for that host or service principal to be invalidated. You can check whether a keytab entry has been superseded in this way by comparing the Key Version Number (KVNO) within the keytab with that considered current by the KDC.
You should not normally need more than one keytab for any given host or service principal, however this can be a requirement for some types of clustering. In that case the appropriate procedure is to create the keytab once using kadmin then distribute copies to any other machines that need one.
See also
Further reading
- Kerberos V5 System Administrator's Guide, version 1.10, MIT, 2012
- kadmin (Ubuntu manpage)
Tags: kerberos