Les chercheurs parlent depuis des années lors de conférences de l'insécurité des technologies d'authentification unique. Ce système d'authentification unique pour tout et à la fois est utilisé par Microsoft depuis longtemps, et les experts en sécurité de l'information ont déclaré en 1997 que ce n'était pas une bonne idée. Une fois de plus, la vulnérabilité de l'authentification unique en général et dans le cas du travail avec des ressources SMB en particulier a été démontrée par le chercheur russe ValdikSS. Il a décrit une méthode qui vous permet de compromettre le compte Microsoft de la victime, de désanonymiser les utilisateurs Microsoft et de découvrir les données VPN.

En effet, pour réussir une attaque, il suffit à un attaquant de dissimuler un lien vers sa propre ressource SMB (ressources réseau : fichiers et dossiers, imprimantes, etc.), par exemple, sous une photo et de forcer la victime à ouvrir il. L'attaque fonctionne sur tous les systèmes d'exploitation modernes, y compris Windows 10 avec les dernières mises à jour. De plus, ces problèmes d'authentification NTLM ont été discutés non seulement en 1997, mais ils sont régulièrement mentionnés. Ainsi, cette question a été soulevée (PDF) l'année dernière lors de la conférence BlackHat. Malheureusement, rien ne change des références fréquentes.

Sur Habrahabr, l'utilisateur ValdikSS a expliqué comment ce "bug des années 90" peut être exploité aujourd'hui. Le chercheur écrit :

"Dès que vous essayez d'ouvrir un lien vers une ressource SMB dans un navigateur standard (Internet Explorer, Edge) ou toute application qui fonctionne via des appels d'API Windows standard ou utilise Internet Explorer comme moteur d'affichage HTML (Outlook, Windows Explorer) , la ressource SMB reçoit immédiatement les informations de votre compte avant même que vous ne voyiez la boîte de dialogue de connexion et de mot de passe. Il suffit à un attaquant, par exemple, d'ajouter un lien vers une image d'un serveur SMB vers une page de site web, ou de vous envoyer un email qui suffira juste à s'ouvrir, et - boum ! - Les informations de votre compte sont entre les mains d'un attaquant.

Bien que la fuite du nom de compte et du hachage du mot de passe d'un ordinateur personnel ne soit pas considérée comme un désastre, lorsqu'il s'agit d'un domaine d'entreprise, une conversation complètement différente commence.

« À partir du nom de domaine, il est généralement facile de comprendre à quelle organisation appartient le compte, puis, si le mot de passe est bien deviné, vous pouvez essayer de vous authentifier sur les ressources de l'entreprise accessibles depuis Internet (mail, VPN).

Mais le mot de passe n'est pas toujours nécessaire de deviner. Si vous connaissez à l'avance une ressource où vous pouvez vous connecter en utilisant l'authentification NTLM, vous pouvez en temps réel, dès que le client se connecte à votre serveur SMB, les requêtes proxy du client vers le serveur distant et du serveur vers le client, et authentifiez-vous avec succès dessus !", explique ValdikSS.

La situation est également aggravée par le fait que dans les systèmes d'exploitation Microsoft modernes, ils promeuvent activement l'utilisation d'un seul compte Microsoft, forçant littéralement l'utilisateur à le créer. Pour les utilisateurs de comptes Microsoft, de telles attaques peuvent être doublement dangereuses, non seulement pour les organisations, mais aussi pour les particuliers. Le fait est qu'en cas d'attaque sur le serveur SMB d'un attaquant, des données seront transmises qui, de fait, compromettront le compte Microsoft de la victime, et de nombreux services y sont rattachés (Skype, Xbox, OneDrive, Office 360, MSN , Bing, Azure, etc. Plus loin).

Le chercheur écrit également que dans certains cas, l'attaque peut être utilisée pour extraire des données sur le hachage de connexion et de mot de passe de la connexion VPN de la victime.

Dans le même temps, ValdikSS a décrit un certain nombre de façons d'exploiter les problèmes d'authentification NTLM. En plus des choses très évidentes, le chercheur a suggéré d'utiliser un espace pour désanonymiser les utilisateurs :

« L'exploitation à des fins de désanonymisation est plus intéressante. Le compte sera envoyé depuis les pages du site si la victime utilise Internet Explorer, ou en cliquant à l'intérieur de la lettre, dans le cas d'Outlook. Presque toutes les interfaces Web des services de messagerie filtrent les images avec le schéma file:// lors de la sortie des messages (le schéma file:// est analogue au schéma \\), mais pas Yandex, qui ne considère pas cela comme une vulnérabilité (qui, dans général, est correct). La désanonymisation par courrier est plus dangereuse, car donne un lien non seulement vers les adresses IP avec un compte Windows, mais aussi avec le courrier.

Le schéma Chrome file:// fonctionne également, mais uniquement à partir de la barre d'adresse. Télécharger quoi que ce soit avec une image SMB ou cliquer sur un lien ne fonctionnera pas. Puisque Chrome est beaucoup plus populaire qu'Internet Explorer, l'ingénierie sociale devra être appliquée.

Vous pouvez voler des comptes pour votre propre bien. Certains fournisseurs VPN utilisent les mêmes noms d'utilisateur et mots de passe pour la connexion au compte et l'authentification VPN. Le compte appartenant à un service particulier peut être déterminé par l'adresse IP de la connexion entrante de l'utilisateur. Et si vous avez un compte Microsoft et que vous avez trouvé le mot de passe à partir du hachage, alors félicitations - vous avez accès aux fichiers dans le cloud OneDrive, à la messagerie Outlook, au compte Skype s'il est lié à un compte Microsoft, et bien plus encore.

En conclusion, ValdikSS écrit que vous pouvez vous protéger de telles attaques, par exemple en restreignant l'accès au port TCP 445 pour toutes les plages d'adresses sauf :

• 192.168.0.0/16
• 169.254.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8
• fd00 ::/8
• fe80 ::/10

Toujours dans les commentaires de l'article, les utilisateurs ont suggéré la méthode suivante :

Éditeur du Registre Windows Version 5.00

"RestrictReceivingNTLMTraffic"=dword:00000002
"RestrictSendingNTLMTraffic"=dword:00000002

De plus, le chercheur a créé une page spéciale qui vous permet de vérifier la vulnérabilité de votre système à ce type d'attaque.

Le système d'exploitation Windows 7 introduit une nouvelle génération de technologies de sécurité pour le bureau, et l'une d'elles est l'authentification et l'autorisation. Certaines technologies visent à renforcer l'infrastructure globale de Windows, et les autres à aider à gérer le système et les données des utilisateurs.

