Part II – Configuring a Master/Slave Kerberos Servers
In Part II, a Master/Slave Kerberos implemenation will be configured together with the necessary tools to replicate/propagate the Heimdal Database from Master to Slave Kerberos Servers.
PreRequisites:
In this tutorial, a Master/Slave Kerberos implementation will be demonstrated. The configuration from Part I of this series will be carried forward in this tutorial. As before, 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:
The configuration files below are from Part I of this tutorial and are reproduced for continuity.
/etc/rc.conf:
kdc_enable="YES" kadmind_enable="YES"
/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.
Slave Server – bsd222.loga.us – Configuration:
On the Slave Server, the /etc/rc.conf and /etc/krb5.conf are virtually identical with the exception noted below for ‘kadmind’
/etc/rc.conf:
kdc_enable="YES"
# kadmind_enable="YES" - Only started on the Master Server
/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.
Copy /etc/krb5.keytab, /var/heimdal/heimdal.db, and /var/heimdal/m-key from the Master Server to the Slave Server
The Slave Server requires an exact copy of the Master Server’s krb5.keytab, heimdal.db and m-key files. To ensure consistency, try to create all the required keytab principals before copying to the Slave Server. This allows the Slave Server to promote to a Master Server in the event the Master Server is permanently non-functional. After copying the files, ensure the file permissions are the same on the slave as on the master.
Initializing and Testing the installation:
Starting the kerberos services on the Slave Server
# service start kdc
Initialize Principal on the Slave Server
# kinit shanes shanes@LOGA.US's Password:
Confirm ticket creation on the Slave Server
# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: shanes@LOGA.US Issued Expires Principal Dec 13 18:58:21 2015 Dec 14 00:58:21 2015 krbtgt/LOGA.US@LOGA.US
Client Configuration and Testing:
On your client, assuming Macintosh OS X in our case, add the following file to the system:
/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.
Initialize Principal on the Client
# kinit shanes shanes@LOGA.US's Password:
Confirm ticket creation on the Client
# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: shanes@LOGA.US Issued Expires Principal Dec 13 18:58:21 2015 Dec 14 00:58:21 2015 krbtgt/LOGA.US@LOGA.US
Testing Senario:
- Stop Master Server kdc and kadmin service. From the client, kdestroy any tickets, then kinit to obtain a new ticket from Slave Server. If successful, move on to step 2 or stop and retrace your steps.
- Restart Master Server kdc and kadmin services. Stop Slave Server kdc services. From the client, kdestroy any tickets, then kinit to obtain a new ticket from the Master Server. If successful, move on or stop and retrace your steps.
Database Replication/Propagation:
As mentioned earlier, every slave needs a copy of the master database, master key, and keytab. Additionally, the keytab, must have the principal “hprop/hostname” for at least the slave, but include the master as well.
Master Server – bsd220.loga.us – Configuration:
The Master Server will initiates the push to securely copy /var/heimdal/heimdal.db from the Master Server to the Slave Server by starting hprop via cron. Below is the crontab -e entry used to automate this process
45 * * * * /usr/libexec/hprop bsd222.loga.us
Slave Server – bsd222.loga.us – Configuration:
The slave server will run hpropd via inetd:
/etc/inetd.conf:
Add the following to the end of the file:
krb5_prop stream tcp nowait root /usr/libexec/hpropd hpropd
/etc/rc.conf:
Add the following to /etc/rc.conf:
inetd_enable="YES"
To manually start inetd:
# service inetd start
Testing Database Replication/Propagation:
- Create a new principal on the Master Server.
- Either wait for the cronjob to execute or manually run ‘hprop’ on the Master Server.
- Stop the kdc and kadmind services on the Master Server.
- Execute the kdestroy command to remove any Kerberos Tickets.
- Use kinit as the new principal just added then issue the klist command to verify Kerberos Ticket was created.
- If all went well, you should see the Kerberos Ticket of the principal.
Summary:
Hopefully, the Master/Slave Replication is working as expected. In part III, SASL/GSSAPI and saslauthd will be utilized to provide pass thru authentication with an OpenLDAP Server.
References:
FreeBSD Handbook Chapter on Kerberos