LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Advisory Watch: August 29th, 2014
Linux Security Week: August 25th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Kerberos Server Replication

5. Kerberos Server Replication

5.1. Description of Replication

Kerberos was designed to allow for a Master/Slave replication cluster. While a Kerberos cluster can consist of any number of hosts, it is recommended that you have at least two. A master which serves as the primary server and at least one slave which is available as a backup to the master. The master and slave servers may be thought of as Primary and Secondary servers respectively.

Kerberos stores all of its information, both account and policy data, in application databases. The Kerberos software distribution includes software for replicating, or copying, this data to other servers.

Kerberos client applications are designed to attempt authentication against secondary servers if the primary master is down. Therefore you do not need to do any extra work during a system failure to fail over your Kerberos authentication service to the backup server. However, the administrative features of Kerberos do not provide for automatic failover.

In the event that your primary server fails, kadmind will be unavailable. Therefore, administrative functions will be unavailable until the primary server is restored or replace. Specifically, principal management, key creation, and key changes, cannot be done during a primary server failure.

5.2. Implementation

Server replication is handled by the kprop command. kprop must be run on the primary master KDC. It should be run in a scheduled cron job to keep the principal database in sync across all servers.

The first step in setting up replication, is to set up ACLs for kpropd. The kpropd acl filename is by default located at /var/Kerberos/krb5kdc/kpropd.acl. In our example, it would have the following contents:


host/kerberos1.gnud.ie@GNUD.IE
host/kerberos2.gnud.ie@GNUD.IE

The kpropd.acl file should only exist on the slave Kerberos server. In Fedora derived GNU/Linux, kadmin will not run on a Kerberos server on which /var/Kerberos/krb5kdc/kpropd.acl exists.

Next you'll need to create host keys for your master and slave Kerberos servers:


{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local:  addprinc -randkey host/kerberos1.gnud.ie
{Kerberos1}kadmin.local:  addprinc -randkey host/kerberos2.gnud.ie

The next step is to extract these keys to the keytab file. The keytab file is a keyring which contains the cryptographic keys needed to authenticate with the KDC. Extraction of keys to the keytab is done with the ktadd sub command:


{Kerberos1}kadmin.local:  ktadd host/kerberos1.gnud.ie
{Kerberos1}kadmin.local:  ktadd host/kerberos2.gnud.ie

Finally, we want to copy the keytab over to the slave server so that it has the keys it needs available to authenticate.


{Kerberos2}bash# scp root@kerberos1.gnud.ie:/etc/krb5.keytab /etc

Here is a crontab entry from the master Kerberos server used to synchronize principal databases every fifteen minutes:


15 * * * * /usr/local/bin/krb5prop.sh

Here are the contents of the krb5prop.sh script:


#!/bin/sh

/usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans

/usr/Kerberos/sbin/kprop -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie > /dev/null

Initially running this command by hand, you should see something similar to the following:


{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util dump /var/Kerberos/krb5kdc/slave_datatrans
{Kerberos1}bash# /usr/Kerberos/sbin/kprop -d -f /var/Kerberos/krb5kdc/slave_datatrans kerberos2.gnud.ie
3234 bytes sent.
Database propagation to kerberos2.gnud.ie: SUCCEEDED
{Kerberos1}bash#

The slave server will now synchronize its principal database with the master server.

5.3. Maintenance

With these cron jobs in place principal propagation should be sufficiently automated as to require no maintenance. At the time of a primary KDC failure, there is no need for human intervention unless the failure will last for an extended period of time.

    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Weekend Edition
How Cops and Hackers Could Abuse California’s New Phone Kill-Switch Law
Why Russian hackers are beating us
DQ Breach? HQ Says No, But Would it Know?
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.