- Documentazione ufficiale
- Guide della comunità
- 12.04 LTS

web wiki forum planet
help.ubuntu-it comunità italiana

- Desktop
- Server
- Ricerca

Questa guida non è stata ancora completamente tradotta. Se vuoi contribuire alla sua traduzione contatta il Gruppo Traduzione di Ubuntu-it.
Guida a Ubuntu Server » Autenticazione di rete »
Indietro | Avanti

# Kerberos

Kerberos è un sistema di autenticazione di rete basato sul principio di un "agente" terzo fidato. Le altre due parti sono l'utente e il servizio a cui l'utente vuole autenticarsi. Non tutti i serivizi e le applicazioni possono usare Kerberos, ma quelle che ne sono in grado, consentono di portare la rete a essere un SSO (Single Sign On).

Questa sezione spiega come installare e configurare un server Kerberos, fornendo alcuni esempi di configurazione.

- Panoramica
- Server Kerberos
- KDC secondario
- Client Kerberos Linux
- Risorse

## Panoramica

Se si è nuovi di Kerberos, ci sono alcuni termini che è bene comprendere prima di procedere. Molti di questi termini potrebbero essere simili ad altri concetti di altri ambienti più familiari.

- Principal: qualsiasi utente, computer e servizio fornito da server deve essere difinito come "Kerberos Principal".

- Istanze: usate dai principal di servizio e da quelli amministrativi.

- Realms: the unique realm of control provided by the Kerberos installation. Think of it as the domain or group your hosts and users belong to. Convention dictates the realm should be in uppercase. By default, ubuntu will use the DNS domain converted to uppercase (EXAMPLE.COM) as the realm.

- Key Distribution Center (KDC): consiste di tre parti, un database di tutti i principal, il server di autenticazione e il server che garantisce i ticket. Per ogni reame deve esserci almeno un KDC.

- Ticket Granting Ticket (TGT): emesso dallo "Authentication Server" (AS), il "Ticket Granting Ticket" è cifrato con la password dell'utente ed è quindi noto solo all'utente e al KDC.

- Ticket Granting Server (TGS): emette i ticket su richiesta dei client.

- Ticket:: conferma l'identità dei due principal. Uno è l'utente e l'altro il servizio richiesto. Il ticket stabilisce una chiave di cifratura usata per garantire la sicurezza della comunicazione durante la fase di autenticazione.

- File keytab: sono file estratti dal KDC e contengono le chiavi di cifratura per un servizio o un host.

To put the pieces together, a Realm has at least one KDC, preferably more for redundancy, which contains a database of Principals. When a user principal logs into a workstation that is configured for Kerberos authentication, the KDC issues a Ticket Granting Ticket (TGT). If the user supplied credentials match, the user is authenticated and can then request tickets for Kerberized services from the Ticket Granting Server (TGS). The service tickets allow the user to authenticate to the service without entering another username and password.

## Server Kerberos

### Installazione

For this discussion, we will create a MIT Kerberos domain with the following features (edit them to fit your needs):

- Realm: EXAMPLE.COM

- Primary KDC: kdc01.example.com (192.168.0.1)

- Secondary KDC: kdc02.example.com (192.168.0.2)

- User principal: steve

- Admin principal: steve/admin

It is strongly recommended that your network-authenticated users have their uid in a different range (say, starting at 5000) than that of your local users.

Before installing the Kerberos server a properly configured DNS server is needed for your domain. Since the Kerberos Realm by convention matches the domain name, this section uses the EXAMPLE.COM domain configured in Server primario of the DNS documentation.

Also, Kerberos is a time sensitive protocol. So if the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. To correct the problem all hosts should have their time synchronized using the same Network Time Protocol (NTP) server. For details on setting up NTP see Sincronizzazione del tempo con NTP.

The first step in creating a Kerberos Realm is to install the krb5-kdc and krb5-admin-server packages. From a terminal enter:

    sudo apt-get install krb5-kdc krb5-admin-server

You will be asked at the end of the install to supply the hostname for the Kerberos and Admin servers, which may or may not be the same server, for the realm.

By default the realm is created from the KDC's domain name.

Creare il reame con l'utilità kdb5_newrealm:

    sudo krb5_newrealm

### Configurazione

The questions asked during installation are used to configure the /etc/krb5.conf file. If you need to adjust the Key Distribution Center (KDC) settings simply edit the file and restart the krb5-kdc daemon. If you need to reconfigure Kerberos from scratch, perhaps to change the realm name, you can do so by typing

    sudo dpkg-reconfigure krb5-kdc

