Chapitre 7 Référence SEAM

Ce chapitre décrit plusieurs des fichiers, commandes et démons faisant partie du produit SEAM. En outre, il donne des renseignements détaillés sur le fonctionnement du système d'authentification Kerberos.

Voici une liste des informations de référence présentées dans ce chapitre.

• "Fichiers SEAM"

• "Commandes de SEAM"

• "Démons de SEAM"

• "Terminologie SEAM"

• "Comment fonctionne le système d'authentification"

• "Accès à un service avec SEAM"

• "Utilisation de la table gsscred"

Fichiers SEAM

Fichier de configuration du module d'authentification enfichable

Le fichier de configuration par défaut du module d'authentification enfichable fourni avec SEAM inclut des entrées de traitement des nouvelles applications Kerberos. Le nouveau fichier comporte des entrées pour le service d'authentification, la gestion des comptes, la gestion des sessions et les modules de gestion des mots de passe.

Pour le module d'authentification, les nouvelles entrées concernent rlogin, login, dtlogin, krlogin, ktelnet et krsh. Un exemple de ces entrées est présenté ci-dessous. Tous ces services ont recours à la nouvelle bibliothèque de modules d'authentification enfichables, /usr/lib/security/pam_krb5.so.1, pour l'authentification Kerberos.

Les trois premières entrées utilisent l'option try_first_pass, qui demande l'authentification au moyen du mot de passe initial de l'utilisateur. L'utilisation du mot de passe initial signifie que l'utilisateur n'est pas invité à entrer un autre mot de passe, même si de multiples mécanismes sont indiqués.

Les trois entrées suivantes utilisent l'option acceptor pour empêcher le module d'authentification enfichable d'effectuer l'étape d'obtention du ticket d'octroi de tickets initial. Pour les applications de serveur Kerberos, l'échange est déjà effectué par l'application ; il n'est donc pas nécessaire d'effectuer l'étape au moyen du module d'authentification enfichable. En outre, une entrée other est incluse comme entrée par défaut pour toutes les entrées exigeant une authentification qui ne sont pas spécifiées.

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

Pour la gestion des comptes, dtlogin possède une nouvelle entrée utilisant la bibliothèque Kerberos, comme indiqué ci-dessous. Une entrée other est incluse pour fournir une valeur par défaut. Actuellement, aucune action n'est effectuée par l'entrée other .

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

Les deux dernières entrées du fichier /etc/pam.conf sont présentées ci-dessous. L'entrée other de gestion de session détruit les justificatifs d'identité d'utilisateur. La nouvelle entrée other de gestion des mots de passe sélectionne la bibliothèque Kerberos.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

Commandes de SEAM

Cette section décrit certaines commandes incluses dans le produit SEAM.

Modifications apportées à la commande share

En plus des nouvelles commandes de SEAM, le produit SEAM comporte des modifications de la commande share dans les versions Solaris 2.6 et Solaris 7. Trois nouveaux modes de sécurité peuvent être employés par la commande share :

krb5

Sélection de l'authentification Kerberos

krb5i

Sélection de l'authentification Kerberos avec intégrité

krb5p

Sélection de l'authentification Kerberos avec intégrité et confidentialité

Si plusieurs modes sont inclus avec la commande share, le premier mode indiqué est utilisé par défaut si le client ne spécifie pas de mode de sécurité. Sinon, le mode sélectionné par le client est utilisé.

Si une requête de montage effectuée au moyen d'un mode Kerberos échoue, le montage se termine avec aucun comme mode de sécurité. Cela arrive fréquemment lorsque le principal racine sur le client NFS n'est pas authentifié. La requête de montage peut réussir, mais l'utilisateur sera incapable d'accéder aux fichiers à moins qu'ils ne soient authentifiés par Kerberos. Toute transaction effectuée entre le client et le serveur exige une authentification Kerberos, même si le système de fichiers n'est pas monté avec un mode de sécurité Kerberos.

Démons de SEAM

Le tableau ci-dessous présente les démons utilisés dans le produit SEAM.

Terminologie SEAM

Cette section présente des termes utilisés dans la documentation SEAM et donne leur définition. Il importe de bien saisir le sens de ces termes afin de pouvoir comprendre le texte.

Terminologie propre à l'authentification

Les termes décrits ci-après sont nécessaires à une bonne compréhension du processus d'authentification. Les programmeurs et les administrateurs de système devraient se familiariser avec ces termes.

Un client est le logiciel exécuté sur le poste de travail d'un utilisateur. Le logiciel SEAM exécuté sur le client effectue des requêtes durant ce processus, et il importe de différencier les actions de ce logiciel et celles de l'utilisateur.

Les termes «serveur» et «service» sont souvent employés de manière interchangeable. Pour fins de clarification, le terme serveur désigne le système physique où le logiciel SEAM est exécuté. Le terme service désigne une fonction particulière prise en charge par un serveur (par exemple, ftp ou nfs). La documentation mentionne souvent des serveurs faisant partie d'un service, mais cela obscurcit le sens des termes ; par conséquent, le serveur désigne le système physique, et le service désigne le logiciel.

Le produit SEAM inclut trois types de clé. L'un deux est la clé privée. Cette clé est attribuée à chaque principal d'utilisateur, et n'est connue que par l'utilisateur du principal et le centre de distribution de clés (KDC). Pour les principaux d'utilisateur, la clé est basée sur le mot de passe de l'utilisateur. Pour les serveurs et les services, la clé est appelée clé de service. Cette clé joue le même rôle que la clé privée, mais est employée par les serveurs et les services. Le troisième type de clé est la clé de session. Il s'agit d'une clé générée par le service d'authentification ou le service d'octroi de tickets. Une clé de session est générée pour assurer des transactions sécuritaires entre un client et un service.

Un ticket est un paquet d'informations permettant de transmettre l'identité d'un utilisateur à un serveur ou service de manière sécuritaire. Un ticket n'est valable que pour un seul client et un service particulier sur un serveur particulier. Il contient le nom du principal du service, le nom du principal de l'utilisateur, l'adresse IP de l'hôte de l'utilisateur, un horodateur et une valeur définissant la durée de vie du ticket. Un ticket est créé avec une clé de session aléatoire pour son utilisation par le client et le service. Une fois un ticket créé, il peut être réutilisé jusqu'à son expiration.

Un justificatif d'identité est un paquet d'informations incluant un ticket et une clé de session correspondante. Les justificatifs d'identité sont souvent chiffrés au moyen d'une clé privée ou d'une clé de service, selon ce qui déchiffrera le justificatif d'identité.

Un authentificateur est un autre type d'informations. Lorsque utilisé avec un ticket, un authentificateur peut servir à authentifier un principal d'utilisateur. Un authentificateur inclut le nom du principal de l'utilisateur, l'adresse IP de l'hôte de l'utilisateur et un horodateur. Contrairement à un ticket, un authentificateur ne peut servir qu'une seule fois, généralement lors d'une demande d'accès à un service. Un authentificateur est chiffré au moyen de la clé de session pour ce client et ce serveur.

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.

Comment fonctionne le système d'authentification

Les applications vous permettent de vous connecter à un système distant si vous détenez un ticket prouvant votre identité et une clé de session correspondante. La clé de session contient des informations propres à l'utilisateur et au service auquel il accède. Un ticket et une clé de session sont créés par le KDC pour tous les utilisateurs lors de leur première connexion. Le ticket et la clé de session associée forment un justificatif d'identité. Si de multiples services de réseau sont employés, un utilisateur peut obtenir plusieurs justificatifs d'identité. L'utilisateur doit détenir un justificatif d'identité pour chaque service exécuté sur un serveur particulier. Par exemple, l'accès au service ftp sur un serveur nommé boston exige un justificatif d'identité, et l'accès au service ftp sur un autre serveur exige son propre justificatif d'identité.

Le processus de création et de stockage des justificatifs d'identité est transparent. Les justificatifs d'identité sont créés par le KDC qui les envoie au demandeur. Lorsqu'un justificatif d'identité est reçu, il est stocké dans un cache de justificatifs d'identité.

Accès à un service avec SEAM

Pour qu'un utilisateur puisse accéder à un service particulier sur un serveur donné, il doit obtenir deux choses. Premièrement, il doit obtenir un justificatif d'identité pour le service d'octroi de tickets (également appelé TGT). Une fois que le service d'octroi de tickets a déchiffré ce justificatif d'identité, le service crée un deuxième justificatif d'identité pour le serveur auquel l'utilisateur souhaite accéder. Ce deuxième justificatif d'identité peut alors être employé pour demander d'accéder au service sur le serveur. Une fois que le serveur a déchiffré avec succès le deuxième justificatif d'identité, l'utilisateur est autorisé à accéder au service. Ce processus est décrit plus en détail ci-dessous.

Obtention d'un justificatif d'identité pour le service d'octroi de tickets

1. Pour démarrer le processus d'authentification, le client envoie une requête au serveur d'authentification pour un principal d'utilisateur particulier. Cette requête n'est pas chiffrée. Comme aucune donnée sécurisée n'est incluse dans la requête, il n'est pas nécessaire de recourir au chiffrement.

2. Lorsque la requête est reçue par le service d'authentification, le nom du principal de l'utilisateur est consulté dans la base de données KDC. Si un principal correspondant existe, le service d'authentification obtient la clé privée pour ce principal. Le service d'authentification génère alors une clé de session à utiliser par le client et le service d'octroi de tickets (appelons-la clé de session 1) et un ticket pour le service d'octroi de tickets (ticket 1). Ce ticket est également appelé ticket d'octroi de tickets (TGT). La clé de session et le ticket sont chiffrés au moyen de la clé privée de l'utilisateur, puis les informations sont renvoyées au client.

3. Le client utilise ces informations pour déchiffrer la clé de session 1 et le ticket 1, en employant la clé privée pour le principal d'utilisateur. Comme la clé privée ne doit être connue que par l'utilisateur et la base de données KDC, les informations contenues dans le paquet devraient être sécuritaires. Le client enregistre les informations dans le cache des justificatifs d'identité.

Normalement, l'utilisateur est alors invité à taper son mot de passe. Si le mot de passe entré est identique à celui utilisé pour créer la clé privée enregistrée dans la base de données KDC, le client peut déchiffrer les informations envoyées par le service d'authentification. Le client possède maintenant un justificatif d'identité à utiliser avec le service d'octroi de tickets. Le client est alors prêt à demander un justificatif d'identité pour un serveur.

Figure 7-2 Obtention d'un justificatif d'identité pour le service d'octroi de tickets

Obtention d'un justificatif d'identité pour un serveur

1. Pour demander d'accéder à un serveur particulier, un client doit d'abord obtenir un justificatif d'identité pour ce serveur auprès du service d'authentification (voir "Obtention d'un justificatif d'identité pour le service d'octroi de tickets"). Le client envoie ensuite une requête au service d'octroi de tickets, qui inclut le nom du principal du service, le ticket 1 et un authentificateur chiffré avec la clé de session 1. Le ticket 1 a été initialement chiffré par le service d'authentification au moyen de la clé de service du service d'octroi de tickets.

2. Étant donné que la clé de service du service d'octroi de tickets est connue par le service d'octroi de tickets, le ticket 1 peut être déchiffré. Les informations incluses dans le ticket 1 incluent la clé de session 1. Le service d'octroi de tickets peut donc déchiffrer l'authentificateur. À ce moment, le principal d'utilisateur est authentifié avec le service d'octroi de tickets.

3. Une fois l'authentification réussie, le service d'octroi de tickets génère une clé de session pour le principal d'utilisateur et le serveur (clé de session 2), et un ticket pour le serveur (ticket 2). La clé de session 2 et le ticket 2 sont ensuite chiffrés au moyen de la clé de session 1. Comme la clé de session 1 n'est connue que par le client et le service d'octroi de tickets, ces renseignements sont sécurisés et peuvent être définis sur le réseau en toute sécurité.

4. Lorsque le client reçoit ce paquet d'informations, il les déchiffre au moyen de la clé de session 1, stockée dans le cache des justificatifs d'identité. Le client a obtenu un justificatif d'identité à employer avec le serveur. Maintenant, le client est prêt à demander l'accès à un service particulier sur ce serveur.

Figure 7-3 Obtention d'un justificatif d'identité pour un serveur

Obtention de l'accès à un service particulier

1. Pour demander l'accès à un service particulier, le client doit d'abord obtenir un justificatif d'identité pour le service d'octroi de tickets auprès du serveur d'authentification, et un justificatif d'identité de serveur auprès du service d'octroi de tickets (voir "Obtention d'un justificatif d'identité pour le service d'octroi de tickets" et "Obtention d'un justificatif d'identité pour un serveur"). Le client peut envoyer une requête au serveur, incluant le ticket 2 et un autre authentificateur. L'authentificateur est chiffré au moyen de la clé de session 2.

2. Le ticket 2 a été chiffré par le service d'octroi de tickets au moyen de la clé de service appropriée. Vu que la clé de service est connue par le principal du service, le service peut déchiffrer le ticket 2 et obtenir la clé de session 2. La clé de session 2 peut ensuite être utilisée pour déchiffrer l'authentificateur. Si l'authentificateur est déchiffré avec succès, le client est autorisé à accéder au service.

Figure 7-4 Obtention de l'accès à un service particulier

Utilisation de la table gsscred

La table gsscred est utilisée par un serveur NFS lorsqu'il tente d'identifier un utilisateur SEAM. Les services NFS utilisent des ID UNIX pour identifier les utilisateurs ; ces ID ne font cependant pas partie du principal ou du justificatif d'identité de l'utilisateur. La table gsscred mappe les UID UNIX (provenant du fichier des mots de passe) aux noms de principal. La table doit être créée et gérée une fois que la base de données KDC est remplie.

Lorsqu'une requête de client est reçue, les services NFS tentent de mapper le nom du principal à un ID UNIX. Si le mappage échoue, la table gsscred est consultée. Avec le mécanisme kerberos_v5, un principal root/nom_de_l'hôte est automatiquement mappé à l'UID 0, et la table gsscred n'est pas consultée. Cela signifie qu'il est impossible d'effectuer des remappages spéciaux de root au moyen de la table gsscred.

Mécanisme à sélectionner pour la table gsscred

Le choix du mécanisme convenant à la table gsscred dépend de plusieurs facteurs.

• Souhaitez-vous réduire le temps de consultation ?

• Voulez-vous augmenter la sécurité de l'accès aux données ?

• Devez-vous créer le fichier rapidement ?

Voici une liste de tous les mécanismes dorsaux pouvant être sélectionnés, ainsi qu'une description de leurs avantages.

files

La table gsscred est enregistrée dans un système de fichiers. Un système de fichiers locaux non partagé offre le mécanisme dorsal le plus sécuritaire, car aucune transmission n'est effectuée sur le réseau après la création de la table. Cette version du fichier se construit le plus rapidement.

xfn_files

La table gsscred est enregistrée dans le système de fichiers /var/fn. Ce système de fichiers peut être partagé ou non. Tous les fichiers xfn sont longs à construire.

xfn_nis

La table gsscred est enregistrée dans l'espace de noms NIS. Les consultations dans ce système de fichiers ne sont pas sécurisées. Tous les fichiers xfn sont longs à construire.

xfn_nisplus

La table gsscred est enregistrée dans l'espace de noms NIS+. Les consultations dans ce système de fichiers ne sont pas sécurisées. Tous les fichiers xfn sont longs à construire.

xfn

La table gsscred est enregistrée dans le système par défaut pour xfn. Tous les fichiers xfn sont longs à construire.

Pour le mécanisme dorsal files, la consultation initiale peut être longue. Pour les autres mécanismes, la consultation initiale peut être plus rapide avec un service de nom. Pour tous les autres mécanismes, une fois les données mises en cache, le temps d'extraction devrait être à peu près semblable.