Capitolo 3 Configurazione di SEAM

Questo capitolo descrive le procedure per la configurazione dei server KDC, dei server di applicazioni di rete, dei server NFS e dei client SEAM. Molte di queste procedure richiedono l'accesso di root, perciò devono essere eseguite da amministratori di sistema o da utenti avanzati. Vengono inoltre descritte le procedure per la configurazione di più settori e altri aspetti riguardanti i server KDC.

• "Configurazione dei server KDC"

• "Configurazione dell'autenticazione tra settori"

• "Configurazione dei server di applicazioni di rete SEAM"

• "Configurazione dei server NFS SEAM"

• "Configurazione dei client SEAM"

• "Sincronizzazione degli orologi tra i KDC e i client SEAM"

• "Sostituzione di un KDC master con uno slave"

• "Amministrazione del database di Kerberos"

• "Rafforzamento della sicurezza"

Mappa delle operazioni di configurazione di SEAM

Alcune parti del processo di configurazione dipendono da altre e devono essere eseguite in un ordine specifico. Molte di queste procedure configurano servizi che sono necessari per l'uso di SEAM. Altre procedure sono indipendenti, e possono essere eseguite al momento appropriato. La tabella seguente indica l'ordine consigliato per l'installazione di SEAM.

Una volta completate le procedure richieste, si potranno eseguire all'occorrenza le operazioni seguenti.

Configurazione dei server KDC

Dopo l'installazione del software SEAM, è necessario configurare i server KDC. Configurando un KDC master e almeno un KDC slave, si istituisce il servizio che emette le credenziali. Queste credenziali rappresentano la base per l'uso di SEAM, perciò l'installazione dei KDC deve essere effettuata prima delle altre operazioni.

La differenza più rilevante tra un KDC master e uno slave è data dal fatto che solo il master può gestire le richieste di amministrazione del database. Ad esempio, la modifica di una password o l'aggiunta di un nuovo nome principale devono essere effettuate sul KDC master. Queste modifiche possono quindi essere propagate ai KDC slave. Sia il KDC slave che il KDC master possono generare le credenziali; questo assicura la ridondanza nel caso in cui il KDC master non possa rispondere.

Configurare un KDC master

In questo esempio si presume che la procedura di preconfigurazione non sia stata eseguita. Se questa procedura è invece stata utilizzata per l'installazione del software, molti dei file indicati qui di seguito non richiederanno di essere modificati; si consiglia tuttavia di esaminare il contenuto dei file.

In questa procedura verranno utilizzati i seguenti parametri di configurazione:

• nome del settore = SPA.IT

• nome del dominio DNS = spa.it

• KDC master = kdc1.spa.it

• KDC slave = kdc2.spa.it

• nome principale di amministrazione = kws/admin

• URL della guida in linea = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  ---

  Nota -

  Adattare l'URL in modo che punti alla sezione "Amministrazione SEAM", come descritto in Note sul prodotto e sull'installazione di SEAM.

  ---

1. Prerequisiti per la configurazione di un KDC master.

   Questa procedura richiede che il KDC master sia installato e che il DNS sia in esecuzione. Per istruzioni specifiche sull'assegnazione dei nomi se si desidera rendere il master intercambiabile, vedere "Sostituzione di un KDC master con uno slave".

2. Diventare superutente sul KDC master.

3. Aprire con un editor il file di configurazione di Kerberos (krb5.conf).

   Si dovranno cambiare i nomi dei settori e i nomi dei server. Per una descrizione completa di questo file, vedere la pagina man krb5.conf(4). Se il software SEAM è stato installato usando i file di configurazione, sarà sufficiente verificare il contenuto del file.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = SPA.IT [realms] SPA.IT = { kdc = kdc1.spa.it kdc = kdc2.spa.it admin_server = kdc1.spa.it } [domain_realm] .spa.it = SPA.IT # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956 }

   In questo esempio, sono state modificate le righe per default_realm, kdc, admin_server e tutte le voci domain_realm. La riga per default_realm è stata inclusa per ragioni di completezza, ma non viene creata dal processo di installazione se il nome del settore e il nome del dominio sono uguali. È stata inoltre modificata la riga che definisce l'help_url.

4. Aprire con un editor il file di configurazione del KDC (kdc.conf).

   Occorrerà modificare il nome del settore. Per una descrizione completa di questo file, vedere la pagina man kdc.conf(4). Se il software SEAM è stato installato usando i file di configurazione, sarà sufficiente verificare il contenuto del file.

   kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] SPA.IT= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /var/krb5/kadm5.keytab acl_file = /var/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s }

   In questo esempio, è stata modificata la definizione del nome del settore nella sezione realms.

5. Creare il database del KDC usando kdb5_util.

   Il comando kdb5_util crea il database del KDC e, se usato con l'opzione -s, crea un file segreto che viene usato per autenticare il KDC prima dell'avvio dei daemon kadmind e krb5kdc.

   kdc1 # /usr/krb5/sbin/kdb5_util create -r SPA.IT -s Inizializzazione del database '/var/krb5/principal' per il settore 'SPA.IT' nome della chiave master 'K/M@SPA.IT' Verrà richiesto di inserire la password master per il database. È importante NON DIMENTICARE questa password. Inserire la chiave master del database KDC: <digitare la chiave> Reinserire la chiave master del database KDC: <digitare nuovamente la chiave>

   L'opzione -r seguita dal nome del settore non è richiesta se il nome del settore è uguale al nome del dominio nello spazio di denominazione dei server.

6. Aprire con un editor il file contenente la lista di controllo degli accessi di Kerberos (kadm5.acl).

   Una volta popolato, il file /etc/krb5/kadm5.acl dovrebbe contenere tutti i nomi principali autorizzati ad amministrare il KDC. La prima voce aggiunta potrebbe apparire come segue:

   kws/admin@SPA.IT *

   Questa riga assegna al nome principale kws/admin del settore SPA.IT l'autorizzazione a modificare i nomi principali o i criteri all'interno del KDC. L'installazione predefinita include un simbolo "*" per designare tutti i nomi principali di tipo admin. Questo potrebbe rappresentare un rischio per la sicurezza, perciò si raccomanda di specificare un elenco dei nomi principali di tipo admin.

7. Avviare kadmin.local.

   La sottoprocedura seguente permette di creare i nomi principali usati da SEAM.

   kdc1 # /usr/krb5/sbin/kadmin.local kadmin.local:

   1. Aggiungere i nomi principali di amministrazione al database usando kadmin.local.

      È possibile aggiungere tutti i nomi principali admin desiderati. È tuttavia necessario aggiungere almeno un nome principale admin per completare il processo di configurazione del KDC. In questo esempio, viene aggiunto un nome principale kws/admin. Al posto di "kws" si potrà usare un altro nome principale appropriato.

      kadmin.local: addprinc kws/admin Inserire la password per il nome principale kws/admin@SPA.IT: <inserire la password> Reinserire la password per il nome principale kws/admin@SPA.IT: <reinserire la password> Nome principale "kws/admin@SPA.IT" creato. kadmin.local:

   2. Creare una tabella di chiavi per kadmin usando kadmin.local.

      Questa sequenza di comandi crea una tabella di chiavi speciale con i nomi principali per kadmin e changepw. Questi nomi principali sono richiesti per il servizio kadmind.

      kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.spa.it Voce per nome principale kadmin/kdc1.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc1.spa.it Voce per nome principale changepw/kdc1.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/kadm5.keytab. kadmin.local:

   3. Uscire da kadmin.local

      Sono stati aggiunti tutti i nomi principali richiesti per le operazioni successive.

      kadmin.local: quit

8. Avviare i daemon di Kerberos.

   kdc1 # /etc/init.d/kdc start kdc1 # /etc/init.d/kdc.master start

