1.1. Informazioni generali

Copyright (c) 2002-2004 V. Alex Brennen (VAB).

Questo documento appartiene al pubblico dominio.

Questo documento è pubblicato all'indirizzo: http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html

1.2. Traduzioni

Al momento questo documento è disponibile nelle seguenti lingue:

• [en] English

• [it] Italiano

Se conoscete una traduzione o intendete tradurlo in un'altra lingua informatemi in modo che io possa distribuire la traduzione o riferirla con un link.

1.3. Contributi e ringraziamenti

• V. Alex Brennen (VAB) <vab (at) cryptnet.net> (Autore principale)

• Nickolai Zeldovich <kolya (at) zepa.net> (Suggerimenti e correzioni tecniche)

1.4. Feedback

Per favore inviate le vostre aggiunte, commenti, correzioni e critiche a questo indirizzo di posta elettronica: <vab@cryptnet.net>.

2.1. Introduzione a Kerberos

Kerberos è un sistema di autenticazione sviluppato dal MIT nell'ambito del progetto Athena. Kerberos usa la crittografia e una terza parte fidata, un arbitro, per eseguire l'autenticazione in maniera sicura attraverso una rete non sicura. In particolare Kerberos usa dei ticket cifrati per evitare di trasmettere le password come testo in chiaro attraverso la rete; Kerberos si basa sul protocollo di Needham e Schroeder.

Adesso sono in uso due versioni di kerberos: la 4 e la 5. Le versioni dalla 1 alla 3 erano versioni interne di sviluppo e non sono mai state pubblicate; la versione 4 ha alcune lacune di sicurezza a non dovrebbe più essere usata. Questo documento tratta soltanto di Kerberos 5, definito nel RFC1510.

La locuzione Infrastruttura Kerberos si riferisce alla configurazione del software, del server e del client che permettono a un amministratore di usare il protocollo Kerberos per realizzare l'autenticazione sulla rete. Precisamente, l'infrastruttura kerberos consiste nel software Kerberos stesso, in alcuni server di autenticazione ridondanti posti in sicurezza, in un deposito centralizzato di account e password e nei sistemi configurati per usare Kerberos come protocollo di autenticazione. Questo documento permetterà di apprendere i passi necessari per installare, configurare e distribuire una tale infrastruttura.

2.2. I benefici di Kerberos

Chi non ha confidenza col protocollo kerberos potrebbe non aver chiaro quali siano i benefici che comporta distribuirlo sulla rete; comunque tutti gli amministratori hanno confidenza con i problemi che Kerberos dovrebbe mitigare. Alcuni di questi problemi sono l'intercettazione della password in transito sulla rete (sniffing), la lettura abusiva del file o del database delle password (stealing), e gli sforzi che si devono sostenere per mantenere un vasto numero di database degli account.

Un' infrastruttura kerberos distribuita in modo appropriato costituisce un buon punto di partenza per la soluzione dei problemi cui si è accennato e aumenta la sicurezza dell'organizzazione. L'uso di Kerberos evita che le password siano trasmesse in chiaro sulla rete; inoltre il sistema centralizza le informazioni sulle credenziali semplificandone la gestione e la manutenzione. Infine l'utilizzo di Kerberos evita di dover conservare le password localmente sulla macchina, riducendo la probabilità che la compromissione di una singola macchina comporti ulteriori violazioni.

Riassumendo, in una grande impresa i benefici di Kerberos si traduranno in minori costi amministrativi attraverso una gestione più semplice di account e password e attraverso il miglioramento nella sicurezza della rete. In un ambiente più piccolo i benefici più evidenti sono costituiti dalla scalabilità dell'infrastruttura di autenticazione e dal miglioramento della sicurezza della rete.

2.3. Come funziona Kerberos

Il protocollo di autenticazione Kerberos usa un segreto condiviso e una terza parte fidata, con ruolo di arbitro, per convalidare l'identità dei client, che possono essere utenti, server o programmi. La terza parte fidata è un server chiamato Key Distribution Center (KDC) che esegue i dèmoni Kerberos. Il segreto condiviso è la password dell'utente trasformata in chiave crittografica; per i server e i sistemi software è generata una chiave casuale.

