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.
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): 192.168.1.13 – This Linux server will act as our KDC and serve out Kerberos tickets.
- Kerberos Client: 192.168.1.14 – This Linux client will request Kerberos tickets from the KDC.
Prerequisites
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.
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false # default_realm = EXAMPLE.COM default_ccache_name = KEYRING:persistent:%{uid} [realms] # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } [domain_realm] # .example.com = EXAMPLE.COM # example.com = EXAMPLE.COM
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 example.com, with my kdc being kdc.example.com
Next edit the /var/kerberos/krb5kdc/kdc.conf file and again replace the instances of example.com to your particular domain, again I will be leaving this as default as I am using the example.com domain here for testing.
[kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88 [realms] EXAMPLE.COM = { #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.
[[email protected] ~]# 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.
[[email protected] ~]# systemctl enable kadmin krb5kdc Created symlink from /etc/systemd/system/multi-user.target.wants/kadmin.service to /usr/lib/systemd/system/kadmin.service. Created symlink from /etc/systemd/system/multi-user.target.wants/krb5kdc.service to /usr/lib/systemd/system/krb5kdc.service. [[email protected] ~]# 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.
[[email protected] ~]# firewall-cmd --permanent --add-service=kerberos success You have new mail in /var/spool/mail/root [[email protected] ~]# firewall-cmd --reload success
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.
[[email protected] ~]# netstat -antup | grep krb tcp 0 0 0.0.0.0:88 0.0.0.0:* LISTEN 12744/krb5kdc tcp6 0 0 :::88 :::* LISTEN 12744/krb5kdc udp 0 0 0.0.0.0:88 0.0.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.
[[email protected] ~]# 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 192.168.1.13 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.
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.
[[email protected] ~]# 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.
[[email protected] ~]# su user [[email protected] root]$ kinit Password for [email protected]: [[email protected] 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.
Summary
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.
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).
And one other thing, you don’t have to use sssd. You are free to use nslcd if you want to :)
Should we install KDC on RHCE exam? or Do we have access to KDC to modify that ?
Installing a KDC is not listed as an objecting on the Red Hat website so I would therefore not worry about needing to know how to do that during the exam.
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
too bad tho , the GUI part is useless as my last test in may/2017 (took in Singapore ) shown there is no gde installed
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.
HTH
Good to know! Haha me either usually, but for setting up Kerberos auth it can make it a lot quicker I’ve found :)
Impeccable Article.
As the 2 keytabs for each systems in the exam are provided, do we still definitely have to go through the authconfig process?
Thanks
If you have a keytab file you just need to copy it to the correct location and set the correct permissions / SELinux context.
so,let’s say I downloaded the keytab file to the /root,
I can do something like that:
chmod 0600 /root/system1.keytab
correct?
but what should be the correct selinux context we need to apply for the keytab file?
Thanks
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.
Thank you!!
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.
Actually whenever you use authconfig-tui nslcd is used
when you use authconfig-gtk then sssd is used as service
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
In my case, my domain name is Arivu.com
[realms]
# Arivu.COM = {
# kdc = kerberos.Arivu.com
# admin_server = kerberos.Arivu.com
# }
Is this correct or in this “kerberos” i need to add my server name?
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.
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?
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. https://fedoraproject.org/wiki/Changes/Authselect