Authentification des utilisateurs NTLM

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

Version du produit d’origine :   Windows Server 2012 R2
Numéro de la base de connaissances initiale :   102716

Résumé

Cet article traite des aspects suivants de l’authentification des utilisateurs NTLM dans Windows :

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

Informations supplémentaires

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

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 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 (Original Equipment Manufacturer). Ce mot de passe ne respecte pas la casse et peut contenir jusqu’à 14 caractères. La version OWF de ce mot de passe est également appelée version de LAN Manager OWF ou ESTD. 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 LAN Manager OWF comporte 16 octets de long. Les 7 premiers octets du mot de passe en texte clair sont utilisés pour calculer les 8 premiers octets du mot de passe de LAN Manager OWF. Les 2 à 7 octets du mot de passe en texte clair sont utilisés pour effectuer l’ordinateur sur les 8 octets du mot de passe de LAN Manager OWF.

Le mot de passe Windows est basé sur le jeu de caractères Unicode. Ce mot de passe respecte la casse et peut contenir 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 l’algorithme de chiffrement RSA MD-4. Cet algorithme calcule un Digest de 16 octets d’une chaîne de longueur variable d’octets de mot de passe en texte clair.

Tout compte d’utilisateur peut ne pas avoir le mot de passe LAN Manager ou le mot de passe Windows. Toutefois, chaque tentative est effectuée pour gérer les deux versions du mot de passe.

Par exemple, si le compte d’utilisateur est transféré à 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 pour Workgroups, seule la version LAN Manager du mot de passe existera. 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 LAN Manager, seule la version Windows du mot de passe existe. (Le mot de passe n’a peut-être pas de représentation 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 laissent pas les mots de passe Windows 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 LAN Manager de votre mot de passe. Pour plus d’informations, consultez l’article suivant dans la base de connaissances Microsoft :

299656 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

Notes

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

Authentification des utilisateurs à l’aide du package d’authentification MSV1_0

Windows utilise l’API LsaLogonUser pour tous les types d’authentification des utilisateurs. 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 d’utilisateurs 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 composants 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 transmis 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 demande vers le service Netlogon sur l’ordinateur de destination. En retour, le service Netlogon transmet la demande à l’autre partie du package d’authentification MSV sur cet ordinateur.

LsaLogonUser prend en charge les ouvertures de session interactives, les ouvertures de session de service et les ouvertures de session réseau. Dans le package d’authentification MSV, tous les formulaires de l’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 sont transmis à LsaLogonUser.

Pour les ouvertures de session interactives, les ouvertures de session par lots et les ouvertures de sessions 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 transmis à LsaLogonUser et à la première partie du package d’authentification MSV. Pour les ouvertures de session de service et les ouvertures de session par lot, le gestionnaire de contrôle des services et le planificateur de tâches fournissent 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 un mot de passe de LAN Manager OWF et en un mot de passe Windows NT OWF. 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 s’assurer qu’ils sont identiques.

Pour les ouvertures de session réseau, le client qui se connecte à l’ordinateur a déjà été associé à un challenge de 16 octets, ou « nonce ». Si le client est un client LAN Manager, le client a traité une réponse de stimulation de 24 octets en chiffrant le Challenge de 16 octets avec le mot de passe du gestionnaire de connexions de réseau local (LAN Manager) de 16 octets. Le client LAN Manager transmet ensuite cette « réponse de Challenge LAN Manager » au serveur. Si le client est un client Windows, une « réponse de stimulation Windows NT » est calculée à l’aide du même algorithme. Toutefois, le client Windows utilise les données Windows OWF 16 octets au lieu des données de LAN Manager OWF. Le client Windows transmet ensuite à la fois la réponse de Challenge de LAN Manager et la stimulation/réponse de Windows NT au serveur. Dans les deux cas, le serveur authentifie l’utilisateur en transférant tous les éléments suivants à l’API LsaLogonUser :

  • Le nom de domaine
  • Nom d’utilisateur
  • Défi d’origine
  • Réponse de Challenge de LAN Manager
  • Réponse à la demande de stimulation Windows NT facultative

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 de Challenge en utilisant le mot de passe OWF de la base de données et le Challenge qui a été transmis. La deuxième partie compare ensuite la réponse de Challenge calculée à la réponse de Challenge passée.

Notes

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

Comme indiqué précédemment, il est possible que la version du mot de passe soit manquante dans la base de données SAM ou à partir de la base de données Active Directory. En outre, il est possible que la version du mot de passe soit manquante dans l’appel de 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 LAN Manager du mot de passe est utilisée pour la comparaison. Cette règle permet d’appliquer le respect de la casse lorsque les ouvertures de session réseau s’effectuent à partir de Windows vers Windows. Cette règle autorise également la compatibilité descendante.

Authentification directe

Le service Netlogon implémente l’authentification directe. Il effectue les fonctions suivantes :

  • Sélectionne le domaine auquel envoyer 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 transmis à 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 qui est membre d’un domaine, le nom de la base de données SAM est considéré comme étant le nom de l’ordinateur. Sur un contrôleur de domaine Active Directory, le nom de la base de données de comptes est le nom du domaine. Sur un ordinateur qui n’est pas membre d’un domaine, toutes les ouvertures de sessions 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 demande 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 auquel elle est connectée comme si le nom de domaine spécifié était ce nom de domaine. Netlogon ne fait pas la distinction entre un domaine qui n’existe pas, un domaine non approuvé et un nom de domaine incorrect.

Netlogon sélectionne un serveur dans le domaine par le biais d’un processus appelé découverte. Une station de travail Windows identifie le nom de l’un des contrôleurs de domaine Windows Active Directory dans son domaine principal. Un contrôleur de domaine Active Directory identifie 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 réseau qui s’exécute dans le service Netlogon. Le localisateur de contrôleurs de domaine utilise la résolution de noms DNS ou NETBIOS pour localiser les serveurs nécessaires, en fonction du type de domaine et d’approbation configurés.