I.1.        Kerberos

I.1.1.             Introduction

Kerberos est le protocole d’authentification réseau par défaut de Windows 2000, 2003 & 2008 qui, précisons le, n’a pas été développé par Microsoft. Il est en usage depuis plusieurs années déjà dans le monde Unix.

Microsoft a choisi de mettre en œuvre l’authentification réseau Kerberos pour renforcer la sécurité sous les systèmes Windows 2000. Serveurs et services réseaux ont en effet besoin de s’assurer de la légitimité des clients qui soumettent des requêtes d’accès.

Le système Kerberos repose sur l’usage de tickets, qui contiennent les informations d’identification des clients, celles-ci sont alors cryptées au moyen de clés partagées.

I.1.1.A)         L’authentification depuis Windows 2000

Windows 2000 prend en charge cinq méthodes d’authentification de l’identité des utilisateurs :

-  NTLM,

-  Kerberos v5,

-  DPA,

-  EAP,

-  Schannel.

Parmi ces cinq méthodes, seuls NTLM et Kerberos sont utilisés pour l’authentification réseau (les trois autres sont principalement employés pour l’authentification lors des connexions par Internet ou par lignes téléphoniques).

NTLM (Windows NT Lan Manager) est le protocole d’authentification réseau par défaut de NT 4, Windows 2000, 2003 & 2008 le prend encore en charge, afin de préserver la compatibilité.

Quand à Kerberos, il est tout simplement le protocole d’authentification réseau par défaut depuis Windows 2000. Il est d’un usage très répandu, notamment parce que son code est public.

I.1.2.             Avantages du système d’authentification Kerberos par rapport à NTLM

En matière d’authentification, Kerberos propose plus d’avantages que NTLM. Kerberos reposant sur des standards existants, Windows 2000 peut inter opérer sur d’autres réseaux utilisant Kerberos v5 comme système d’authentification, à la différence de NTLM qui demeure une norme propriétaire de Microsoft.

Pair ailleurs, l’authentification Kerberos permet des connexions plus rapides avec les serveurs d’application et de fichiers, en effet, un serveur Kerberos n’a besoin de vérifier qu’une seule fois les informations fournies pas le client pour assurer l’accès. Une fois l’accès autorisé, cette identité est utilisée durant tout le temps de connexion sur le réseau. Si le système Kerberos permet une authentification à la fois du client et du serveur, NTLM fournit uniquement une authentification du client (ce qui peut poser des problèmes, puisqu’il n’y a aucun moyen de vérifier que le serveur est bien fiable ou bien qu’il ne s’agisse pas d’un imposteur).

I.1.3.             Les modifications apportées par Microsoft sur Kerberos

Lors du choix d’utiliser Kerberos sous Windows 2000, Microsoft a apporté quelques modifications sur le protocole, afin que l’authentification initiale des utilisateurs puisse s’effectuer au moyen de certificats de clés publiques, au lieu des clés secrètes partagées, utilisées dans Kerberos v5.

I.1.4.             Le protocole Kerberos

I.1.4.A)         1.1. Les concepts de base du protocole

Le système d'authentification Kerberos est issu du projet Athena du MIT (Massachusetts Institue of Technology), lancé en mai 1983. La première utilisation du protocole remonte à septembre 1986. Le nom Kerberos tire son origine de la mythologie grecque, faisant référence à Cerbère, un chien monstrueux à trois têtes, qui gardait l'accès aux Enfers.

Le protocole Kerberos à la particularité de permettre une authentification mutuelle entre serveurs et clients, et de serveurs à serveurs, contrairement à d'autres protocoles existants (comme par exemple NTLM). Lors de la conception de Kerberos, l'hypothèse principale était que le réseau sur lequel est implanté le protocole est un réseau non sécurisé. Les réseaux non sécurisés peuvent facilement être infiltré par des tiers usurpant l'identité d'un client.

Kerberos repose sur un principe de « secrets partagés ». Cela signifie que ce « secret » ne doit concerner que les partenaires (personnes, ordinateurs) indispensables à l’accomplissement de la tâche nécessaire, et doit être mis en œuvre de telle sorte que chaque partenaire partageant le secret soit dans la mesure de vérifier l’identité des autres partenaires.

