Designed primarily for client-server model, Kerberos provides mutual authentication where both, the user and the server verify each other’s identity. Its messages are protected against various attacks what makes this mechanism very reliable for authentication between many services. It also allows you to implement SSO authentication for as many services as you want. This is quite practical approach for authenticating many services using a single Kerberos ticket instead of providing passwords for each individual service.

However, Kerberos installation and set-up sometimes can be challenging. That’s why this topic will be split into 3 different parts, each describing the procedures of installing the Kerberos, integrating it with Apache Kafka and Cloudera CDH as an example of Kerberos integration with various software platforms.

This is the first part of Kerberos series where you will be able to install Kerberos server, Kerberos client, and test a simple SSH connection using Kerberos ticketing system.

Prerequisites

Whole process will be done on CentOS 7.5 operating system and before installation begins, you need to configure some things on your machine. By following instructions within this section, you will:

• Create a new sudo user

• Setup and install ntp service

• Configure/etc/hostsfile

• Adjust server’s hostname

CREATING A NEW OS USER

Using command line interface (CLI), login as a root user and run the following commands:

[root~]# adduser [root~]# passwd [root~]# usermod -aG wheel

By running these lines, you will create a new user, create a new password for the new user and add it to the wheel group. Adding user to the wheel group means that they can gain access to administrator levels. It’s typically tied directly into sudo.

NTP SERVICE INSTALLATION AND SETUP

Since the security of Kerberos authentication is in part based upon the time stamps of tickets, it is critical to have accurately set clocks on Kerberos servers. Setting a short ticket lifetime is convenient way of preventing attackers from preforming successful brute force or replay attacks. So, if you allow your clocks of your servers to drift, there is a high chance that you will make your network vulnerable to such attacks. Clock synchronization is of high importance in security of Kerberos and if clocks are not synchronized within a reasonable window, Kerberos will report fatal errors and refuse to function.

NOTE: Clients attempting to authenticate from a machine with an inaccurate clock will be failed by the KDC in authentication attempts due to the time difference with the KDC’s clock!

Installation and setup of NTP service can be done by execution the following lines:

[root~]# yum -y install ntp [root~]# ntpdate 0.rhel.pool.ntp.org [root~]# systemctl start ntpd.service [root~]# systemctl enable ntpd.service

SETTING UP HOSTNAME AND RECONFIGURATION OF HOSTS FILE

The last prerequisite for Kerberos installation is to set properly hostname and content of the/etc/hostsfile. This is quite important since Kerberos uses domain of server’s FQDN as a REALM.

Hosts file configuration

Using one of the text editors, open/etc/hostsfile and configure it as follows:

[root~]# vi /etc/hosts <machine_ip_address> 127.0.0.1 localhost.localdomain localhost # The following lines are desirable for IPv6 capable hosts ::1 localhost.localdomain localhost

Setting up Hostname

It is already mentioned that hostname value plays quite important role in Kerberized environment. Hostname of every machine should match their FQDN so that Kerberos can function properly.

To set the hostname value, first open /etc/hostname file using some text editor that your machine has and change the content to match your machine FQDN, if it’s not already:

[root~]# vi /etc/hostname kdc.example.com

After saving the changes, run the following command. Make sure that you change value so that matches your environment:

[root~]# hostnamectl set-hostname

Verify that your changes were successfully applied by running:

[root~]# hostname kdc.example.com

Kerberos installation and setup

Package list:

• KDC server packages: krb5-server

• Admin packages: krb5-libs

• Client packages: krb5-workstation, pam_krb5

Configuration files:

• kdc.conf

• kadm5.acl

• krb5.conf

KDC SERVER INSTALLATION AND SETUP

Install required packages for KDC Server:

[root~]# yum -y install krb5-server krb5-libs

After installing these packages, start with configuration of three main config files:

• /etc/krb5.conf

• /var/kerberos/krb5kdc/kadm5.acl

• /var/kerberos/krb5kdc/kdc.conf

KRB5.CONF (CLIENT CONFIGURATION)

Start configuration process by configuring client file first. This way it’s going to be easier later to configure the rest of the files.

First thing to consider is Kerberos REALM. Let’s say that your machine FQDN is kdc.example.com. By following Kerberos documentation, REALM should contain whole domain part in capital letters (EXAMPLE.COM).

Knowing this, use again text editor to reconfigure default krb5.conf file:

[root~]# vi /etc/krb5.conf # Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ [libdefaults] default_realm = EXAMPLE.COM dns_lookup_kdc = false dns_lookup_realm = false ticket_lifetime = 86400 renew_lifetime = 604800 forwardable = true default_tgs_enctypes = aes256-cts default_tkt_enctypes = aes256-cts permitted_enctypes = aes256-cts udp_preference_limit = 1 kdc_timeout = 3000 rdns = false [realms] EXAMPLE.COM = { kdc = kdc.example.com admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log

Let us take a look on what’s defined here. Withinlibdefaultsection define your defult_realm. This value will be used as a default value every time when you don’t specify REALM for your principals.