In Kerberos gli utenti sono detti "principal"; il KDC conserva un database dei principal e delle chiavi segrete che essi usano per autenticarsi. In Kerberos la conoscenza della chiave segreta è considerata una valida dimostrazione di identità, perciò il server Kerberos è affidabile per autenticare ogni client nei confronti di ogni altro client. Con Kerberos l'autenticazione è ottentuta senza trasmettere alcuna password in chiaro attraverso la rete. Nel seguito sarà spiegata la corrispondenza fra il protocollo Kerberos e il software Kerberos in GNU Linux.

Il KDC esegue i due importanti dèmoni Kerberos kadmind e krb5kdc. Una convenzione di denominazione in GNU Linux prevede che i processi il cui nome inizia per "k" siano attinenti al kernel o eseguiti nello spazio del kernel; invece krb5kdc e kadmind sono eseguiti in spazio utente.

kadmind è il demone amministrativo di Kerberos; kadmind si usa attraverso il programma kadmin per la manutenzione del database dei principal e la configurazione dei criteri. Se si sceglie di non permettere il login remoto tramite ssh sulla macchina Kerberos, kadmin consente l'amministrazione remota dei componenti Kerberos del server.

krb5kdc è la bestia da soma del server Kerberos, vestendo il ruolo di terza parte fidata nel processo di autenticazione. Quando un utente vuole autenticarsi presso un sistema o un servizio, chiede un ticket al KDC. Un ticket è un datagramma che contiene l'identità del client, una chiave di sessione, una marcatura oraria e altre indicazioni; il datagramma è cifrato con la chiave segreta del server.

Descrivendo il processo più in dettaglio, esso inizia con la richiesta di autenticazione che è trasmessa al demone krb5kdc. Quest'ultimo, ricevuta la richiesta, cerca il client, cioè il principal, nel database dei principal per autenticarlo; legge la chiave segreta del client nel database e cifra un ticket speciale detto Ticket Granting Ticket (TGT), che invia al client. Il client riceve il TGT cifrato che contiene una chiave di sessione; se il client conosce la password (la chiave segreta che è conservata nel database dei principal) può decifrare il TGT, quindi lo cifra con la chiave di sessione, che è contenuta nel TGT stesso, per presentarlo a un Ticket Granting Service (TGS). Il TGS rilascia un ulteriore Ticket che consentirà al client di ottenere l'autenticazione presso uno specifico sistema o servizio.

L'autenticazione sicura si realizza tramite l'uso di ticket cifrati che possono essere decifrati soltanto se il client conosce la chiave segreta. Il ticket contiene informazioni sull'orario per prevenire attacchi di replica, che consistono in rappresentazioni fraudolente di un ticket rilasciato precedentemente, per ottenere un accesso illecito.

2.4. Compromissione dell'infrastruttura Kerberos

Il primo modo in cui un aggressore può tentare di compromettere un'infrastruttura Kerberos è attaccando il server Kerberos; se l'aggressore riuscisse a ottenere un accesso di root al KDC egli avrebbe accesso al database delle password cifrate dei principal. In questo modo l'aggressore potrebbe accedere anche al software Kerberos e ai file di configurazione e modificarli per fare in modo che il sistema consenta delle autenticazioni che non dovrebbero avere successo.

Tra gli altri metodi per attaccare l'infrastruttura di Kerberos vanno citati gli attacchi di replica (replay attack) e i tentativi di indovinare la password (password guessing attack). Un attacco di replica si esplica intercettando o acquisendo altrimenti un ticket Kerberos e utilizzandolo fraudolentemente per tentare di ottenere l'autenticazione. Per provare a indovinare la password si possono intercettare dei ticket Kerberos sulla rete per decifrarli mediante un attacco di forza bruta.

Un aggressore può sfruttare le vulnerabilità del software vetusto ancora presente nell'infrastruttura; per esempio sono noti parecchi problemi con la versione 4 di Kerberos il più importante dei quali è una fondamentale debolezza nel protocollo usato per la crittografia. Il progetto di Kerberos versione 4 contempla l'uso di DES in modalità normale che permette a un aggressore di intercettare e modificare il testo cifrato del ticket senza lasciare tracce. Per prevenire questi attacchi Kerberos è stato modificato nella versione 5 che usa triple DES in modalità Cipher Block Chaining (CBC).