Ce procédé est possible par l’utilisation d’un cryptage symétrique par clé secrète, où une même clé est utilisée aussi bien pour le cryptage que pour le décryptage.

Un partenaire crypte l’information, et un autre la décrypte avec succès.

Ce succès est l’unique garantie que les deux partenaires connaissent le secret partagé.

I.1.4.B)        Les authentificateurs

L’authentificateur est une information (unique) cryptée dans le secret partagé. Sa validité est limitée à un seul usage, afin de réduire les risques d’usurpation de l’identité d’une personne par un tiers.

Kerberos v5 limite ainsi les attaques résultant de la réutilisation d’un authentificateur par un fraudeur.

Le tableau suivant décrit les divers champs qui composent un authentificateur Kerberos :

I.1.4.C)        Le centre de distribution des clés

Le protocole Kerberos possède trois parties (en référence à Cerbère qui possédait trois têtes), il fait en effet intervenir un client, un serveur et une autorité approuvée qui est considérée comme le KDC (Key Distribution Server), le centre de distributions des clés.

Le KDC gère une base de données qui centralise toutes les informations liées aux comptes pour les principaux du domaine Kerberos.

Un principal est une entité unique qui possède un nom unique et qui participe aux communications réseau.

Le système exécutant le service KDC (qui contient une BDD dans laquelle sont stockées des informations relatives à la sécurité des comptes) doit être sécurisé physiquement.

La clé secrète partagée entre un principal et le KDC constitue une partie de cette information de sécurité.

Chaque principal possède sa propre clé secrète, dont la durée de vie est assez longue (souvent qualifiée de clé à long terme).

Dans le cas de principaux associés à des êtres humains, la clé à long terme est attribuée à partir du mot de passe de l’utilisateur.

Il existe la clé de session, qui est émise par le KDC lorsqu’un principal désire communiquer avec un autre principal. Si un client veut communiquer avec un serveur, il envoie une demande au KDC qui lui fera parvenir sa clé de session.

Une clé de session se compose de deux parties, chacune de ces deux paties parties est cryptée dans la partie correspondante de la clé à long terme du client et du serveur.

Ainsi, la clé à long terme du client contient la copie de la partie client de la clé de session, et la clé à long terme du serveur comprend la copie de la partie serveur de la clé de session.

Cette clé n’est valable que pendant la durée de la session client pour laquelle elle a été transmise.

Pour terminer avec la présentation du KDC, précisons que celui-ci fournit essentiellement deux services (que nous développerons dans les chapitres suivants) le service d’Authentification ou AS (Authentication Service), et le service d’octroi de tickets ou TGS (Ticket-Granting Service).

I.1.4.D)        Tickets de session

Le client reçoit un message crypté du KDC, contenant à la fois les parties client et serveur de la clé de session. La partie serveur de la clé de session est comprise dans un ticket dit de session (qui contient également les informations relatives au client). Ce ticket est crypté au moyen du secret partagé entre le serveur et le KDC.

Le client, une fois qu’il a reçu la partie client de la clé de session et le ticket de session pour le serveur (autant dire la partie serveur de la clé de session), peut alors contacter le serveur.

Pour cela, il va envoyer un message au serveur, contenant le ticket de session, et un authentificateur crypté au moyen de la clé de session.

Le serveur décrypte alors le ticket de session, en utilisant la clé secrète partagée, et en extrait la clé de session provenant du KDC. Cette clé de session va lui permettre de décrypter l’authentification envoyée par le client.

A ce stade, une authentification mutuelle peut avoir lieu, à condition que le client en fasse la demande. Cette méthode d’authentification est une des propriétés propre à Kerberos, qui le différencie des autres protocoles actuels (habituellement, les autres systèmes ne valident que le client).

Les tickets de session ont une durée de vie limitée fixée par la stratégie adoptée dans le domaine (cette durée est inscrite dans le ticket par le KDC), ainsi, un principal n’a pas à entrer en contact avec le KDC chaque fois qu’il veut communiquer avec un autre principal.

I.1.4.E)         Les Tickets d’octroi de tickets

