Types de tickets

Les tickets ont des propriétés régissant leur utilisation. Ces propriétés sont attribuées au ticket lors de sa création, mais vous pouvez les modifier ultérieurement. (Par exemple, un ticket peut passer de transférable à transféré). Vous pouvez visualiser les propriétés d'un ticket au moyen de la commande klist (voir "Comment afficher les tickets").

Les tickets peuvent être décrits par un ou plusieurs des termes suivants :

transférable/transféré

Un ticket transférable peut être envoyé d'un hôte à un autre, sans que le client doive se réauthentifier. Par exemple, si l'utilisateur david obtient un ticket transférable pendant qu'il utilise l'ordinateur de julie, il peut se connecter à son propre ordinateur sans devoir obtenir un nouveau ticket (et donc sans se réauthentifier). (La section "Exemple -- Création d'un ticket" donne un exemple de ticket transférable.) Comparez ce type de ticket au ticket à proxy, décrit plus loin.

initial

Un ticket initial est émis directement, et n'est pas basé sur un ticket d'octroi de tickets. Certains services, par exemple les applications qui changent les mots de passe, peuvent exiger que les tickets soient identifiés comme initiaux afin de s'assurer que le client connaît sa clé secrète -- car un ticket initial indique que le client s'est récemment authentifié (plutôt que de se fier à un ticket d'octroi de tickets pouvant exister depuis longtemps).

incorrect

Un ticket incorrect est un ticket postdaté non encore utilisable. (Voir postdaté, ci-après.) Il sera refusé par un serveur d'applications jusqu'à ce qu'il soit validé. Pour être validé, il doit être présenté au KDC par le client dans une requête de service d'octroi de tickets, avec l'indicateur VALIDATE activé, une fois son heure de validité atteinte.

postdatable/postdaté

Un ticket postdaté ne devient valide qu'un certain temps après sa création. Ce genre de ticket est utile, par exemple, pour les traitements par lots exécutés durant la nuit, étant donné que si le ticket est volé, il ne pourra pas être employé avant l'exécution du traitement par lots. Lorsqu'un ticket postdaté est émis, il a le type incorrect et demeure ainsi jusqu'à ce que son heure de validité soit atteinte, et que le client demande la validation par le KDC. (Voir incorrect, ci-dessus.) Un ticket postdaté est normalement valide jusqu'à l'heure d'expiration du ticket d'octroi de tickets. Toutefois, s'il est identifié comme renouvelable, sa durée de vie est généralement égale à la durée de vie totale du ticket d'octroi de tickets. Voir renouvelable, ci-dessous.

à proxy/proxy

Il peut parfois s'avérer nécessaire pour un principal de permettre à un service d'effectuer une opération à sa place (par exemple si le principal demande à un service d'exécuter une tâche d'impression sur un troisième hôte). Le service doit être en mesure d'adopter l'identité du client, mais uniquement pour cette opération. En pareil cas, le serveur agit comme proxy pour le client. Le nom du principal du proxy doit être précisé lors de la création du ticket.

Un ticket à proxy est semblable à un ticket transférable, mais il n'est valide que pour un seul service, tandis qu'un ticket transférable accorde au service l'usage complet de l'identité du client. On peut donc considérer un ticket transférable comme une sorte de super-proxy.

renouvelable

Étant donné que les tickets à longue durée de vie peuvent poser des risques de sécurité, on peut désigner un ticket comme étant renouvelable. Un ticket renouvelable possède deux heures d'expiration : l'heure à laquelle l'instance courante du ticket expire, et la durée de vie maximale de tout ticket. Si un client veut continuer d'utiliser un ticket, il le renouvelle avant sa première expiration. Par exemple, un ticket peut être valide durant une heure, et la durée de vie de tous les tickets peut être de dix heures. Si le client détenant le ticket désire le conserver plus d'une heure, il doit le renouveler au cours de cette heure. Lorsqu'un ticket atteint la durée de vie maximale des tickets (10 heures), il expire automatiquement et ne peut plus être renouvelé.

Pour savoir comment visualiser les attributs des tickets, consultez la section "Comment afficher les tickets".

Durée de vie des tickets

Lorsqu'un principal obtient un ticket, y compris un ticket d'octroi de tickets, la durée de vie du ticket est la plus petite des deux valeurs suivantes :

• La durée de vie spécifiée par l'option -l de kinit, si kinit est utilisée pour obtenir la durée de vie des tickets ou pour renouveler le ticket

• La durée de vie maximale (max_life) spécifiée dans le fichier kdc.conf

• La durée de vie maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket. (Dans le cas de kinit, le principal de service est krbtgt/secteur)

• La durée de vie maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur qui demande le ticket.

La Figure 7-1 indique comment la durée de vie d'un ticket d'octroi de tickets est établie, et illustre la provenance des quatre valeurs de durée de vie. Bien que la Figure 7-1 indique comment la durée de vie d'un ticket d'octroi de tickets est déterminée, le même principe s'applique lorsqu'un principal obtient un ticket. Les seules différences sont que kinit ne fournit pas de valeur de durée de vie et que le principal de service fournissant le ticket spécifie la durée de vie maximale (plutôt que le principal krbtgt/secteur ).

Figure 7-1 Détermination de la durée de vie d'un ticket d'octroi de tickets

La durée de vie d'un ticket renouvelable est également établie en fonction du minimum de quatre valeurs, mais les valeurs de durée de vie renouvelable sont utilisées :

• La durée de vie renouvelable spécifiée par l'option -r de kinit, si kinit est utilisée pour obtenir ou renouveler le ticket

• La durée de vie renouvelable maximale (max_renewable_life) spécifiée dans le fichier kdc.conf

• La valeur renouvelable de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket (dans le cas de kinit, le principal de service est krbtgt/secteur)

• La valeur renouvelable de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur qui demande le ticket

Noms de principal

Chaque ticket est identifié par un nom de principal. Ce nom peut identifier un utilisateur ou un service. Voici des exemples de noms de principal.