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.

Red Hat Certified Engineer RHCE Video Course
Studying for your RHCE certification? Checkout our RHCE video course over at Udemy which is 20% off when you use the code ROOTUSER.

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/[email protected]'
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/[email protected] with password.
kadmin.local:  addprinc user
WARNING: no policy specified for [email protected]; defaulting to no policy
Enter password for principal "[email protected]":
Re-enter password for principal "[email protected]":
Principal "[email protected]" 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 Kerberos window Linux

Once 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 [email protected]:

[user@client root]$ klist
Ticket cache: KEYRING:persistent:1004:1004
Default principal: [email protected]

Valid starting       Expires              Service principal
06/11/2016 00:51:16  06/12/2016 00:51:16  krbtgt/[email protected]

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


We have successfully configured a key distribution center (KDC) which is capable of providing Kerberos tickets to clients.

This post is part of our Red Hat Certified Engineer (RHCE) exam study guide series. For more RHCE related posts and information check out our full RHCE study guide.

Leave a comment ?


  1. You chose to use a GUI version of authconfig? No wonder you come from a Windows world mate :)

    • Haha, I also just have a bad time with managing sssd manually, I guess authconfig-tui would be my second choice. In an exam they have the GUI available anyway, it’s quick and easy so may as well I say!

      • There was no GUI installed when I took my exam. Perhaps things have changed and it’s now installed on VMs by default.

        Time is premium on RHCE and installing GUI manually takes time (at least for me).

  2. And one other thing, you don’t have to use sssd. You are free to use nslcd if you want to :)

  3. Should we install KDC on RHCE exam? or Do we have access to KDC to modify that ?

  4. Very useful. I have had my IPA setup for sometime and was struggling with how to connect to it and wasn’t sure if I was missing anything.
    Keep up the awesome work.


    I am seeing the below error in my kerb client machine.. i am able to successfully authenticate using klist username from my client.

    Authenticating as principal user1/[email protected] with password.
    kadmin.local: No such file or directory while initializing kadmin.local interface

  6. too bad tho , the GUI part is useless as my last test in may/2017 (took in Singapore ) shown there is no gde installed

  7. I not a big fan of GUI driven configuration, but under time pressure I make exceptions ;)
    Installing the authconfig-gtk as follows took ~20 secs:
    yum -y install authconfig-gtk xauth urw-fonts
    Then log in with ‘ssh -X’ and run authconfog-gtk.

  8. As the 2 keytabs for each systems in the exam are provided, do we still definitely have to go through the authconfig process?


  9. so,let’s say I downloaded the keytab file to the /root,
    I can do something like that:

    chmod 0600 /root/system1.keytab


    but what should be the correct selinux context we need to apply for the keytab file?


    • If you copy the keytab to the correct location (something like /etc/file.keytab I think) and run a restorecon on it, it should automatically change to what it needs to be.

  10. Do you know what version of RHEL is used on the exam? Any idea if the admin credentials for the FreeIPA server are provided? Would like to use ipa-client-install for its simplicity.. still haven’t gotten this process working correctly in setting up Kerberos.

    • The current exams are based on RHEL 7. You should be provided with all required credentials, you don’t need to go hunting for them or set up your own accounts.

      • RHEL 7 I know, but I’ve read about some discrepancies between different versions 7.0-7.5, namely in regard to NFS and Kerberos setup.

        Are you sure about the Kerberos credentials? Someone else told me I’ll need to know how to configure without the admin password.. will the keytab be provided?

        • Oh right, to be honest I can’t recall which version I had specifically, and not sure how frequently they update them, I do remembering having to remember some slight variations in steps for certain things just in case one didn’t work. Keytab was provided.

  11. Actually whenever you use authconfig-tui nslcd is used
    when you use authconfig-gtk then sssd is used as service

  12. [realms]
    # EXAMPLE.COM = {
    # kdc =
    # admin_server =
    # }

    In my case, my domain name is

    # Arivu.COM = {
    # kdc =
    # admin_server =
    # }

    Is this correct or in this “kerberos” i need to add my server name?

  13. I have a question, after getting ticket successfully, what would be the next step?

    I couldn’t ssh from client to server even though i got ticket.
    From client machine, i changed to “myown” user and “ssh server-IP” but it required to enter a password.
    I put in password of “myown” user but it kept asking password.

  14. I follow exactly the steps but I stuck at the kinit (couple of times repeated)

    Error saying
    kinit: Client ‘[email protected]’ not found in Kerberos database while getting initial credentials

    Any service we need to start?

  15. authconfig has been replaced for years by authselect so the GUI is long gone and authselect does not update the files in /etc/pam.d correctly.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>