Avant d'établir des mesures de sécurité efficaces dans Windows 7, telles que le partage de fichiers et de dossiers, il est important de comprendre les types de comptes d'utilisateurs utilisés lors de la configuration de la sécurité et comment le protocole réseau authentifie et autorise les ouvertures de session des utilisateurs.

L'authentification est le processus utilisé pour vérifier l'identité d'un utilisateur lors de l'accès à un système informatique ou à des ressources système supplémentaires. Dans les réseaux informatiques privés et publics (y compris Internet), le moyen le plus courant de s'authentifier consiste à vérifier les informations d'identification de l'utilisateur ; c'est-à-dire nom d'utilisateur et mot de passe. Cependant, pour les types de transactions critiques tels que le traitement des paiements, l'authentification par nom d'utilisateur et mot de passe n'est pas suffisante, car les mots de passe peuvent être volés ou compromis. Pour cette raison, la majeure partie des activités sur Internet, ainsi que de nombreuses autres transactions, utilisent désormais des certificats numériques qui sont émis et vérifiés par une autorité de certification.

L'authentification précède logiquement l'autorisation. L'autorisation permet au système de déterminer si un utilisateur authentifié peut accéder aux ressources système protégées et les mettre à jour. L'autorisation vous permet de définir un accès directif aux dossiers et fichiers, les heures d'accès, l'espace de stockage autorisé, etc.

• Les modifications apportées aux ressources système sont initialement autorisées par l'administrateur système.
• Lorsqu'un utilisateur tente d'accéder à une ressource système ou de la mettre à jour, l'autorisation d'agir est évaluée par le système ou l'application.

Cette dernière option permet à l'utilisateur d'accéder sans authentification ni autorisation. Il est utilisé lorsque vous souhaitez accorder l'accès à des utilisateurs anonymes et non authentifiés. Cet accès est généralement très limité.

Processus d'autorisation et d'authentification.

Pour accéder aux fichiers sur le réseau, les utilisateurs doivent être authentifiés pour vérifier leur identité. Cela se fait pendant le processus de connexion au réseau. Le système d'exploitation Windows 7 pour la connexion au réseau dispose des méthodes d'authentification suivantes :

• Protocole Kerberos version 5 : la principale méthode d'authentification pour les clients et les serveurs exécutant les systèmes d'exploitation Microsoft Windows. Il est utilisé pour authentifier les comptes d'utilisateurs et les comptes d'ordinateurs.
• Windows NT LAN Manager (NTLM) : utilisé pour la compatibilité descendante avec les systèmes d'exploitation antérieurs à Windows 2000 et certaines applications. Il est moins flexible, efficace et sécurisé que le protocole Kerberos version 5.
• Mappage de certificat : généralement utilisé pour l'authentification de connexion avec une carte à puce. Le certificat stocké sur la carte à puce est associé à un compte utilisateur. Un lecteur de carte à puce est utilisé pour lire les cartes à puce et authentifier l'utilisateur.

Nouvelles fonctionnalités d'authentification dans Windows 7.

Un certain nombre d'améliorations liées aux processus de connexion et d'authentification des utilisateurs ont été ajoutées depuis Windows Vista®. Ces améliorations ont augmenté l'ensemble de fonctionnalités d'authentification de base pour aider à fournir une meilleure sécurité et une meilleure gérabilité. Dans Windows 7, Microsoft poursuit les améliorations entamées dans Windows Vista avec les nouvelles fonctionnalités d'authentification suivantes :

• Carte à puce
• Biométrie
• Intégration de la personnalité sur Internet.

Carte à puce.

L'utilisation de cartes à puce est la méthode d'authentification la plus courante. Pour encourager les organisations et les utilisateurs à utiliser des cartes à puce, Windows 7 introduit de nouvelles fonctionnalités qui facilitent leur utilisation et leur déploiement. Ces nouvelles fonctionnalités permettent d'utiliser les cartes à puce pour diverses tâches, notamment :

• Cartes à puce plug and play
• Identification personnelle de vérification (PIV), norme du National Institute of Standards and Technology (NIST) des États-Unis
• Prise en charge de la connexion par carte à puce Kerberos.
• Chiffrement de lecteur BitLocker
• Documents et e-mail
• À utiliser avec des applications métier.

Biométrie.

La biométrie est une technologie de plus en plus populaire qui offre un accès facile aux systèmes, services et ressources. La biométrie utilise la mesure de ses caractéristiques physiques invariables pour identifier de manière unique une personne. Les empreintes digitales sont l'un des éléments biométriques les plus couramment utilisés.

Jusqu'à présent, Windows n'avait pas de support standard pour les appareils biométriques. Pour résoudre ce problème, Windows 7 introduit le Windows Biometric Framework (WBF). WBF fournit un nouvel ensemble de composants prenant en charge les empreintes digitales biométriques. Ces composants augmentent la sécurité des utilisateurs.

Le cadre biométrique Windows permet aux utilisateurs et aux administrateurs de configurer et de gérer facilement des périphériques biométriques sur un ordinateur local ou dans un domaine.

Intégration de la personnalité sur Internet.

La gestion de compte est une stratégie de sécurité. La stratégie de groupe est utilisée pour autoriser ou refuser l'authentification d'ordinateurs spécifiques ou de tous les ordinateurs que vous gérez en ligne.

L'intégration de l'identité en ligne peut être contrôlée par la stratégie de groupe. Une stratégie configurée comme suit : « Sécurité réseau : autoriser cet ordinateur à utiliser un ID en ligne lors de la demande d'authentification PKU2U » contrôle la capacité de l'ID en ligne à authentifier cet ordinateur à l'aide du protocole PKU2U. Ce paramètre de stratégie n'affecte pas la capacité des comptes de domaine ou des comptes d'utilisateurs locaux à se connecter à cet ordinateur.

L'authentification est une procédure indispensable pour chaque utilisateur, ordinateur et compte de service Windows, mais son mécanisme n'est pas étudié en profondeur par les administrateurs système. Tout le monde sait que pour se connecter à un ordinateur, il faut entrer le bon mot de passe, mais combien savent ce qui se passe ensuite ? L'authentification Windows et ses protocoles associés sont activés chaque fois qu'un utilisateur, un ordinateur ou un service se connecte localement ou à un contrôleur de domaine (DC). Cet article se concentrera d'abord sur les principes de base de l'authentification Windows, puis sur les protocoles qui lui sont associés. En conclusion, de brèves recommandations sont données pour améliorer la fiabilité de la procédure d'authentification dans un réseau Windows.

Authentification : principes généraux

