Part I – Configuring Kerberos Server and Client

In Part I, configuring a Heimdal Kerberos Server and Client is demonstrated.  Additionally, SSH will be configured to allow single sign on using Kerberos.

 

PreRequisites:

In this tutorial, the base installation of Heimdal Kerberos is utilized as opposed to installing it from the Ports Collection.  Installation of Cyrus SASL Ports is needed, as well as, a working OpenLDAP Directory Server.  The tutorial will not cover the installation and configuration of OpenLDAP which is covered in previous tutorials posted on this site.  Additionally, a functional DNS Server is required with forward and reverse host name resolution.  Also, all the clients and servers require the same time.  Please set all the ntpd daemons to the appropriate settings to ensure consistent time accross the network.

 

Heimdal Kerberos:

Setting up a Heimdal KDC – Key Distribution Center is fairly straight forward.  However, setting up a Heimdal KDC in a Master/Slave configuration takes a bit more, however, the effort is worth the additional effort.

 

Operating Environment:

Server 1 – Master Server:

Hostname: bsd220.loga.us

IP Address: 192.168.0.220

Server 2 – Slave Server:

Hostname: bsd222.loga.us

IP Address: 192.168.0.222

 

DNS Resolution:

Before we get started we need to ensure our Kerberos Servers have the proper DNS entries and that the host names can be resolved.

root@bsd220:/ # host bsd220.loga.us
bsd220.loga.us has address 192.168.0.220

root@bsd220:/ # host bsd222.loga.us
bsd220.loga.us has address 192.168.0.222

Of course, the reverse lookup, as well… 

root@bsd220:/ # host 192.168.0.220
220.0.168.192.in-addr.arpa domain name pointer bsd220.loga.us.

root@bsd220:/ # host 192.168.0.222
222.0.168.192.in-addr.arpa domain name pointer bsd222.loga.us.

 

Master Server – bsd220.loga.us – Configuration:

Add these lines to /etc/rc.conf:

kdc_enable="YES"
kadmind_enable="YES"

 

Next, edit /etc/krb5.conf:

[libdefaults]
    default_realm = LOGA.US
[realms]
    LOGA.US = {
        kdc = 192.168.0.220
        kdc = 192.168.0.222
        admin_server = 192.168.0.220
    }
[domain_realm]
    .loga.us = LOGA.US

Note:  IP Addresses are used in the krb5.conf.  I found using FQDN’s for KDC’s and the Admin Server produce inconsistent results when the KDC FQDN, the Admin Server FQDN and the HostName of the server are all the same, especially when utilizing a Master/Slave configuration.

 

Create the Kerberos Database:

Create the Kerberos Database using the kstash command and enter a Master Key for security.

# kstash
# Master key: xxxxxxxxxx
# Verifying password - Master key: xxxxxxxxxx

 

Initialize the Kerberos Database:

Initialize the Kerberos Database with the kadmin utility using the -l option.

# kadmin -l
# kadmin> init LOGA.US
* Accept default options

 

Adding Principals:

While still in kadmin, create a principal ‘loga’ using the add command.  Type ? at the prompt for available options.

kadmin> add shanes
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx

 

Before we move on, let’s create an ‘admin’ principal

kadmin> add larry/admin
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx

 

Access to the administration server is controlled by an ACL file, /var/heimdal/kadmind.acl.  Please create this file in the appropriate directory with the following contents:

larry/admin@LOGA.US all

 

Initializing and Testing the installation:

Starting the kerberos services

# service kdc start
# service kadmind start

Initialize  Principal

# kinit shanes
shanes@LOGA.US's Password:

Confirm ticket creation

# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: shanes@LOGA.US

  Issued                Expires               Principal
Dec 13 14:48:21 2015  Dec 14 00:48:21 2015  krbtgt/LOGA.US@LOGA.US

 

Configuring a Server to utilize Kerberos:

The next step is creating keytabs for Kerberos Services such as LDAP.  However, before starting this process, one should initialize an admin kerberos principal using the kinit command.  Using our ‘admin’ principal larry/admin, the kinit command is as follows:

# kinit larry/admin

 

# kadmin
kadmin> add --random-key ldap/bsd220.loga.us
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
kadmin> ext_keytab ldap/bsd220.loga.us
kadmin> exit

 

Additionally, the ktutil command can be used to accomplish the same function

# ktutil get -p larry/admin ldap/bsd220.loga.us

Note: Use the service/hostname format for the Kerberos Principal

 