Trattando della robustezza della versione 4 di Kerberos è importante notare anche che parecchie implementazioni soffrono di vulnerabilità di superamento del buffer (buffer overflow). Le implementazioni di riferimento di Kerberos versione 5 hanno riparato le vulnerabilità di superamento del buffer presenti nella versione 4 ma le distribuzioni della versione 5 generalmente forniscono programmi che consentono la compatibilità all'indietro e supportano le applicazioni preesistenti progettate per Kerberos 4; si ritiene che il codice compatibile presente nella versione 5 sia ancora vulnerabile agli attacchi di buffer overflow.

Quindi, visti i problemi del protocollo della versione 4 e le potenziali vulnerabilità di superamento del buffer, è meglio non supportare né usare Kerberos versione 4.

Riassumendo, da questa descrizione su come sia possibile compromettere un'infrastruttura Kerberos, si comprende che la sicurezza dello stesso server Kerberos è un'esigenza prioritaria; bisogna poi eseguire software Kerberos aggiornato e restare vigili scegliendo buone password e predisponendo buoni criteri per le password.

3.1. Descrizione generale della configurazione della macchina

Questa sezione del documento descrive l'installazione e la configurazione delle macchine e del software che svolge il ruolo di KDC. È possibile intervenire con aggiustamenti sulle configurazioni suggerite ma saranno presentati alcuni punti chiave che è importante tenere a mente quando si configura il KDC e anche se si sceglie di praticare una strategia di configurazione alternativa è necessario aver compreso il materiale che viene presentato quì.

Le macchine eseguono il demone Kerberos e conservano le password e le informazioni sui criteri, perciò è molto importante per la salvaguardia della rete che questi server siano messi in sicurezza. Bisognerà prendere ogni misura possibile per scongiurare la compromissione di questi server; le raccomandazioni per la sicurezza contenute in questa sezione rivestono fondamentale importanza.

La raccomandazione principale è di usare macchine dedicate per erogare il servizio KDC di kerberos; l'hardware dovrà essere inaccessibile alle minacce materiali e anche il sistema GNU Linux andrà rinforzato il più possibile. Dalla compromissione del KDC deriverebbe la compromissione dell'intera infrastruttura Kerberos.

3.2. Hardware

Il servizio Kerberos non ha grosse richieste riguardo all'hardware e ha capacità di ridondanza, quindi l'hardware del server può essere esiguo. Per i server Kerberos che ho distribuito ho usato macchine con un processore Pentium III e due dischi in RAID 1 hardware, sufficienti per svolgere da quaranta a centomila autenticazioni al giorno. Anche se il server può essere dotato di schede di rete ridondanti, bisogna evitare di tenerle attive entrambe contemporaneamente perché Kerberos scrive l'indirizzo IP del KDC nei ticket e se durante il processo di autenticazione il client contatta il KDC attraverso interfacce multiple possono insorgere difficoltà.

È importante evidenziare che il servizio Kerberos andrebbe eseguito su hardware dedicato. Riservare una macchina a Kerberos significa che soltanto gli amministratori di Kerberos avranno bisogno di accedere a quella macchina e che sulla macchina non saranno in esecuzione altri servizi, salvo probabilmente SSH. Tutte le password degli utenti saranno conservate presso i server Kerberos, quindi sarà bene limitare il più possibile l'accesso fisico alle macchine interessate; usando hardware riservato a Kerberos sarà più semplice adempiere a questo requisito, magari chiudendo il server con la sua console in un proprio armadio.

Per approfittare della capacità nativa di Kerberos di fornire ridondanza bisogna avere almeno due macchine che funzionano da KDC. Kerberos è progettato per essere distribuito con un server principale (master) e uno o più server secondari (slave); non c'è limite al numero di secondari.

3.3. Installazione di GNU Linux

