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): 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.
[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/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. [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.
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.
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 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.
[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 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.
[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.
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.