Kerberos VS NT LAN Manager (NTLM)

Les systèmes d’exploitation gèrent l’authentification les utilisateurs dans les applications ou lors de l’accès à des ressources par le réseau souvent à travers une authentification unique ou SSO (Single Sign-On).
Pour y parvenir, ils peuvent implémenter des protocoles d’authentification existants.
Kerberos et NTLM (NT LAN Manager) en font partie.
Ainsi, les administrateurs réseau sont tôt ou tard confrontés à ces protocoles et doivent connaître leurs fonctionnements.

Ce tutoriel vous donne un aperçu des fonctionnements de NTLM et Kerberos.
Vous trouverez donc les principales différences entre ces protocoles d’authentification.

Qu’est-ce que NT LAN Manager (NTLM)

NT LAN Manager (NTLM) est le nom d’une famille de protocoles de sécurité. NTLM est utilisé par les protocoles d’application pour authentifier les utilisateurs distants et, éventuellement, pour fournir une sécurité de session lorsque
par l’application.
C’est une forme d’authentification unique (SSO) permettant aux utilisateurs de s’authentifier auprès d’applications sans soumettre le mot de passe sous-jacent.

Il propose les fonctionnalités suivantes :

• La suite de protocoles NTLM est implémentée dans un Security Support Provider (SSP)
• Une API Win32 utilisée par les systèmes Microsoft Windows pour effectuer une variété d’opérations liées à la sécurité, comme l’authentification
• Elle comprend le protocole d’authentification LAN Manager, les protocoles NTLMv1, NTLMv2 et NTLM2 Session.
• NTLM est largement déployé, même sur les nouveaux systèmes, pour maintenir la compatibilité avec les anciens systèmes

L’établissement de la connexion et authentification NTLM

NTLM est un protocole d’authentification de type défi-réponse.
Cela signifie que pour authentifier un utilisateur, le serveur envoie un défi au client.
Le client renvoie alors une réponse qui est une fonction de défi, du mot de passe de l’utilisateur et éventuellement d’autres informations.
Le calcul de la réponse correcte nécessite la connaissance du mot de passe de l’utilisateur.
Le serveur (ou une autre partie à laquelle le serveur fait confiance) peut valider la réponse en consultant une base de données de comptes pour obtenir le mot de passe de l’utilisateur et en calculant la réponse appropriée pour ce défi.

Essentiellement, la connexion est à trois poignées de main.
Voici un exemple :

1. Des messages de protocole spécifiques à l’application sont envoyés entre le client et le serveur
2. Le protocole NTLM commence lorsque l’application requiert une session authentifiée. Le client
   envoie un message NTLM NEGOTIATE_MESSAGE au serveur. Ce message spécifie les caractéristiques de
   caractéristiques de sécurité souhaitées pour la session
3. Le serveur envoie un message NTLM CHALLENGE_MESSAGE au client. Ce message comprend caractéristiques de sécurité convenues, et un non ce que le serveur génère
4. Le client envoie un message NTLM AUTHENTICATE_MESSAGE au serveur. Ce message contient le nom d’un utilisateur et une réponse qui prouve que le client possède le mot de passe de l’utilisateur.
   Le serveur valide la réponse envoyée par le client.
   • Si le nom d’utilisateur correspond à un compte local, il peut valider la réponse en utilisant les informations de sa base de données de comptes locaux
   • Si le nom d’utilisateur est celui d’un domaine, il peut valider la réponse en envoyant les informations d’authentification de l’utilisateur (le nom de l’utilisateur, le défi envoyé à l’utilisateur, etc. nom d’utilisateur, le défi envoyé au client et la réponse reçue du client) à un contrôleur de contrôleur de domaine (DC) qui peut valider la réponse. Le protocole NTLM se termine
5. Si le défi et la réponse prouvent que le client a le mot de passe de l’utilisateur, l’authentification réussit et le protocole de l’application continue selon sa spécification
   l’authentification réussit, et le protocole d’application continue selon ses spécifications. Si l’authentification
   Si l’authentification échoue, le serveur peut envoyer l’état d’une manière spécifiée par le protocole d’application, ou il peut simplement mettre fin à la connexion

NTLM sur un transport Server Message Block (SMB) est utilité comme méthode d’authentification et du chiffrement NTLM sur un PC ne faisant pas partie d’un domaine Windows.

Qu’est-ce que Kerberos

Kerberos est un protocole d’authentification de réseau informatique mis au point Kerberos en 1988 par Le Massachusetts Institute of Technology (MIT).