L'authentification est l'un des composants de tout système de contrôle d'accès informatique. Comme le montre la figure 1, les systèmes de contrôle d'accès fournissent l'identification, l'authentification, l'autorisation et la génération de rapports.

Identification. Le processus d'identification utilise un ensemble de données qui identifient de manière unique un objet de sécurité (par exemple, un utilisateur, un groupe, un ordinateur, un compte de service) dans un service d'annuaire partagé. Un service d'annuaire tel qu'Active Directory (AD) permet aux objets d'être identifiés de manière unique, tout comme le DNS certifie que deux personnes ne peuvent pas avoir la même adresse e-mail. En interne, Windows utilise des SID, des identificateurs uniques mondiaux (GUID) et d'autres balises uniques. Dans la plupart des cas, un nom de compte unique, tel que Rgrimes, est suffisant pour l'identification. Dans une grande forêt AD, vous devez utiliser des noms d'utilisateur principaux (UPN) complets, tels que [courriel protégé] Lors de l'utilisation de cartes à puce, le sujet de sécurité peut présenter son certificat numérique ou sa clé.

Authentification ou authentification. Une fois que le principal de sécurité a saisi ou fourni les informations nécessaires à l'identification (par exemple, nom d'utilisateur, jeton de sécurité), il doit saisir ou présenter des informations d'authentification privées (par exemple, mot de passe et code PIN). Sous Windows, le principal de sécurité saisit ces informations sur l'écran de connexion à l'aide des programmes Microsoft Graphical Identification and Authentication DLL (msgina.dll) et Winlogon.exe. Le protocole d'authentification et le moteur système codent les informations soumises sur l'ordinateur de bureau et transmettent la demande d'authentification. Le service d'authentification Windows peut être une base de données SAM ou AD. La base de données SAM gère les procédures de connexion locales et les connexions aux contrôleurs de domaine Windows NT 4.0. AD authentifie les requêtes dans les domaines Windows 2000 ou ultérieurs. Un protocole d'authentification (par exemple, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) est utilisé pour transporter les demandes d'authentification et les transactions ultérieures entre l'écran de connexion et le service d'authentification. Un peu plus bas, chaque protocole d'authentification sera considéré séparément.

Autorisation Si le service d'authentification certifie la combinaison de l'identifiant et des données d'authentification "secrètes", alors l'identité du sujet de sécurité est considérée comme authentifiée avec succès. Le système collecte ensuite des informations sur l'appartenance du sujet de sécurité (c'est-à-dire l'utilisateur) à des groupes. Il n'est pas rare qu'un utilisateur appartienne à plusieurs groupes bien définis - local (local), domaine (domaine local), global (global) et universel (universel) - à la suite des procédures normales d'affectation des membres. Le système vérifie les groupes locaux par rapport à la base de données SAM locale et vérifie les groupes locaux et globaux sur les contrôleurs de domaine dans le domaine d'accueil de l'utilisateur, ainsi que les groupes universels sur le contrôleur de domaine qui contient le catalogue global. Directement ou indirectement, le système collecte toutes les informations d'appartenance au groupe pour obtenir des informations sur les autorisations de sécurité.

