wiki:InsiaAdminSysKerberos

Sommaire

Administration système - Kerberos

1. Présentation

Kerberos est issu du projet Athena développé notamment au MIT, dont le but consistait à fournir l'infrastructure technologique pour créer un parc de postes de travail interchangeables où le réseau assurait la mobilité des personnes. Le système X Windows est également issu de ce projet.

L'implémentation actuelle de Kerberos est la version 5 (RFC 1510 et [RFC 4120), et représente la partie authentification et autorisation distribuée de cette généralisation du réseau au service de l'usager.

Kerberos ne désigne qu'un protocole, donc les parties (des machines principalement) et les discussions qu'il peut y avoir lieu entre elles. Il existe de nombreuses implémentation de ce protocole, plus ou moins interopérables. Il est notoirement connu que le système d'autorisation de Microsoft (ADS) est basé sur Kerberos, par exemple.

Le protocole utilise naturellement de nombreuses technologies de cryptographie (symétrique et assymétrique) pour parvenir à ses fins (créer de la confiance dans un réseau auquel on ne peut pas faire confiance). Ceci a posé des problèmes pour l'implémentation américaine du MIT, les autorités ayant longtemps bloqué l'export de ces technologies, ceci rendant la diffusion du logiciel sur Internet difficilement possible. On a ainsi vu apparaître des alternatives.

Implémentations

Implémentation Nom Licence
MIT Kerberos (implémentation de référence) krb5 MIT/X
Projet suédois/Européen (pas de restriction sur la crypto) Heimdal BSD
Implémentation du projet GNU Shishi GPL
Implémentation "maison" pour intérop. avec ADC Samba 3 GPL
Microsoft + Crypto spécifique Active Directory (Service) Propriétaire

Utilisateurs

  • PHP, administration: php-kadm5 (MIT)
  • Apache, authn+autz: libapache2-mod-auth-kerb (MIT)
  • FreeRadius?: radiusd-freeradius-krb5 (MIT)
  • Perl: libauthen-kerb5-perl (MIT)
  • PAM: pam-heimdal, pam-krb5
  • SASL: Heimdal, MIT (via GSSAPI)
  • NFSv4
  • Samba 4

2. Description

Architecture

Dans le mécanisme d'authentification et d'autorisation de Kerberos, 4 éléments sont impliqués, dont 2 font partie des services Kerberos au sens strict:

  1. Le client (utilisateur du service)
  2. Le serveur (un service précis, exemple: un serveur HTTP)
  3. Le serveur d'authentification (AS en anglais)
  4. Le distributeur de ticket d'accès (TGS en anglais)

En général les deux services Kerberos sont hébergées au sein d'un même démon (le KDC, voir plus bas). L'administration de la base Kerberos (identités et autorisations) se fait également en général à travers un service dédié (kadmind).

Jargon

Ticket prouve l'identité d'une personne, obtenue auprès d'un AS
Ticket session key valide un ticket pendant une période donnée, obtenue auprès d'un AS
Credential un ticket valide (donc ticket + ticket session key)
Client-to-server ticket ticket d'autorisation d'accès à un service, obtenu auprès d'un TGS
Primary login pour un client, nom du service pour un serveur
Instance nom du serveur (FQDN en général)
Realm domaine pour ranger/cloisonner les utilisateurs, il faut un serveur Kerberos par domaine
Principal Identifiant complet sous la forme Primary/Instance?@Realm

Mécanismes

Un unique service, le KDC (Key Distribution Center) intègre en général les fonctions de l'AS et du TGS.

  1. Le client demande un ticket initial auprès de l'AS, ou utilise celui qu'il a déjà demandé s'il est dans son cache local
  2. Si une demande a eu lieu en 1, le AS répond par un ticket granting ticket et une clé de session valide pendant un certain temps. Le client en général va donc garder ces deux informations pour ne pas les redemander systématiquement.
  3. Le client, muni de son ticket granting ticket (prouvant qui il est) demande l'autorisation d'accès à un service précis auprès du TGS
  4. Si le TGS autorise la personne identifiée, il renvoie un client-to-server ticket
  5. Muni du client-to-server ticket, le client peut alors obtenir l'accès au service souhaité

Ceci implique bien entendu qu'il existe une relation de confiance entre le KDC (serveur Kerberos) et le service qui doit véfifier la validité du client-to-server ticket. Il existe donc en pratique un compte par utilisateur et un compte par service dans la base Kerberos.

La notion de temps est très importante avec Kerberos, tous les tickets en particulier sont marqués (timestamp) ont une durée de validitée limitée (compromis utilisabilité/sécurité). Il faut donc un ensemble de clients, serveurs et services suffisament synchronisés (on pense à NTP !). En théorie, les écarts de plus de 10 minutes entre deux machines ne sont pas tolérés.

3. Notes

Mots de passe

Le mécanisme du ticket initial (ticket granting ticket) sert à minimiser les vérifications et manipulations d'information impliquant les mots de passe. De fait, Kerberos fonctionnant par distribution de tickets, il est le mécanisme le plus adapté pour implémenter une solution de SSO (Single Sign On).

Cependant les utilisateurs veulent pouvoir changer leur mot de passe sans passer par un administrateur: ceci n'est pas prévu par le protocole Kerberos. Mais il existe un service standard, qui peut bien sûr être protégé par Kerberos, permettant cette opération à distance.

Microsoft est connu pour avoir notamment dérivé du standard Kerberos sur ce point et possède un mécanisme particulier.

Autorisations

Kerberos est un protocole d'authentification et ne prévoit pas de mécanisme particulier pour gérer les autorisations d'accès entre les utilisateurs et les services (ACLs, etc). Même si le protocole permet d'authentifier (obtention du ticket granting ticket) puis éventuellement d'autoriser (client-to-server ticket), en pratique les implémentations ne fournissent pas de moyen de contrôle (elles vérifient juste la validité du service).

C'est donc le rôle des applications d'apporter leur propre gestion d'autorisation. Microsoft a ajouté une gestion d'autorisation centralisée en étendant le protocole et en permettant de transporter dans les tickets client-to-server des attributs supplémentaires (propriétaires).

GSSAPI

Le magnifique acronyme Generic Security Services Application Program Interface représente une API standard pour décrire les opérations permettant de manipuler un système d'authentification et d'autorisation (à l'instar de PAM par exemple), et est très souvent utilisée comme le front end standard pour accéder aux services de Kerberos. Cette API décrit aussi bien les prototypes de fonctions de la bibliothèque de programmation que les formats exacts des données transitant sur le réseau (wire-leve).

Ce mécanisme est similaire à SASL, une API générique décrivant à peu près les mêmes services. Il existe parfois des "plugins passerelle", permettant d'utiliser SASL en frontend pour GSSAPI ou l'inverse. La polyvalence de ces APIs reste vraie en pratique.

Note: Microsoft utilise également une API dérivée de GSSAPI qu'ils dénomment SSPI (Security Service Provider Interface).

Last modified 13 years ago Last modified on May 7, 2007, 12:49:07 PM