Outre les tickets de session que nous avons vu précédemment, le système Kerberos fait intervenir d’autres tickets.

Le TGT (ticket d’octroi de tickets) permet au KDC de vérifier l’identité de tel ou tel principal (afin de limiter les actes frauduleux).

Lorsqu’un utilisateur se connecte à un domaine Kerberos, il saisit un mot de passe, il en résulte alors une clé à long terme.

Cette clé est envoyée au KDC qui recherche alors une copie identique dans sa base de données. Lorsque le client envoie la clé à long terme au KDC, il sollicite également un ticket de session et une clé de session à utiliser pour communiquer avec le KDC pendant toute la durée de la session.

Le ticket renvoyé par le KDC est le TGT.

Une fois que le client a tout reçu, il utilise sa clé à long terme pour décrypter la clé de session, puis se débarrasse de la clé à long terme, dont il n’a plus besoin pour communiquer.

Le principal de type client sollicite un ticket de session auprès du KDC, afin de communiquer avec un serveur (par exemple). En utilisant la clé de session, le client génère un authentificateur qu’il envoie au KDC, accompagné du TGT et d’une requête de ticket de session pour le serveur auquel il va accéder.

A réception de ce message, le KDC décrypte le TGT à l’aide de sa clé à long terme pour en extraire la clé de session. Il se sert ensuite de cette clé pour vérifier la validité de l’authentification envoyée par le client.

I.1.5.             Les Sous protocoles

Un système Kerberos fait intervenir les trois sous protocoles suivants :

- AS (Authentication Service),

- TGS (Ticket-Granding Service),

- CS (Client/Server).

I.1.5.A)         Le service d’authentification AS

Le sous protocole AS est utilisé par le KDC (le centre de distributions des clés) pour fournir au client une clé de session et un ticket d’octroi de ticket (TGT).

A la connexion d’un utilisateur sur le réseau, un message KRB_AS_REQ (aussi appelé « requête de service d’authentification Kerberos ») est envoyé au service AS.

Voici le contenu de ce message :

Une fois qu’il a reçu le KRB_AS_REQ, le service AS du KDC vérifie le contenu de ce message.

Si la vérification échoue, le KDC va générer un message d’erreur, le KDC_ERROR qu’il renvoie alors au client.

Dans le cas contraire, si la vérification réussit, le KDC crée une clé de session et un TGT qu’il transmet au client par le biais du message KRB_AS_REP (voir tableau ci-dessous).

Le client décrypte ce message ainsi que le TGT qu’il a reçu grâce à sa clé à long terme.

I.1.5.B)        Le service TGS

TGS est utilisé par le KDC pour fournir une clé de session et un ticket de session au client (qu’il va utilisé pour le serveur).

Le client sollicite au KDC un ticket de session pour un serveur donné, en envoyant un message KRB_TGS_REQ.

La structure de ce message est identique à celle du KRB_AS_REQ que nous avons vu précédemment (mis à part que le KRB_TGS_REQ utilise les champs que nous avions qualifiés d’inutilisés).

Lorsque le KDC reçoit ce message, il le décrypte grâce à sa clé secrète partagée. Il en extrait alors la clé de session du client, qu’il utilise ensuite pour décrypter l’authentificateur.

Si celui-ci est valide, le KDC génère une clé de session que se partageront le client et le serveur.

Ensuite, le KDC crypte une copie de la clé de session au moyen de celle du client.

Une autre copie est placée dans un ticket, accompagnée des données d’autorisation du client.

Le ticket est ensuite crypté à l’aide de la clé à long terme du serveur.

Toutes ces données sont renvoyées au client à l’aide d’un message KRB_TGS_REP.

La structure de ce message est identique à celle du KRB_AS_REP.

A réception de ce message, le client le décrypte, et décode la clé de session en utilisant sa propre clé de session. Il stocke la clé de session décryptée dans sa mémoire cache. Le client extrait ensuite le ticket pour le serveur, qu’il stocke également.

I.1.5.C)        Le sous protocole CS

CS est le sous protocole utilisé lorsque le client envoie le ticket de session à un serveur, sous la forme d’un message KRB_AP_REQ. Le contenu de ce message est décrit dans le tableau ci-dessous :

