Types de tickets

Les tickets ont des propriétés qui régissent la façon dont ils peuvent être utilisés. Ces propriétés sont assignées au ticket lors de sa création et peuvent être modifiées ultérieurement. Par exemple, un ticket peut passer de forwardable à forwarded. Vous pouvez visualiser les propriétés de ticket à l'aide de la commande klist. Voir Affichage des tickets Kerberos.

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

Transmissible/transmis

Un ticket transmissible peut être envoyé à partir d'un hôte vers un autre, supprimant la nécessité pour un client de se réauthentifier. Par exemple, si l'utilisateur david obtient un ticket transmissible sur la machine de l'utilisateur jennifer, david peut se connecter à sa propre machine sans devoir obtenir un nouveau ticket (et donc s'authentifier à nouveau). Reportez-vous à Example 6–1 pour consulter un exemple de ticket transmissible.

Initial

Un ticket initial est un ticket émis directement, et non sur la base d'un ticket d'octroi de tickets. Certains services, tels que les applications modifiant les mots de passe, peuvent nécessiter des tickets marqués comme étant initiaux afin d'assurer que le client puisse démontrer qu'il connaît sa clé secrète. Un ticket initial indique que le client s'est récemment authentifié et ne dépend pas d'un ticket d'octroi de tickets qui peut être plus ancien.

Non valide

Un ticket non valide est un ticket postdaté qui n'est pas encore devenu utilisable. Un ticket non valide est rejeté par un serveur d'application jusqu'à ce qu'il soit validé. Pour être validé, un ticket doit être présenté au KDC par le client dans une demande de TGS, avec l'indicateur –VALIDATE, après l'heure de début.

Postdatable/postdaté

Un ticket postdaté est un ticket qui ne devient valide qu'après une période spécifiée après sa création. Par exemple, un tel ticket peut être utile avec les tâches exécutées par lots la nuit car le ticket, s'il est volé, ne peut pas être utilisé tant que l'exécution de ces tâches n'a pas eu lieu. Lorsqu'un ticket postdaté est émis, il est émis en tant que non valide et le reste jusqu'à ce que son heure de début soit dépassée, et que le client demande la validation par le KDC. Un ticket postdaté est normalement valide jusqu'à l'heure d'expiration du ticket d'octroi de tickets. Toutefois, si le ticket est marqué comme renouvelable, sa durée de vie est normalement égale à la durée de vie entière du ticket d'octroi de tickets.

Utilisable avec proxy/proxy

A certains moments, principal peut s'avérer nécessaire de permettre à un service d'effectuer une opération en son nom. Le nom du principal du proxy doit être spécifié lors de la création du ticket. Oracle Solaris ne prend pas en charge les tickets utilisables avec proxy ou les tickets proxy.

Un ticket utilisable avec proxy est similaire à un ticket transmissible à ceci près qu'il n'est valide que pour un seul service. Un ticket transmissible accorde le service auquel la utilisation complète de l'identité du client. Un ticket transmissible peut par conséquent être considéré comme une sorte de super-proxy.

Renouvelable

Comme les tickets avec de très longues durées de vie impliquent un risque en matière de sécurité, les tickets peuvent être désignés comme renouvelables. Un ticket renouvelable possède deux moments d'expiration : l'heure à laquelle l'instance courante du ticket expire et la durée de vie maximale de tout ticket (une semaine). Si un client souhaite continuer à utiliser un ticket, il peut le renouveler avant sa première expiration. Par exemple, supposons qu'un ticket peut être valide pendant une heure, et que tous les tickets ont une durée de vie maximale de dix heures. Si le client détenant le ticket souhaite le conserver plus d'une heure, il doit le renouveler dans l'heure. Lorsqu'un ticket atteint sa durée de vie maximale (dix heures), celui-ci expire automatiquement et ne peut pas être renouvelé.

Pour plus d'informations concernant la façon de visualiser les attributs des tickets, reportez-vous à la section Affichage des tickets Kerberos.

Durée de vie des tickets

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

• La valeur de la durée de vie qui est spécifiée par l'option –l de kinit, sikinit est utilisée pour obtenir le ticket. Par défaut, kinit utilise la valeur de durée de vie maximale

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

• Valeur 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/realm.

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

La capture d'écran suivante illustre une durée de vie d'un TGT est déterminée et d'où les quatre valeurs de durée de vie de ces dernières. Par un principal obtient un ticket, la durée de vie du ticket est déterminé de la même manière. Les deux différences sont que kinit n'offre pas une valeur de durée de vie et que le principal de service fournissant le ticket offre une valeur de durée de vie maximale au lieu du principal krbtgt/realm.

Figure 7-1  Détermination de la durée de vie d'un TGT

La durée de vie d'un ticket renouvelable est déterminée à partir de la plus basse de quatre valeurs, comme suit :

• Valeur de 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.

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

• Valeur de durée de vie renouvelable 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/realm.

• Valeur de durée de vie renouvelable maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur demandant le ticket.

Noms de principaux Kerberos

Chaque ticket est identifié par un nom de principal. Le nom de principal peut identifier un utilisateur ou un service. Les exemples suivants montrent les noms de principal standard, procédez comme suit :

changepw/kdc1.example.com@EXAMPLE.COM

Principal pour le serveur KDC maître qui permet l'accès au KDC lorsque vous modifiez les mots de passe.

clntconfig/admin@EXAMPLE.COM

Principal utilisé par l'utilitaire d'installation kclient.

ftp/boston.example.com@EXAMPLE.COM

Un principal utilisé par le service ftp. Ce principal peut être utilisé à la place d'un principal host.

host/boston.example.com@EXAMPLE.COM

Principal utilisé par des applications utilisant Kerberos (klist et kprop, par exemple) et des services (tels que ftp et telnet). Ce principal est appelé host ou principal de service. Le principal est utilisé pour authentifier les montages NFS. Ce principal est également utilisé par un client pour vérifier que le TGT émis au client provient du bon KDC.

K/M@EXAMPLE.COM

Nom de principal de la clé principale. Un nom de principal de clé principale est associé à chaque KDC maître.

kadmin/history@EXAMPLE.COM

Principal incluant une clé utilisée pour conserver l'historique des mots de passe d'autres principaux. Chaque KDC maître possède l'un de ces principaux.

kadmin/kdc1.example.com@EXAMPLE.COM

Principal pour le serveur KDC maître qui permet l'accès au KDC à l'aide de la commande kadmind.

kadmin/changepw.example.com@EXAMPLE.COM

Principal utilisé pour accepter les demandes de modification de mot de passe émises par les clients qui n'exécutent pas une version d'Oracle Solaris.

krbtgt/EXAMPLE.COM@EXAMPLE.COM

Ce principal est utilisé lors de la génération d'un ticket d'octroi de tickets.

krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM

Ce principal est un exemple de ticket d'octroi de tickets inter-domaine.

nfs/boston.example.com@EXAMPLE.COM

Principal utilisé par le service NFS. Ce principal peut être utilisé à la place d'un principal host.

root/boston.example.com@EXAMPLE.COM

Principal associé au compte root sur un client. Ce principal est appelé principal root et fournit un accès root aux systèmes de fichiers montés NFS.

username@EXAMPLE.COM

Principal d'un utilisateur.

username/admin@EXAMPLE.COM

Principal admin pouvant être utilisé pour l'administration de la base de données KDC.