Installando GNU Linux su server dedicati all'esecuzione dei servizi kerberos si percorreranno ulteriori passi per garantirne la sicurezza.

Per prima cosa si installerà soltanto il software assolutamente necessario per il servizio Kerberos, costituito dal sistema operativo di base e dai pacchetti Kerberos, escludendo X e qualunque applicazione grafica. SSH è opzionale e andrà installato se si desidera poter amministrare i server a distanza; del resto i server saranno parecchio più sicuri se si permetterà di accedervi soltanto mediante il terminale collegato direttamente ad essi.

In un sistema GNU Linux basato su Fedora Core, il servizio kerberos è fornito dai pacchetti:

krb5-server
krb5-libs

La documentazione e le librerie di sviluppo non andranno installate sul KDC perché non si intende usare questa macchina per altre attività che non siano l'espletamento del servizio KDC.

Nel passo successivo ci si accerterà che non vi siano porte aperte oltre a quelle necessarie e che tutti gli aggiornamenti di sicurezza siano stati applicati. Il procedimento per controllare quali aggiornamenti di sicurezza vanno applicati dipende dal programma di gestione dei pacchetti in uso. Per determinare su quali porte la macchina è in ascolto si può usare il comando netstat; per esempio su una macchina che ha in esecuzione soltanto ssh, si leggerà:

bash$ netstat -an | grep -i listen | less
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

Infine si dovrà configurare il server in modo che possano accedervi soltanto i server che devono comunicare con lui per esigenze di autenticazione, editando i file /etc/hosts.allow and /etc/hosts.deny insieme al file iptables.

3.4. La scelta del realm

I nomi dei realm [domini di protezione] sono sensibili alle maiuscole e devono esere unici sulla rete; è buona pratica usare come nome del realm il nome del dominio di secondo livello scritto in lettere maiuscole. Se si sta configurando Kerberos soltanto per una sottorete anziché per la rete intera, si potrebbe usare un nome di dominio figlio da far corrispondere alla sottorete.

Quando si sceglie la topologia dei realm si deve prendere in considerazione l'assetto complessivo dell'organizzazione; se si hanno uffici remoti o sottogruppi indipendenti è bene che essi appartengano a un realm separato. La topologia dei realm di Kerberos deve riflettere la topologia del sistema di gestione e non la struttura fisica della rete.

Infine si dovrà tener presente l'esistenza di sistemi preesistenti, come distribuzioni precedenti di Kerberos o raggruppamenti di rete che si intende mantenere (per esempio domini di Windows NT).

Se si installa Kerberos in una rete che ne ospita già una distribuzione, nella rete globale o in una sottorete, bisogna evitare una collisione di nomi. Il caso più comune in cui succede di distribuire kerberos in un ambiente in cui è già stato installato precedentemente è dove esiste un cluster IBM SP; la soluzione migliore è creare appositamente per il cluster SP un realm con un nome di dominio almeno di terzo livello e usare un nome di dominio di secondo livello per il realm Kerberos principale.

In questo documento si utilizzerà un esempio che aiuterà a illustrare il disegno e la configurazione di un'infrastruttura. Soggetto dell'esempio sarà una mitica università fondata per educare le persone ai contenuti liberi e per compiere ricerche sull'argomento, l'Università GNU di Dublino in Irlanda. L'esempio comprende due server Kerberos usati per autenticare gli studenti e il corpo docente. Il nome di dominio dell'università è gnud.ie quindi per il realm Kerberos si userà GNUD.IE.

3.5. Configurazione del software Kerberos

Adesso è necessario configurare Kerberos, creare un amministratore, determinare un criterio di sicurezza e inizializzare il database dei principal di Kerberos.

Il primo passaggio consiste nell'editare il file di configurazione /etc/krb5.conf. In questo file si imposta il realm, si estende la definizione del realm specificando i server kerberos e infine si imposta il dominio del realm. Nell'esempio il contenuto del file è il seguente:

default_realm = GNUD.IE

[realms]
 GNUD.IE = {
  kdc = kerberos1.gnud.ie:88
  kdc = kerberos2.gnud.ie:88
  admin_server = kerberos1.gnud.ie:749
  default_domain = gnud.ie
 }