9. Avviare kadmin.

   A questo punto, si potranno aggiungere i nomi principali usando lo strumento di amministrazione di SEAM. Il comando di esempio seguente è presentato in forma semplificata. È necessario eseguire il login con uno dei nomi principali admin creati precedentemente in questa procedura.

   kdc1 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin:

   1. Creare il nome principale del KDC master usando kadmin.

      Il nome principale dell'host verrà usato dalle applicazioni basate su Kerberos (come klist e kprop) e dai servizi basati su Kerberos (come ftp e telnet).

      kadmin: addprinc -randkey host/kdc1.spa.it Nome principale "host/kdc1.spa.it@SPA.IT" creato. kadmin:

   2. Opzionale: Creare il nome principale root per il KDC master usando kadmin.

      Questo nome principale verrà usato per le attivazioni NFS autenticate, e potrebbe perciò non essere necessario su un KDC master.

      kadmin: addprinc root/kdc1.spa.it Inserire la password per il nome principale root/kdc1.spa.it@SPA.IT: <inserire la password> Reinserire la password per il nome principale root/kdc1.spa.it@SPA.IT: <reinserire la password> Nome principale "root/kdc1.spa.it@SPA.IT" creato. kadmin:

   3. Aggiungere il nome principale dell'host usato come KDC master alla tabella di chiavi del KDC master.

      Aggiungendo il nome principale dell'host alla tabella di chiavi, questo nome principale potrà essere usato automaticamente.

      kadmin: ktadd host/kdc1.spa.it kadmin: Voce per nome principale host/kdc1.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/krb5.keytab kadmin: quit

   4. Uscire da kadmin

      kadmin: quit

10. Aggiungere una voce per ogni KDC nel file di configurazione usato per la propagazione (kpropd.acl).

    Per una descrizione completa di questo file, vedere la pagina man kprop(1M). Se il software SEAM è stato installato usando i file di configurazione, sarà sufficiente verificare il contenuto del file.

    kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.spa.it@SPA.IT host/kdc2.spa.it@SPA.IT

11. Opzionale: Sincronizzare l'orologio del KDC master usando NTP o un altro meccanismo di sincronizzazione.

    Non è necessario installare e usare NTP, ma perché l'autenticazione riesca tutti gli orologi dovranno rientrare nello spazio orario definito nella sezione libdefaults del file krb5.conf. Per informazioni su NTP, vedere "Sincronizzazione degli orologi tra i KDC e i client SEAM".

Configurare un KDC slave

In questa procedura viene configurato un nuovo KDC slave di nome kdc3. Nell'esempio si ipotizza che non sia stata usata la procedura di preconfigurazione durante l'installazione del software o che, in tale procedura, kdc3 non sia stato definito come slave. Se la procedura è stata eseguita e kdc3 è stato identificato come slave, non sarà necessario modificare molti dei file qui indicati; è consigliabile comunque esaminarne il contenuto.

In questa procedura vengono usati i seguenti parametri di configurazione:

• nome del settore = SPA.IT

• nome del dominio DNS = spa.it

• kdc master = kdc1.spa.it

• kdc slave = kdc2.spa.it e kdc3.spa.it

• nome principale di amministrazione = kws/admin

• URL della guida in linea = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  ---

  Nota -

  Adattare l'URL in modo che punti alla sezione "Amministrazione SEAM", come descritto in Note sul prodotto e sull'installazione di SEAM.

  ---

1. Prerequisiti per la configurazione di un KDC slave.

   Questa procedura richiede che il KDC master sia stato configurato e che il software del KDC slave di SEAM sia stato installato su kdc3. Per istruzioni specifiche sulla configurazione del server slave come sistema di backup per la sostituzione del master in caso di guasto, vedere "Sostituzione di un KDC master con uno slave".

2. Sul KDC master: Diventare superutente.

3. Sul KDC master: Avviare kadmin.

   È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master.

   kdc1 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin:

   1. Sul KDC master: Aggiungere i nomi principali degli host slave al database usando kadmin.

      Perché il sistema slave possa funzionare, è necessario che disponga di un nome principale per l'host.

      kadmin: addprinc -randkey host/kdc3.spa.it Nome principale "host/kdc3@SPA.IT" creato. kadmin:

   2. Opzionale: Sul KDC master, creare il nome principale root per il KDC slave usando kadmin.

      Questo nome principale è necessario solo se il sistema slave attiverà via NFS un file system autenticato.

      kadmin: addprinc root/kdc3.spa.it Inserire la password per il nome principale root/kdc3.spa.it@SPA.IT: <inserire la password> Reinserire la password per il nome principale root/kdc3.spa.it@SPA.IT: <reinserire la password> Nome principale "root/kdc3.spa.it@SPA.IT" creato. kadmin:

   3. Uscire da kadmin

      kadmin: quit

4. Sul KDC master: Aprire con un editor il file di configurazione di Kerberos (krb5.conf).

   È necessario aggiungere una voce per ogni slave. Per una descrizione completa di questo file, vedere la pagina man krb5.conf(4). Se kdc3 è stato definito come server slave durante la procedura di preconfigurazione, sarà sufficiente verificare il contenuto del file.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = SPA.IT [realms] SPA.IT = { kdc = kdc1.spa.it kdc = kdc2.spa.it kdc = kdc3.spa.it admin_server = kdc1.spa.it } [domain_realm] .spa.it = SPA.IT # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

5. Sul KDC master: Aggiungere una voce per ogni KDC slave nel file di configurazione usato per la propagazione del database (kpropd.acl).

   Per una descrizione completa di questo file, vedere la pagina man kprop(1M). Se kdc3 è stato definito come server slave durante la procedura di preconfigurazione, sarà sufficiente verificare il contenuto del file.

   kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.spa.it@SPA.IT host/kdc2.spa.it@SPA.IT host/kdc3.spa.it@SPA.IT

6. Su tutti i server slave: Copiare i file di amministrazione di KDC dal KDC master.

   Questa operazione deve essere eseguita su tutti i KDC slave, poiché il KDC master contiene le informazioni aggiornate necessarie per tutti i server KDC. Se kdc3 è stato definito come server slave durante la procedura di preconfigurazione, sarà sufficiente verificare il contenuto dei file. Si potrà usare ftp o un meccanismo di trasferimento analogo per trasferire una copia dei seguenti file dal master:

   • /etc/krb5/krb5.conf

   • /etc/krb5/kdc.conf

   • /etc/krb5/kpropd.acl

7. Sul nuovo slave: Aggiungere il nome principale dell'host slave alla tabella di chiavi dello slave usando kadmin.

   È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master. Questa voce permetterà il funzionamento di kprop e di altre applicazioni basate su Kerberos.

   kdc3 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin: ktadd host/kdc3.spa.it kadmin: Voce per nome principale host/kdc3.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/krb5.keytab kadmin: quit

8. Sul KDC master: Aggiungere i nomi dei KDC slave al lavoro cron, che esegue automaticamente i backup, con il comando crontab -e.

   Aggiungere il nome di ogni KDC slave alla fine della riga kprop_script. Se kdc3 è stato definito come server slave durante la procedura di preconfigurazione, sarà sufficiente verificare il contenuto del file.

   10 3 * * * /usr/krb5/lib/kprop_script kdc2.spa.it kdc3.spa.it

   Eventualmente, si potrà cambiare l'ora impostata per i backup. Nella configurazione dell'esempio, il processo di backup ha inizio ogni giorno alle 3:10 AM.

9. Sul KDC master: Eseguire un backup del database e propagarlo usando kprop_script.

   Se è già disponibile una copia di backup del database, non sarà necessario crearne una nuova. Per maggiori informazioni, vedere "Propagare manualmente il database di Kerberos ai KDC slave".

   kdc1 # /usr/krb5/lib/kprop_script kdc3.spa.it Propagazione del database su kdc3.spa.it: OPERAZIONE ESEGUITA

10. Sul nuovo slave: Creare un file segreto usando kdb5_util.

    kdc3 # /usr/krb5/sbin/kdb5_util stash kdb5_util: Impossibile trovare/leggere la chiave master memorizzata durante la lettura della chiave master dalla tastiera kdb5_util: Attenzione: l'operazione proseguirà senza chiave master Inserire la chiave master per il database del KDC: <inserire la chiave>

11. Sul nuovo slave: Avviare il daemon KDC (krb5kdc).

    kdc3 # /etc/init.d/kdc start

