For this discussion, we will create a MIT Kerberos domain with the following features (edit them to fit your needs):
Before installing the Kerberos server, a properly configured DNS server is needed for your domain. Since the Kerberos Realm by convention matches the domain name, this section uses the
EXAMPLE.COM domain configured in the section Primary Server of the DNS documentation.
Also, Kerberos is a time sensitive protocol. If the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. To correct the problem all hosts should have their time synchronized using the same Network Time Protocol (NTP) server. Check out the NTP chapter for more details.
The first step in creating a Kerberos Realm is to install the
krb5-admin-server packages. From a terminal enter:
sudo apt install krb5-kdc krb5-admin-server
You will be asked at the end of the install to supply the hostname for the Kerberos and Admin servers, which may or may not be the same server, for the realm. Since we are going to create the realm, and thus these servers, type in the full hostname of this server.
By default the realm name will be domain name of the KDC server.
Next, create the new realm with the
It will ask you for a database master password, which is used to encrypt the local database. Chose a secure password: its strength is not verified for you.
The questions asked during installation are used to configure the
/etc/krb5kdc/kdc.conf files. The former is used by the kerberos 5 libraries, and the latter configures the KDC. If you need to adjust the Key Distribution Center (KDC) settings simply edit the file and restart the
krb5-kdc daemon. If you need to reconfigure Kerberos from scratch, perhaps to change the realm name, you can do so by typing
sudo dpkg-reconfigure krb5-kdc
The manpage for
krb5.confis in the
Let’s create our first principal. Since there is no principal create yet, we need to use
kadmin.local, which uses a local unix socket to talk to the KDC, and requires root privileges:
$ sudo kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: addprinc ubuntu WARNING: no policy specified for ubuntu@EXAMPLE.COM; defaulting to no policy Enter password for principal "ubuntu@EXAMPLE.COM": Re-enter password for principal "ubuntu@EXAMPLE.COM": Principal "ubuntu@EXAMPLE.COM" created. kadmin.local: quit
To be able to use
kadmin remotely, we should create an admin principal. Convention suggests it should be an admin instance, as that also makes creating generic ACLs easier. Let’s create an admin instance for the ubuntu principal:
$ sudo kadmin.local Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin.local: addprinc ubuntu/admin WARNING: no policy specified for ubuntu/admin@EXAMPLE.COM; defaulting to no policy Enter password for principal "ubuntu/admin@EXAMPLE.COM": Re-enter password for principal "ubuntu/admin@EXAMPLE.COM": Principal "ubuntu/admin@EXAMPLE.COM" created. kadmin.local: quit
Next, the new admin principal needs to have the appropriate Access Control List (ACL) permissions. The permissions are configured in the
You can also use a more generic form for this ACL:
The above will grant all privileges to any admin instance of a principal. See the
kadm5.acl manpage for details.
Now restart the
krb5-admin-server for the new ACL to take affect:
sudo systemctl restart krb5-admin-server.service
The new user principal can be tested using the kinit utility:
$ kinit ubuntu/admin Password for ubuntu/admin@EXAMPLE.COM:
After entering the password, use the klist utility to view information about the Ticket Granting Ticket (TGT):
$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: ubuntu/admin@EXAMPLE.COM Valid starting Expires Service principal 04/03/20 19:16:57 04/04/20 05:16:57 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 04/04/20 19:16:55
Where the cache filename
krb5cc_1000 is composed of the prefix
krb5cc_ and the user id (uid), which in this case is
kinit will inspect
/etc/krb5.conf to find out which KDC to contact, and its address. The KDC can also be found via DNS lookups for special TXT and SRV records. You can add these records to your
example.com DNS zone:
_kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc01.example.com. _kerberos._udp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 10 0 88 kdc02.example.com. _kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1 0 749 kdc01.example.com. _kpasswd._udp.EXAMPLE.COM. IN SRV 1 0 464 kdc01.example.com.
See the DNS chapter for detailed instructions on setting up DNS.
A very quick and useful way to troubleshoot what
kinit is doing is to set the environment variable
KRB5_TRACE to a file, or
stderr, and it will show extra information. The output is quite verbose:
$ KRB5_TRACE=/dev/stderr kinit ubuntu/admin  1585941845.278578: Getting initial credentials for ubuntu/admin@EXAMPLE.COM  1585941845.278580: Sending unauthenticated request  1585941845.278581: Sending request (189 bytes) to EXAMPLE.COM  1585941845.278582: Resolving hostname kdc01.example.com (...)
Your new Kerberos Realm is now ready to authenticate clients.