Immédiatement après l'authentification, le système collecte les SID du compte et les appartenances aux groupes dans un objet appelé jeton d'accès. L'utilisateur devra peut-être se déconnecter et se reconnecter pour que les nouvelles autorisations de sécurité prennent effet. Si un utilisateur doit accéder à un objet (par exemple, un fichier, un dossier, une imprimante, une clé de registre) protégé par des autorisations NTFS, un processus (par exemple, l'Explorateur Windows) agissant en tant qu'utilisateur fournit son propre jeton d'accès. Chaque objet NTFS possède une liste d'entrées de contrôle d'accès (ACE), qui sont essentiellement des autorisations NTFS familières (par exemple, Autoriser la lecture, Autoriser l'écriture). L'ensemble des ACE attribuées aux utilisateurs et aux groupes constitue la liste de contrôle d'accès (ACL) d'un objet donné. Notamment, l'ACL d'un objet est représentée par des autorisations de sécurité, qui peuvent être consultées dans l'Explorateur Windows.

Un jeton d'accès contenant le compte et les groupes auxquels l'utilisateur est associé détermine les autorisations effectives de l'utilisateur. Le processus d'autorisation consiste à autoriser ou à refuser l'accès à un objet particulier en comparant le jeton d'accès à l'ACL de l'objet. L'autorisation est fournie par le moniteur de référence de sécurité Windows (Figure 1). Dans l'exemple illustré à la figure 1, l'utilisateur dispose des autorisations de lecture, d'écriture et de modification. Toutefois, le groupe Tout le monde auquel appartient l'utilisateur ne dispose pas de l'autorisation Modifier. Les membres d'autres groupes disposent des autorisations Lire et Modifier, mais l'autorisation Refuser du groupe Tout le monde remplace l'autorisation Modifier. L'objet a également des ACL qui refusent l'autorisation Contrôle total au groupe HR, mais l'utilisateur n'appartient pas à ce groupe. Ainsi, les autorisations effectives de l'utilisateur par rapport à l'objet sur écran 2- Lire et écrire.

Reporting (comptabilité). Si le mode audit est activé sous Windows, le système stocke l'événement d'authentification dans le journal de sécurité, et c'est le dernier composant du système de contrôle d'accès - le rapport. Les événements d'enregistrement initial et d'autorisation ultérieurs les plus complexes se produisent en quelques secondes et sont cachés à l'utilisateur. Toutes les opérations complexes sont affectées au protocole d'authentification.

Tâches de protocole

Un protocole d'authentification doit effectuer au moins deux tâches. Premièrement, il doit transmettre en toute sécurité les transactions du demandeur à la base de données d'authentification et à tout autre ordinateur hébergeant la ressource correspondante. Deuxièmement, il doit stocker le mot de passe ou le jeton en toute sécurité. Ce dernier est particulièrement intéressant pour les pirates de mots de passe. Le protocole d'authentification doit protéger les informations saisies par l'utilisateur lorsqu'elles sont transmises à la base de données d'authentification (c'est-à-dire SAM ou AD). Pour ce faire, le protocole signe, masque ou crypte la transaction. De plus, un horodatage lui est attribué afin qu'un attaquant ne puisse pas utiliser les informations d'identification à l'avenir. Afin d'éviter que le mot de passe de l'utilisateur ne soit immédiatement extrait de la base de données, le protocole doit s'assurer que les mots de passe sont cachés dans la base de données d'authentification.

Depuis plus d'une décennie, les protocoles d'authentification ont principalement assuré la sécurité en stockant les mots de passe sous une forme cachée (généralement hachée) dans la base de données d'authentification et en empêchant complètement le transfert des mots de passe entre le challenger et la base de données d'authentification en texte clair (même sous forme cachée) . Le processus de requête-réponse ressemble à ceci :

1. L'ordinateur reçoit les données d'identification et d'authentification de l'utilisateur et demande l'authentification au serveur approprié.
2. Le serveur d'authentification génère une valeur aléatoire aléatoire (appelée challenge) et l'envoie au challenger.
3. Le demandeur reçoit la demande et effectue des opérations mathématiques sur celle-ci et sur la forme cachée du mot de passe, puis transmet le résultat (appelé réponse) au serveur d'authentification.
4. Le serveur d'authentification effectue également des manipulations mathématiques sur la requête selon une méthode identique à celle utilisée sur le poste de travail et compare le résultat avec la réponse reçue. Si les résultats correspondent, le demandeur est considéré comme authentifié avec succès.

Les protocoles d'authentification utilisent un processus de défi-réponse, de sorte que le mot de passe n'est jamais transmis sur le réseau.

Enregistrement local et de domaine

Lors de l'enregistrement d'un utilisateur, l'une des premières tâches de Windows consiste à déterminer si la procédure s'applique uniquement à la machine locale ou à un compte de domaine. Les utilisateurs qui se connectent en tant que compte local n'ont accès qu'aux ressources de leur ordinateur et uniquement si les informations du compte utilisateur sont contenues dans la base de données SAM locale. Si les utilisateurs doivent accéder aux ressources sur un ordinateur distant sans s'authentifier auprès du domaine, leurs comptes doivent être dupliqués dans la base de données SAM locale de chaque ordinateur disponible. Les comptes de chaque machine membre doivent être synchronisés (mêmes identifiants, mots de passe et dates d'expiration des informations d'identification sur toutes les machines). Sinon, la situation devient beaucoup plus compliquée. Il est difficile de desservir des réseaux peer-to-peer (P2P) de taille moyenne qui n'utilisent que des procédures d'enregistrement locales.

Les contrôleurs de domaine ne sont pas soumis à l'obligation de synchroniser plusieurs comptes d'utilisateurs sur différents ordinateurs. Avec l'authentification de domaine, les ordinateurs enregistrés dans le domaine recherchent les contrôleurs de domaine pour présenter les informations d'identification du compte d'utilisateur du domaine pour les demandes d'authentification. Ainsi, si un utilisateur distant tente d'accéder à une ressource locale sur une machine, cette machine demande au DC de vérifier l'identité de l'utilisateur demandeur. Les comptes d'utilisateurs de domaine résident uniquement sur les contrôleurs de domaine et ne sont créés qu'une seule fois. Tout ordinateur membre qui doit authentifier un compte dans le domaine peut contacter les contrôleurs de domaine à tout moment. Il n'y a aucun problème de synchronisation des connexions, des mots de passe et des dates d'expiration car les informations d'identification et la gestion des comptes sont effectuées à un seul endroit - sur le DC. Quel que soit le type de connexion (local ou domaine), Windows doit authentifier la demande de l'utilisateur.

Protocoles d'authentification Windows

Comme indiqué ci-dessus, Windows utilise quatre principaux protocoles d'authentification : LAN Manager, NTLM, NTLMv2 et Kerberos. LAN Manager remonte à l'époque de DOS et a continué à être utilisé avec les premières versions de Windows. NTLM est sorti avec NT. NT Server 4.0 Service Pack 4 (SP4) était nouveau avec NTLMv2 et Windows 2000 a introduit Kerberos. Par défaut, tous les ordinateurs exécutant Windows 2000 et les systèmes d'exploitation plus récents sont compatibles avec les quatre protocoles d'authentification. En envoyant les commandes appropriées à ces systèmes, d'autres postes de travail et serveurs peuvent choisir le protocole pour traiter la demande d'authentification. Les systèmes Windows 9x et versions ultérieures avec l'ensemble complet de correctifs logiciels sont compatibles avec LM, NTLM et NTLMv2. Sur la plate-forme Microsoft, Kerberos ne peut être utilisé que par les clients Windows 2000 (ou versions ultérieures) lors de l'accès aux domaines Windows 2000 (et versions ultérieures). Un ordinateur exécutant Windows 2000 ou version ultérieure doit disposer de Kerberos et d'au moins un autre protocole d'authentification installé.

Les recherches sur la sécurité ont montré que les protocoles plus anciens (LM et NTLM) sont vulnérables aux attaques d'écoute clandestine et de devinette de mot de passe.

Gestionnaire de réseau local

IBM a développé le protocole LAN Manager et l'a appliqué aux premières versions des réseaux Windows et Windows. Comme tous les protocoles d'authentification Microsoft, LAN Manager génère un hachage de mot de passe (hachage LM) qui est stocké et utilisé par l'expéditeur et le destinataire au cours du processus d'authentification. LAN Manager génère des hachages LM en changeant toutes les lettres du mot de passe en majuscules, en divisant le mot de passe en deux moitiés de 7 caractères, puis en le cryptant. À l'avenir, le hachage LM est utilisé dans plusieurs opérations séquentielles, similaires au processus de demande-réponse décrit ci-dessus.

Si auparavant LAN Manager était tout à fait acceptable, il est maintenant considéré comme très peu fiable. À l'aide d'outils spéciaux, les mots de passe chiffrés avec le hachage LAN Manager peuvent être convertis en texte brut en quelques secondes seulement. Les hachages LM sont inhérents à des lacunes fondamentales, et il existe également un certain nombre de vulnérabilités :

• les mots de passe peuvent consister en une séquence limitée de 128 caractères ASCII ;
• la longueur du mot de passe ne dépasse pas 14 caractères ;
• si le mot de passe contient moins de 14 caractères, les caractères manquants sont remplacés par une forme hachée facile à deviner, ce qui vous permet de déterminer avec précision la longueur du mot de passe ;
• LAN Manager convertit tous les caractères alphabétiques du mot de passe en majuscules avant la mise en cache.

Pourquoi LAN Manager n'est-il pas encore hors d'usage ? Pour la rétrocompatibilité, il est activé par défaut sur tous les ordinateurs Windows, y compris Windows Server 2003. Dans les dernières bases de données d'authentification Windows, un hachage LM faible est stocké avec des hachages plus forts au cas où une transaction LAN Manager devrait être effectuée. Si votre entreprise n'utilise pas d'autres applications nécessitant une authentification LAN Manager, vous pouvez (et devriez) désactiver LAN Manager.

NTLM

Avec l'avènement de NT, Microsoft a conçu et déployé le protocole d'authentification NTLM plus sécurisé. NTLM utilise un algorithme d'authentification plus efficace qui crée un hachage de mot de passe plus fort (hachage NTLM). Le mot de passe NTLM peut comporter jusqu'à 128 caractères. Contrairement au hachage LAN Manager, qui se limite à utiliser uniquement des caractères ASCII, NTLM est compatible avec le jeu de caractères Unicode complet, ce qui augmente la complexité des mots de passe. Le hachage NTLM est tronqué au caractère 128, converti en une valeur Unicode 16 bits, traité par une fonction d'allocation MD4 et stocké dans une chaîne hexadécimale de 32 caractères. En raison de l'utilisation d'un hachage NTLM dans les opérations de défi-réponse, la séquence d'authentification NTLM est beaucoup plus complexe que la procédure LAN Manager.

NTLMv2

En conséquence, il s'est avéré que NTLM était également vulnérable et les spécialistes de Microsoft ont préparé NTLMv2, qui est toujours considéré comme assez fiable, bien que Kerberos soit désormais le protocole préféré. NTLMv2 est encore largement utilisé pour la journalisation locale et dans certains autres cas. NTLMv2 est similaire à NTLM, mais le hachage de mot de passe NTLMv2 utilise l'authentification de message HMAC-MD5 et la séquence défi-réponse est horodatée pour empêcher les attaques dans lesquelles un attaquant enregistre les informations d'identification, puis les utilise.

En général, NTLMv2 est plus résistant aux attaques par force brute que NTLM car le protocole utilise une clé de chiffrement de 128 bits. Seuls deux craqueurs de mots de passe (dont l'un est le LC5 de Symantec) sont connus pour avoir été capables de craquer les hachages de mots de passe NTLMv2.

KerberosName

Microsoft a adopté Kerberos comme protocole d'authentification de domaine par défaut pour les domaines Windows 2000 et AD ultérieurs. Kerberos est une norme ouverte adaptée à l'interaction avec des domaines étrangers (appelés domaines sous UNIX et Linux). Chaque DC dans les domaines AD joue le rôle d'un serveur de distribution (Kerberos Distribution Server, KDC) et peut participer à la procédure d'authentification. La sécurité est renforcée par les fonctionnalités suivantes de Kerberos :

• authentification mutuelle entre client et serveur ;
• une protection renforcée par mot de passe, puisque Windows envoie le mot de passe uniquement lors de l'accès initial, et non à chaque événement d'authentification, et que toutes les sessions de communication sont cryptées ;
• une séquence challenge-réponse avec un horodatage empêche un attaquant d'utiliser un mot de passe intercepté après un certain temps ;
• un processus serveur peut accéder à une ressource distante pour le compte d'un utilisateur ;
• interopérabilité.

Brève description du fonctionnement de Kerberos :

1. Une fois l'authentification de base réussie, l'ordinateur de l'utilisateur demande un ticket de sécurité au serveur Kerberos (DC) pour les futures demandes d'authentification.
2. Le serveur Kerberos envoie un ticket au demandeur pour qu'il participe aux futurs événements d'authentification et d'autorisation sans suggérer à nouveau les informations d'identification d'origine.
3. Lorsqu'un demandeur doit accéder à une ressource de serveur membre, il obtient un autre ticket d'accès du serveur Kerberos et le présente au serveur de ressources pour validation.
4. Les identifiants d'authentification initiaux ne sont transmis sur les canaux du réseau dans aucune des sessions d'authentification suivantes (jusqu'à ce que le ticket émis à l'étape 2 expire).

Notez que bien que Kerberos fonctionne comme une infrastructure à clé publique (PKI), toutes les informations sont protégées à l'aide de clés symétriques (par opposition aux clés asymétriques utilisées dans la plupart des services d'authentification).

Carte à puce

La force des mots de passe et autres méthodes d'authentification à paramètre unique décline rapidement. Le commerce électronique fait son chemin dans la vie quotidienne et les moyens de vol d'identité (spam, escroqueries d'URL) et la possibilité d'abus de mots de passe sont en augmentation. De nombreux experts pensent que l'authentification à deux paramètres - sous la forme de cartes à puce, de périphériques USB ou d'autres périphériques cryptographiques - deviendra monnaie courante pour les transactions sur Internet à l'avenir. Les développeurs Microsoft intègrent des fonctionnalités de certificat numérique et de carte à puce dans leurs solutions. Pour utiliser des cartes à puce, vous devez installer les services de certificats et distribuer des certificats de carte à puce. Bien sûr, vous avez également besoin de cartes à puce physiques, de lecteurs et de logiciels de fournisseurs. Les utilisateurs peuvent ensuite éventuellement insérer leurs cartes à puce dans des lecteurs locaux pour accéder à l'ordinateur Windows. Lorsqu'elles sont utilisées correctement, les cartes à puce peuvent augmenter considérablement la force de l'authentification.

Sécurité du protocole d'authentification

Certains articles prétendent à tort qu'il est encore facile de déchiffrer le mécanisme d'authentification de Microsoft. En fait, sur les 20 outils de piratage de mots de passe existants, seuls deux fonctionnent avec NTLMv2 et un seul avec Kerberos. Mais en prenant quelques mesures simples, cette menace peut également être conjurée. Pour éviter les tentatives de devinettes et les réinitialisations de mot de passe, procédez comme suit (la plupart des paramètres peuvent être configurés localement ou via la stratégie de groupe).

• Désactivez le stockage des hachages LM comme décrit dans l'article Microsoft "Comment empêcher Windows de stocker un hachage LAN manager de votre mot de passe dans Active Directory et les bases de données SAM locales" ( http://support.microsoft.com/default.aspx?scid=kb;en-us;299656). Ceci est fait afin d'empêcher les pirates d'ouvrir le mot de passe d'origine.
• Désactivez tous les protocoles d'authentification à l'exception de NTLMv2 et Kerberos (après des tests approfondis). La procédure est décrite dans l'article Microsoft TechNet « Sécurité réseau : niveau d'authentification LAN Manager » ().
• Désactivez le démarrage à partir d'un support amovible pour empêcher les outils de craquage de mot de passe de s'exécuter en contournant le système d'exploitation. La désactivation du démarrage à partir de tous les lecteurs sauf du lecteur par défaut empêche les pirates de mot de passe hors ligne d'accéder à la base de données d'authentification dans laquelle les hachages de mot de passe sont stockés.
• Les utilisateurs doivent attribuer des mots de passe complexes d'au moins 8 caractères.
• Les utilisateurs doivent changer leurs mots de passe au moins tous les trimestres.
• Activez le verrouillage du compte pendant au moins une minute avec réinitialisation automatique. Cela empêche de deviner les mots de passe sur le réseau.

Responsabilités de l'utilisateur

Avec NTLMv2, Kerberos et les cartes à puce, Windows fournit des mécanismes d'authentification puissants qui résistent aux écoutes clandestines et aux attaques par force brute. Mais les meilleures pratiques et les protocoles d'authentification forts ne seront d'aucune utilité si les utilisateurs attribuent des mots de passe faibles. Il est nécessaire d'apprendre aux utilisateurs à choisir correctement les mots de passe et à s'assurer que les mots de passe sont complexes et forts.

Roger Grimes- Editeur Windows IT Pro et consultant en sécurité. Certifié par CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE : Sécurité et Sécurité+.

11/02/2011 Jean de Klerk

Bien entendu, tout administrateur Windows a dû gérer plus d'une fois les deux principaux protocoles d'authentification de l'environnement Windows : Kerberos et NTLM. Cet article se concentre sur la prise en charge de Kerberos et NTLM sur les systèmes Windows 7 et Windows Server 2008 R2. Mais d'abord, je voudrais souligner les principales différences entre ces protocoles.

Les développeurs Microsoft ont d'abord implémenté le protocole Kerberos dans Windows 2000. Le protocole NTLM a été utilisé bien plus tôt, à l'époque de Windows NT. Kerberos est un protocole d'authentification basé sur le concept de tiers de confiance (TTP), tandis que NTLM est basé sur un mécanisme de défi/réponse. Les différences entre les deux protocoles sont décrites plus en détail dans le tableau.

Lors de la communication pendant l'authentification NTLM, une ressource serveur (par exemple, un serveur de fichiers) génère une demande qui est envoyée au client. Le client génère une réponse NTLM qui inclut le hachage du mot de passe de l'utilisateur et le serveur vérifie que la réponse est correcte. Si le client utilise un compte local, le serveur valide la réponse de l'utilisateur par rapport au hachage du mot de passe de l'utilisateur, qui est stocké dans la base de données locale du gestionnaire de comptes de sécurité (SAM). Si le client utilise un compte de domaine, le serveur transmet la réponse au contrôleur de domaine pour vérification, car seuls les contrôleurs de domaine stockent des copies des hachages de mot de passe utilisateur dans leurs bases de données Active Directory (AD).

Dans Windows Kerberos, le tiers de confiance est un contrôleur de domaine Windows 2000 ou version ultérieure qui héberge le service Kerberos Key Distribution Center (KDC). Le KDC facilite l'authentification entre un client et un serveur compatibles Kerberos. Le service KDC est automatiquement installé en tant que composant du système AD et se compose de deux sous-systèmes : le service d'authentification (AS) et le service d'octroi de tickets (TGS).

Lorsqu'un utilisateur se connecte à un domaine Windows à l'aide du protocole Kerberos, le client Windows authentifie d'abord l'utilisateur auprès du contrôleur de domaine à l'aide du mot de passe de l'utilisateur. Dans le même temps, le client demande un Ticket Grant Ticket (TGT) au service d'authentification. Le TGT peut être considéré comme un mot de passe temporaire (par défaut, sa durée de vie est de 8 heures) qui remplacera le mot de passe de l'utilisateur dans les demandes d'authentification ultérieures. Lorsqu'un utilisateur a besoin d'accéder à une ressource serveur, le client présentera un TGT pour émettre un TGT pour s'authentifier auprès de la ressource serveur. Sachez que, contrairement à NTLM, le protocole Kerberos n'est pas utilisé pour l'authentification locale avec le gestionnaire de comptes de sécurité Windows ; sa portée est limitée à l'authentification de domaine sur un contrôleur de domaine.

Kerberos est le protocole d'authentification standard de Windows 2000 et des versions plus récentes de Microsoft. Sur ces systèmes d'exploitation, le protocole d'authentification est défini à l'aide d'un mécanisme de négociation. Si le protocole Kerberos par défaut n'est pas adapté ou pris en charge par l'un des composants client ou serveur impliqués dans l'authentification, Windows revient à l'utilisation de NTLM.

Pourquoi Kerberos ?

Kerberos est plus efficace que NTLM pour plusieurs raisons. Lors de l'utilisation du protocole Kerberos, le hachage du mot de passe de l'utilisateur est exposé beaucoup moins fréquemment que lors de l'utilisation de NTLM. Le hachage du mot de passe n'est exposé que lorsque l'utilisateur demande le TGT - en fait, une fois toutes les huit heures. D'autre part, avec NTLM, le hachage du mot de passe est exposé chaque fois que le client utilise NTLM pour s'authentifier auprès du serveur. Il s'agit d'un avantage important du protocole Kerberos par rapport au protocole NTLM ; le fait est qu'il existe des outils spéciaux qui vérifient le trafic réseau pour la présence de hachages de mots de passe. Ces outils capturent les hachages découverts et les utilisent pour récupérer les mots de passe des utilisateurs à l'aide d'une méthode de force brute.

Un autre avantage de Kerberos est qu'il utilise des horodatages pour se protéger contre les attaques par relecture. C'est pourquoi il est si important d'avoir un service de synchronisation de l'heure qui fonctionne parfaitement dans un environnement Windows centré sur Kerberos. Dans Windows 2000 et les versions plus récentes du système, les services de temps fonctionnent sans configuration préalable. Si les horloges d'ordinateurs sur différents ordinateurs ne sont pas synchronisées, cela peut entraîner un trafic supplémentaire dans le processus d'authentification Kerberos ou, dans le pire des cas, cette situation peut entraîner une erreur dans le processus d'authentification.

En plus de ce qui précède, le protocole Kerberos implémente des fonctionnalités d'authentification avancées telles que l'authentification mutuelle et la délégation d'authentification. L'authentification mutuelle signifie que l'utilisateur et le service s'authentifient mutuellement, tandis que NTLM est limité à l'authentification de l'utilisateur. Sans cette fonctionnalité, il peut y avoir des situations où les utilisateurs fournissent leurs informations d'identification à un faux serveur.

Un service peut accéder à des ressources distantes pour le compte d'un utilisateur à l'aide d'un mécanisme de délégation d'authentification. En d'autres termes, l'utilisateur peut accorder au système intermédiaire le droit de s'authentifier (l'utilisateur) sur le serveur d'application pour son propre compte. Par conséquent, le serveur d'application est capable de prendre des décisions d'autorisation non basées sur l'identité du système mandataire, mais sur la base de l'identité de l'utilisateur. La fonction de délégation d'authentification est très utile dans les applications multiniveaux telles que l'accès aux bases de données à l'aide d'un frontal Web.

Enfin, il faut dire que bien que Microsoft ait beaucoup travaillé sur la modernisation du protocole NTLM, à savoir la création d'une version de NTLMv2 prise en charge dans NT4 SP4 et les versions plus récentes, des algorithmes de chiffrement plus modernes sont implémentés dans le produit Microsoft Kerberos. J'en parlerai plus en détail dans la section sur les outils de chiffrement du protocole Kerberos.

Limites du protocole NTLM

Les avantages de l'authentification à l'aide du protocole Kerberos ne font aucun doute. Mais même dans un environnement AD Server 2008, Windows utilise souvent NTLM, par exemple lorsque vous vous connectez à un système Windows antérieur à Windows 2000 ou lorsque vous vous connectez à une ressource partagée à l'aide de la commande net use et d'une adresse IP (plutôt qu'un nom NetBIOS ). De plus, les applications qui n'ont pas de noms principaux de service (SPN) correctement configurés continueront d'utiliser NTLM.

Pour savoir quel protocole - NTLM ou Kerberos - vous utilisez actuellement, vous pouvez visualiser le trafic NTLM à l'aide de l'utilitaire netmon ou d'un autre traceur de réseau ; Une alternative consiste à vérifier le contenu du cache de tickets Kerberos à l'aide de l'outil klist (inclus avec Windows 7 et Server 2008). Dans Windows 7 et Server 2008, Microsoft a implémenté de nouvelles stratégies de groupe qui peuvent être utilisées pour surveiller et bloquer l'utilisation du protocole NTLM par vos utilisateurs et applications. Il existe trois stratégies de ce type au total : une pour le trafic NTLM entrant (pour la surveillance et le blocage au niveau du serveur), une autre pour le trafic NTLM sortant (pour la surveillance et le blocage au niveau du client) et la troisième pour le trafic de domaine (pour la surveillance et le blocage). blocage au niveau du contrôleur de domaine). Ils sont situés dans le conteneur d'objets de stratégie de groupe (CPO) des options de sécurité, accessible en sélectionnant successivement Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies locales (voir Figure 1). Ils commencent tous par Sécurité réseau : Restreindre NTLM :.

Chaque paramètre de stratégie possède des options d'audit et de blocage. Lorsque vous activez la fonction d'audit NTLM, le programme crée des entrées de journal des événements avec les données NTLM d'origine et les numéros 8001, 8002, 8003 et 8004. Les entrées de journal sont stockées dans le conteneur Opérationnel avec le chemin d'accès Observateur d'événements (local), Applications Et journaux de services, Microsoft, Windows, NTLM. Je vous recommande de commencer par auditer NTLM dans un environnement de test et de vous assurer que toutes vos applications y sont correctement représentées. Si vous commencez à bloquer arbitrairement l'utilisation du protocole, il est fort probable que certaines applications ne fonctionneront pas. Pour éviter la perte d'événements, vous devez installer une solution de collecte d'événements d'audit avant de commencer à tester les outils d'audit NTLM ; Vous pouvez utiliser le collecteur d'événements Windows intégré, les abonnements aux événements ou une solution tierce. De plus, je vous recommande de commencer par surveiller NTLM sur vos serveurs. Vous pouvez connecter des clients pour une analyse détaillée une fois qu'il devient clair que le serveur utilise le protocole NTLM. Une fois que vous comprenez quelles applications utilisent NTLM, vous pouvez développer une stratégie de blocage NTLM. Cette stratégie peut inclure une politique d'exclusion pour les applications héritées qui ne peuvent pas être réécrites ou reconfigurées et nécessiteront toujours l'utilisation de NTLM.

Malheureusement, les paramètres NTLM mentionnés ne peuvent pas être appliqués sur les anciens systèmes Windows. Cependant, ces systèmes permettent la gestion des versions du protocole NTLM. Vous pouvez, par exemple, désactiver l'extrait de code LM du protocole d'authentification NTLM (puisque cet extrait est intrinsèquement faible) ou appliquer NTLMv2. Pour ce faire, utilisez le paramètre GPO Network Security: LAN Manager Authentication Level, qui se trouve dans le conteneur GPO Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité (voir Figure 2).

Outils de chiffrement Kerberos

Les protocoles cryptographiques utilisés par les protocoles d'authentification jouent un rôle important dans la sécurisation de ces derniers. Comme je l'ai déjà noté, dans ce domaine, les performances de Kerberos sont supérieures à celles du protocole NTLM. L'algorithme de chiffrement RC4 a été implémenté pour la première fois dans le protocole Windows Kerberos sous Windows 2000 et est toujours pris en charge sur les systèmes Server 2008 ainsi que Windows 7 (plus précisément, sa version RC4_HMAC_MD5 est prise en charge). Dans Server 2008, Windows Vista et versions ultérieures, Microsoft a ajouté la prise en charge de Advanced Encryption Standard, le cryptage AES, tandis que Windows 7 et Server 2008 R2 prennent en charge les types de cryptage Kerberos AES (AES128_HMAC_SHA1 et AES256_HMAC_SHA1) prêts à l'emploi. AES est un algorithme de chiffrement plus récent et plus puissant que DES. La logique Kerberos sur les contrôleurs de domaine migre vers la norme de chiffrement AES lorsque vous mettez à niveau votre domaine AD vers le niveau fonctionnel de domaine Windows 2008 (DFL).

Sur les systèmes Windows 7 et Server 2008 R2, les types de chiffrement DES pour le protocole d'authentification Kerberos sont désactivés par défaut. Cela peut entraîner des problèmes de compatibilité si l'une des applications héritées est codée en dur avec le chiffrement DES uniquement, ou si le compte Windows exécutant un service particulier (le compte de service) est configuré pour utiliser le chiffrement DES uniquement. Ces services ou applications échoueront si vous ne pouvez pas reconfigurer le service ou l'application correspondant pour prendre en charge un autre type de chiffrement (RC4 ou AES) ou restaurer la prise en charge de la norme DES.

Pour savoir si vous avez des applications ou des services codés pour le chiffrement DES uniquement, vous pouvez exécuter un traceur de réseau au démarrage de l'application ou du service correspondant et vérifier le contenu des champs Etype dans les en-têtes d'authentification Kerberos. Pour déterminer si un utilisateur ou un compte d'ordinateur AD ou un compte d'ordinateur est configuré pour utiliser uniquement les types de chiffrement DES, vérifiez si Utiliser les types de chiffrement Kerberos DES pour ce compte est sélectionné dans l'onglet Compte des propriétés de l'objet. Ces propriétés sont accessibles à partir du composant logiciel enfichable MMC Utilisateurs et ordinateurs AD.

Si vous effectuez les vérifications mentionnées ci-dessus et constatez que vous rencontrez ce problème, vous pouvez activer le chiffrement DES pour l'authentification Kerberos sur les ordinateurs exécutant Windows 7 ou Server 2008 R2 à l'aide du paramètre de sécurité réseau GPO : configurez les types de chiffrement compatibles avec la norme Kerberos ; ces paramètres se trouvent dans le conteneur GPO Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies locales, Options de sécurité.

Ainsi, des deux protocoles d'authentification Windows, Kerberos est le préféré. Les administrateurs doivent toujours insister pour que les utilisateurs et les applications utilisent Kerberos et non NTLM. Les nouvelles restrictions d'utilisation de NTLM introduites dans Windows 7 et Server 2008 R2 nous offrent une excellente occasion d'atteindre cet objectif.

Jean de Clerc [courriel protégé]) est un employé du bureau de sécurité de HP. Spécialisé dans la gestion des identités et de la sécurité dans les produits Microsoft

Authentification sur les systèmes Windows Server 2008 R2 et Windows 7

Question/réponse Windows NT. Avec l'authentification Windows intégrée, le navigateur client s'authentifie auprès du serveur via une communication cryptographique.

L'authentification intégrée de Windows prend en charge à la fois le protocole Kerberos v5 et le protocole NTLM (NT LAN Manager) pour l'authentification via le package Negotiate. Si Active Directory est présent et que la prise en charge du navigateur est appropriée (IE 5 ou supérieur sur une plate-forme Windows 2000), le protocole Kerberos est utilisé, sinon le protocole NTLM est utilisé. Kerberos et NTLM ont tous deux certaines limitations. Un fait intéressant est que les avantages de l'un correspondent aux faiblesses de l'autre. Kerberos fonctionne généralement avec des serveurs proxy, mais il n'est pas aussi efficace avec les pare-feu. NTLM fonctionne généralement à travers des pare-feu, mais interagit plutôt médiocrement avec les serveurs proxy.

Quelques mots sur Microsoft Negotiate

Microsoft Negotiate est un package qui fournit une interface entre différents fournisseurs de support de sécurité. Il peut choisir entre différents packages d'authentification. IIS utilise le package Negotiate pour l'authentification, auquel cas il choisit le protocole Kerberos ou le protocole NTLM. Ce package ajoute également la prise en charge des futurs packages d'authentification, ce qui est un avantage de Negotiate . Par défaut, Negotiate sélectionne Kerberos comme protocole le plus sécurisé. Si, pour une raison quelconque, le protocole Kerberos n'est pas disponible, Negotiate revient à l'utilisation de NTLM .

Authentification NTLM

NTLM est une version étendue de l'ancien protocole d'authentification LM (LAN Manager). NTLM fonctionne par questions/réponses entre le serveur et le client sans envoyer le mot de passe de l'utilisateur sur le réseau en clair. Le client doit confirmer qu'il connaît le mot de passe de l'utilisateur en envoyant un hachage chiffré.

NTLM fonctionne de la manière suivante.

1. L'utilisateur spécifie un nom d'utilisateur, un mot de passe et un nom de domaine lors de la connexion à l'ordinateur client.
2. Le client génère un hachage du mot de passe donné et supprime l'original.
3. Le client envoie le nom d'utilisateur en texte clair au serveur.
4. Le serveur envoie une donnée aléatoire de 16 bits au client.
5. Le client chiffre ce fragment, ainsi que le hash du mot de passe de l'utilisateur, et les transmet au serveur.
6. Le serveur envoie le nom d'utilisateur, une donnée aléatoire et la réponse du client au contrôleur de domaine.
7. Le contrôleur de domaine crypte une donnée aléatoire avec son propre hachage du mot de passe de l'utilisateur, puis les compare avec les éléments envoyés par le serveur.
8. Si les valeurs correspondent, le contrôleur de domaine informe le serveur que l'authentification a réussi.
9. Si les valeurs ou le nom d'utilisateur ne correspondent pas, le contrôleur de domaine avertit le serveur, qui envoie le message approprié au client. Le navigateur client invite alors l'utilisateur données d'authentification.

Authentification Kerberos

Dans la mythologie grecque antique, Kerberos est un fabuleux chien à trois têtes qui protégeait le monde souterrain des gens. Actuellement, le terme Kerberos fait référence à un protocole d'authentification sécurisé pour accéder aux ressources. Kerberos est basé sur l'authentification par clé secrète, dans laquelle le client et le serveur utilisent la même clé pour le chiffrement et le déchiffrement. Le client prouve la connaissance de la clé en chiffrant le message, et le serveur prouve la connaissance de la clé en déchiffrant le message. Le serveur prend alors une partie du message, le chiffre et l'envoie au client. Tout en maintenant l'intégrité du message, le résultat de l'authentification sera positif.

Le fonctionnement de Kerberos repose sur un serveur central appelé Key Distribution Center ( KDC ) ( Centre de distribution de clés) qui fournit toutes les clés nécessaires. Le KDC émet des TGT (Ticket-Granting Tickets) et les fournit aux clients qui demandent l'accès à une ressource sur le serveur.

Ce qui suit montre le processus pour qu'un client reçoive un billet TGT initial.

1. L'utilisateur se connecte à l'ordinateur client avec un nom d'utilisateur et un mot de passe.
2. Le client crypte le mot de passe et le stocke.
3. Le client envoie un message au KDC demandant des données d'authentification pour le service TGT, ainsi que le mot de passe chiffré de l'utilisateur.
4. Le KDC compare le mot de passe crypté avec sa copie principale pour vérifier leur identité. Il vérifie également l'horodatage joint par le client à la demande pour s'assurer que l'horodatage spécifié est inférieur à cinq minutes par rapport à l'heure du KDC.
5. S'il y a une correspondance complète, le KDC crée le données d'authentification pour le service TGT en générant clé de session connectez-vous et cryptez-le avec une clé personnalisée.
6. KDC crée un autre fragment données d'authentification par cryptage clé de session login et user TGT avec leur propre master key.
7. KDC envoie les deux fragments données d'authentification client.
8. Le client déchiffre la clé de session de connexion du premier segment données d'authentification avec un mot de passe crypté et stocke cette clé de connexion de session dans son cache de tickets.
9. Le client stocke également le TGT dans son cache de tickets.

Le client dispose désormais d'un TGT et peut l'utiliser pour obtenir des tickets d'accès aux ressources. Voici comment ça se passe.

1. Le client demande un ticket au KDC pour accéder aux ressources sur le serveur. Le client présente son TGT au KDC avec le nom de ressource souhaité et un message d'authentification chiffré dans la clé de connexion de session.