12. Opzionale: Sul nuovo slave, sincronizzare l'orologio del KDC master usando NTP o un altro meccanismo di sincronizzazione dell'ora.

    Non è necessario installare e usare NTP, ma è importante, perché l'autenticazione abbia successo, che tutti gli orologi rientrino nell'arco di tempo predefinito specificato nella sezione libdefaults del file krb5.conf. Per maggiori informazioni su NTP, vedere "Sincronizzazione degli orologi tra i KDC e i client SEAM".

Configurazione dell'autenticazione tra settori

Sono disponibili diversi modi per collegare i settori in modo che gli utenti di un settore possano essere autenticati in un altro. Normalmente questo si ottiene stabilendo una chiave segreta da condividere tra due settori. Il rapporto tra i settori può essere gerarchico o direzionale (vedere"Gerarchia tra i settori").

Stabilire un'autenticazione gerarchica tra settori

In questo esempio verranno usati due settori, EURO.NORD.SPA.IT e NORD.SPA.IT. L'autenticazione tra i settori verrà stabilita in entrambe le direzioni. Questa procedura dovrà essere eseguita sul KDC master di entrambi i settori.

1. Prerequisiti per stabilire un'autenticazione gerarchica tra i settori.

   Questa procedura richiede che in entrambi i settori sia stato configurato il KDC master. Per provare il processo in modo completo, devono essere installati diversi client o KDC slave.

2. Diventare root sul primo KDC master.

3. Creare i nomi principali per il servizio TGT per i due settori usando kadmin.

   È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master.

   # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin: addprinc krbtgt/EURO.NORD.SPA.IT@NORD.SPA.IT Inserire la password per il nome principale krgtgt/EURO.NORD.SPA.IT@NORD.SPA.IT: <Inserire la password> kadmin: addprinc krbtgt/NORD.SPA.IT@EURO.NORD.SPA.IT Inserire la password per il nome principale krgtgt/NORD.SPA.IT@EURO.NORD.SPA.IT: <Inserire la password> kadmin: quit

   ---

   Nota -

   La password inserita per i nomi principali deve essere identica in entrambi i KDC; questo significa che la password per krbtgt/EURO.NORD.SPA.IT@NORD.SPA.IT dovrà essere uguale in entrambi i settori.

   ---

4. Aggiungere al file di configurazione di Kerberos (krb5.conf) le voci necessarie per definire i nomi di dominio per ogni settore.

   # cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .euro.nord.spa.it = EURO.NORD.SPA.IT .nord.spa.it = NORD.SPA.IT

   In questo esempio vengono definiti i nomi di dominio per i settori EURO.NORD.SPA.IT e NORD.SPA.IT. È importante inserire prima il sottodominio, poiché la ricerca nel file viene eseguita dall'alto in basso.

5. Copiare il file di configurazione di Kerberos su tutti i client del settore corrente.

   Perché l'autenticazione tra settori possa funzionare, su tutti i sistemi (inclusi i KDC slave e gli altri server) deve essere installata la nuova versione del file di configurazione di Kerberos (/etc/krb5/krb5.conf) .

6. Ripetere queste operazioni nel secondo settore.

Stabilire un'autenticazione diretta tra settori

In questo esempio vengono usati due settori: EURO.NORD.SPA.IT e VENDITE.SUD.SPA.IT. L'autenticazione tra i settori verrà stabilita in entrambe le direzioni. Questa procedura dovrà essere eseguita sul KDC master di entrambi i settori.

1. Prerequisiti per stabilire un'autenticazione diretta tra i settori.

   Questa procedura richiede che in entrambi i settori sia stato configurato il KDC master. Per provare il processo in modo completo, devono essere installati diversi client o KDC slave.

2. Diventare superutente su uno dei KDC master.

3. Creare i nomi principali per il servizio TGT per i due settori usando kadmin.

   È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master.

   # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin: addprinc krbtgt/EURO.NORD.SPA.IT@VENDITE.SUD.SPA.IT Inserire la password per il nome principale krgtgt/EURO.NORD.SPA.IT@VENDITE.SUD.SPA.IT: <Inserire la password> kadmin: addprinc krbtgt/VENDITE.SUD.SPA.IT@EURO.NORD.SPA.IT Inserire la password per il nome principale krgtgt/VENDITE.SUD.SPA.IT@EURO.NORD.SPA.IT: <Inserire la password> kadmin: quit

   ---

   Nota -

   La password inserita per i nomi principali deve essere identica in entrambi i KDC; questo significa che la password per krbtgt/EURO.NORD.SPA.IT@VENDITE.SUD.SPA.IT dovrà essere uguale in entrambi i settori.

   ---

4. Aggiungere al file di configurazione di Kerberos le voci necessarie per definire il percorso diretto fino al settore remoto (kdc.conf).

   Questo esempio si riferisce ai client del settore EURO.NORD.SPA.IT. Cambiando il nome del settore si otterranno le definizioni appropriate per VENDITE.SUD.SPA.IT.

   # cat /etc/krb5/krb5.conf [libdefaults] . . [capaths] EURO.NORD.SPA.IT = { VENDITE.SUD.SPA.IT = . } VENDITE.SUD.SPA.IT = { EURO.NORD.SPA.IT = . }

5. Copiare il file di configurazione di Kerberos su tutti i client del settore corrente.

   Perché l'autenticazione tra settori diversi possa funzionare, su tutti i sistemi (inclusi i KDC slave e gli altri server) deve essere installata la nuova versione del file di configurazione di Kerberos (krb5.conf).

6. Ripetere queste operazioni per il secondo settore.

Configurazione dei server di applicazioni di rete SEAM

I server di applicazioni di rete sono host a cui è possibile accedere usando una delle seguenti applicazioni di rete: ftp, rcp, rlogin, rsh o telnet. Per abilitare la versione SEAM di questi comandi su un server sono richieste alcune semplici operazioni.

Configurare un server di applicazioni di rete SEAM

In questa procedura vengono usati i seguenti parametri di configurazione:

• server di applicazioni = torino

• nome principale di amministrazione = kws/admin

• nome del dominio DNS = spa.it

• nome del settore = SPA.IT

1. Prerequisiti per la configurazione di un server di applicazioni.

   Questa procedura richiede che il KDC master sia stato configurato. Per provare il processo in modo completo, devono essere installati diversi client.

2. Installare il software client SEAM.

   Il software client SEAM deve essere installato.

3. Opzionale: Installare un client NTP o un altro meccanismo per la sincronizzazione degli orologi.

   Per informazioni su NTP, vedere "Sincronizzazione degli orologi tra i KDC e i client SEAM".

4. Avviare kadmin.

   L'uso dello strumento Amministrazione SEAM per l'aggiunta di un nome principale è descritto in "Creare un nuovo nome principale". L'esempio seguente spiega come aggiungere i nomi principali richiesti dalla riga di comando. È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master.

   kdc1 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin:

   1. Creare il nome principale host del server.

      kadmin: addprinc -randkey host/torino.spa.it Nome principale "host/torino.spa.it" creato. kadmin:

   2. Opzionale: Creare un nome principale root per il nome principale dell'host.

      kadmin: addprinc root/torino.spa.it Inserire la password per il nome principale root/torino.spa.it@SPA.IT: <Inserire la password> Reinserire la password per il nome principale root/torino.spa.it@SPA.IT: <Reinserire la password > Nome principale "root/torino.spa.it@SPA.IT" creato. kadmin:

   3. Aggiungere il nome principale host del server alla tabella di chiavi del server.

      Se il comando kadmin non è in esecuzione, riavviarlo con il comando seguente: /usr/krb5/bin/kadmin -p kws/admin

      kadmin: ktadd host/torino.spa.it kadmin: Voce per nome principale host/torino.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/krb5.keytab kadmin: quit

   4. Uscire da kadmin

      kadmin: quit

Configurazione dei server NFS SEAM