[domain_realm]
 .gnud.ie = GNUD.IE
 gnud.ie = GNUD.IE

Il database di Kerberos si crea e inizializza con il comando:

{Kerberos1}bash# /usr/Kerberos/sbin/kdb5_util create -s

Il flag -s fa in modo che il KDC crei un file riservato per autenticare sé stesso; si usa il flag -r per specificare un realm. Quando si crea un nuovo database è necessario specificare il realm soltanto se nel file krb5.conf sono definiti più realm.

A questo punto Kerberos domanderà di predisporre una master password per il database; è molto importante non dimenticarla. Non sarà possibile compiere alcuna azione amministrativa sul server se non si ricorderà la master password.

Ora è necessario editare il file delle acl [access control list] sul KDC per concedere l'accesso come amministratore. Normalmente questo file si trova in /var/Kerberos/krb5kdc/kadm5.acl. Può essere necessario specificarne la posizione nel file kdc.conf, il cui percorso è precisato nel file /etc/krb5.conf ed ha come valore predefinito /var/Kerberos/krb5kdc/kdc.conf. Considerando l'esempio dell'Università GNU di Dublino si dovrà modificare il file delle acl perché contenga la riga:

*/admin@GNUD.IE     *

Questa impostazione significa che a ogni account che termina con un /admin nel realm GNUD.IE sono concessi tutti i diritti d'accesso.

Una volta impostato l'accesso per gli utenti amministratori bisogna creare tali utenti; questo si fa utilizzando il comando kadmin.local, impartito da una shell di root sul KDC e usando il suo sottocomando addprinc. Di solito il nome dell'account amministrativo è admin; nell'esempio della Università GNU di Dublino è scritto come:

{Kerberos1}bash# /usr/Kerberos/sbin/kadmin.local -q "addprinc admin/admin"

Sul server andranno eseguiti i dèmoni krb5kdc e kadmin. Se è necessario potrà essere eseguito anche krb524 per fornire la compatibilità con i client Kerberos 4. Tuttavia prima di far partire krb524 si rammenti l'avvertimento riguardante le debolezze nella sicurezza di Kerberos 4 e ci si accerti di avere davvero bisogno di questa funzionalità. Sui KDC si possono configurare i dèmoni krb5kdc e kadmin per avviarsi automaticamente, tramite il comando chkconfig.

{Kerberos1}bash# /sbin/chkconfig krb5kdc on
{Kerberos1}bash# /sbin/chkconfig kadmin on

Alternativamente si possono avviare manualmente, impartendo i comandi:

{Kerberos1}bash# /etc/rc.d/init.d/krb5kdc start
{Kerberos1}bash# /etc/rc.d/init.d/kadmin start

Questo è sufficiente per ottenere un KDC funzionante.

3.6. Creazione dei principal

Si crea un principal di Kerberos per un utente con il comando:

{Kerberos1}bash# kadmin.local
{Kerberos1}kadmin.local: addprinc <username>

Se Kerberos deve supportare un vasto numero di account, si può scrivere uno script per creare i principal in massa.

4.1. L'importanza della sincronia temporale

La sicurezza di Kerberos è basata anche sui time stamp dei ticket perciò è d'importanza critica che gli orologi dei sever kerberos siano regolati con accuratezza. Come è stato discusso nell'introduzione a kerberos, i ticket hanno una scadenza breve per prevenire attacchi di forza bruta e attacchi di replica.

Permettendo agli orologi di subire scostamenti si rende la rete vulnerabile a questi attacchi. A causa dell'importanza della sincronia degli orologi nella sicurezza del protocollo Kerberos, se gli orologi non sono sincronizzati entro un ragionevole intervallo Kerberos presenta errori fatali e smette di funzionare. I client che tentino di autenticarsi da una macchina con un orologio non accurato falliranno il tentativo di autenticazione presso il KDC a causa della differenza di ora con il suo orologio.

4.2. Introduzione a NTP

