Kerberos è stato progettato per permettere l'implementazione di un cluster di replica in configurazione master e slave. Un cluster Kerberos può consistere in qualunque numero di host; si raccomanda di schierarne almeno due: un master che funziona come server principale e almeno uno slave che resta disponibile come backup del master. I server master e slave sono anche detti rispettivamente server primario e server secondario.
Kerberos conserva tutte le sue informazioni, relative agli account e ai criteri, in database applicativi; la distribuzione del software Kerberos comprende programmi per replicare, o copiare, questi dati sugli altri server.
Le applicazioni client Kerberos sono progettate per tentare l'autenticazione sui server secondari se il server primario è indisponibile, quindi in caso di guasto non è necessario alcun provvedimento aggiuntivo per spostare il servizio di autenticazione di Kerberos sul server di backup. Invece le funzioni di amministrazione di Kerberos non sono interessate dal failover automatico.
In caso di guasto del server primario, kadmind diventa indisponibile, quindi le funzioni di amministrazione non saranno utilizzabili finché il server primario non sarà riparato o sostituito. In particolare durante un guasto al server primario non si potranno effettuare la gestione dei principal, la creazione e la sostituzione delle chiavi.
Per avviare la replica si impartisce il comando kprop sul master KDC; si può anche pianificarne l'esecuzione come job di cron per mantenere il database dei principal sincronizzato fra i server.
Nell'impostazione della replica innanzitutto si configurano le ACL per kpropd; il file delle ACL di kpropd per impostazione predefinita si trova nel percorso: /var/Kerberos/krb5kdc/kpropd.acl. Nell'esempio esso conterrà le righe:
host/kerberos1.gnud.ie@GNUD.IE host/kerberos2.gnud.ie@GNUD.IE
Il file kpropd.acl può esistere soltanto sui server Kerberos secondari; nei sistemi GNU Linux derivati da Fedora, kadmin non viene eseguito su un server Kerberos su cui sia presente il file /var/Kerberos/krb5kdc/kpropd.acl.
Dopo di questo si devono creare le chiavi di host per i server Kerberos master e slave:
{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc -randkey host/kerberos1.gnud.ie
{Kerberos1}kadmin.local: addprinc -randkey host/kerberos2.gnud.ie
Le chiavi devono essere estratte nel file keytab: si tratta di un portachiavi che contiene le chiavi crittografiche che servono per autenticarsi presso il KDC. L'estrazione delle chiavi nel keytab si ottiene con il sottocomando ktadd:
{Kerberos1}kadmin.local: ktadd host/kerberos1.gnud.ie
{Kerberos1}kadmin.local: ktadd host/kerberos2.gnud.ie
Infine sarà necessario copiare il keytab sul server slave in modo che questo abbia le chiavi necessarie per procedere all'autenticazione.
{Kerberos2}bash# scp root@kerberos1.gnud.ie:/etc/krb5.keytab /etc
Questa linea inserita nel crontab del master server Kerberos sincronizza i database dei principal ogni quindici minuti:
15 * * * * /usr/local/bin/krb5prop.sh
Questo è il contenuto dello script krb5prop.sh:
#!/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
Questo comando, impartito manualmente, restituisce qualcosa di simile a quel che segue:
{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#
Il server slave sincronizzerà il database dei principal con il server master.
Una volta che siano stati impostati i job di cron, la propagazione dei principal sarà automatica e non richiederà alcuna manutenzione; al momento di un guasto del KDC primario non sarà necessario un intervento umano, a meno che il guasto non duri molto tempo.