Dans un article précédent, nous avons expliqué de manière simplifiée le principe de l'authentification NTLm . Nous allons dans cet article tenté d'expliquer le principe de fonctionnement de Kerberos. L'authentification Kerberos est assurée par le centre de distribution de clés (KDC) des contrôleurs de domaine Active Directory.
Dans notre exemple, le client souhaite accéder à une ressource située sur le serveur à droite dans l'image ci-dessous. Pour cela il devra obtenir une sorte de visa qui spécifie le nom du service hébergé par ce serveur.
- Le client ouvre sa session à l'aide de son compte et de son mot de passe.
- Le poste de l'utilisateur envoie une demande d'authentification Kerberos au contrôleur de domaine. Cette requête contient une clé liée au mot de passe de l'utilisateur. Cette demande Kerberos est appelé « AS-REQ ».
- Si les informations sont exactes et que le compte est bien actif, le contrôleur de domaine fournit une sorte de passeport à l'utilisateur d'une durée de 10 heures par défaut. Lorsqu'il est expiré, l'ordinateur en demande un nouveau. Ce ticket s'appelle TGT et la réponse du contrôleur de domaine est appelé « AS-REP ». En même temps que le TGT, le KDC du contrôleur de domaine envoie une clé de session crypté à l'utilisateur. La clé de session sera utilisée dans les étapes suivantes pour protéger le trafic. Les échanges sont également horodatés et Kerberos n'accepte pas de décalage de plus de 5 minutes entre le poste client et le contrôleur de domaine (voir synchronisation des horloges dans un domaine AD) .
- L'utilisateur souhaite accéder à une ressource sur un serveur acceptant Kerberos. Il va utiliser son TGT valide afin de demander un autre ticket au contrôleur de domaine en précisant le service cible. La demande et la réponse sont cryptées par la clé de session. La demande envoyée au DC s'appelle « TGS-REQ ».
- Le contrôleur de domaine, va fournir au client un nouveau ticket précisant le nom du service auquel il s'applique (un genre de visa) ainsi qu'une clé de session pour le service demandé. Ce ticket s'appelle TGS. La réponse s'appelle « TGS-REP ».
- Le poste client envoie le ticket au serveur pour accéder à la ressource. Cette demande s'appelle « AP-REQ ».
- Avec Kerberos, le service peut optionnellement, répondre à une demande d'authentification mutuelle en envoyant une réponse « AP-REP »
Selon l'appartenance aux groupes de l'utilisateur et les permissions sur le service, l'utilisateur sera autorisé à accéder à certains ou tous les éléments.
|
|
Le contrôleur de domaine utilise le mot de passe d'un compte spécifique de l'annuaire AD : « KrbTGT » entre autres pour signer les tickets. Le compte « KRBTGT » est un compte spécifique dans l'annuaire et joue un rôle important pour la sécurité des échanges sur le réseau. Il est possible de réinitialiser le mot de passe de ce compte « KrbTGT » en respectant certaines règles : http://www.pbarth.fr/node/203. Lors d'un changement de mot de passe il est important que la modification soit répliquée sur tous les contrôleurs de domaine. Il est donc indispensable de vérifier la bonne santé de l'AD et de la réplication. Il existe un compte KrbTGT spécifique sur les contrôleurs de domaine en lecture seule. |
|
La ressource est liée à un nom de service indiquant le type de service et le nom DNS. Cette valeur doit être inscrite dans les attributs du compte de la machine qui héberge le service, si le service est exécuté sur le compte système, ou sinon sur le nom du compte qui exécute le service. Les tickets TGS font référence à ce nom. Par exemple pour le serveur de fichier « File2 » il dispose des SPN ci-dessous.
|
|
Il est nécessaire d'activer les fonctionnalités avancées dans le menu affichage de la console « Utilisateurs et Ordinateurs AD » pour voir les attributs détaillés). |
|
|
Host : n'est pas un service mais un ensemble de services, comprenant entre autres CIFS (partage de fichier) que nous verrons un peu plus loin. « TermServ » est utilisé par les services RDS. Voir : https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff649429(v=pandp.10) |
Sur un poste client, il est possible de voir les tickets Kerberos avec la commande « klist ». Le résultat est de la forme :
LogonId est 0:0x5bdc840
Tickets mis en cacheÿ: (6)
#0> Clientÿ: pbarth @ HTRAB.LAN
Serveurÿ: krbtgt/HTRAB.LAN @ HTRAB.LAN
Type de chiffrement KerbTicketÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de tickets 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
Heure de d‚marrageÿ: 6/24/2019 20:47:48 (Local)
Heure de finÿ: 6/25/2019 6:47:01 (Local)
Heure de renouvellementÿ: 7/1/2019 20:47:01 (Local)
Type de cl‚ de sessionÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de cacheÿ: 0x2 -> DELEGATION
KDC appel‚ÿ: 2016DC2.htrab.lan
#1> Clientÿ: pbarth @ HTRAB.LAN
Serveurÿ: krbtgt/HTRAB.LAN @ HTRAB.LAN
Type de chiffrement KerbTicketÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de tickets 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Heure de d‚marrageÿ: 6/24/2019 20:47:01 (Local)
Heure de finÿ: 6/25/2019 6:47:01 (Local)
Heure de renouvellementÿ: 7/1/2019 20:47:01 (Local)
Type de cl‚ de sessionÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de cacheÿ: 0x1 -> PRIMARY
KDC appel‚ÿ: 2016DC2.htrab.lan
Pour accéder à des partages de fichiers à l'aide de Kerberos, le service est CIFS comme vous pouvez le voir ci-dessous en rouge. Il s'agit d'un ticket permettant d'accéder au partage de fichiers sur le serveur 2016DC1 :
#2> Clientÿ: pbarth @ HTRAB.LAN
Serveurÿ: cifs/2016dc1 @ HTRAB.LAN
Type de chiffrement KerbTicketÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de tickets 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Heure de d‚marrageÿ: 6/24/2019 20:47:48 (Local)
Heure de finÿ: 6/25/2019 6:47:01 (Local)
Heure de renouvellementÿ: 7/1/2019 20:47:01 (Local)
Type de cl‚ de sessionÿ: AES-256-CTS-HMAC-SHA1-96
Indicateurs de cacheÿ: 0
KDC appel‚ÿ: 2016DC2.htrab.lan
Il est possible de créer des SPN particuliers avec la commande « SetSPN ». Dans l'exemple suivant je vous propose de créer dans notre zone DNS deux enregistrements de type A avec les noms « toto » et « titi » qui pointent sur l'adresse de notre serveur de fichier « File1 ».
Une fois ces enregistrements créés, nous allons ajouter comme SPN « toto » et « toto.htrab.lan » sur le compte de l'ordinateur « File1 » avec les commandes :
setspn -a cifs/toto file1
setspn -a cifs/toto.htrab.lan file1
Nous ouvrons une session utilisateur sur un poste client avec un compte utilisateur du domaine. Depuis cette session nous essayons d'accéder au partage « \\toto.htrab.lan » et « \\titi.htrab.lan ».
Avec la commande « Klist », nous pouvons constater qu'il existe un ticket de service pour le partage vers « toto », cependant il n'y en a pas pour « titi ».
En résumé, l'accès aux partages « toto.htrab.lan » utilise les protocoles Kerberos car il existe un SPN avec un nom de service « CIFS » et le nom DNS. L'accès à « titi.htrab.lan » est également possible mais les services utiliseront NTLM comme mécanisme d'authentification. Un accès à un partage en utilisant l'adresse IP plutôt que le nom, utilise automatiquement NTLM comme protocole d'authentification.
L'image ci-dessous provient d'une capture de trame réseau avec « NetSH », le fichier « Etl » généré est lu avec Message Analyser.
Dans l'encadré bleu, vous pouvez voir les échanges « AS-REQ » et « AS-REP » afin d'obtenir le « TGT ». En rouge, la demande de ticket « TGS » pour accéder au partage(CIFS) « toto.htrab.lan ».
Il est également possible d'utiliser Kerberos avec des serveurs autres que Windows et de gérer les SPN correspondant aux services offerts par ces serveurs non Microsoft : « ktpass ».
Par rapport au protocole NTLM, Kerberos est nettement moins sensible, à commencer par le serveur de ressource qui n'est pas concernée par les informations d'authentification, mais juste par le ticket TGS. Nous ne détaillerons pas les éléments dans cet article, mais il est possible d'augmenter la sécurité des échanges notamment « AS-REQ » et « AS-REP » en utilisant le blindage Kerberos. L'utilisation du TGT/TGS évite de faire circuler le mot de passe (même s'il est crypté) trop fréquemment sur le réseau comme pour NTLM.
Les tickets Kerberos intègrent les groupes dont l'utilisateur est directement membre et les groupes hérités, ainsi que certains groupes spécifiques comme « utilisateurs authentifiés ». Il est possible d'étendre les informations de sécurité de Kerberos en ajoutant des informations liées aux propriétés de l'utilisateur, comme par exemple, le nom du service. Ces éléments se nomment des « revendications » (claims). Ils sont utilisés entre autres avec Dynamic Access Control, qui offre une autre méthode de gérer les droits d'authentifications.
Conseil de lecture technique :