I server NFS utilizzano gli UID UNIX per identificare gli utenti e non possono usare direttamente i nomi principali. Per poter tradurre un nome principale in un UID, è necessario creare una tabella di credenziali che mappi i nomi principali degli utenti in UID UNIX. Le procedure seguenti descrivono le operazioni necessarie per configurare un server NFS SEAM, per amministrare la tabella delle credenziali e per avviare le modalità di sicurezza di Kerberos per i file system attivati via NFS. La tabella seguente descrive le operazioni descritte in questa sezione.

Configurare un server NFS SEAM

Questa procedura richiede che sia stato configurato il KDC master. Per provare il processo in modo completo sono necessari diversi client. Vengono usati i seguenti parametri di configurazione:

nome del settore = SPA.IT




nome del dominio DNS = spa.it




server NFS = milano.spa.it




nome principale di amministrazione = kws/admin

1. Prerequisiti per la configurazione di un server NFS SEAM.

   Deve essere installato il software client SEAM.

2. Opzionale: Installare un client NTP o un altro meccanismo per la sincronizzazione degli orologi.

   Per maggiori informazioni su NTP, vedere "Sincronizzazione degli orologi tra i KDC e i client SEAM".

3. Avviare kadmin.

   L'uso dello strumento Amministrazione SEAM per l'aggiunta di un nome principale è descritto in "Creare un nuovo nome principale". L'esempio seguente spiega come aggiungere i nomi principali richiesti dalla riga di comando. È necessario eseguire il login con uno dei nomi principali admin creati durante la configurazione del KDC master.

   milano # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin:

   1. Creare il nome principale per il servizio NFS del server.

      kadmin: addprinc -randkey nfs/milano.spa.it Nome principale "nfs/milano.spa.it" creato. kadmin:

   2. Opzionale: Creare un nome principale root per il server NFS.

      kadmin: addprinc root/milano.spa.it Inserire la password per il nome principale root/milano.spa.it@SPA.IT: <Inserire la password> Reinserire la password per il nome principale root/milano.spa.it@SPA.IT: <Reinserire la password > Nome principale "root/milano.spa.it@SPA.IT" creato. kadmin:

   3. Aggiungere il nome principale del servizio NFS del server nella tabella di chiavi del server.

      kadmin: ktadd nfs/milano.spa.it kadmin: Voce per nome principale nfs/milano.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/krb5.keytab kadmin: quit

   4. Uscire da kadmin

      kadmin: quit

4. Creare la tabella gsscred.

   Per maggiori informazioni, vedere "Creare una tabella di credenziali".

5. Condividere il file system NFS usando le modalità di sicurezza di Kerberos.

   Per maggiori informazioni, vedere "Configurare un ambiente NFS sicuro con più modalità di sicurezza Kerberos".

6. Su ogni client: autenticare sia il nome principale dell'utente che il nome principale di root.

   Per maggiori informazioni, vedere "Impostazione dell'autenticazione root per l'attivazione dei file system NFS".

Modificare il meccanismo back-end per la tabella gsscred

1. Diventare superutente sul server NFS.

2. Aprire con un editor il file /etc/gss/gsscred.conf e cambiare il meccanismo.

   Si potrà utilizzare uno dei seguenti meccanismi back-end: files, xfn_files, xfn_nis, xfn_nisplus o xfn. I vantaggi di ciascun meccanismo sono descritti in "Uso della tabella gsscred".

Creare una tabella di credenziali

La tabella di credenziali gsscred viene usata dai server NFS per mappare i nomi principali di SEAM in UID. Perché i client NFS possano attivare i file system da un server NFS usando l'autenticazione Kerberos, è necessario creare o rendere disponibile questa tabella.

1. Diventare superutente sul server appropriato.

   Il server da cui eseguire questo comando e l'ID da utilizzare per eseguirlo dipendono dal meccanismo back-end selezionato per supportare la tabella gsscred. Per tutti i meccanismi, ad eccezione di xfn_nisplus, è necessario diventare root.

   Se il meccanismo back-end è...	Procedere in questo modo
   files	Eseguire il comando sul server NFS
   xfn	Selezionare l'host in base all'impostazione predefinita del file xfn
   xfn_files	Eseguire il comando sul server NFS
   xfn_nis	Eseguire il comando sul master NIS
   xfn_nisplus	Eseguire il comando su qualunque sistema, purché in possesso delle autorizzazioni richieste per la modifica dei dati NIS+.

2. Opzionale: Se /var/fn non esiste e si desidera usare una delle opzioni xfn, creare un database XFN iniziale.

   # fnselect files # fncreate -t org -o org//

3. Creare la tabella delle credenziali usando gsscred.

   Questo comando raccoglie le informazioni da tutte le fonti elencate nella voce passwd del file /etc/nsswitch.conf. Se non si desidera includere le password locali nella tabella delle credenziali, si dovrà rimuovere temporaneamente la voce files. Per maggiori informazioni, vedere la pagina man gsscred(1M).

   # gsscred -m kerberos_v5 -a

Aggiungere una singola voce alla tabella delle credenziali

Questa procedura richiede che la tabella gsscred sia già stata installata sul server NFS.

1. Diventare superutente su un server NFS.

2. Aggiungere una voce alla tabella usando gsscred.

   # gsscred -m [meccanismo] -n [nome] -u [uid] -a

   meccanismo	Meccanismo di sicurezza da utilizzare.
   nome	Nome principale dell'utente, definito nel KDC.
   uid	UID dell'utente, definito nel database delle password.
   -a	Aggiunge l'UID alla mappa dei nomi principali.

Esempio: Aggiunta di una voce singola alla tabella delle credenziali

L'esempio seguente aggiunge una voce per l'utente giulia, mappato sull'UID 3736. L'UID, se non specificato nella riga di comando, viene ricavato dal file delle password.

# gsscred -m kerberos_v5 -n giulia -u 3736 -a

Configurare un ambiente NFS sicuro con più modalità di sicurezza Kerberos

1. Diventare superutente sul server NFS.

2. Aprire con un editor il file /etc/dfs/dfstab e aggiungere l'opzione sec= con le modalità di sicurezza richieste alle voci appropriate.

   # share -F nfs -o [modalità] [filesystem]

   modalità	Modalità di sicurezza da usare per la condivisione. Se si utilizzano più modalità di sicurezza, autofs userà la prima della lista come modalità predefinita.
   filesystem	Percorso del file system da condividere.

   Tutti i client che cercheranno di accedere ai file del file system specificato richiederanno l'autenticazione Kerberos. Per completare l'accesso ai file, dovranno essere autenticati sia il nome principale dell'utente, sia il nome principale root sul client NFS.

3. Controllare che il servizio NFS sia in esecuzione sul server.

   Se questo è il primo comando di condivisione utilizzato, è probabile che i daemon NFS non siano in esecuzione. I comandi seguenti permettono di arrestare e riavviare i daemon.

   # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start

4. Opzionale: Se si utilizza autofs, modificare i dati auto_master in modo da selezionare una modalità di sicurezza diversa da quella predefinita.

   Questa procedura non è necessaria se non si utilizza autofs per accedere al file system, o se si intende accettare la modalità di sicurezza predefinita.

   /home auto_home -nosuid,sec=krbi

5. Opzionale: Eseguire manualmente il comando mount per accedere al file system usando una modalità diversa da quella predefinita.

   In alternativa, la modalità di sicurezza può essere specificata con il comando mount, ma in questo modo non verrà sfruttata la funzione di attivazione automatica:

   # mount -F nfs -o sec=krb5p /export/home

Esempio: Condivisione di un file system con una sola modalità di sicurezza Kerberos

In questo esempio, per poter accedere ai file sarà necessaria l'autenticazione Kerberos.

# share -F nfs -o sec=krb5 /export/home

Esempio: Condivisione di un file system con più modalità di sicurezza Kerberos

In questo esempio, sono state selezionate tutte le tre modalità di sicurezza Kerberos. Se alla richiesta di attivazione non viene specificata una modalità di sicurezza, verrà usata la prima modalità elencata su tutti i client NFS V3 (in questo caso, krb5). Per maggiori informazioni, vedere "Modifiche al comando share".

# share -F nfs -o sec=krb5:krb5i:krb5p /export/home

Configurazione dei client SEAM

