Migrazione a kerberos 5 della autenticazione per la cella AFS enea.it G. Bracco L'attività è basata sul supporto fornito da CASPUR [Andrei Maslennikov e Ruggero Nepi]
Nel'ambito del contratto con CASPUR per il supporto AFS è stata programmata la migrazione della autenticazione degli utenti della cella AFS enea.it da quella nativa di AFS, basata su di una versione di Kerberos 4, a Kerberos 5. L'implementazione Kerberos 5 scelta è quella prodotta da MIT: L'architettura individuata: Migrazione a Kerberos 5 http://web.mit.edu/kerberos master KDC [afskdc.frascati.enea.it] del realm ENEA.IT i dbserver afs: server slave di autenticazione Kerberos 5 kaserver disattivato e sostituito da fakeka che emula la funzionalità di kaserver in ambiente kerberos 5 Con tale approccio tutte le applicazioni che fanno richiesta di token (ad es. klog, ssh,...) continuano a funzionare senza problemi
Contenuto Infrastruttura e componenti Procedura di migrazione I servizi di Kerberos 5 Il test di migrazione su cella virtuale Test da effettuare sul campo Opportunità future ssh con chiave e token AFS autenticazione macchine di calcolo Windows
Le macchine coinvolte nell'operazione di migrazione sono i 6 db server e il KDC [IBM x336, Xeon 3 Ghz, 1GB RAM, RAID1, Scientific Linux 4.2] I componenti software: Kerberos 5 originale MIT: installato in /usr/kerberos/.. [Non usato ma non viene modificato] Kerberos 5 con patch CASPUR: in /usr/k5/..; la patch permette di estrarre un keytab senza forzare il cambio della password (l'estrazione avviene usando con kadmin ktadd) afs2k5db - utility di conversione del db kaserver in db importabile in kerberos 5 tramite kdb5_util ftp://ftp.cmf.nrl.navy.mil/pub/kerberos5/afs-krb5-1.3.tar.gz monifile - utility per l'automatizzazione della replica dei db kerberos tra master e slave [da INFN] L'infrastruttura e i componenti
Attività di preparazione che non interrompe il servizio: Installazione e configurazione KDC; il database di kaserver viene copiato da un dbserver e convertito in db kerberos. Attivazione dei demoni kerberos 5 Installazione e configurazione pacchetti kerberos 5 sui dbserver. Attivazione del meccanismo di replica master/slave (monifile/kprop/kpropd) e verifica di funzionamento Migrazione vera e propria: Procedura di migrazione Si disattivano i kaserver su tutti i db server Si effettua una nuova conversione del db kaserver in quello di kerberos 5 e si propaga da master KDC a slaves Su tutti i dbserver vengono create ed attivate le istanze fakeka Si aggiorna l'utility WARC a kerberos 5 A questo punto il servizio con autenticazione Kerberos 5 è attivo
Anche ai fini della configurazione dei firewall: KDC: I servizi di kerberos krb5kdc - port 88 udp/tcp (kerberos) port 750 udp/tcp (kerberos 4) krb524d - port 4444 udp kadmind - port 464 tcp/udp (kpasswd) port 749 tcp/udp (kadmin) [kerberos_master - port 751 tcp/udp] kprop (client) Slaves (DBserver AFS) krb5kdc - port 88 udp/tcp (kerberos) port 750 udp/tcp (kerberos 4) krb524d - port 4444 udp fakeka - port udp 7004 [è lo stesso di kaserver] kpropd - port tcp 754 verso KDC
Il test di migrazione CASPUR ha acquisito esperienza nella migrazione a Kerberos 5, inclusa la migrazione della cella INFN nazionale che presenta analogie con quella ENEA. Per l'ambiente ENEA-GRID è stata effettuata una prova per verificare anche il funzionamento di LSF. In ENEA un primo test è stato compiuto nel mese di dicembre 2006 utilizzando un sistema virtualizzato composto da 2 macchine con attivati AFS e la versione Free di LSF (Lava) [Scientific Linux 3.0.4] Tale ambiente di test è disponibile a richiesta su lin4p.frascati.enea.it: 172.1.50.11: AFS dbserver/fileserver/client, LSF master batch daemon e host, KDC Kerberos 5 172.1.50.12: Client AFS, LSF host L'utente si connette a tale cella virtuale aprendo una sessione su lin4p e collegandosi in ssh sulle macchine virtuali.
Test di installazione su cella virtuale (1) I due host virtuali: sl304-1.qemuz, sl304-2.qemuz La cella AFS: qemuz Pacchetto CASPUR per la migrazione./migrate-to-k5/ afs2k5db [compilazione statica] afs2k5db.dinamico k5-caspur-150.a.i386.rpm k5.configure k5setup.sh tools /tools: destroy.sh [script di ripristino]
Test di installazione su cella virtuale (2) 1) Installazione rpm kerberos 2) Impostazione dei valori dei parametri in k5.configure, ovvero il REALM, il nomedel KDC, il dominio DNS e la password di admin/admin:./migrate-to-k5]# cat k5.configure # Inserire con le maiuscole il nome del REAME: K5REALM="QEMUZ" # Inserire il nome del server con il dominio K5SERVER="sl304-1.qemuz" # Inserire il nome del dominio K5DOMAIN="qemuz" # Password di admin/admin K5ADMPW="xxxxxxx"
Test di installazione su cella virtuale (3) 3) verifica che l'utility afs2k5db funzioni, provando a lanciarla:./afs2k5db Usage:./afs2k5db [-r saltrealm] [-m] [-l lifetime] [-4]AFS-db-filename [user...] Tale utility serve a convertire il database di kaserver in un file kaserver.mit che fa da input a kdb5_util, l'utility che genera il DB di kerberos5: afs2k5db -l 30d /usr/afs/db/kaserver.db0 > kaserver.mit kdb5_util load -update -verbose kaserver.mit
4) esecuzione dello script k5setup.sh i cui passi essenziali sono: # 0 : creazione krb5.conf, krb.conf, krb.realm, kdc.conf # 1 : copia dei files di configurazione creati # 2 : creazione della ACL per amministrazione da remoto # 3 : inizializzazione Database Kerberos # 3a: creazione della stash key [permette a KDC di autenticarsi] # 3b: aggiunta dell'utente admin/admin per amministrazione remota # 3c: aggiunta chiavi # 3d: popolamento del database della macchina # 3e: importazione database AFS: afs2k5db e poi kdb5_util # 4 : inizializzazione Kerberos ad AFS: shutdown kaserver e attivazione fakeka # 4a: aggiunta dei servizi al boot # 4b: avvio dei servizi Viene chiesta la KDC Database Master Key Test di installazione su cella virtuale (3)
Risultato: Test di installazione su cella virtuale (4) A valle della migrazione si è verificato che LSF funziona come pure l'utenticazione con ssh, senza alcuna modifica di configurazione. (LSF utilizza le utility gettok e puttok per trasmettere i token). In generale anche gli altri servizi che utilizzano direttamente il token o che hanno capacità di richiederlo ad una macchina dbserver dovrebbero mantenere la loro funzionalità ( ad es. server Citrix ) In ogni caso è possibile ripristinare la situazione precedente, riattivando kaserver e riutilizzando il suo database che viene comunque preservato. Anche tale operazione è stata provata sulla cella virtuale.
Test da effettuare sul campo: la replica Nella cella virtuale non è stato testato il funzionamento del sistema di allineamento delle repliche del database di kerberos 5 e tale test verrà effettuato sul campo, preliminarmente alla migrazione vera e propria. Il meccanismo di replica è basato su kprop/kpropd, componenti standard di Kerberos 5 MIT. Si tratta di un meccanismo client/server dove il master KDC ha il ruolo di client che spedisce l'intero contenuto del db kerberos agli slave. I test di prestazioni effettuati da CASPUR sulla cella nazionale INFN (anch'essa in WAN) sono positivi. Sulla macchina KDC verrà poi installato il servizio xinetd monifile che provvede ad accorgersi che il DB di kerberos viene variato e ordina quindi l'aggiornamento tramite kprop/kpropd. monifile fa uso di fam e portmap ed è stato sviluppato in INFN.
i comandi specifici kerberos 5 Utente (in generale non ne ha bisogno: klog continua a funzionare): kinit (kinit -4) - crea il ticket kerberos (kerberos 4) afslog - converte il ticket kerberos 4 in token kdestroy (kdestroy -4) - distrugge il ticket kerberos (kerberos 4) klist - lista i tickets kerberos
i comandi specifici kerberos 5 Amministrazione: [per la gestione ordinaria WARC] kadmin (su KDC kadmin.local NON richiede autenticazione)? - fornisce la lista dei comandi disponibili. listprincs - lista di tutti i principal (user/host/servizi) getprinc name - informazione su un principal addprinc name - si aggiunge un principal cpw amos - si cambia la password di un principal... addprinc -randkey host/sl304-2.qemuz - si crea un principal per un host ktutil - utility per la gestione dei keytab, ad es. chiavi di macchine kdb5_util - utility per la gestione del DB Kerberos 5
Opportunità future: ssh Come si è già sottolineato, l'approccio adottato permette di mantere la funzionalità dei client ssh attualmente attivi su tutte le macchine. In futuro pero' sarà possibile utilizzare l'opportunità offerta da kerberos 5 di permettere in modo semplice la connessione ssh basata su chiave (senza password da parte dell'utente) con ottenimento del token AFS. Tale risultato richiederà però: la generazione di una chiave per ognuno degli host coinvolti (e la gestione di questo DB delle chiavi [puo' essere un'area AFS sufficientemente protetta] L'aggiornamento dei client ssh Tale possibilità è spesso richiesta dagli utenti più evoluti e puo' essere sfruttata anche in ambienti per il calcolo parallelo => mpi
Opportunità future: ambiente Windows (1) E' ben noto che Active Directory di Microsoft è un'altra implementazione di kerberos 5, vicina e compatibile alla distribuzione Kerberos 5 MIT. La migrazione a Kerberos 5 potrà permettere quindi di integrare anche l'accesso alle macchine di calcolo Windows che fanno parte di ENEA- GRID con le stess utenze e password usate in UNIXs/AFS. Per giungere a tale risultato non è stata ancora definita con precisione la metodologia da adottare, che deve essere identificata anche discutendo l'interazione con quanto è già stato fatto in ambiente Windows in ambito ENEA e verificando le possibili soluzioni già provate da CASPUR. A titolo di esempio viene qui riportata nel seguito la soluzione adottata presso l'università di Paderborn (Germania) dalla quale abbiamo avuto una breve descrizione della loro infrastruttura, basata su due realm indipendenti in relazione di trust.
Due REALM indipendenti: AD.UNI-PADERBORN.DE : Windows AD realm UNI-PADERBORN.DE: kerberos 5 realm di UNIX/AFS Tra i due REALM viene stabilito una relazione di Trust tramite la creazione di 2 principals nel realm kerberos 5 krbtgt/ad.uni-paderborn.de@uni-paderborn.de krbtgt/uni-paderborn.de@ad.uni-paderborn.de ed una opportuna configurazione di Active Directory. Ogni utente UNIX/AFS è definito ANCHE in Active Directory e gli viene assegnato un attributo: altsecurityidentities: Kerberos:userid@UNI-PADERBORN.DE Localmente hanno implementato alcuni scripts che in fase di creazione dell'utenza generano in modo automatico le informazioni richieste in ambiente Active Directory Opportunità future: ambiente Windows (2)