Kerberos on RHEL

This page describes steps required to get a basic kerberos KDC running on RHEL/RHEL clone (e.g. CentOS). Additional steps may be required for setting up firewalls or other security policies etc., please refer to the respective platform documentation for configuration. Documentation for MIT's implementation is available here. Detailed documentation for installing and configuring kerberos on RHEL can be found here

Introduction

Kerberos is a network authentication protocol which works on the basis of principals and tickets. Every entity in the kerberos ecosystem corresponds to a principal. For example a NFS server may be running with a principal "nfs/nfs-server.ampool.io@AMPOOL.IO" while the a user who is accessing the NFS server has a principal "ent_userX@AMPOOL.IO". The principals for services are also known as service principals and are generally of the format "\/\@REALM" where is the name of the service, is the name of the network host running the service.

Note

KDC has multiple services running on it, for simplicity we will refer the group as a single entity i.e KDC. We will also not go into the details of the contents(parts) of the tickets and which part can be decrypted by which entity's key.

  1. User/client runs kinit(1) command with a principal name(default name is the logged in user name). This sends a TGT request to the KDC, TGT (Ticket Granting Ticket) is a special type of ticket which needs to be fetched only once until it expires.
  2. KDC responds with the TGT (TGT can not be decrypted fully by the user and it has to be presented to the KDC as is for further communication). The user has to use his password to decrypt a part of the data which is used for further communication with the KDC.
  3. The user sends the TGT again to the KDC along with the name of the service(service principal name) it want to access.
  4. The KDC verifies the TGT and returns the service ticket for the service.
  5. The client then presents the service ticket to the service on the network, the service ticket has all information to prove the identity of the user to the service. The service opens up the service ticket using its own key(keytab) and authenticate the client/user for session initiation.

About passwords/keys and keytabs

The tickets issued by the KDC have multiple parts and each part may be encrypted with keys owned by different entities. Each entity has a key to decrypt its part from the ticket, in an interactive session this key is derived from the password which is provided to the user by the administrator. For sessions which are automated; keytabs have the required key to decrypt the corresponding parts of a ticket. If a keytab is provided then there is no need for user to enter a password interactively. Long running services usually use keytabs instead of interactive passwords.

Installing and configuring MIT kerberos KDC on RHEL and RHEL like systems

In this section we will list the steps required to get a KDC running on a RHEL/RHEL Clone system.

Installing the packages

RHEL uses the yum package manager to install packages(dnf is a more recent package manager which has a similar command set as yum). Install the MIT kerberos KDC packages.

yum install -y krb5-server krb5-libs krb5-auth-dialog krb5-workstation

Edit config files

Edit /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf to change the REALM.

A sample kdc.conf may look like:

[kdcdefaults]
 kdc_ports = 88
 kdc_tcp_ports = 88

[realms]
 TEST.AMPOOL.IO = {
  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
 }

The corresponding krb5.conf will may look like:

[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 = TEST.AMPOOL.IO
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
TEST.AMPOOL.IO = {
 kdc = 127.0.0.1
 admin_server = 127.0.0.1
}

[domain_realm]

Note

This krb5.conf file is on the KDC so a kdc address of "127.0.0.1" will work, you can specify any address of KDC host for kerberos clients running on different hosts.

Create the kerberos database

Run the following command to create KDC database

/usr/sbin/kdb5_util create -s

This command may take long time to complete if enough entropy(randomness) is not present on the system. This may happen with systems which are just powered on or are running on a hypervisor as a guest.

Provide admin access to specific principals

Edit /var/kerberos/krb5kdc/kadm5.acl and add princiapls which will be considered administrators by the KDC. A line

*/admin@<YOUR REALM>  *

will make all principals matching the regex administrators. kadmin.local command when run as root can also be used to do admin tasks locally on KDC.

Start the services

Start the KDC and kadmin service.

/sbin/service krb5kdc start
/sbin/service kadmin start

Basic admin operations

Adding a user principal

Run addprinc command from the kadmin shell and provide password for the user.

bash-4.3$ sudo kadmin.local 
Authenticating as principal root/admin@TEST.AMPOOL.IO with password.
kadmin.local:  addprinc test
WARNING: no policy specified for test@TEST.AMPOOL.IO; defaulting to no policy
Enter password for principal "test@TEST.AMPOOL.IO": 
Re-enter password for principal "test@TEST.AMPOOL.IO": 
Principal "test@TEST.AMPOOL.IO" created. 

Adding a service principal

Create a service principal with random key as no human is going to/expected to know the password, it will be used only with keytab.

kadmin.local:  addprinc -randkey nfs/arda.ampool.io
WARNING: no policy specified for nfs/arda.ampool.io@TEST.AMPOOL.IO; defaulting to no policy
Principal "nfs/arda.ampool.io@TEST.AMPOOL.IO" created.
kadmin.local:

Generating keytab for a principal

Use ktadd command to add the keys for a principal to a keytab file

kadmin.local:  ktadd -k /tmp/nfsserver.keytab nfs/arda.ampool.io
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type arcfour-hmac added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type camellia256-cts-cmac added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type camellia128-cts-cmac added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type des-hmac-sha1 added to keytab WRFILE:/tmp/nfsserver.keytab.
Entry for principal nfs/arda.ampool.io with kvno 5, encryption type des-cbc-md5 added to keytab WRFILE:/tmp/nfsserver.keytab.
kadmin.local:  

Attention

keytab files should not be stored in insecure locations (like /tmp) or with insecure permissions(like read for all). Anybody having access to keytab file can act as the service who's keys are in the keytab file.