How to configure Kerberos service principals
Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.
The specific steps to enable Kerberos for a service can vary, but in general both of the following are needed:
- A principal for the service – usually
service/host@REALM
- A keytab accessible to the service wherever it’s running – usually in
/etc/krb5.keytab
For example, let’s create a principal for an LDAP service running on the ldap-server.example.com
host:
ubuntu@ldap-server:~$ sudo kadmin -p ubuntu/admin
Authenticating as principal ubuntu/admin with password.
Password for ubuntu/admin@EXAMPLE.COM:
kadmin: addprinc -randkey ldap/ldap-server.example.com
No policy specified for ldap/ldap-server.example.com@EXAMPLE.COM; defaulting to no policy
Principal "ldap/ldap-server.example.com@EXAMPLE.COM" created.
Let’s dig a bit into what is happening here:
- The
kadmin
command is being run on theldap-server
machine, not on the Key Distribution Center (KDC). We are usingkadmin
remotely. - It’s being run with
sudo
. The reason for this will become clear later. - We are logged in on the server as
ubuntu
, but specifying anubuntu/admin
principal. Remember theubuntu
principal has no special privileges. - The name of the principal we are creating follows the pattern
service/hostname
. - In order to select a random secret, we pass the
-randkey
parameter. Otherwise we would be asked to type in a password.
With the principal created, we need to extract the key from the KDC and store it in the ldap-server
host, so that the ldap
service can use it to authenticate itself with the KDC. Still in the same kadmin
session:
kadmin: ktadd ldap/ldap-server.example.com
Entry for principal ldap/ldap-server.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal ldap/ldap-server.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
This is why we needed to run kadmin
with sudo
: so that it can write to /etc/krb5.keytab
. This is the system keytab file, which is the default file for all keys that might be needed for services on this host, and we can list them with klist
. Back in the shell:
$ sudo klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 ldap/ldap-server.example.com@EXAMPLE.COM
2 ldap/ldap-server.example.com@EXAMPLE.COM
If you don’t have the kadmin
utility on the target host, one alternative is to extract the keys on a different host and into a different file, and then transfer this file securely to the target server. For example:
kadmin: ktadd -k /home/ubuntu/ldap.keytab ldap/ldap-server.example.com
Entry for principal ldap/ldap-server.example.com with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/home/ubuntu/ldap.keytab.
Entry for principal ldap/ldap-server.example.com with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/home/ubuntu/ldap.keytab.
Note:
Notice how thekvno
changed from2
to3
in the example above, when usingktadd
a second time? This is the key version, and it invalidated the previously extracted key withkvno 2
. Every time a key is extracted withktadd
, its version is bumped and that invalidates the previous ones!
In this case, as long as the target location is writable, you don’t even have to run kadmin
with sudo
.
Then use scp
to transfer it to the target host:
$ scp /home/ubuntu/ldap.keytab ldap-server.example.com:
And over there copy it to /etc/krb5.keytab
, making sure it’s mode 0600
and owned by root:root
.