Un client SEAM può essere qualunque host, non un server KDC, della rete in cui devono essere utilizzati i servizi SEAM. Questa sezione descrive la procedura da seguire per installare un client SEAM, e contiene informazioni specifiche sull'uso dell'autenticazione di root per attivare i file system NFS.

Configurare un client SEAM

In questa procedura vengono usati i seguenti parametri di configurazione:

nome del settore = SPA.IT




nome del dominio DNS = spa.it




KDC master = kdc1.spa.it




KDC slave = kdc2.spa.it




client = client.spa.it




nome principale di amministrazione = kws/admin




nome principale dell'utente = mre




URL della guida in linea = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

---

Nota -

Adattare l'URL in modo che punti alla sezione "Amministrazione SEAM", come descritto in Note sul prodotto e sull'installazione di SEAM.

---

1. Prerequisiti per la configurazione di un client SEAM.

   Deve essere installato il software client SEAM.

2. Aprire con un editor il file di configurazione di Kerberos (krb5.conf).

   Se è stata usata la procedura di preconfigurazione, sarà sufficiente verificare il contenuto del file. Per modificare il file rispetto alla versione predefinita di SEAM, sarà necessario cambiare i nomi dei settori e i nomi dei server, e specificare il percorso dei file della guida per gkadmin.

   kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = SPA.IT [realms] SPA.IT = { kdc = kdc1.spa.it kdc = kdc2.spa.it admin_server = kdc1.spa.it } [domain_realm] .spa.it = SPA.IT # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://milano:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

3. Opzionale: Sincronizzare l'ora con l'orologio del KDC master usando NTP o un altro meccanismo di sincronizzazione.

   Per informazioni su NTP, vedere "Sincronizzazione degli orologi tra i KDC e i client SEAM".

4. Opzionale: Creare un nome principale per l'utente.

   Questa operazione è necessaria solo se all'utente associato all'host corrente non è stato ancora assegnato un nome principale. Per istruzioni sull'uso dello strumento Amministrazione SEAM, vedere "Creare un nuovo nome principale". Qui di seguito è mostrato un esempio dalla riga di comando.

   client1 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin: addprinc mre Inserire la password per il nome principale mre@SPA.IT: <Inserire la password> Reinserire la password per il nome principale mre@SPA.IT: <Reinserire la password> kadmin:

5. Creare un nome principale per root.

   kadmin: addprinc root/client1.spa.it Inserire la password per il nome principale root/client1.spa.it@SPA.IT: <Inserire la password> Reinserire la password per il nome principale root/client1.spa.it@SPA.IT: <Reinserire la password > kadmin: quit

6. (Opzionale) Per fare in modo che gli utenti del client SEAM possano attivare automaticamente i file system NFS basati su Kerberos usando l'autenticazione Kerberos, sarà necessario autenticare l'utente root.

   Il modo più sicuro per eseguire questo processo è con l'uso del comando kinit; tuttavia, gli utenti dovranno usare kinit come root ogni volta che dovranno attivare un file system protetto con Kerberos. In alternativa, si può scegliere di usare una tabella di chiavi. Per informazioni dettagliate sui requisiti delle tabella di chiavi, vedere "Impostazione dell'autenticazione root per l'attivazione dei file system NFS".

   client1 # /usr/krb5/bin/kinit root/client1.spa.it Password per root/client1.spa.it@SPA.IT: <Inserire la password>

   Per usare la tabella di chiavi, aggiungere il nome principale di root alla tabella di chiavi del client usando kadmin:

   client1 # /usr/krb5/sbin/kadmin -p kws/admin Inserire la password: <Inserire la password per kws/admin> kadmin: ktadd root/client1.spa.it kadmin: Voce per nome principale root/client.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/krb5.keytab kadmin: quit

7. Se si desidera che il client avverta gli utenti sulla scadenza dei ticket di Kerberos, creare una voce nel file /etc/krb5/warn.conf.

   Per maggiori informazioni, vedere warn.conf(4).

8. Aggiornare il percorso di ricerca della shell dell'utente includendovi la posizione dei comandi e delle pagine man di SEAM.

   Se il software SEAM è stato installato usando i file di configurazione, ed è stata selezionata l'opzione per aggiornare automaticamente la definizione di PATH, sarà sufficiente modificare la variabile MANPATH. Se si utilizza la C shell, digitare:

   % set path=(/usr/krb5/bin $path) % set MANPATH=(/usr/krb5/man $MANPATH)

   Per applicare queste modifiche in modo permanente al percorso di ricerca della shell, modificare il proprio file .cshrc o .login.

   Se si utilizza la Bourne shell o la Korn shell, digitare:

   $ PATH=/usr/krb5/bin:$PATH $ MANPATH=/usr/krb5/man:$MANPATH

   Per applicare queste modifiche in modo permanente al percorso di ricerca della shell, modificare il proprio file .profile.

Impostazione dell'autenticazione root per l'attivazione dei file system NFS

Per accedere a un file system NFS non basato su Kerberos, gli utenti potranno attivare il file system come root, oppure accedere automaticamente al file system usando l'automounter (senza bisogno delle autorizzazioni di root).

L'attivazione di un file system NFS basato su Kerberos avviene sostanzialmente nello stesso modo, ma comporta un ostacolo in più. Per attivare un file system NFS basato su Kerberos, infatti, gli utenti devono usare il comando kinit come root per ottenere le credenziali per il nome principale root del client, poiché tale nome principale non si trova generalmente nella tabella di chiavi del client. Questo vale anche se si utilizza l'automounter. Non solo questo è un passaggio aggiuntivo, ma costringe anche gli utenti a conoscere la password di root del loro sistema e la password del nome principale root.

Per evitare questo passaggio, è possibile aggiungere il nome principale root del client alla tabella di chiavi del client, che fornirà automaticamente le credenziali per root. Questo permette agli utenti di attivare i file system NFS senza bisogno di eseguire il comando kinit e rende più semplice l'uso del sistema, ma rappresenta un rischio per la sicurezza. Ad esempio, se un utente ottiene l'accesso a un sistema che contiene il nome principale root nella sua tabella di chiavi, quell'utente ha la possibilità di ottenere le credenziali di root. Questo significa che occorrerà adottare le misure di sicurezza appropriate. Per maggiori informazioni, vedere "Amministrazione delle tabelle di chiavi".

Sincronizzazione degli orologi tra i KDC e i client SEAM

Tutti gli host che partecipano al sistema di autenticazione Kerberos devono avere gli orologi interni sincronizzati entro un arco di tempo massimo specificato (detto scostamento orario), che rappresenta un ulteriore controllo di sicurezza di Kerberos. Il superamento dello scostamento orario tra gli host produce il rifiuto delle richieste dei client.

Lo scostamento orario determina anche per quanto tempo i server di applicazioni debbano registrare i messaggi del protocollo di Kerberos al fine di riconoscere e rifiutare le richieste ripetute. Perciò, quanto più lungo è il valore dello scostamento orario, tanto maggiore sarà il volume di informazioni che i server di applicazioni dovranno raccogliere.

Il valore predefinito per lo scostamento orario massimo è di 300 secondi (cinque minuti), ma è possibile modificarlo nella sezione libdefaults del file krb5.conf.

Per ragioni di sicurezza, si consiglia di non aumentare lo scostamento orario a più di 300 secondi.

Poiché è importante mantenere gli orologi sincronizzati tra i KDC e i client SEAM, si consiglia a tale scopo di usare il software Network Time Protocol (NTP). Si tratta di un software di pubblico dominio prodotto dalla University of Delaware incluso in Solaris a partire dalla versione 2.6.

Un altro metodo per sincronizzare gli orologi è quello di usare il comando rdate e i lavori cron, che possono rappresentare un processo meno vincolante dell'uso di NTP. In questa sezione, tuttavia, si farà riferimento all'uso di NTP. Si ricordi inoltre che, se si utilizza la rete per sincronizzare gli orologi, il protocollo di sincronizzazione deve essere di per sé sicuro.