To complete the task of adding keytabs for the various principals, the following additional keytabs need to be added via the kadmin or ktutil utilities

host/bsd220.loga.us
host/bsd222.loga.us
ldap/bsd220.loga.us
ldap/bsd222.loga.us
hprop/bsd220.loga.us
hprop/bsd222.loga.us

* The keytab hprop/bsd220.loga.us and hprop/bsd222.loga.us are utilized for replication

 

A list of keytabs can be obtained using the ktutil command:

# ktutil list

Vno  Type                     Principal                     Aliases
  1  aes256-cts-hmac-sha1-96  host/bsd220.loga.us@LOGA.US   
  1  des3-cbc-sha1            host/bsd220.loga.us@LOGA.US   
  1  arcfour-hmac-md5         host/bsd220.loga.us@LOGA.US   
  1  aes256-cts-hmac-sha1-96  host/bsd222.loga.us@LOGA.US   
  1  des3-cbc-sha1            host/bsd222.loga.us@LOGA.US   
  1  arcfour-hmac-md5         host/bsd222.loga.us@LOGA.US   
  1  aes256-cts-hmac-sha1-96  ldap/bsd220.loga.us@LOGA.US   
  1  des3-cbc-sha1            ldap/bsd220.loga.us@LOGA.US   
  1  arcfour-hmac-md5         ldap/bsd220.loga.us@LOGA.US   
  1  aes256-cts-hmac-sha1-96  ldap/bsd222.loga.us@LOGA.US   
  1  des3-cbc-sha1            ldap/bsd222.loga.us@LOGA.US   
  1  arcfour-hmac-md5         ldap/bsd222.loga.us@LOGA.US   
  1  aes256-cts-hmac-sha1-96  hprop/bsd220.loga.us@LOGA.US  
  1  des3-cbc-sha1            hprop/bsd220.loga.us@LOGA.US  
  1  arcfour-hmac-md5         hprop/bsd220.loga.us@LOGA.US  
  1  aes256-cts-hmac-sha1-96  hprop/bsd222.loga.us@LOGA.US  
  1  des3-cbc-sha1            hprop/bsd222.loga.us@LOGA.US  
  1  arcfour-hmac-md5         hprop/bsd222.loga.us@LOGA.US

 

Configuring Kerberos Client

The client requires the same exact /etc/krb5.conf file located on the server.  In our case, the contents of the /etc/krb5.conf file are as follows:

[libdefaults]
    default_realm = LOGA.US
[realms]
    LOGA.US = {
        kdc = 192.168.0.220
        kdc = 192.168.0.222
        admin_server = 192.168.0.220
    }
[domain_realm]
    .loga.us = LOGA.US

Note:  IP Addresses are used in the krb5.conf.  I found using FQDN’s for KDC’s and the Admin Server produce inconsistent results when the KDC FQDN, the Admin Server FQDN and the HostName of the server are all the same, especially when utilizing a Master/Slave configuration.

 

Kerberizing the Server and Client for SSH:

On the Master Server – bsd220.loga.us.  Change the file, /etc/ssh/sshd_config, to reflect the following:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

On the Client, change the file /etc/ssh/ssh_config, to reflect the following:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

 

Testing the Kerberos implemenation:

On the client, ensure you kinit as the principle who you will login to the server via ssh contains the same username and password as that user.  Even without Kerberos, the user ‘shanes’ should be able to login via ssh to the server bsd220.loga.us.  As the kerberized principle ‘shanes’, he should login without being prompted for a password.

# kinit shanes
# ssh shanes@bsd220.loga.us
shanes@bsd220:~ %

 

After kinit as shanes, you should not be prompted with a password request.  If you do, make sure you have a principal ‘shanes’ in the kerberos database using the kadmin utility.

# kadmin -l
kadmin > list *
shanes
default
larry/admin
kadmin/admin
kadmin/hprop
krbtgt/LOGA.US
kadmin/changepw
changepw/kerberos
host/bsd220.loga.us
host/bsd222.loga.us
ldap/bsd220.loga.us
ldap/bsd222.loga.us
WELLKNOWN/ANONYMOUS
hprop/bsd220.loga.us
hprop/bsd222.loga.us

Summary:

Hopefully, the configuration of Kerberos and the subsequent SSH configurations worked as expected.  In part II, the configuration of the Slave Kerberos Server and replication from the Master Kerberos Server will be demonstrated.

 

References:

Heimdal Kerberos Github Wiki

MIT Kerberos Documentation

FreeBSD Handbook Chapter on Kerberos