1. Once the KDC is properly running, an admin user -- the admin principal -- is needed. It is recommended to use a different username from your everyday username. Using the kadmin.local utility in a terminal prompt enter:

       sudo kadmin.local
       Authenticating as principal root/admin@EXAMPLE.COM with password.
       kadmin.local: addprinc steve/admin
       WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy
       Enter password for principal "steve/admin@EXAMPLE.COM":
       Re-enter password for principal "steve/admin@EXAMPLE.COM":
       Principal "steve/admin@EXAMPLE.COM" created.
       kadmin.local: quit

   In the above example steve is the Principal, /admin is an Instance, and @EXAMPLE.COM signifies the realm. The "every day" Principal, a.k.a. the user principal, would be steve@EXAMPLE.COM, and should have only normal user rights.

   Sostituire EXAMPLE.COM e steve con il proprio reame e il nome utente dell'amministratore.

2. Il nuovo utente amministratore necessita dei permessi ACL (Access Control List) corretti, configurati tramite il file /etc/krb5kdc/kadm5.acl:

       steve/admin@EXAMPLE.COM        *

   This entry grants steve/admin the ability to perform any operation on all principals in the realm. You can configure principals with more restrictive privileges, which is convenient if you need an admin principal that junior staff can use in Kerberos clients. Please see the kadm5.acl man page for details.

3. Riavviare krb5-admin-server affinché le nuove ACL abbiano effetto:

       sudo /etc/init.d/krb5-admin-server restart

4. Il nuovo utente può essere provato con l'utilità kinit:

       kinit steve/admin
       steve/admin@EXAMPLE.COM's Password:

   Una volta inserita la password, usare l'utilità klist per visualizzare le informazioni riguardo il TGT (Ticket Granting Ticket):

       klist
       Credentials cache: FILE:/tmp/krb5cc_1000
               Principal: steve/admin@EXAMPLE.COM

         Issued           Expires          Principal
       Jul 13 17:53:34  Jul 14 03:53:34  krbtgt/EXAMPLE.COM@EXAMPLE.COM

   Where the cache filename krb5cc_1000 is composed of the prefix krb5cc_ and the user id (uid), which in this case is 1000. You may need to add an entry into the /etc/hosts for the KDC so the client can find the KDC. For example:

       192.168.0.1   kdc01.example.com       kdc01

   Replacing 192.168.0.1 with the IP address of your KDC. This usually happens when you have a Kerberos realm encompassing different networks separated by routers.

5. The best way to allow clients to automatically determine the KDC for the Realm is using DNS SRV records. Add the following to /etc/named/db.example.com:

       _kerberos._udp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
       _kerberos._tcp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
       _kerberos._udp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com.
       _kerberos._tcp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com.
       _kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1  0 749 kdc01.example.com.
       _kpasswd._udp.EXAMPLE.COM.      IN SRV 1  0 464 kdc01.example.com.

   Sostituire EXAMPLE.COM, kdc01 e kdc02 con il nome del proprio dominio, il KDC primario e quello secondario.

   Consultare DNS (Domain Name Service) per le istruzioni sulla configurazione di DNS.

Il reame Kerberos è ora pronto per autenticare i client.

## KDC secondario

Once you have one Key Distribution Center (KDC) on your network, it is good practice to have a Secondary KDC in case the primary becomes unavailable. Also, if you have Kerberos clients that are in different networks (possibly separated by routers using NAT), it is wise to place a secondary KDC in each of those networks.

1. Per prima cosa installare il pacchetto e quando vengono chiesti i nomi di Kerberos e Admin, inserire il nome del KDC primario:

       sudo apt-get install krb5-kdc krb5-admin-server

2. Una volta installato il pacchetto, creare il KDC secondario. Da un terminale, digitare:

       kadmin -q "addprinc -randkey host/kdc02.example.com"

   Una volta eseguiti i comandi kadmin viene chiesto la propria password NOME_UTENTE/ADMIN@EXAMPLE.COM.

3. Estrarre il file keytab_

       kadmin -q "ktadd -norandkey -k keytab.kdc02 host/kdc02.example.com"

4. Dovrebbe esserci un file keytab.kdc02 nella directory corrente, spostare il file in /etc/krb5.keytab:

       sudo mv keytab.kdc02 /etc/krb5.keytab

   Se il percorso a keytab.kdc02 è diverso, modificarlo in base al proprio caso.

   È possibile elencare tutti i principal presenti in un file Keytab, utile durante la risoluzione dei problemi, con l'utilità klist:

       sudo klist -k /etc/krb5.keytab

   The -k option indicates the file is a keytab file.

5. Dovrebbe esserci un file kpropd.acl in ogni KDC che presenti tutti i KDC del reame. Per esempio, sia sul KDC primario che secondario, creare un file /etc/krb5kdc/kpropd.acl:

       host/kdc01.example.com@EXAMPLE.COM
       host/kdc02.example.com@EXAMPLE.COM

6. Creare un database vuoto nel KDC secondario:

       sudo kdb5_util -s create

7. Avviare il demone kpropd che resterà in ascolto per le connessioni dall'utilità kprop. kprop è usato per trasferire i file di dump:

       sudo kpropd -S

8. Da un terminale dal KDC primario, creare un file di dump del database principale:

       sudo kdb5_util dump /var/lib/krb5kdc/dump