Per sincronizzare l'orario fra i server è disponibile il protocollo NTP (Network Time Protocol); esistono molti server NTP pubblici utilizzabili per la sincronizzazione. NTP può sincronizzare gli orologi dei client al millisecondo sulla LAN ed entro decine di millisecondi attraverso una WAN. I server NTP sono divisi in strati (stratum). I server NTP primari sono classificati come stratum 1; essi non devono essere usati per sincronizzare le macchine perché sono in numero esiguo. I server pubblici dello stratum 2 sono disponibili per la sinconizzazione dei client e a loro volta si sincronizzano con i server pubblici stratum 1. Si imposteranno i server Kerberos per interrogare tre server stratum 2 usando NTP. Questa è una lista di server pubblici dello stratum 2 [aggiornato dal traduttore].

4.3. Installazione e configurazione di NTP

Per abilitare NTP in GNU Linux è necessario installare il pacchetto NTP ed editare il file di configurazione, che per impostazione predefinita è /etc/ntp.conf. I valori della configurazione di default sono accettabili; bisogna soltanto aggiungere i server che si intende usare per sincronizzare l'orario. Non è necessario usare l'autenticazione ma si può farlo per aumentare la sicurezza; andrà usata se si utilizzano i server NTP della LAN. Quì c'è un esempio di file di configurazione per l'Università GNU di Dublino: ntp.conf.

Per ottenere l'effettiva sincronizzazione si imposta un job di cron:

30 * * * * /usr/sbin/ntpdate -s

Se i sistemi si trovano dietro un firewall si userà -su invece che soltanto -s. L'argomento -u indica a ntpdate di usare porte non privilegiate per la connessione in uscita ai server stratum 2.

5.1. Descrizione della replica

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.

5.2. Implementazione

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.

5.3. Manutenzione

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.

6.1. Configurazione generale dei client GNU Linux

Le distribuzioni di Kerberos per GNU Linux comprendono un pacchetto client che contiene tutto il software e i file di configurazione necessari per configurare una macchina GNU Linux capace di effettuare l'autenticazione Kerberos su un KDC. Nei sistemi basati su Fedora e suoi derivati si tratta del pacchetto krb5-workstation. Perché il sistema possa usare Kerberos per l'autenticazione, anche con l'utilizzo delle applicazioni compatibili, Kerberos deve essere configurato su di esso.

La configurazione consiste nell'editare il file /etc/krb5.conf, dove si specifica il realm, i KDC, il server amministrativo, il logging, il dominio predefinito, e le informazioni sul KDC; andrà modificato anche il file kdc.conf, la posizione del quale può essere specificata nel file krb5.conf; il percorso predefinito è /var/Kerberos/krb5kdc/kdc.conf. Il file kdc.conf contiene informazioni sul criterio dell'algoritmo di crittografia applicato nel realm.

Sul sistema che si vuole abilitare a effettuare l'autenticazione con Kerberos si devono immettere le medesime informazioni di configurazione che sono state scritte nel file /etc/krb5.conf del KDC. Si consultino anche i file di configurazione di esempio per l'università GNU di Dublino: krb5.conf e kdc.conf.

A questo punto è possibile provare l'autenticazione di Kerberos, usando il comando kinit:

bash$ kinit <username>

Se l'autenticazione non riesce si può cercare una descrizione della causa del fallimento nei file del registro di sistema del client e nel file log di KDC nel KDC su cui si tenta di autenticarsi. Durante l'indagine sui problemi di autenticazione può essere d'aiuto avere un terminale aperto che esegue il comando tail -f sul file log di KDC. Nell'esempio di krb5.conf la posizione del file di registro del KDC è /var/log/Kerberos/krb5kdc.log.

6.2. PAM

La tecnologia PAM, o moduli di autenticazione inseribili (Pluggable Authentication Modules), che è inclusa in molte distribuzioni di GNU Linux, si integra con Kerberos tramite il modulo pam_krb5. Per utilizzare l'autenticazione Kerberos con PAM si deve installare il modulo pam_krb5 e modificare i file di configurazione di PAM.

Con il modulo pam_krb5 vengono installati dei file di configurazione esemplificativi, che si trovano in /usr/share/doc/pam_krb5-1.55/pam.d. La modifica fondamentale che è necessario inserire per permettere ai servizi controllati da PAM di autenticarsi con Kerberos è di questo tipo:

