How To Configure Linux To Authenticate Using Kerberos

Kerberos is an authentication protocol that can provide secure network login or SSO for various services over a non-secure network. Kerberos works with the concept of tickets which are encrypted and can help reduce the amount of times passwords need to be sent over the network.

These tickets are issued throughout the Kerberos realm by a centralised key distribution center (KDC). Here we will cover how to setup a KDC and obtain a Kerberos ticket from a client system in CentOS Linux.

Note that for the RHCE exam you will not have to actually create the KDC, you will only need to setup a client to connect to an existing KDC. We have covered both parts so that you can create your own KDC in order have something to connect to while learning.

Example Environment

Here is a list of our servers that we will be testing with, both are running CentOS 7.

  • Kerberos Server (KDC): – This Linux server will act as our KDC and serve out Kerberos tickets.
  • Kerberos Client: – This Linux client will request Kerberos tickets from the KDC.


In order for Kerberos to function correctly, the following must first be configured on both servers.

  • NTP: Time synchronization is required, if the time difference is more than 5 minutes authentication will fail. See our guide on synchronizing time with NTP for further details regarding setting this up.
  • DNS: The FQDN’s should ideally resolve in a proper environment, however here we do get by with only using IP addresses. Modifying /etc/hosts would also work for testing, however using DNS properly is recommended.

Setup a KDC

As mentioned previously, setting up a KDC is not an RHCE objective, however you will need one in order to perform other objectives that use Kerberos, such as setting up NFS to use Kerberos.

The following commands are run on our KDC server.

yum install krb5-server krb5-workstation

Once these packages have been installed the /etc/krb5.conf file needs to be modified. By default a few things are commented out that need to be configured. Below is a copy of the default configuration.

 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
# default_realm = EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{uid}

#  kdc =
#  admin_server =
# }


Remove the comments from default_realm, and the entire [realms] section and set these appropriately for your environment, for this example I’ll stick with using, with my kdc being

Next edit the /var/kerberos/krb5kdc/kdc.conf file and again replace the instances of to your particular domain, again I will be leaving this as default as I am using the domain here for testing.

 kdc_ports = 88
 kdc_tcp_ports = 88

  #master_key_type = aes256-cts
  acl_file = /var/kerberos/krb5kdc/kadm5.acl
  dict_file = /usr/share/dict/words
  admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
  supported_enctypes = aes256-cts:normal aes128-cts:normal des3-hmac-sha1:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal

Create a Kerberos Database

Now we’re ready to create a Kerberos database with the kdb5_util command as shown below. You will be prompted to enter a password which will act as the master key, this is used by the KDC to encrypt the database so it is very important to store this securely.

[root@kdc ~]# kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

This command took about a minute to complete as it took a while to load random data, you can move your mouse around in the GUI or press keys to speed up the process. The -s flag is specified so that a stash file is created, allowing for the Kerberos service to automatically start up without requiring the master key to be provided manually.

Service Management

Speaking of starting automatically, we want to enable and start both kadmin and krb5kdc so that our Kerberos KDC services will be automatically available after system reboot.

[root@kdc ~]# systemctl enable kadmin krb5kdc
Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/kadmin.service.
Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/krb5kdc.service.

[root@kdc ~]# systemctl start kadmin krb5kdc

For further information on basic service management with systemctl, see our guide here.

Firewall Configuration

In order for other systems to communicate with the services of the KDC, correct firewall rules need to be set. This can be done as shown below with firewalld.

[root@kdc ~]# firewall-cmd --permanent --add-service=kerberos
You have new mail in /var/spool/mail/root

[root@kdc ~]# firewall-cmd --reload

The predefined Kerberos service allows both TCP/UDP port 88 traffic in. We can check and confirm that the krb5kdc service is indeed listening on these ports for connections.

[root@kdc ~]# netstat -antup | grep krb
tcp        0      0    *               LISTEN      12744/krb5kdc
tcp6       0      0 :::88                   :::*                    LISTEN      12744/krb5kdc
udp        0      0    *                           12744/krb5kdc
udp6       0      0 :::88                   :::*                                12744/krb5kdc

We have only allowed Kerberos through, note that traffic to kadmin requires TCP 749 so if you want to access that remotely you’ll need to consider opening that too, however for our purposes and to increase security we’ll leave that as local access only.

Kerberos Administration

The KDC can be administered by running the kadmin.local command. To view available commands within the kadmin.local context, simply run ‘?’. From this helpful information we can see that ‘addprinc’ can be used to add a Kerberos principal, which we’ll do for our ‘user’ account.

[root@kdc ~]# kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local:  addprinc user
WARNING: no policy specified for user@EXAMPLE.COM; defaulting to no policy
Enter password for principal "user@EXAMPLE.COM":
Re-enter password for principal "user@EXAMPLE.COM":
Principal "user@EXAMPLE.COM" created.

Our KDC is now ready to accept client connections and provide tickets to the ‘user’ principal.

Setup The Client

Now it’s time to configure our client system to use the KDC. There are a few different methods that you can use to complete this, personally I find using the GUI to actually be very quick and easy here. In order to use the GUI, first install the authconfig-gtk package.

yum install authconfig-gtk -y

Once complete simply run ‘authconfig-gtk’ from a terminal window within the GUI. This will open up the Authentication Configuration window. From the Identity & Authentication tab, select LDAP from the User Account Configuration drop down in order to get access to the Authentication Configuration which is where we will select Kerberos password and provide our realm and KDC information.

In this example, as shown previously the realm on the KDC is EXAMPLE.COM, the IP address of our KDC is as I do not have DNS setup I am not able to use the FQDN, and the admin server is also the same as the KDC as this is where kadmin is running.

authentication-configuration-window-linuxOnce you have defined your realm and KDC, click the Apply button.

If you’re not a fan of the GUI or simply don’t have one installed, you can also use the text user interface instead by running ‘authconfig-tui’. Both of these will configure our /etc/sssd/sssd.conf file automatically, however you can manually edit this if you know what you’re doing. Personally I’ve always had a terrible experience when trying to set sssd.conf manually, so I definitely recommend using either of these authconfig tools.

Create the user

On our KDC we have created a principal for ‘user’, we’ll now create a local user account on the client system. This is not technically required, we should be able to kinit from another user however for consistency we’ll use this account.

[root@client ~]# useradd user

Now we’re ready to try and get a ticket from the KDC, first we become the new user and run the ‘kinit’ command which is used to obtain and cache our Kerberos ticket.

[root@client ~]# su user

[user@client root]$ kinit
Password for user@EXAMPLE.COM:

[user@client root]$ klist
Ticket cache: KEYRING:persistent:1004:1004
Default principal: user@EXAMPLE.COM

Valid starting       Expires              Service principal
06/11/2016 00:51:16  06/12/2016 00:51:16  krbtgt/EXAMPLE.COM@EXAMPLE.COM

From ‘klist’ we can see that we have been issued with a ticket which is valid for 24 hours.