Partager via

Authentification utilisateur NTLM

  • Article

Cet article fournit des informations sur l’authentification utilisateur NTLM.

Numéro de base de connaissances d’origine : 102716

Résumé

Cet article décrit les aspects suivants de l’authentification utilisateur NTLM dans Windows :

  • Stockage de mot de passe dans la base de données des comptes
  • Authentification utilisateur à l’aide du package d’authentification MSV1_0
  • Authentification directe

Plus d’informations

Stockage de mot de passe dans la base de données des comptes

Les enregistrements utilisateur sont stockés dans la base de données SAM (Security Accounts Manager) ou dans la base de données Active Directory. Chaque compte d’utilisateur est associé à deux mots de passe : le mot de passe compatible avec le Gestionnaire de réseau local et le mot de passe Windows. Chaque mot de passe est chiffré et stocké dans la base de données SAM ou dans la base de données Active Directory.

Le mot de passe compatible LAN Manager est compatible avec le mot de passe utilisé par le gestionnaire de réseau local. Ce mot de passe est basé sur le jeu de caractères fabricant d’équipement d’origine (OEM). Ce mot de passe n’est pas sensible à la casse et peut comporter jusqu’à 14 caractères. La version OWF de ce mot de passe est également connue sous le nom de version OWF du Gestionnaire de réseau local ou ESTD. Ce mot de passe est calculé à l’aide du chiffrement DES pour chiffrer une constante avec le mot de passe de texte clair. Le mot de passe OWF du Gestionnaire de réseau local est de 16 octets. Les 7 premiers octets du mot de passe de texte clair sont utilisés pour calculer les 8 premiers octets du mot de passe OWF du Gestionnaire de réseau local. Les 7 deuxièmes octets du mot de passe de texte clair sont utilisés pour ordinateurr les 8 deuxièmes octets du mot de passe OWF du Gestionnaire de réseau local.

Le mot de passe Windows est basé sur le jeu de caractères Unicode. Ce mot de passe respecte la casse et peut comporter jusqu’à 128 caractères. La version OWF de ce mot de passe est également appelée mot de passe OWF Windows. Ce mot de passe est calculé à l’aide de la fonction de hachage RSA MD4. Cette fonction calcule une synthèse de 16 octets d’une chaîne de longueur variable d’octets de mot de passe de texte clair.

Tout compte d’utilisateur peut ne pas avoir le mot de passe du Gestionnaire de réseau local ou le mot de passe Windows. Toutefois, chaque tentative est effectuée pour conserver les deux versions du mot de passe.

Par exemple, si le compte d’utilisateur est porté à partir d’une base de données UAS LAN Manager à l’aide de PortUas, ou si le mot de passe est modifié à partir d’un client LAN Manager ou d’un client Windows for Workgroups, seule la version du gestionnaire de réseau local du mot de passe existe. Si le mot de passe est défini ou modifié sur un client Windows et que le mot de passe n’a aucune représentation du Gestionnaire de réseau local, seule la version Windows du mot de passe existe. (Le mot de passe peut ne pas avoir de représentation du Gestionnaire de réseau local, car le mot de passe est supérieur à 14 caractères ou parce que les caractères ne peuvent pas être représentés dans le jeu de caractères OEM.)

Les limites d’interface utilisateur dans Windows ne permettent pas aux mots de passe Windows de dépasser 14 caractères. Les implications de cette limitation sont abordées plus loin dans cet article.

Dans Windows 2000 Service Pack 2 et dans les versions ultérieures de Windows, un paramètre est disponible qui vous permet d’empêcher Windows de stocker un hachage du Gestionnaire de réseau local de votre mot de passe. Pour plus d’informations, consultez le numéro d’article suivant pour afficher l’article dans la Base de connaissances Microsoft :

299656 Comment empêcher Windows de stocker un hachage du gestionnaire LAN de votre mot de passe dans Active Directory et les bases de données SAM locales

Note

Microsoft ne prend pas en charge manuellement ou par programmation la modification de la base de données SAM.

Authentification utilisateur à l’aide du package d’authentification MSV1_0

Windows utilise l’API LsaLogonUser pour toutes sortes d’authentifications utilisateur. L’API LsaLogonUser authentifie les utilisateurs en appelant un package d’authentification. Par défaut, LsaLogonUser appelle le package d’authentification MSV1_0 (MSV). Ce package est inclus dans Windows NT. Le package d’authentification MSV stocke les enregistrements utilisateur dans la base de données SAM. Ce package prend en charge l’authentification directe des utilisateurs dans d’autres domaines à l’aide du service Netlogon.

En interne, le package d’authentification MSV est divisé en deux parties. La première partie du package d’authentification MSV s’exécute sur l’ordinateur auquel il est connecté. La deuxième partie s’exécute sur l’ordinateur qui contient le compte d’utilisateur. Lorsque les deux parties s’exécutent sur le même ordinateur, la première partie du package d’authentification MSV appelle la deuxième partie sans impliquer le service Netlogon. La première partie du package d’authentification MSV reconnaît que l’authentification directe est requise, car le nom de domaine passé n’est pas son propre nom de domaine. Lorsque l’authentification directe est requise, MSV transmet la demande au service Netlogon. Le service Netlogon achemine ensuite la requête vers le service Netlogon sur l’ordinateur de destination. À son tour, le service Netlogon transmet la demande à l’autre partie du package d’authentification MSV sur cet ordinateur.