Kerberos s’appuie sur la cryptographie à clé symétrique et nécessite un tiers de confiance, et peut éventuellement utiliser la cryptographie à clé publique pendant certaines phases de l’authentification.
Il Kerberos utilise le port UDP 88 par défaut.
Il fonctionne sur la base de tickets pour permettre aux nœuds communiquant sur un réseau non sécurisé de prouver leur identité les uns aux autres de manière sécurisée.
Ses concepteurs l’ont principalement orienté vers un modèle client-serveur, et il fournit une authentification mutuelle – l’utilisateur et le serveur vérifient tous deux l’identité de l’autre.
Les messages du protocole Kerberos sont protégés contre les écoutes et les attaques par relecture.
En pratique, les trois composants de sécurité du protocole Kerberos sont représentés comme suit :

• Un client cherchant à s’authentifier
• Un serveur auquel le client veut accéder
• Le service Kerberos Key Distribution Center (KDC)

Dans le monde Windows, l’authentification Kerberos [MS-KILE] remplace NTLM comme protocole d’authentification préféré notamment dans les domaines Windows avec Active Directory.
Mais il est utilisé sur MacOS, Linux, les systèmes UNIX ou BSD.

L’établissement de la connexion et authentification Kerberos

Voici les étapes d’une authentification Kerberos dans Windows :

• L’utilisateur partage son nom d’utilisateur, son mot de passe et son nom de domaine avec le client
• Le client assemble un paquet – ou un authentificateur – qui contient toutes les informations pertinentes sur le client, y compris le nom d’utilisateur, la date et l’heure. Toutes les informations contenues dans l’authentifiant, à l’exception du nom d’utilisateur, sont chiffrées avec le mot de passe de l’utilisateur
• Le client envoie l’authentifiant chiffré au KDC.
• Le KDC vérifie le nom d’utilisateur pour établir l’identité du client. Le KDC vérifie ensuite le mot de passe de l’utilisateur dans la base de données AD. Il tente ensuite de déchiffrer l’authentifiant avec le mot de passe. Si le KDC parvient à déchiffrer l’authentifiant, l’identité du client est vérifiée
• Une fois l’identité du client vérifiée, le KDC crée un ticket ou une clé de session, qui est également chiffré et envoyé au client
• Le ticket ou la clé de session est stocké dans le bac Kerberos du client ; le ticket peut être utilisé pour accéder au serveur pendant une période déterminée, qui est généralement de 8 heures
• Si le client doit accéder à un autre serveur, il envoie le ticket original au KDC avec une demande d’accès à la nouvelle ressource
• Le KDC déchiffre le ticket avec sa clé. (Le client n’a pas besoin d’authentifier l’utilisateur car le KDC peut utiliser le ticket pour vérifier que l’identité de l’utilisateur a été confirmée précédemment)
• Le KDC génère un ticket ou une clé de session mis à jour pour que le client puisse accéder à la nouvelle ressource partagée. Ce ticket est également chiffré par la clé du serveur. Le KDC envoie ensuite ce ticket au client.
• Le client enregistre cette nouvelle clé de session dans son bac Kerberos et en envoie une copie au serveur.
• Le serveur utilise son propre mot de passe pour déchiffrer le ticket
• Si le serveur parvient à déchiffrer la clé de session, le ticket est légitime. Le serveur ouvre alors le ticket et examine la liste de contrôle d’accès (ACL) pour déterminer si le client dispose des autorisations nécessaires pour accéder à la ressource

Kerberos VS NT LAN Manager (NTLM) : Les différences

NTLM présentait plusieurs failles de sécurité connues liées au hachage et au salage des mots de passe.
Par conséquent, les systèmes étaient vulnérables aux attaques par force brute, c’est-à-dire lorsqu’un attaquant tente de craquer un mot de passe en multipliant les tentatives de connexion. Si l’utilisateur choisit un mot de passe faible ou courant, il est particulièrement vulnérable à ces tactiques.

De plus, ils possède certaines limitations. Par exemple, il ne prend pas en charge l’authentification multifactorielle (AMF), qui consiste à utiliser deux informations ou plus pour confirmer l’identité de l’utilisateur.
Ainsi son utilisation n’est plus recommandée par Microsoft car NTLM ne prend pas en charge les méthodes cryptographiques actuelles, telles que AES ou SHA-256 contrairement à Kerberos.
Microsoft a adopté Kerberos comme protocole d’authentification privilégié pour Windows 2000 et les domaines Active Directory suivants.