Add a host or service principal to a keytab using MIT Kerberos
|Debian (Lenny, Squeeze)|
To add a host or service principal to a keytab using MIT Kerberos
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.
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
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
kadm5.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.
A host or service principal can be added to a new or existing keytab using the
ktadd command of
kadmin -q "ktadd -k /etc/apache2/http.keytab HTTP/www.example.com"
-q option specifies a
kadmin command to be executed, in this case
-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.
/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
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
On Debian-based systems
kadmin is provided by the
krb5-user package, whereas on Red Hat-based systems it is provided by the
You can list the content of a keytab using the
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
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 -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
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.