Ce chapitre n’est pas une description complète du protocole Kerberos.

Ce chapitre est plutôt une initiation à certains concepts Kerberos, souvent mal compris et qui vous seront utiles pour vous aider à gérer correctement votre réseau Active Directory.

A propos de Kerberos

Dans la mythologie grecque, le cerbère est un chien à trois têtes qui contrôle la porte d’entrée de l’Enfer. En gros il est le maître des clefs. Quoi de plus naturel alors que de donner ce nom (kerberos veut dire cerbère en grec ancien) à un service d’authentification dont le rôle est de donner des clefs aux utilisateurs d’un réseau informatique.

Comme ça avait été mentionné dans la présentation historique de l’AD, Kerberos a été créé au sein du MIT dans le cadre d’un projet financé par la DARPA américaine. L’objectif était donc de promouvoir la sécurité et non la facilité d’usage.

Kerberos peut sembler compliqué au premier abord, mais c’est en fait beaucoup plus simple que ça en a l’air.

Microsoft a fait un très bon travail d’intégration dans l’Active Directory pour permettre à tout un chacun de bénéficier de cette technologie sans avoir à se pencher sur sa complexité.

Note

Kerberos v4, kerberos v5. Les premières versions de Kerberos vraiment déployées à grande échelle sont la version 4 au début des années 90. Dans les années 90, la version Kerberos 5 est sortie, et c’est sur cette version que se base Active Directory, sans rétrocompatibilité avec la version 4. En gros, il n’y a que du kerberos v5 en production aujourd’hui. Si vous tombez sur une documentation parlant de Kerberos v4, c’est qu’elle est obsolète.

Kerberos est un système d’authentification entre deux systèmes basé sur un tiers de confiance :

  • Le tiers de confiance est le serveur Kerberos.

  • Le poste client fait confiance au serveur Kerberos.

  • Le serveur de fichiers fait confiance au serveur Kerberos.

Donc le serveur de fichiers fera confiance au poste client quand le poste client se connectera en lui ayant présenté un ticket obtenu auprès du serveur Kerberos (on parle de la notion de ticket juste après). On a donc ici un système d’authentification mutuelle basé sur un tiers de confiance.

Note

Un serveur Active Directory intègre un serveur Kerberos qu’on appelle aussi KDC.

Donc on pourra utiliser indifféremment les noms AD, DC, contrôleur de domaine, KDC ou serveur Kerberos pour désigner le fournisseur du service Kerberos.

En schématisant un peu, on peut résumer le fonctionnement du serveur Kerberos avec le schéma ci-après. C’est un résumé qui oublie volontairement certains détails pour en faciliter la compréhension, mais qui contient à peu près tous les détails nécessaires pour débugger les problèmes Kerberos que vous pourrez rencontrer dans votre environnement AD.

A gauche nous avons un client Windows :

  1. A l’ouverture de session, l’utilisateur s’authentifie sur le serveur Kerberos de l’AD grâce à son mot de passe. C’est une authentification basée sur un challenge (le serveur demande au poste de chiffrer un message contenant certaines informations, notamment l’heure) en cryptographie symétrique ;

  2. Une fois que le serveur Kerberos a authentifié l’utilisateur, il donne à l’utilisateur un TGT. On peut voir le TGT comme un mot de passe temporaire qui est utilisé par le poste client pour demander d’autres tickets. Cela évitera d’avoir à ré-utiliser son de passe par la suite en s’authentifiant de manière transparente auprès d’autres services intégrés dans le domaine. Dans le principe, on échange un mot de passe de longue durée (votre mot de passe qui est changé tous les 3 mois par exemple), par un mot de passe à durée courte (le TGT sera renouvelé au maximum tous les jours pendant au maximum une semaine). En pratique le TGT est renouvelé tous les jours au moment de l’ouverture de session par l’utilisateur.

  3. L’utilisateur veut se connecter au serveur de fichiers srvfiles.mydomain.lan. Dans l’explorateur de fichier, l’utilisateur tape \srvfiles.mydomain.lan. Le client Windows va demander au serveur Kerberos un ST pour le SPN correspondant à la chaîne de caractères HOST/srvfiles.mydomain.lan.

  4. Le serveur Kerberos cherche dans sa base LDAP une entrée qui a un attribut servicePrincipalName avec la valeur demandée. S’il trouve une entrée correspondante, il prépare un ST correspondant au compte Kerberos en question et le renvoie à l’utilisateur.

  5. Le poste client se connecte au serveur de fichiers avec le ST qu’il vient d’obtenir. Le serveur de fichiers valide que le ticket a bien été généré par le serveur Kerberos, et donc le serveur de fichiers authentifie l’utilisateur.

  6. Le serveur de fichiers valide enfin que l’utilisateur a bien les droits d’accès à la ressource à laquelle il cherche à se connecter, et lui autorise ou refuse l’accès à la ressource.

Note

Authentification vs autorisations

Le rôle du serveur Kerberos est d’authentifier un utilisateur sur le réseau, pas de valider si un utilisateur est sensé avoir accès à une ressource donnée.

En gros, vous pouvez demander un ticket pour le serveur de comptabilité auquel vous n’auriez pas le droit, le serveur Kerberos vous le donnera.

Quand vous présenterez le ticket au serveur de comptabilité, il validera que le ticket est bon et que vous êtes bien la personne que vous prétendez être, mais après le serveur de comptabilité va vérifier si vous êtes bien dans un groupe autorisé à vous connecter, il verra que vous faites partie d’aucun groupe autorisé et il vous refusera l’accès.

