Tipi di ticket

I ticket sono dotati di proprietà che determinano in che modo possono essere utilizzati. Queste proprietà vengono assegnate durante la loro creazione, ma possono essere modificate successivamente. (Ad esempio, un ticket inoltrabile può diventare inoltrato.) Le proprietà dei ticket possono essere visualizzate con il comando klist (vedere "Visualizzare i ticket").

I ticket possono essere definiti da uno o più dei seguenti termini:

inoltrabile/inoltrato

Un ticket inoltrabile può essere inviato da un host ad un altro, evitando al client di doversi autenticare nuovamente. Ad esempio, se l'utente davide ottiene un ticket inoltrabile mentre lavora sul sistema di giovanna, egli potrà eseguire il login sul proprio sistema senza bisogno di richiedere un nuovo ticket (e perciò senza doversi autenticare nuovamente). (Per un esempio di ticket inoltrabile, vedere "Esempio: Creazione di un ticket".) Confrontare il ticket inoltrabile con il ticket delegabile descritto più avanti.

iniziale

Un ticket si dice iniziale quando viene emesso direttamente, cioè non sulla base di un TGT. Alcuni servizi, come le applicazioni per la modifica delle password, richiedono che i ticket siano iniziali per avere la certezza che il client conosca la sua chiave segreta. Un ticket iniziale indica infatti che il client si è autenticato recentemente (invece di operare sulla base di un TGT, che può essere stato emesso da diverso tempo).

non valido

Si dice non valido un ticket postdatato che non sia ancora diventato utilizzabile. (Vedere la definizione di postdatato.) Questi ticket vengono rifiutati dai server di applicazioni finché non diventano validi. Per diventare validi, essi devono essere presentati al KDC dal client in una richiesta TGS, con il flag VALIDATE, una volta trascorsa la data iniziale.

postdatabile/postdatato

Un ticket si dice postdatato quando diventa valido dopo un certo tempo dalla sua creazione. Questi ticket sono utili, ad esempio, per i lavori batch da eseguire durante la notte, poiché in caso di furto non potranno essere utilizzati fino all'ora stabilita per l'esecuzione del lavoro. I ticket postdatati vengono generati come non validi e rimangono tali fino a quando non trascorre la loro data iniziale e finché il client non richiede una convalida al KDC. (Vedere la definizione di non valido.) I ticket postdatati sono normalmente validi fino alla data di scadenza del TGT; tuttavia, se sono rinnovabili, la loro durata è normalmente uguale all'intera durata del TGT. Vedere la definizione di rinnovabile.

delegabile/proxy

A volte, si può avere la necessità che un servizio esegua un'operazione per conto di un nome principale. (Ad esempio, un nome principale può richiedere a un servizio di eseguire un lavoro di stampa su un terzo host.) Il servizio deve avere la possibilità di assumere l'identità del client, ma per una sola operazione. In questo caso, si dice che il server funge da proxy per il client. Il nome principale del proxy deve essere specificato durante la creazione del ticket.

Un ticket delegabile è simile a un ticket inoltrabile, ma è valido solo per un singolo servizio, mentre i ticket inoltrabili concedono al servizio l'uso completo dell'identità del client. Un ticket inoltrabile può perciò essere considerato una sorta di super-proxy.

rinnovabile

Poiché i ticket con una durata molto lunga possono rappresentare un rischio per la sicurezza, i ticket possono essere designati come rinnovabili. Un ticket rinnovabile ha due date di scadenza: la data di scadenza dell'istanza corrente del ticket e la durata massima applicata a tutti i ticket. Se un client vuole continuare ad usare un certo ticket, esso può rinnovarlo prima della prima data di scadenza. Ad esempio, si supponga che un ticket abbia una validità di un'ora e che la durata massima di tutti i ticket sia di dieci ore. Se il client in possesso del ticket volesse prolungare la sua durata per più di un'ora, esso dovrà rinnovarlo entro l'ora di validità. Quando un ticket raggiunge la durata massima (10 ore), esso scade automaticamente e non può essere rinnovato.

Per informazioni su come visualizzare gli attributi dei ticket, vedere "Visualizzare i ticket".

Durata dei ticket

Ogni volta che un nome principale ottiene un ticket, inclusi i TGT, la durata del ticket viene impostata in base al valore più piccolo tra i seguenti:

• La durata specificata dall'opzione -l di kinit, se si è usato kinit per ottenere il ticket

• La durata massima (max_life) specificata nel file kdc.conf

• La durata massima specificata nel database di Kerberos per il nome principale del servizio che ha emesso il ticket. (Nel caso di kinit, il nome principale del servizio è krbtgt/settore)

• La durata massima specificata nel database di Kerberos per il nome principale dell'utente che ha richiesto il ticket.

La Figura 7-1 illustra come viene determinata la durata dei TGT e da dove provengono i quattro valori di durata considerati. La Figura 7-1 si riferisce al modo in cui viene determinata la durata di un TGT, ma lo stesso accade essenzialmente ogni volta che un qualunque nome principale ottiene un ticket. Le uniche differenze consistono nel fatto che kinit non fornisce un valore di durata, e che il nome principale del servizio che emette il ticket fornisce un valore per la durata massima (invece del nome principale krbtgt/settore).

Figura 7-1 Come viene determinata la durata di un TGT

La durata dei ticket rinnovabili viene determinata in base al più piccolo di questi quattro valori:

• Il valore della durata rinnovabile specificata dall'opzione -r di kinit, se per ottenere o rinnovare il ticket si è utilizzato kinit

• Il valore della durata massima rinnovabile (max_renewable_life) specificato nel file kdc.conf

• Il valore della durata massima rinnovabile specificato nel database di Kerberos per il nome principale del servizio che ha emesso il ticket (nel caso di kinit, il nome principale del servizio è krbtgt/settore)

• Il valore della durata massima rinnovabile specificato nel database di Kerberos per il nome principale dell'utente che ha richiesto il ticket

Nomi principali

Ogni ticket è identificato da un nome principale. Il nome principale può identificare un utente o un servizio. Qui di seguito sono mostrati alcuni esempi di diversi nomi principali.

Tabella 7-4 Esempi di nomi principali

Nome principale	Descrizione
root/torino.spa.it@SPA.IT	Nome principale associato all'account root su un client NFS. Il nome principale root è necessario per le attivazioni NFS autenticate.
host/torino.spa.it@SPA.IT	Nome principale usato dalle applicazioni basate su Kerberos (klist e kprop, ad esempio) e dai servizi basati su Kerberos (come ftp e telnet). Viene detto nome principale host o di servizio.
nome_utente@SPA.IT	Nome principale di un utente.
nome_utente/admin@SPA.IT	Nome principale admin che può essere usato per amministrare il database del KDC.
ftp/torino.spa.it@SPA.IT	Nome principale usato dal servizio ftp. Può essere usato al posto di un nome principale host.
K/M@SPA.IT	Nome principale della chiave master. Vi è un nome principale di questo tipo associato ad ogni KDC master.
kadmin/history@SPA.IT	Nome principale che include una chiave usata per conservare le password già utilizzate per altri nomi principali. Vi è un nome principale di questo tipo associato ad ogni KDC master.
kadmin/kdc1.spa.it@SPA.IT	Nome principale per il KDC master che consente l'accesso al KDC mediante kadmind.
changepw/kdc1.spa.it@SPA.IT	Nome principale per il KDC master che consente l'accesso al KDC durante la modifica delle password.
krbtgt/SPA.IT@SPA.IT	Nome principale usato durante la generazione di un TGT.