Une fois le ticket reçu, le serveur le décrypte, et en extrait les données d’autorisation du client et la clé de session.

Le serveur utilise alors cette dernière pour décrypter l’authentificateur du client. Si celui-ci paraît valide, le serveur examine si une balise d’authentification mutuelle à été inséré.

Si le serveur détecte cette balise, il utilise la clé de session pour crypter l’horodatage contenu dans l’authentificateur du client, et renvoyer le résultat du cryptage au client, à l’aide d’un message KRB_AP_REP (voir structure dans le tableau ci-dessous).

A réception de ce message, le client décrypte l’authentificateur du serveur en utilisant la clé de session, et compare l’horodatage renvoyé par le serveur à celui spécifié dans l’authentificateur du client.

Si les horodatages sont identiques, la communication entre le client et le serveur peut alors se poursuivre.

I.1.6.             Kerberos et Windows 2000

La mise en œuvre du protocole Kerberos sous Windows 2000 est appelée Microsoft Kerberos, Microsoft ayant développé ses propres extensions pour ce système d’authentification.

Microsoft Kerberos se charge uniquement de vérifier l’identité des utilisateurs, sans intervenir dans l’autorisation des accès.

Une fois que Microsoft Kerberos a authentifié un utilisateur, c’est l’autorité locale de sécurité, ou LSA qui autorise ou refuse l’accès à la ressource sollicitée.

I.1.6.A)         Centre de distribution de clés, ou KDC

La notion de KDC (que nous avons déjà abordés précédemment) est fondamentale dans la technologie Kerberos.

Sous Windows 2000, le KDC est mis en œuvre sous la forme d’un service de domaine (voir screenshoot ci-dessous), et la base de données de comptes nécessaires au KDC est incluse dans Active Directory.

Chaque contrôleur de domaine Windows 2000 exécute un service KDC, ainsi que Active Directory.

Différents contrôleurs peuvent ainsi procéder à des authentifications et traiter des demandes de ticket, sans dépendre d’un KDC unique.

Chaque KDC Kerberos possède son propre nom de principal. Sous Win 2000, le nom unité est krbtgt.

En effet, à la création d’un domaine Windows 2000, un compte utilisateur krbtgt est crée pour le principal KDC (voir image ci-dessous).

Ce compte est prédéfini, et ne peut ni être modifié, ni supprimé, ni renommé. Il ne peut pas non plus être activé en vue d’un usage de compte utilisateur normal.

Il est important de préciser, que même s’il paraît désactivé, le compte demeure toujours utilisé par le KDC.

Le mot de passe du compte krbtgt est généré automatiquement par Windows 2000. La clé employée par le compte krbtgt est déterminée à partir du mot de passe du compte, tout comme une clé d’utilisateur à long terme normale.

La clé à long terme du compte krbtgt est utilisée pour crypter et décrypter les tickets d’octroi de tickets (TGT).

Tous les KDC d’un même domaine emploient le même compte krbtgt ; ainsi dans un domaine Windows 2000 qui comprend cinq contrôleurs de domaines, chaque contrôleur dispose de son propre KDC, mais ceux-ci utilisent le même compte krbtgt.

Ce fonctionnement est très utile, car il permet à tous les KDC d’un même domaine d’utiliser la même clé à long terme pour crypter ou décrypter les TGT.

I.1.6.B)        La Stratégie Kerberos

Sous Windows 2000, une stratégie d’authentification Kerberos est définie au niveau de chaque domaine. Chaque domaine Windows 2000 constitue ainsi un domaine Kerberos. La stratégie Kerberos d’un domaine est stockée dans Active Directory, et seuls les membres du groupe Administrateurs de domaine sont autorisés à la modifier.

Voici les différentes options paramétrables dans la stratégie Kerberos :

- appliquer les restrictions pour l’ouverture d’une session,

- durée de vie maximale du ticket de service,

- durée de vie maximale du ticket utilisateur,

- durée de vie maximale pour le renouvellement du ticket,

- tolérance maximale pour la synchronisation de l’horloge

L’image ci-dessous présente ces options avec les valeurs par défaut :

Nous allons rapidement détailler ces options.