Nous répétons donc : le rôle du serveur Kerberos est d’authentifier un utilisateur, c’est à dire qu’il s’assure que l’utilisateur qui demande à se connecter à un service membre du domaine Kerberos est bien celui qu’il prétend être ; le service Kerberos ne gère absolument pas les droits et restrictions d’accès des utilisateurs.

Dans ce schéma de fonctionnement, il est important de s’apercevoir que le serveur de fichiers n’a pas eu à se connecter au serveur Kerberos pour authentifier l’utilisateur (contrairement à ce qui se serait passé si nous avions fait une authentification NTLM).

Comme il est mentionné dans la note ci-dessus, le serveur kerbérisé peut avoir à valider les droits d’accès de l’utilisateur à travers une requête LDAP sur le serveur AD. En pratique, le Service Ticket contient une extension PAC dans laquelle le serveur Kerberos aura rajouté une liste signée des groupes dont fait partie l’utilisateur. Le serveur de fichiers utilisera cette liste pour valider les droits d’accès de l’utilisateur, évitant ainsi une requête LDAP sur le serveur AD.

Note

Les attributs servicePrincipalName dans l’AD sont des champs texte « libres ». On peut avoir autant de SPN que l’on veut. Quand un client kerbérisé veut se connecter à un service donné, il doit pouvoir trouver par lui même le bon SPN correspondant. Si le client n’est pas capable de trouver le bon SPN, il ne pourra pas demander de Service Ticket. Le format des SPN a donc été globalement normalisé :

Pour un serveur de fichiers, on pourra avoir les SPN suivants et on peut en rajouter autant qu’on veut :

Pour un serveur LDAP ou le service GC (cf. chapitre sur le LDAP) :

  • LDAP/srvads.mydomain.lan ;

  • GC/srvads.mydomain.lan ;

Pour un serveur proxy :

  • HTTP/srvproxy.mydomain.lan ;

Pour un serveur web :

  • HTTP/srvintranet.mydomain.lan ;

en pratique on peut faire un SPN sur une adresse IP, même si ce n’est vraiment pas conseillé :

Comme on le voit dans la liste ci-dessus, l’objectif est de pouvoir trouver le bon compte kerberos pour lequel on doit recevoir un Service Ticket.

Note

Le protocole Kerberos peut être utilisé en TCP ou en UDP. En pratique, les clients Windows n’utilisent plus que du TCP. Les clients Windows XP utilisaient du UDP par défaut, ce qui peut poser des problèmes sur des réseaux VPN avec des MTU plus bas.

Un paquet Kerberos a une taille maximale par défaut MaxTokenSize qui est configurée sur les clients et les serveurs Kerberos à 12000 octets. Si un utilisateur fait partie de plus de 120 groupes, des problèmes d’autorisation peuvent apparaître, car la liste des groupes sera tronquée.

On peut aussi noter que la relation de confiance entre le serveur de fichiers et le serveur Kerberos a été faite lorsque le serveur de fichiers a été joint au domaine.

Note

Kerberos et le temps

Les différents messages Kerberos (authentification initiale, authentification avec TGT, Service Ticket, etc.) sont horodatés pour éviter des attaques par rejeu.

Par défaut le protocole Kerberos autorise au maximum un écart de 5 minutes entre le client et le serveur. Il est donc primordial que tous les systèmes d’un réseau soient correctement configurés pour rester à l’heure vis à vis d’un serveur NTP.

Selon la configuration de votre réseau Windows, il est possible que la connexion passe aussi même si l’horloge n’est pas à l’heure. En effet et dans ce cas, le client Windows va downgrader son authentification et faire du NTLM, qui lui n’est pas soumis à cette rigueur temporelle.

Par rapport au schéma de fonctionnement décrit plus haut, on peut en déduire plusieurs choses :

  • Si on utilise une adresse IP plutôt qu’un nom DNS, le serveur ira chercher un attribut servicePrincipalName correspondant à une IP.

    Ce mode n’est pas configuré par défaut, et il n’est pas recommandé de le mettre en place. Le client Windows fera par défaut un downgrade sur une authentification NTLM, et on aura l’impression que tout fonctionne normalement, alors que l’on sera en train d’utiliser un protocole moins sécurisé.

  • Si on utilise un nom de machine, il faut que cette machine soit référencée dans les DNS.

    Si la machine n’est pas référencée dans le DNS, la machine Windows essaiera de faire une requête NetBIOS si NetBIOS n’est pas désactivé. NetBIOS est une faille de sécurité, il doit être supprimé, donc comme corollaire, vous avez besoin d’un DNS bien configuré !

  • Si on utilise un alias de nom de machine, l’explorateur Windows va faire une première requête de Service Ticket en utilisant ce nom, et si ça loupe, il va faire une requête DNS pour obtenir le vrai nom de machine derrière le CNAME, puis faire une requête de Service Ticket en utilisant le vrai nom de machine pour le SPN et non le nom CNAME. Toutefois, le fait de suivre les CNAME ne fait pas partie des spécifications Kerberos, c’est un choix d’implémentation de l’explorateur Windows. Voir ci après sur comment faire des bons alias.

  • Si les postes ne sont pas à l’heure, l’authentification Kerberos ne fonctionnera pas. Le poste client fera éventuellement un downgrade d’authentification en NTLM.

Il y a quelques livres sur Kerberos, mais ils sont souvent soit obsolètes soit trop universitaires, soit tout simplement indigestes.