auth       required     /lib/security/pam_krb5.so use_first_pass

6.3. Il server web Apache

Si può utilizzare Kerberos come meccanismo di autenticazione per il server web Apache; tale funzionalità è fornita dal modulo mod_auth_kerb, mediante il quale è possibile impostare Kerberos come tipo di autenticazione per le occorrenze del controllo di accesso nel file httpd.conf. Si noti che questo non è il meccanismo di autenticazione ideale quando si usa kerberos, perché i ticket sono conservati nel server web anziché nella macchina client; peraltro se la finalità è di implementare una soluzione di accesso a un solo stadio o di consolidare gli account questa soluzione è praticabile. mod_auth_kerb può supportare Kerberos 4 ma questo documento non ne tratta, in considerazione delle debolezze nella sicurezza della versione 4 del protocollo.

Il sito di mod_auth_kerb si trova all'indirizzo http://modauthkerb.sourceforge.net/. Si raccomanda di usare il protocollo HTTPS per l'accesso ai siti che usano mod_auth_kerb, perché esso usa l'autenticazione di base che trasmette i dati in codifica base64 ed è semplice tradurli in testo in chiaro. È importante che le credenziali di autenticazione siano cifrate con SSL per garantire che il nome utente e la password siano protette mentre sono trasmesse al server web.

Si riportano i passaggi necessari per compilare Apache con il modulo mod_auth_krb.

bash$ export 'LIBS=-L/usr/Kerberos/lib -lkrb5 -lcrypto -lcom_err'
bash$ export 'CFLAGS=-DKRB5 -DKRB_DEF_REALM=\\\"GNUD.IE\\\"'
bash$ export 'INCLUDES=-I/usr/Kerberos/include'
bash$ mkdir apache_x.x.x/src/modules/kerberos
bash$ cp mod_auth_kerb-x.x.x.c apache_x.x.x/src/modules/kerberos
bash$ ./configure --prefix=/home/httpd --add-module=src/modules/Kerberos/mod_auth_kerb.c
bash$ make
bash$ make install

È consigliabile collaudare Apache per verificarne il buon funzionamento; quando si dispone di una copia sicuramente funzionante di Apache con SSL abilitato, si può modificare il file httpd.conf per fornire l'autenticazione kerberos per una directory.

Il frammento che segue è un esempio che abilita l'autenticazione Kerberos 5 per una directory attraverso il modulo mod_auth_kerb:

<Directory "/home/httpd/htdocs/content">
   AllowOverride None
   AuthType KerberosV5
   AuthName "Kerberos Login"
   KrbAuthRealm GNUD.IE
   require valid-user
</Directory>

6.4. Microsoft Windows

La compatibilità fra lo standard Kerberos del MIT e la versione Microsoft è limitata, a causa della imperfetta implementazione dello standard Kerberos da parte di Microsoft. Quì è disponibile un documento pubblicato da Microsoft che descrive in che modo e con che limiti la versione viziata di Kerberos prodotta da Microsoft può operare insieme con quella standard.

7.1. L'API di Kerberos

Le librerie di sviluppo di Kerberos permettono di abilitare qualsiasi applicazione all'autenticazione con Kerberos. Sono due le librerie principali, una di uso generale usata per la semplice autenticazione e una libreria di amministrazione utile per svolgere funzioni amministrative quali le operazioni sui principal. Nei sistemi GNU Linux derivati da Fedora, il pacchetto rpm krb5-devel contiene le librerie di sviluppo e la documentazione. Una descrizione dell'API per queste librerie si trova nella documentazione di kerberos, inclusa nella maggior parte delle distribuzioni; nei derivati di Fedora si installa nel percorso: /usr/share/doc/krb5-devel-1.2.2/api.

La documentazione è nel formato LaTeX; per consultarla si devono generare da essa i file dvi che poi possono leggersi con il programma xdvi. Per far ciò si usano i comandi:

bash$ cd /usr/share/doc/krb5-devel-x.x.x/api/
bash$ su
bash# make
bash# (^d)
bash$ xdvi library.dvi