dns_lookup s turned off since enabling this option does open doors to a type of denial-of-service attack, if someone spoofs the DNS records and redirects you to another server.

By using ticket_lifetime we are defing default lifetime for initial ticket requests. The default value is 1 day.

renew_lifetime sets the default renewable lifetime for initial ticket requests. The default value is 0.

If forwardable flag is true, initial tickets will be forwardable. The default value is false.

We will set default_tgs_enctypes, default_tkt_enctypes and permitted_enctypes to aes256-cts which is asimetric hash algorithm that is quite safe. The default value for this tag isaes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4, but single-DES encryption types will be implicitly removed from this list if the value of allow_weak_crypto parameter is false. We removed them in general and only left the strong ones. If you want, you can support more than one algorithm.

If rdns flag is set to true, reverse name lookup will be used in addition to forward name lookup to canonicalizing hostnames for use in service principal names. If dns_canonicalize_hostname is set to false, this rdns flag has no effect. The default value is true, but in our case, we don’t need this so we will set this value to false.

The rest of the config is pretty much self-explanatory.

kadm5.acl

After client configuration, the next step would be to configure kadm5.acl file that is located at/var/kerberos/krb5kdc/kadm5.acl, to specify which principals have access to the kerberos database.

Modify the contet as follows:

[root~]# vi /var/kerberos/krb5kdc/kadm5.acl */admin@EXAMPLE.COM *

kdc.conf

The kdc.conf is the server configuration file and we need to modify it to match some parameters that we defined inside client configuration (krb5.conf):

[root~]# vi /var/kerberos/krb5kdc/kdc.conf [kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88 [realms] EXAMPLE.COM = { #master_key_type = aes256-cts key_stash_file = /var/kerberos/krb5kdc/stash 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 }

Creating KDC Database

Next thing would be creating KDC database that will hold all of principals, This is a short and simple step:

[root~]# kdb5_util create -r EXAMPLE.COM -s

STARTING KERBEROS

To get Kerberos up and running, we need to start and enable two services:

[root~]# systemctl start krb5kdc.service [root~]# systemctl start kadmin.service [root~]# systemctl enable krb5kdc.service [root~]# systemctl enable kadmin.service

CREATING PRINCIPALS

Objects in the KDC database are known as principals and can be users or hosts. Assign root to the adminrole and as a standard user so they can use Kerberized services:

[root~]# kadmin.local kadmin.local: addprinc root/admin kadmin.local: addprinc kadmin.local: quit

Add yours machine FQDN as the new host (kdc.example.com) so that it may host Kerberized services. Also, add principals for each user and server that will use Kerberos and copy the encrypted Kerberos keytab file to every new host that you want to use as Kerberos client:

[root~]# kadmin.local kadmin.local: addprinc -randkey host/kdc.example.com kadmin.local: ktadd host/kdc.example.com kadmin.local: quit

Notice the flag-randkeythat is used here to generate a random password for our host principal. For host principal, you don’t really need to know the passwords since they are encrypted within the keytab file. Keytab, by default, should be located at /etc/krb5.keytab.

SSH Authentication Using Kerberos

In this section, you will be guided through the steps of setting up SSH authentication using Kerberos to verify that your installation was successful. This will allow you to login on remote machine using SSH protocol without providing any passwords. For start, you will configure KDC server to also operate as a client. Later, you will configure another machine to operate only as a Kerberos client.

On KDC Server

Install Kerberos client packages that we mentioned above:

[root~]# yum -y install krb5-workstation pam_krb5

Login to synkerberos01.kdc.syntio.net as the standard user you added to the Kerberos database (username). If you try to runsshcommand to connect to the same server, you will be prompted for a password.

[username~]$ ssh kdc.example.com username@kdc.example.com's password:

In order to avoid this, first we need to confiugre two ssh config files so we can actually use kerberos mechanism. Two main config file to configure are:

• /etc/ssh/ssh_config

• /etc/ssh/sshd_config

Configure/etc/ssh/sshd_configfile to include the following lines:

[root~]# vi /etc/ssh/sshd_config KerberosAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes

Configure/etc/ssh_configto include following lines:

[root~]# vi /etc/ssh/ssh_config Host * GSSAPIAuthentication yes GSSAPIDelegateCredentials yes

These are minimal requirements for running ssh with kerberos authentication mechanism. There are more settings available for this type of authentication, but we will not cover them in this document since they are not requirement for successful testing.

From the command line we can allow Kerberos authentication either using authconfig-tui or simply with the command:

[root~]# authconfig --enablekrb5 --update

This will make changes to the PAM configuration. I would also reload SSH at this stage to be certain everything is in place:

[root~]# systemctl reload sshd

NOTE: Make sure that your firewall is in place. In order to have a successful communication with KDC server, you need to open port 88 for TCP and UDP traffic.

Connect to the KDC and authenticate to receive a token with the following command:

[username~]$ kinit

You will be prompted for a principal password.

If everything went right, You can now list your token using klist:

[username~]$ klist

Output should look something like this: