Fonctionnement du service Kerberos

Vous trouverez ci-dessous une présentation de l'authentification Kerberos. Pour une description plus détaillée, reportez-vous à la section Fonctionnement du système d'authentification Kerberos.

Du point de vue de l'utilisateur, le service Kerberos est pratiquement invisible une fois la session Kerberos démarrée. Les commandes telles que rsh ou ftp fonctionnent de la même manière. L'initialisation d'une session Kerberos n'implique souvent rien de plus que la connexion et l'indication du mot de passe Kerberos.

Le système Kerberos est basé sur le concept de ticket. Un ticket est un ensemble d'informations électroniques qui identifient un utilisateur ou un service tel que le service NFS. Tout comme votre permis de conduire vous identifie et indique les privilèges de conduite dont vous disposez, un ticket vous identifie ainsi que vos privilèges d'accès au réseau. Lorsque vous effectuez une transaction basée sur Kerberos (par exemple, si vous vous connectez à distance à une autre machine), vous envoyez de façon transparente une demande de ticket à un KDC (Key Distribution Center, centre de distribution des clés). Le KDC accède à une base de données pour authentifier votre identité et renvoie un ticket qui vous autorise à accéder à l'autre machine. "De façon transparente" signifie que vous n'avez pas à demander explicitement un ticket. La demande s'effectue dans le cadre de la commande rlogin. Puisque seul un client authentifié peut obtenir un ticket d'un service particulier, un autre client ne peut pas utiliser rlogin sous une fausse identité.

Certains attributs sont associés aux tickets. Par exemple, un ticket peut être transmissible, ce qui signifie qu'il peut être utilisé sur un autre ordinateur sans nouveau processus d'authentification. Un ticket peut également être postdaté, ce qui signifie qu'il n'est pas valide avant une heure spécifiée. Les utilisations des tickets, par exemple, pour spécifier quels utilisateurs sont autorisés à obtenir quels types de ticket, sont définies par des stratégies. Les stratégies sont déterminées lors de l'installation ou de l'administration de Kerberos.

Les sections suivantes expliquent davantage les processus d'authentification Kerberos.

Authentification initiale : le TGT

L'authentification Kerberos comprend deux phases : une authentification initiale qui autorise toutes les authentifications, puis les authentifications suivantes.

La figure ci-dessous illustre la manière dont l'authentification initiale a lieu.

Figure 21-1 Authentification Kerberos initiale pour une session

1. Un client (un utilisateur, ou un service comme NFS) commence une session Kerberos en demandant un TGT (ticket d'octroi de tickets) dans le KDC (centre de distribution de clés). Cette demande est souvent effectuée automatiquement à la connexion.

   Un TGT est nécessaire pour obtenir d'autres tickets pour des services spécifiques. Considérez le TGT comme étant semblable à un passeport. Comme un passeport, le TGT vous identifie et vous permet d'obtenir de nombreux "visas", où les "visas" (tickets) ne sont pas des pays étrangers mais des machines distantes ou des services réseau. Comme les passeports et les visas, le TGT et les autres différents tickets ont une durée de vie limitée. La seule différence réside dans le fait que les commandes Kerberos voient que vous avez un passeport et qu'elles obtiennent les visas pour vous. Vous n'avez pas à effectuer les transactions vous-même.

   Une autre analogie pour le TGT est celle du passe de ski de trois jours valable dans quatre différentes stations. Vous pouvez montrer le passe dans la station de votre choix et vous recevez un ticket pour les pistes correspondantes, tant que le passe n'a pas expiré. Une fois que vous avez accès aux pistes, vous pouvez skier autant que vous le voulez dans cette station. Si vous passez à une autre station le jour suivant, vous devez montrer votre passe à nouveau, et vous obtenez l'accès aux pistes de la nouvelle station. La différence réside dans le fait que les commandes Kerberos voient que vous avez un passe de ski de trois jours, et qu'elles obtiennent l'accès aux pistes pour vous. Ainsi, vous n'avez pas à effectuer les opérations vous-même.

2. Le KDC crée un TGT qu'il renvoie, sous forme chiffrée, au client. Le client déchiffre le TGT en utilisant le mot de passe du client.

3. Maintenant en possession d'un TGT en cours de validité, le client peut demander des tickets pour toutes sortes d'opérations réseau, telles que rlogin ou telnet, aussi longtemps que le TGT est valide. Ce ticket dure généralement quelques heures. À chaque fois que le client effectue une opération réseau unique, il demande un ticket pour cette opération au KDC.

Authentifications Kerberos suivantes

Une fois que le client a reçu l'authentification initiale, chaque nouvelle authentification suit le modèle indiqué dans la figure ci-dessous.

Figure 21-2 Obtention de l'accès à un service à l'aide de l'authentification Kerberos

1. Le client demande un ticket au KDC pour un service particulier, par exemple, pour se connecter à distance à une autre machine, en envoyant au KDC son TGT comme preuve d'identité.

2. Le KDC envoie le ticket pour le service spécifique au client.

   Par exemple, si l'utilisateur joe demande l'accès à un système de fichiers NFS qui a été partagé avec krb5, l'authentification est nécessaire. Puisqu'il est déjà authentifié (c'est-à-dire, qu'il possède déjà un TGT), lorsqu'il tente d'accéder aux fichiers, le système client NFS obtient automatiquement et de façon transparente un ticket du KDC pour le service NFS.

   Par exemple, supposons que l'utilisateur joe utilise rlogin sur le serveur boston. Comme il est déjà authentifié, c'est-à-dire qu'il a déjà un TGT, il obtient automatiquement et de façon transparente un ticket en tant que partie de la commande rlogin. Ce ticket lui permet de se connecter à distance à boston aussi souvent qu'il le souhaite jusqu'à expiration du ticket. Si joe veut se connecter à distance à la machine denver, il obtient un autre ticket, comme à l'étape 1.

3. Le client envoie le ticket au serveur.

   Lors de l'utilisation du service NFS, le client NFS envoie le ticket automatiquement et de manière transparente au service NFS pour le serveur NFS.

4. Le serveur autorise l'accès au client.

Ces étapes montrent que le serveur ne communique pas toujours avec le KDC. Cependant, le serveur s'enregistre auprès du KDC, tout comme le premier client. À des fins de simplification, cette partie a été omise.

Applications distantes Kerberos

Les commandes basées sur Kerberos disponibles pour un utilisateur comme joe sont les suivantes :

• ftp

• rcp

• rdist

• rlogin

• rsh

• ssh

• telnet

Ces applications sont les mêmes que les applications Solaris du même nom. Cependant, elles ont été étendues pour utiliser les principaux Kerberos pour authentifier les transactions, afin que vous disposiez d'une sécurité Kerberos. Pour plus d'informations sur les principaux, reportez-vous à la section Principaux Kerberos

Ces commandes sont traitées plus en détail à la section Commandes utilisateur Kerberos .

Principaux Kerberos

Un client dans le service Kerberos est identifié par son principal. Un principal est une identité unique à laquelle le KDC peut affecter les tickets. Un principal peut être un utilisateur, comme joe, ou un service, tel que nfs ou telnet.

Par convention, un nom de principal est divisé en trois composants : le primaire, l'instance et le domaine. Un principal Kerberos type peut être, par exemple, joe/admin@ENG.EXAMPLE.COM. Dans cet exemple :

• joe est le primaire. Le primaire peut être un nom d'utilisateur, comme ici, ou un service, comme nfs. Le primaire peut également être l'hôte, ce qui signifie que ce principal est un principal de service qui est configuré afin de fournir divers services réseau, ftp, rcp, rlogin etc.

• admin est l'instance. Une instance est facultative dans le cas de principaux d' utilisateur, mais elle est nécessaire pour les principaux de service. Par exemple, si l'utilisateur joe agit parfois en tant qu'administrateur système, il peut utiliser joe/admin pour se distinguer dans son identité d'utilisateur habituelle. De même, si joe a des comptes sur deux hôtes différents, il peut utiliser deux noms de principal avec différentes instances, par exemple, joe/denver.example.com et joe/boston.example.com. Notez que le service Kerberos traite joe et joe/admin comme deux identités totalement différentes.

  Dans le cas d'un principal de service, l'instance est le nom d'hôte complet. bigmachine.eng.example.com est un exemple d'une telle instance. Le principal ou l'instance pour cet exemple pourrait être ftp/bigmachine.eng.example.com ou host/bigmachine.eng.example.com.

• ENG.EXAMPLE.COM est le domaine Kerberos. Les domaines sont abordés dans Domaines Kerberos.

Les éléments suivants sont tous les noms de principaux valides :

• joe

• joe/admin

• joe/admin@ENG.EXAMPLE.COM

• nfs/host.eng.example.com@ENG.EXAMPLE.COM

• host/eng.example.com@ENG.EXAMPLE.COM

Domaines Kerberos

Un domaine est un réseau logique qui définit un groupe de systèmes sous le même KDC maître. La Figure 21-3 montre comment les domaines peuvent se rapporter les uns aux autres. Certains domaines sont hiérarchiques, où un domaine est un surensemble de l'autre domaine. Dans le cas contraire, les domaines sont non hiérarchiques (ou "directs") et le mappage entre les deux domaines doit être défini. Une fonction du service Kerberos est d'autoriser l'authentification au sein des domaines. Chaque domaine a seulement besoin de disposer d'une entrée de principal pour l'autre domaine dans son KDC. Cette fonction Kerberos est appelée authentification inter-domaine.

Figure 21-3 Domaines Kerberos

Serveurs Kerberos

Chaque domaine doit inclure un serveur qui gère la copie principale de la base de données du principal. Ce serveur est appelé le serveur KDC maître. En outre, chaque domaine doit contenir au moins un serveur KDC esclave, qui contient des copies de la base de données du principal. Le serveur KDC maître et le serveur KDC esclave créent tous deux des tickets utilisés pour établir l'authentification.

Le domaine peut également inclure un serveur d'application Kerberos. Ce serveur permet d'accéder aux services utilisant Kerberos (tels que ftp, telnet, rsh et NFS). Si vous avez installé SEAM 1.0 ou 1.0.1, le domaine peut inclure un serveur d'application de réseau Kerberos, mais ce logiciel n'a pas été inclus avec ces versions.

La figure suivante illustre le contenu possible d'un domaine.

Figure 21-4 Domaine Kerberos typique