L’option Appliquer les restrictions pour l’ouverture d’une session est activé par défaut. Elle provoque pour chaque demande de ticket de session, la vérification des droits d’accès de l’utilisateur au serveur cible.

La Durée de vie maximale du ticket de service est spécifié en minutes. Microsoft a choisi d’utiliser le terme « ticket de service » au lieu du « ticket de session » que nous avons utilisé dans les chapitres précédent.

La valeur spécifiée pour cette option ne peut être inférieure à dix minutes, et supérieure à la durée de vie maximale du ticket utilisateur.

La valeur de l’option Durée de vie maximale du ticket utilisateur est elle aussi spécifiée en minutes. Comme pour l’option ci-dessus, Microsoft a choisi d’utiliser le terme de « ticket utilisateur » à la place de TGT.

Le paramètre Durée de vie maximale pour le renouvellement du ticket est spécifié en jours.

L’option Tolérance maximale pour la synchronisation de l’horloge détermine le décalage maximal autorisé pour les horloges, et doit être spécifié en minutes.

I.1.6.C)        Contenu d’un ticket Microsoft Kerberos

Les tickets Microsoft Kerberos contiennent des éléments supplémentaires par rapport aux tickets de base du protocole Kerberos. Windows 2000 utilise des identificateurs de sécurité ou SID (Security Identifier).

Ces identificateurs de sécurité sont employés pour représenter les comptes utilisateur et les groupes.

Chaque ticket utilisé par un client contient le SID de l’utilisateur, ainsi que les SID des groupes auxquels appartient l’utilisateur.

Le nom de l’utilisateur est spécifié dans le ticket sous la forme : UPN : nom@domaine.

I.1.6.D)        Délégation de l’authentification et Pré-authentification

Le système Kerberos autorise deux méthodes de délégation de l’authentification : par tickets en mode proxy, et par tickets transférables. La version Microsoft du protocole ne prend en charge que les tickets transférables.

De plus, la stratégie Kerberos des domaines Windows 2000 n’autorise que les utilisateurs membres du groupe Administrateurs de domaine, d’utiliser ces tickets. Cette autorisation peut également être accordée aux utilisateurs individuels.

Pour accéder aux comptes utilisateurs depuis Active Directory, cliquez sur Démarrer>>Programmes>>Outils d’administration>>Utilisateurs et ordinateurs Active Directory.

Afficher les propriétés de l’utilisateur, l’option d’approbation de la délégation d’authentification est disponible sous l’onglet Compte. Vous remarquerez que cet onglet présente également une option permettant d’interdire la délégation.

Dans un système Kerberos, certains messages comprennent un champ de pré authentification. Sous Windows 2000, Kerberos utilise par défaut cette option dans les domaines (ce champ contient l’horodatage du client).

Cependant la pré-authentification peut être désactivée, action nécessaire, dans certains cas, pour obtenir l’interopérabilité de Microsoft Kerberos avec d’autres versions du protocole.

I.1.6.E)         Fournisseurs de sécurité (SSP) et autorité de sécurité locale (LSA)

A l’amorçage d’un système Windows 2000 Server, deux SSP sont automatiquement démarrés : le SSP Kerberos et le SSP NTLM. Par défaut Windows 2000 utilise le SSP Kerberos, sauf si le client n’est pas compatible avec Kerberos, par exemple avec les systèmes Windows 9x, auquel cas, c’est le fournisseur de sécurité NTLM qui est employé.

Ce dernier est également utilisé avec les systèmes Windows 2000 Server configurés en tant que serveurs membres ou autonomes, ainsi que pour les connexions locales avec des contrôleurs de domaine.

Chaque client utilise une zone de la mémoire volatile pour stocker ses informations d’identification. Cette zone est protégée par l’autorité de sécurité locale (LSA), et ne peut être enregistré dans le fichier d’échange stocké sur le disque dur.

Lorsqu’un utilisateur se déconnecte du système, le contenu de cette zone est automatiquement détruit.

Le SSP Kerberos gère la mémoire cache d’identification. Il est utilisé pour récupérer et renouveler tickets et clés. C’est à l’autorité de sécurité locale qu’il appartient d’avertir le SSP que de telles fonctions doivent être exécutées.