LsaLogonUser prend en charge les journaux interactifs, les journaux de service et les journaux réseau. Dans le package d’authentification MSV, toutes les formes d’ouverture de session passent le nom du compte d’utilisateur, le nom du domaine qui contient le compte d’utilisateur et une fonction du mot de passe de l’utilisateur. Les différents types d’ouverture de session représentent le mot de passe différemment lorsqu’ils le transmettent à LsaLogonUser.

Pour les journaux interactifs, les journaux de traitement par lots et les journaux de service, le client d’ouverture de session se trouve sur l’ordinateur exécutant la première partie du package d’authentification MSV. Dans ce cas, le mot de passe en texte clair est transmis à LsaLogonUser et à la première partie du package d’authentification MSV. Pour les journaux de service et les journaux de traitement par lots, le Gestionnaire de contrôle de service et le Planificateur de tâches offrent un moyen plus sécurisé de stocker les informations d’identification du compte.

La première partie du package d’authentification MSV convertit le mot de passe en texte clair à la fois en mot de passe OWF du Gestionnaire de réseau local et en mot de passe OWF Windows NT. Ensuite, la première partie du package transmet le mot de passe en texte clair au service NetLogon ou à la deuxième partie du package. La deuxième partie interroge ensuite la base de données SAM pour les mots de passe OWF et vérifie qu’elles sont identiques.

Pour les connexions réseau, le client qui se connecte à l’ordinateur a déjà reçu un défi de 16 octets ou « nonce ». Si le client est un client LAN Manager, le client a calculé une réponse de défi de 24 octets en chiffrant le défi de 16 octets avec le mot de passe OWF du Gestionnaire de 16 octets. Le client LAN Manager transmet ensuite cette « réponse au défi du gestionnaire LAN » au serveur. Si le client est un client Windows, une « réponse aux défis Windows NT » est calculée à l’aide du même algorithme. Toutefois, le client Windows utilise les données OWF Windows de 16 octets au lieu des données OWF du Gestionnaire de réseau local. Le client Windows transmet ensuite à la fois la réponse du défi du gestionnaire LAN et la réponse du défi Windows NT au serveur. Dans les deux cas, le serveur authentifie l’utilisateur en transmettant tous les éléments suivants à l’API LsaLogonUser :

  • Nom de domaine
  • Nom de l’utilisateur
  • Le défi original
  • Réponse au défi du gestionnaire LAN
  • Réponse facultative du défi Windows NT

La première partie du package d’authentification MSV transmet ces informations inchangées à la deuxième partie. Tout d’abord, la deuxième partie interroge les mots de passe OWF à partir de la base de données SAM ou de la base de données Active Directory. Ensuite, la deuxième partie calcule la réponse au défi à l’aide du mot de passe OWF de la base de données et du défi passé. La deuxième partie compare ensuite la réponse de défi calculée à la réponse de défi passée.

Note

NTLMv2 permet également au client d’envoyer un défi avec l’utilisation de clés de session qui contribuent à réduire le risque d’attaques courantes.

Comme mentionné précédemment, une version du mot de passe peut être manquante à partir de la base de données SAM ou de la base de données Active Directory. En outre, l’une ou l’autre version du mot de passe peut être manquante dans l’appel à LsaLogonUser. Si la version Windows du mot de passe de la base de données SAM et la version Windows du mot de passe de LsaLogonUser sont disponibles, elles sont utilisées. Sinon, la version du Gestionnaire de réseau local du mot de passe est utilisée pour la comparaison. Cette règle permet d’appliquer la sensibilité de la casse lorsque les connexions réseau se produisent de Windows à Windows. Cette règle autorise également la compatibilité descendante.

Authentification directe

Le service NetLogon implémente l’authentification directe. Il exécute les fonctions suivantes :

  • Sélectionne le domaine auquel passer la demande d’authentification.
  • Sélectionne le serveur dans le domaine.
  • Transmet la demande d’authentification au serveur sélectionné.

La sélection du domaine est simple. Le nom de domaine est passé à LsaLogonUser. Le nom de domaine est traité comme suit :

  • Si le nom de domaine correspond au nom de la base de données SAM, l’authentification est traitée sur cet ordinateur. Sur une station de travail Windows membre d’un domaine, le nom de la base de données SAM est considéré comme le nom de l’ordinateur. Sur un contrôleur de domaine Active Directory, le nom de la base de données de compte est le nom du domaine. Sur un ordinateur qui n’est pas membre d’un domaine, tous les journaux traitent les demandes localement.
  • Si le nom de domaine spécifié est approuvé par ce domaine, la demande d’authentification est transmise au domaine approuvé. Sur les contrôleurs de domaine Active Directory, la liste des domaines approuvés est facilement disponible. Sur un membre d’un domaine Windows, la requête est toujours transmise au domaine principal de la station de travail, ce qui permet au domaine principal de déterminer si le domaine spécifié est approuvé.
  • Si le nom de domaine spécifié n’est pas approuvé par le domaine, la demande d’authentification est traitée sur l’ordinateur connecté comme si le nom de domaine spécifié était ce nom de domaine. NetLogon ne distingue pas un domaine inexistant, un domaine non approuvé et un nom de domaine mal typé.

NetLogon sélectionne un serveur dans le domaine par un processus appelé découverte. Une station de travail Windows découvre le nom de l’un des contrôleurs de domaine Windows Active Directory dans son domaine principal. Un contrôleur de domaine Active Directory découvre le nom d’un contrôleur de domaine Active Directory dans chaque domaine approuvé. Le composant qui effectue la découverte est le localisateur de contrôleurs de domaine qui s’exécute dans le service Netlogon. Le localisateur de contrôleur de domaine utilise NETBIOS ou la résolution de noms DNS pour localiser les serveurs nécessaires, en fonction du type de domaine et d’approbation configuré.