NTP permette di gestire in modo preciso la sincronizzazione dell'ora e/o degli orologi di rete in un ambiente di rete. NTP è essenzialmente un'implementazione server/client. Designando un sistema come orologio di riferimento (server NTP), gli orologi di tutti gli altri sistemi (client NTP) verranno sincronizzati con quello di riferimento. La sincronizzazione avviene attraverso il daemon xntpd, che definisce e mantiene un'ora di sistema UNIX in conformità con i server standard di Internet. La Figura 3-1, mostra un esempio dell'uso dell'implementazione server/client NTP.

Figura 3-1 Sincronizzazione degli orologi con NTP

Per garantire che i KDC e i client SEAM abbiano gli orologi sincronizzati, procedere come segue:

1. Configurare un server NTP nella rete (è possibile scegliere qualunque sistema ad eccezione del KDC master). Vedere "Configurare un server NTP".

2. Durante la configurazione dei KDC e dei client SEAM nella rete, configurarli come client NTP del server NTP. Vedere "Configurare un client NTP".

Configurare un server NTP

1. Diventare superutente sul sistema da configurare come server NTP.

2. Spostarsi nella directory /etc/inet.

3. Copiare il file ntp.server nel file ntp.conf.

   # cp ntp.server ntp.conf

4. Spostarsi nella directory /etc/init.d.

5. Avviare il daemon xntpd.

   # ./xntpd start

Configurare un client NTP

1. Diventare superutente sul sistema da configurare come client NTP.

2. Spostarsi nella directory /etc/inet.

3. Copiare il file ntp.client nel file ntp.conf.

   # cp ntp.client ntp.conf

4. Spostarsi nella directory /etc/init.d.

5. Avviare il daemon xntpd.

   # ./xntpd start

Sostituzione di un KDC master con uno slave

