Authentification utilisateur NTLM

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

S’applique à : Windows Server 2012 R2
Numéro de la 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 du compte
• 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 du compte

Les enregistrements d’utilisateur sont stockés dans la base de données gestionnaire des comptes de sécurité (SAM) 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 du 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 la base de données Active Directory.

Le mot de passe compatible avec LAN Manager est compatible avec le mot de passe utilisé par LAN Manager. Ce mot de passe est basé sur le jeu de caractères oem. Ce mot de passe ne respecte pas 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 ou ESTD de LAN Manager. Ce mot de passe est calculé à l’aide du chiffrement DES pour chiffrer une constante avec le mot de passe en texte clair. Le mot de passe OWF de LAN Manager est de 16 octets. Les 7 premiers octets du mot de passe en texte clair sont utilisés pour calculer les 8 premiers octets du mot de passe OWF de LAN Manager. Les 7 deuxièmes octets du mot de passe en texte clair sont utilisés pour l’ordinateur des 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 Windows OWF. 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 en texte clair.

N’importe quel compte d’utilisateur peut ne pas avoir le mot de passe du gestionnaire de réseau réseau 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 LAN Manager UAS à 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 de LAN Manager 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 pas de représentation du Gestionnaire de réseau réseau, seule la version Windows du mot de passe existe. (Le mot de passe peut ne pas avoir de représentation de LAN Manager, car le mot de passe comporte plus de 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 de l’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 pour vous permettre d’empêcher Windows de stocker un hachage LAN Manager de votre mot de passe. Pour plus d’informations, case activée 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

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 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 connexions interactives, les ouvertures de session de service et les connexions 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 passent à LsaLogonUser.

Pour les connexions interactives, les connexions par lots et les ouvertures de session de service, le client d’ouverture de session se trouve sur l’ordinateur qui exécute la première partie du package d’authentification MSV. Dans ce cas, le mot de passe en texte clair est passé à LsaLogonUser et à la première partie du package d’authentification MSV. Pour les ouvertures de session de service et les ouvertures de session 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 lan 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 obtenir les mots de passe OWF et vérifie qu’ils sont identiques.

Pour les connexions réseau, le client qui se connecte à l’ordinateur a déjà fait l’objet d’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 réseau réseau de 16 octets. Le client LAN Manager transmet ensuite cette « réponse au défi du gestionnaire de réseau local » au serveur. Si le client est un client Windows, une « réponse au défi 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 réseau. Le client Windows transmet ensuite la réponse au défi du gestionnaire de réseau local et la réponse au défi Windows NT au serveur. Dans les deux cas, le serveur authentifie l’utilisateur en transmettant toutes les informations suivantes à l’API LsaLogonUser :

• Nom de domaine
• Nom d’utilisateur
• Le défi original
• Réponse au défi DU GESTIONNAIRE DE RÉSEAU RÉSEAU
• Réponse facultative au 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 en utilisant le mot de passe OWF de la base de données et le défi qui a été transmis. La deuxième partie compare ensuite la réponse de défi calculée à la réponse de défi transmise.

Comme mentionné précédemment, une version du mot de passe peut être manquante dans la base de données SAM ou dans 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 toutes deux utilisées. Dans le cas contraire, la version du gestionnaire LAN du mot de passe est utilisée à des fins de comparaison. Cette règle permet d’appliquer le respect de la casse lorsque des connexions réseau se produisent de Windows vers 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, toutes les connexions 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 fait pas la distinction entre 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ôleur de domaine qui s’exécute dans le service Netlogon. Le localisateur de contrôleur de domaine utilise la résolution de noms NETBIOS ou DNS pour localiser les serveurs nécessaires, en fonction du type de domaine et d’approbation configuré.