Le LSA doit disposer d’une copie du mot de passe de l’utilisateur, placée dans une zone sécurisée du registre, et ce pendant toute la durée de session de l’utilisateur. Le LSA utilise cette copie du mot de passe en cas d’expiration du TGT, et permet ainsi au SSP Kerberos d’obtenir un autre TGT, sans qu’il soit nécessaire de redemander son mot de passe à l’utilisateur.

I.1.6.F)         Résolution de noms DNS

Le système d’authentification Microsoft Kerberos utilise le DNS pour localiser un KDC disponible pour traiter une requête initiale d’authentification. Par définition, tous les contrôleurs de domaine Windows 2000 sont des KDC.

Chaque KDC apparaît sous la forme _kerberos._udp.nomDuDomainDNS dans l’enregistrement SRV du système DNS. C’est à partir de cet enregistrement que chaque client peut obtenir l’adresse IP de l’ordinateur exécutant le KDC approprié.

Un ordinateur exécutant Windows 2000 dans un domaine Kerberos qui n’est pas un domaine Windows 2000 ne peut rechercher un enregistrement SRV. Dans ce cas là, le nom du serveur KDC est stocké dans le registre de l’ordinateur Windows 2000.

I.1.6.G)        Données d’autorisation

Un système d’authentification Kerberos vérifie uniquement l’identité des principaux, et autorise ensuite, si la vérification est positive, l’accès aux ressources que les principaux peuvent utiliser.

Les tickets Kerberos contiennent un champ réservé aux données d’autorisation, mais le système Kerberos en lui-même ne contrôle ni le contenu de ce champ, ni l’utilisation faite de ce contenu.

Dans un ticket Microsoft Kerberos, le champ réservé aux données d’autorisation contient la liste des SID de l’utilisateur, y compris les SID des groupes auxquels il appartient.

Le KDC obtient cette information de Active Directory, et l’insère dans le TGT fourni au client.

Lorsqu’un client sollicite un ticket de session (ou un ticket de service, comme l’appelle Microsoft), le KDC renvoie le contenu du champ de données d’autorisation du TGT dans le ticket de session. Le LSA vérifie la validité de chaque ticket de session.

I.1.7.             Synthèse

Windows 2000 supporte les protocoles d’authentification Windows NTLM, Kerberos v5, DPA, EAP et SChannel.

NTLM et Kerberos sont les deux protocoles utilisés par Windows 2000 pour les ouvertures de session locales ou d’utilisateurs interactifs. Kerberos est le protocole d’authentification par défaut de Windows 2000 ; NTLM est pris en charge pour garantir la compatibilité ascendante.

Le protocole Kerberos à plusieurs avantages sur NTLM, qui était le protocole d’authentification standard des versions antérieures de Windows NT. Kerberos permet notamment l’authentification mutuelle d’un client et d’un serveur, par laquelle le client peut ainsi vérifier l’identité du serveur. NTLM n’offre pas cette possibilité. D’autre part, les domaines Kerberos Windows 2000 peuvent communiquer avec des domaines Kerberos d’autres versions Kerberos, ce que ne permet pas NTLM (car c’est un protocole propriétaire des OS Microsoft).

Un système Kerberos comprend plusieurs composants, dont le centre de distributions des clés ou KDC, des tickets de session, des tickets d’octroi de tickets, ou TGT.

Le KDC en lui-même est formé de deux différents services : le service d’authentification, ou AS, et le service d’octroi de tickets, ou TGS.

Sous Windows 2000, Microsoft utilise sa propre monture du protocole Kerberos. Le système d’authentification Microsoft Kerberos comporte des extensions au système Kerberos normalisé, développées pour répondre à des besoins spécifiques de Windows 2000, par exemple l’usage de certificats de clé publique pour la connexion à des domaines Windows 2000, au lieu de la clé partagée normale.

Sous Windows 2000, Microsoft a implémenté le KDC sous la forme d’un service automatiquement installé sur tous les contrôleurs de domaine. Kerberos stocke les PAC (Privilege Attribute Certificate) dans les tickets. Le Pac est constitué du SID de l’utilisateur et des SID des groupes auxquels il appartient.