Le procedure qui descritte permettono di sostituire un KDC master con un KDC slave. Si consiglia di utilizzarle solo in caso di guasto del KDC master o quando il KDC master debba essere reinstallato (ad esempio per l'adozione di un nuovo hardware).

Configurare un KDC slave come sistema di backup

Questa procedura deve essere eseguita sul KDC slave da rendere disponibile in sostituzione del master.

1. Durante l'installazione, usare un alias sia per il KDC master che per il KDC slave da configurare per la sua sostituzione.

   Nel definire i nomi host per i KDC, includere un alias per ogni sistema nel DNS e usare questi alias nel definire gli host in /etc/krb5/krb5.conf.

2. Installare il software del KDC master.

   Insieme al software del KDC master vengono installati i file binari e gli altri file che saranno necessari per la sostituzione, inclusi tutti i file che saranno richiesti dal KDC slave. Al termine dell'installazione, non riavviare il sistema.

3. Seguire la procedura per l'installazione di un KDC slave.

   Prima della sostituzione, questo server dovrebbe funzionare esattamente come gli altri KDC slave del settore. Per le relative istruzioni, vedere "Configurare un KDC slave". Non installare il software slave. Tutti i file necessari vengono installati durante l'installazione del software master.

4. Spostare i comandi del KDC master.

   Per evitare che i comandi del KDC master vengano eseguiti dallo slave, spostare kprop, kadmind e kadmin.local in una posizione riservata.

   kdc4 # mv /usr/krb5/lib/kprop /usr/krb5/lib/kprop.save kdc4 # mv /usr/krb5/lib/kadmind /usr/krb5/lib/kadmind.save kdc4 # mv /usr/krb5/sbin/kadmin.local /usr/krb5/sbin/kadmin.local.save

5. Disabilitare l'avvio di kadmind in /etc/init.d/kdc.master.

   Per evitare che lo slave gestisca le richieste di modifica del database del KDC, commentare la riga per l'avvio di kadmind nello script:

   kdc4 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then # $BINDIR/kadmind fi ;;

6. Commentare la riga kprop nel file crontab di root.

   Questa operazione impedirà allo slave di propagare la sua copia del database del KDC.

   kdc4 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/krb5/lib/kprop_script kdc1.spa.it

Sostituire un KDC master con uno slave

Questa procedura richiede che il KDC slave sia stato configurato per la sostituzione del master (vedere "Configurare un KDC slave come sistema di backup"). In questa procedura, il server master che viene sostituito è denominato kdc1, mentre lo slave che lo sostituisce è denominato kdc4.

1. Sul vecchio master: Arrestare il processo kadmind.

   L'arresto del processo kadmind impedisce che il database del KDC venga modificato.

   kdc1 # /etc/init.d/kdc.master stop

2. Sul vecchio master: Commentare la riga kprop nel file crontab di root.

   Questa operazione impedisce che il vecchio master propaghi la sua copia del database del KDC.

   kdc1 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/krb5/lib/kprop_script kdc2.spa.it

3. Sul vecchio master: Disabilitare l'avvio di kadmind in /etc/init.d/kdc.master.

   Per impedire che il master riavvii kadmind in caso di riavvio del server, commentare la riga per l'avvio di kadmind nello script:

   kdc1 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then # $BINDIR/kadmind fi ;;

4. Sul vecchio master: Eseguire kprop_script per eseguire il backup e la propagazione del database.

   kdc1 # /usr/krb5/lib/kprop_script kdc4.spa.it Propagazione del database su kdc4.spa.it: OPERAZIONE ESEGUITA

5. Sul vecchio master: Rinominare i comandi del KDC master.

   Per impedire che vengano eseguiti i comandi del KDC master, rinominare kprop, kadmind e kadmin.local usando un nome differente.

   kdc4 # mv /usr/krb5/lib/kprop /usr/krb5/lib/kprop.save kdc4 # mv /usr/krb5/lib/kadmind /usr/krb5/lib/kadmind.save kdc4 # mv /usr/krb5/sbin/kadmin.local /usr/krb5/sbin/kadmin.local.save

6. Sul server DNS: Cambiare l'alias per il master.

   Per scambiare i server, aprire con un editor il file di zona spa.it e cambiare la voce relativa a masterkdc.

   masterkdc IN CNAME kdc4

7. Sul server DNS: Riavviare il server di denominazione del dominio Internet.

   Eseguire il comando seguente su entrambi i server per ottenere le informazioni sul nuovo alias:

   # pkill -1 in.named

8. Sul nuovo master: Rinominare i comandi del KDC master.

   kdc4 # mv /usr/krb5/lib/kprop.save /usr/krb5/lib/kprop kdc4 # mv /usr/krb5/lib/kadmind.save /usr/krb5/lib/kadmind kdc4 # mv /usr/krb5/sbin/kadmin.local.save /usr/krb5/sbin/kadmin.local

9. Sul nuovo master: Creare una tabella di chiavi per kadmin usando kadmin.local.

   Questa sequenza di comandi crea una speciale tabella di chiavi con i nomi principali per admin e changepw. Questi nomi principali sono necessari per il servizio kadmind.

   kdc4 # /usr/krb5/sbin/kadmin.local kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.spa.it Voce per nome principale kadmin/kdc4.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.spa.it Voce per nome principale changepw/kdc4.spa.it con kvno 3, tipo di cifratura DES-CBC-CRC aggiunta alla tabella di chiavi WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: quit

10. Sul nuovo master: Abilitare l'avvio di kadmind in /etc/init.d/kdc.master.

    kdc4 # cat /etc/init.d/kdc.master . . case "$1" in 'start') if [ -f $KDC_CONF_DIR/kdc.conf ] then $BINDIR/kadmind fi ;;

11. Sul nuovo master: Avviare kadmind.

    kdc4 # /etc/init.d/kdc.master start

12. Abilitare la riga kprop nel file crontab di root.

    kdc4 # crontab -e #ident "@(#)root 1.19 98/07/06 SMI" /* SVr4.0 1.1.3.1 */ # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * 0,4 /etc/cron.d/logchecker 10 3 * * 0 /usr/lib/newsyslog 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean 10 3 * * * /usr/krb5/lib/kprop_script kdc1.spa.it

Amministrazione del database di Kerberos

Il database di Kerberos è la struttura portante del sistema di autenticazione e deve essere amministrato correttamente. Questa sezione descrive alcune delle procedure necessarie per amministrare il database di Kerberos, tra cui il backup e il ripristino del database, la configurazione di una propagazione parallela e l'amministrazione del file segreto. La procedura per la configurazione iniziale del database è descritta in "Configurare un KDC master".

Backup e propagazione del database di Kerberos

La propagazione del database di Kerberos dal KDC master ai KDC slave è una delle operazioni di configurazione più importanti. Se la propagazione non viene eseguita con una frequenza sufficiente, il KDC master e i KDC slave rischiano di non essere sincronizzati; in questo caso, se il KDC master dovesse arrestarsi, i KDC slave non disporranno delle informazioni più recenti del database. Inoltre, se un KDC slave è stato configurato come master per scopi di bilanciamento dei carichi, i client che utilizzano questo slave come KDC master non disporranno delle informazioni più recenti. Per queste ragioni, è importante impostare la propagazione con una frequenza sufficiente in base alla frequenza delle modifiche effettuate al database di Kerberos.

Durante la configurazione del KDC master, lo script kprop_script viene inserito in un lavoro cron perché esegua automaticamente il backup del database di Kerberos nel file /var/krb5/slave_datatrans e lo propaghi ai KDC slave. Può accadere, tuttavia, che il database di Kerberos venga danneggiato. Se questo accade su uno dei KDC slave, tale danneggiamento può passare completamente inosservato, poiché la successiva propagazione automatica del database ne installerà una nuova copia. Se invece il file viene danneggiato sul KDC master, il database danneggiato verrà copiato su tutti i server slave durante la propagazione successiva, e il backup danneggiato sovrascriverà la copia corretta precedente sul KDC master.

Poiché questo scenario non prevede l'esistenza di una copia di backup "sicura", è consigliabile configurare un lavoro cron che copi periodicamente il file slave_datatrans in un'altra posizione, o che crei una copia di backup separata usando il comando dump di kdb5_util. In questo modo, se il database dovesse essere danneggiato, sarà possibile ripristinare il backup più recente sul KDC master usando il comando load di kdb5_util.

Un altro aspetto importante da osservare è che, poiché il file di salvataggio del database contiene le chiavi dei nomi principali, è necessario proteggere questo file dagli accessi non autorizzati (nella configurazione predefinita, il file di salvataggio del database ha le autorizzazioni di lettura/scrittura solo per l'utente root). Questo significa che si dovrà usare solo il comando kprop per propagare il file di archiviazione del database, il quale esegue una cifratura dei dati trasferiti. Inoltre, kprop propaga i dati solo ai KDC slave, riducendo la probabilità che il file del database venga inviato accidentalmente a un host non autorizzato.

Se il database di Kerberos viene aggiornato dopo essere stato propagato e il file del database viene danneggiato prima della propagazione successiva, gli slave non conterranno gli aggiornamenti, che andranno perduti. Per questa ragione, se vengono effettuate numerose modifiche al database diverso tempo prima di una propagazione pianificata, è consigliabile propagare il database manualmente per evitare la perdita di dati.

File kpropd.acl

Il file kpropd.acl di un KDC contiene un elenco di nomi principali di host, uno per riga, che specifica i sistemi da cui il KDC può ricevere un database aggiornato attraverso il meccanismo di propagazione. Se si utilizza il KDC master per propagare il database a tutti i KDC slave, il file kpropd.acl di ogni slave dovrà contenere solo il nome principale dell'host del master.

Tuttavia, l'installazione di SEAM e le successive procedure di configurazione descritte in questo manuale permettono di aggiungere lo stesso file kpropd.acl sia al KDC master che ai KDC slave. Il file contiene tutti i nomi principali degli host KDC. Questa configurazione permette di propagare il database da qualunque KDC, nel caso in cui i KDC designati perla propagazione diventino temporaneamente indisponibili. Inoltre, la presenza di una copia identica del file su tutti i KDC ne facilita la manutenzione.

Comando kprop_script

Il comando kprop_script utilizza il comando kprop per propagare il database di Kerberos ad altri KDC. (Se kprop_script viene eseguito su un KDC slave, esso propagherà la copia del database di Kerberos di quello slave agli altri KDC.) kprop_script può accettare come argomenti un elenco di nomi host, separati da spazi, che denotino i KDC su cui eseguire la propagazione.

L'esecuzione di kprop_script crea una copia di backup del database di Kerberos nel file /var/krb5/slave_datatrans e copia questo file sui KDC specificati. Il database di Kerberos rimane bloccato fino al termine della propagazione.

Eseguire il backup del database di Kerberos

1. Diventare superutente sul KDC master.

2. Eseguire il backup del database di Kerberos usando il comando dump di kdb5_util.

   # /usr/krb5/sbin/kdb5_util dump [-verbose] [-d nome_db] [nome_file] [nomi_principali...]

   -verbose	Visualizza tutti i nomi principali e i criteri di cui viene eseguito il backup.
   nome_db	Nome del database di cui deve essere eseguito il backup. Si noti che a tutti i nomi di database specificati viene aggiunto il suffisso ".db", e che è possibile specificare un percorso assoluto per il file. Se non viene specificata l'opzione -d, il nome predefinito del database è /var/krb5/principal, che diventa effettivamente /var/krb5/principal.db.
   nome_file	File in cui deve essere eseguito il backup del database. È possibile specificare un percorso assoluto per il file. Se non viene specificato il nome di un file, il database viene salvato nell'output standard.
   nomi_principali	Elenco dei nomi principali (separati da uno spazio) di cui deve essere eseguito il backup. È necessario utilizzare nomi principali pienamente qualificati. Se non viene specificato nessun nome principale, il backup viene eseguito sull'intero database.

Esempio: Backup del database di Kerberos

L'esempio seguente descrive il backup del database di Kerberos in un file di nome dumpfile. Poiché viene specificata l'opzione -verbose, vengono visualizzati tutti i nomi principali di cui viene eseguito il backup.

# kbd5_util dump -verbose dumpfile 
kadmin/kdc1.euro.spa.it@EURO.SPA.IT 
krbtgt/euro.spa.it@EURO.SPA.IT 
kadmin/history@EURO.SPA.IT 
pak/admin@EURO.SPA.IT 
pak@EURO.SPA.IT
changepw/kdc1.euro.spa.it@EURO.SPA.IT
#

L'esempio seguente descrive il backup dei nomi principali pak e pak/admin dal database di Kerberos.

# kdb5_util dump -verbose dumpfile pak/admin@EURO.SPA.IT pak@EURO.SPA.IT
pak/admin@EURO.SPA.IT
pak@EURO.SPA.IT
#

Ripristinare il database di Kerberos

1. Diventare superutente sul KDC master.

2. Ripristinare il database di Kerberos usando il comando load di kdb_util.

   # /usr/krb5/sbin/kdb5_util load [-verbose] [-d nome_db] [-update] [nome_file]

   -verbose	Visualizza tutti i nomi principali e i criteri che vengono ripristinati.
   nome_db	Nome del database che deve essere ripristinato. Si noti che a tutti i nomi di database specificati viene aggiunto il suffisso ".db", e che è possibile specificare un percorso assoluto per il file. Se non viene specificata l'opzione -d, il nome predefinito del database è/var/krb5/principal, che diventa effettivamente /var/krb5/principal.db.
   -update	Aggiorna il database esistente; diversamente, viene creato un nuovo database o viene sovrascritto il database esistente.
   nome_file	File da cui deve essere ripristinato il database. È possibile specificare un percorso assoluto per il file.

Esempio: Ripristino del database di Kerberos

L'esempio seguente descrive il ripristino del database di nome database1.db nella directory corrente dal file dumpfile. Poiché non viene specificata l'opzione -update, l'operazione di ripristino crea un nuovo database.

# kdb5_util load -d database1 dumpfile

Propagare manualmente il database di Kerberos ai KDC slave

Questa procedura spiega come propagare il database di Kerberos usando il comando kprop. Questo comando può essere usato se occorre sincronizzare un KDC slave con il KDC master al di fuori del lavoro cron periodico. A differenza di kprop_script, kprop permette di propagare solo il backup corrente del database, senza bisogno di creare prima una nuova copia di backup.

1. Diventare superutente sul KDC master.

2. (Opzionale) Eseguire il backup del database usando il comando kdb5_util.

   # /usr/krb5/sbin/kdb5_util dump /var/krb5/slave_datatrans

3. Propagare il database su un KDC slave usando il comando kprop.

   # /usr/krb5/lib/kprop -f /var/krb5/slave_datatrans KDC_slave

Se si desidera eseguire un backup del database e propagarlo a un KDC slave al di fuori del lavoro cron periodico, è anche possibile usare il comando kprop_script come segue:

# /usr/krb5/lib/kprop_script KDC_slave

Configurazione di una propagazione parallela

In genere, il KDC master viene usato esclusivamente per propagare il suo database ai KSC slave. Tuttavia, se nel sito sono presenti numerosi KDC slave, può essere comodo suddividere il carico del processo di propagazione, mediante una propagazione parallela.

La propagazione parallela permette a determinati KDC slave di condividere le operazioni di propagazione con il KDC master. Questo permette di velocizzare la propagazione e di alleggerire il lavoro del KDC master.

Ad esempio, si supponga che nel sito siano presenti un KDC master e sei slave (come mostrato nella Figura 3-2), in cui i server da slave-1 a slave-3 formino un unico raggruppamento logico e i server da slave-4 a slave-6 un secondo raggruppamento logico. Configurando una propagazione parallela, il KDC master potrà propagare il database a slave-1 e a slave-4, e questi slave potranno a loro volta propagare il database agli slave del loro gruppo.

Figura 3-2 Esempio di configurazione di una propagazione parallela

Configurare una propagazione parallela

Quella descritta non è una procedura dettagliata, ma un elenco generale delle operazioni di configurazione da eseguire per abilitare la propagazione parallela.

1. Sul KDC master, modificare la voce kprop_script nel lavoro cron includendo solo gli argomenti per gli slave che dovranno eseguire la propagazione successiva (slave di propagazione).

2. Su ogni slave di propagazione, aggiungere una voce kprop_script al lavoro cron che includa gli argomenti per gli slave su cui eseguire la propagazione. Perché la propagazione parallela riesca, il lavoro cron deve essere configurato in modo da essere eseguito dopo la propagazione del nuovo database allo slave di propagazione.

   ---

   Nota -

   La durata della propagazione del database agli slave di propagazione dipende da fattori come l'ampiezza di banda della rete e le dimensioni del database.

   ---

3. Su ogni KDC slave, configurare le autorizzazioni appropriate per la propagazione, aggiungendo il nome principale dell'host del KDC propagante al rispettivo file kpropd.acl.

Esempio: Configurazione di una propagazione parallela

Usando l'esempio della Figura 3-2, la voce kprop_script del KDC master dovrebbe avere la forma seguente:

10 3 * * * /usr/krb5/lib/kprop_script slave-1.spa.it slave-4.spa.it

La voce kprop_script di slave-1 dovrebbe avere la forma seguente (si noti che la propagazione sullo slave inizierà un'ora dopo la propagazione eseguita dal master):

10 4 * * * /usr/krb5/lib/kprop_script slave-2.spa.it slave-3.spa.it

Il file kpropd.acl degli slave di propagazione dovrà contenere la voce seguente:

host/master.spa.it@SPA.IT

Il file kpropd.acl degli slave propagati da slave-1 dovrà contenere la voce seguente:

host/slave-1.spa.it@SPA.IT

Amministrazione del file segreto

Il file segreto contiene la chiave master per il database di Kerberos, che viene creata automaticamente quando si crea il database. Se questo file viene danneggiato, è possibile usare il comando stash di kdb5_util(1M) per sostituirlo. L'unico caso in cui è necessario rimuovere un file segreto è dopo la rimozione del database di Kerberos con il comando destroy di kdb5_util. Poiché infatti il file segreto non viene rimosso automaticamente insieme al database, per completare l'operazione è necessario eliminarlo manualmente.

Rimuovere un file segreto

1. Diventare superutente sul KDC che contiene il file segreto.

2. Rimuovere il file segreto.

   # rm file_segreto

   file_segreto

   Percorso del file segreto. Nella configurazione predefinita, il file segreto si trova in /var/krb5/.k5.settore.

Se occorre ricreare il file segreto, si può usare l'opzione -f del comando kdb5_util.

Rafforzamento della sicurezza

Queste procedure descrivono le operazioni da effettuare per rafforzare la sicurezza dei server di applicazioni SEAM e dei server KDC.

Abilitare solo le applicazioni basate su Kerberos

Questa procedura limita l'accesso via rete al server mediante telnet, ftp, rcp, rsh e rlogin alle sole transazioni autenticate da Kerberos.

1. Modificare la voce telnet in /etc/inetd.conf.

   Aggiungere l'opzione -a user alla voce telnet per limitare l'accesso agli utenti che possono fornire informazioni di autenticazione valide.

   telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a user

2. Modificare la voce ftp in /etc/inetd.conf.

   Aggiungere l'opzione -a alla voce ftp per abilitare solo i collegamenti autenticati da Kerberos.

   ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd -a

3. Disabilitare le voci di Solaris per gli altri servizi in /etc/inetd.conf.

   Commentare o rimuovere le voci per shell e login.

   # shell stream tcp nowait root /usr/sbin/in.rshd in.rshd # login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind

Limitare l'accesso ai server KDC

I server KDC master e slave memorizzano localmente le rispettive copie del database KDC. La limitazione dell'accesso a questi server e ai loro database è perciò importante per la sicurezza generale dell'installazione SEAM.

1. Disabilitare i servizi remoti in /etc/inetd.conf.

   Per rendere sicuro un server KDC, è buona norma disabilitare tutti i servizi di rete non essenziali commentando le voci per l'avvio di questi servizi in /etc/inetd.conf. In genere, gli unici servizi di cui è richiesta l'esecuzione sono time e krdb5_kprop. I servizi che utilizzano i loopback tli (ticlts, ticotsord e ticots) possono restare abilitati. Dopo la modifica, il file dovrebbe avere la forma seguente (per ragioni di brevità, l'esempio non include tutte le righe commentate):

   kdc1 # cat /etc/inetd.conf # #ident "@(#)inetd.conf 1.33 98/06/02 SMI" /* SVr4.0 1.5 */ . . #name dgram udp wait root /usr/sbin/in.tnamed in.tnamed # #shell stream tcp nowait root /usr/sbin/in.rshd in.rshd #login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind #exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd #comsat dgram udp wait root /usr/sbin/in.comsat in.comsat #talk dgram udp wait root /usr/sbin/in.talkd in.talkd # #uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # #finger stream tcp nowait nobody /usr/sbin/in.fingerd in.fingerd # # Time service is used for clock synchronization. # time stream tcp nowait root internal time dgram udp wait root internal # . . # 100234/1 tli rpc/ticotsord wait root /usr/lib/gss/gssd gssd #dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd #100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd 100134/1 tli rpc/ticotsord wait root /usr/krb5/lib/ktkt_warnd kwarnd #klogin stream tcp nowait root /usr/krb5/lib/rlogind rlogind -k #eklogin stream tcp nowait root /usr/krb5/lib/rlogind rlogind -k -e #telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd #ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd #kshell stream tcp nowait root /usr/krb5/lib/rshd rshd -k -c -A krb5_prop stream tcp nowait root /usr/krb5/lib/kpropd kpropd

   Al termine delle modifiche, riavviare il server.

2. Limitare l'accesso all'hardware che supporta il KDC.

   Per limitare l'accesso fisico, collocare il server e il suo monitor in un luogo sicuro. Gli utenti normali non dovrebbero avere alcun tipo di accesso a questo server.

3. Memorizzare copie di backup del database KDC su dischi locali o sui server slave.

   L'archiviazione su nastro del database KDC è consigliabile solo se i nastri possono essere riposti in un luogo sicuro. Questo vale anche per le copie delle tabelle di chiavi. La soluzione ideale è quella di memorizzare i file in un file system locale che non sia condiviso da altri sistemi. Il file system di memorizzazione può risiedere sia sul KDC master che sugli slave.