9. Estrarre il keytab del KDC primario e copiarlo in /etc/krb5.keytab:

       kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com"
       sudo mv keytab.kdc01 /etc/krb5.keytab

   Assicurarsi che ci sia un host per kdc01.example.com prima di estrarre il keytab.

10. Usando l'utilità kprop eseguire il push del database sul KDC secondario:

        sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com

    Dovrebbe essere visualizzato un messaggio di SUCCEEDED se la propagazione è andata a buon fine. Se si è verificato un errore, per maggiori informazioni, controllare /var/log/syslog sul KDC secondario.

    You may also want to create a cron job to periodically update the database on the Secondary KDC. For example, the following will push the database every hour (note the long line has been split to fit the format of this document):

        # m h  dom mon dow   command
        0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump &&
        /usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com

11. Sempre nel KDC secondario, creare un file stash in cui salvare la chiave principale di Kerberos:

        sudo kdb5_util stash

12. Avviare il demone krb5-kdc sul KDC secondario:

        sudo /etc/init.d/krb5-kdc start

The Secondary KDC should now be able to issue tickets for the Realm. You can test this by stopping the krb5-kdc daemon on the Primary KDC, then by using kinit to request a ticket. If all goes well you should receive a ticket from the Secondary KDC. Otherwise, check /var/log/syslog and /var/log/auth.log in the Secondary KDC.

## Client Kerberos Linux

Questa sezione spiega come configurare un sistema Linux come un client Kerberos consentendo l'accesso a qualsiasi servizio Kerberos ad accesso effettuato correttamente da parte degli utenti.

### Installazione

Per autenticarsi in un reame Kerberos sono necessari i pacchetti krb5-user e libpam-krb5 oltre ad altri non strettamente necessari, ma che semplificano molto la gestione. Per installare questi pacchetti, digitare:

    sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config

Il pacchetto auth-client-config consente una semplice configurazione dell'autenticazione PAM per diverse sorgenti e libpam-ccreds memorizza le credenziali di autenticazione consentendo di effettuare l'accesso anche se il KDC non è disponibile. Questo pacchetto è utile anche per i computer portatili che possono autenticarsi su reti aziendali, ma devono essere in grado di farlo anche al di fuori della rete.

### Configurazione

Per configurare il client, in un terminale digitare:

    sudo dpkg-reconfigure krb5-config

Viene quindi chiesto di inserire il nome del reame Kerberos. Inoltre, se non si dispone di un DNS configurato con i record SRV di Kerberos, viene richiesto il nome dell'host del KDC e del server amministrativo.

Il comando dpkg-reconfigure aggiunge delle voci al file /etc/krb5.conf del proprio reame. Dovrebbero essere disponibili delle voci simili alle seguenti:

    [libdefaults]
            default_realm = EXAMPLE.COM
    ...
    [realms]
            EXAMPLE.COM = }
                    kdc = 192.168.0.1
                    admin_server = 192.168.0.1
            }

If you set the uid of each of your network-authenticated users to start at 5000, as suggested in Installazione, you can then tell pam to only try to authenticate using Kerberos users with uid > 5000:

    # Kerberos should only be applied to ldap/kerberos users, not local ones.
    for i in common-auth common-session common-account common-password; do
     sudo sed -i -r \
     -e 's/pam_krb5.so minimum_uid=1000/pam_krb5.so minimum_uid=5000/' \
     /etc/pam.d/$i
    done

This will avoid being asked for the (non-existent) Kerberos password of a locally authenticated user when changing its password using passwd.

Per avviare la configurazione, richiedere un ticket usando l'utilità kinit. Per esempio:

    kinit steve@EXAMPLE.COM
    Password for steve@EXAMPLE.COM:

Una volta ottenuto un ticket, i dettagli possono essere visualizzati usando klist:

    klist
    Ticket cache: FILE:/tmp/krb5cc_1000
    Default principal: steve@EXAMPLE.COM

    Valid starting     Expires            Service principal
    07/24/08 05:18:56  07/24/08 15:18:56  krbtgt/EXAMPLE.COM@EXAMPLE.COM
            renew until 07/25/08 05:18:57

    Kerberos 4 ticket cache: /tmp/tkt1000
    klist: You have no tickets cached

Usare auth-client-config per configurare il modulo libpam-krb5 affinché richieda un ticket durante la fase di accesso:

    sudo auth-client-config -a -p kerberos_example

Una volta autenticati con successo, si dovrebbe ricevere un ticket.

## Risorse

- For more information on MIT's version of Kerberos, see the MIT Kerberos site.

- The Ubuntu Wiki Kerberos page has more details.

- Il libro Kerberos: The Definitive Guide di O'Reilly è un ottimo punto di riferimento per impostare un server Kerberos.

- Also, feel free to stop by the #ubuntu-server and #kerberos IRC channels on Freenode if you have Kerberos questions.

Indietro | Avanti