Algorithmes et exemples de validation d’accès réseau pour Windows Server 2003, Windows XP et Windows 2000

Cet article explique comment la validation de compte Windows fonctionne pendant l’accès réseau à l’aide du protocole NTLM.

Applicabilité : Windows 10 - toutes les éditions, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 103390

Résumé

Voici un algorithme simplifié qui explique comment la validation de compte Windows est observée pour fonctionner pendant l’accès réseau à l’aide du protocole NTLM. Il utilise l’accès via le protocole SMB (Server Message Block) comme exemple, mais il s’applique à toutes les autres applications serveur qui prennent en charge l’authentification NTLM. Cette discussion ne couvre pas le fonctionnement interne de ce processus. Avec ces informations, vous pouvez prédire le comportement de l’ouverture de session réseau Windows dans des conditions déterministes.

Lorsque Kerberos est utilisé pour authentifier l’utilisateur et obtenir l’accès aux ressources du serveur, le processus est différent de ce que fait NTLM.

N’oubliez pas que la base de données locale est la base de données de domaine et la seule base de données sur les contrôleurs de domaine. Mais sur les autres serveurs et tous les ordinateurs, la base de données locale diffère du contrôleur de domaine.

Informations contextuelles

Lorsque deux ordinateurs Windows Server 2003, Windows XP ou Windows 2000 communiquent sur un réseau, ils utilisent un protocole de haut niveau appelé SMB (Server Message Block). Les commandes SMB sont incorporées dans les protocoles de transport, tels que NetBIOS Enhanced User Interface (NetBEUI) ou TCP/IP. Par exemple, lorsqu’un ordinateur client exécute une NET USE commande, une trame « Configuration de session SMB et X » est envoyée.

Dans Windows, le SMB « Session Setup » inclut le compte d’utilisateur, une fonction de hachage du mot de passe chiffré et du domaine d’ouverture de session. Un contrôleur de domaine examine toutes ces informations pour déterminer si le client dispose des autorisations nécessaires pour exécuter la commande NET USE.

Algorithmes

Un ordinateur client Windows envoie la commande suivante à un serveur :

NET USE x: \\server\share

L’ordinateur client Windows envoie un SMB « Session Setup » qui contient son domaine de connexion, son compte d’utilisateur et son mot de passe.

Le serveur examine le nom de domaine ou le nom d’ordinateur spécifié par le SMB. Si le nom est le propre nom du serveur, l’algorithme suivant est exécuté :

    It checks its own domain database or computer database for
        a matching account.
    If it finds a matching account then
        The SMB password is compared to the domain database password or the computer database password.
        If  the password matches then
            The command completed successfully.
        If  the password does NOT match then
            The user is prompted for a password.
                The password is retested as above.
            System error 1326 has occurred. Logon failure: unknown
            user name or bad password.
        End
    If  it does NOT find the account in the domain Security Accounts Manager (SAM) database or computer SAM database then
        Guest permissions are tested.
        If  the guest account is enabled
            The command completed successfully.
        If  the guest account is disabled
            (* See Note a).
            The user is prompted for a password.
            System error 1326 has occurred. Logon failure:
                unknown user name or bad password.
        End

Si le domaine spécifié dans le SMB est approuvé par le serveur, l’algorithme suivant est exécuté :

    The server will do pass-through authentication. The
        network logon request will be sent to a server that has a domain controller role in the
        specified trusted domain.

Si aucun canal sécurisé n’est configuré, l’algorithme suivant est exécuté :

The trusted domain controller checks its own domain database
        for a matching account.
    If the trusted domain controller finds a matching account, then
       NOT for Windows 2000 and later versions:
    It determines whether the account is a local or global account.
       If the account is local, then
           Guest permissions on the original server are tested.
           If the guest account is enabled
               The command completed successfully.
           If the guest account is disabled
               (* See Note 1) The user is prompted for a password.
               System error 1326 has occurred. Logon failure:
               unknown user name or bad password.
        End
        If the account is global (the only option for Active Directory)
           The SMB password is compared to the domain database
               password.
           If  the password matches, then
               The command completed successfully.
               (* See Note 2)
           If  the password does NOT match, then
               The user is prompted for a password.
                   The password is retested as above.
               System error 1326 has occurred. Logon failure:
               unknown user name or bad password.
       End
    If the trusted domain controller does NOT find the account in the trusted domain controller
           database, then
       Guest permissions are tested on the original server, not the trusted domain.  (* See Note 3)
       If  the guest account is enabled
           The user will have original server guest access.
           The command completed successfully.
       If  the guest account is disabled
           (* See Note 1) The user is prompted for a password.
           System error 1326 has occurred. Logon failure:
           unknown user name or bad password.
    End

Importante

Les cas suivants décrivent les scénarios dans lesquels le client utilise un domaine utilisateur différent de celui que le serveur a ou connaît. Il existe un problème avec cette incompatibilité lorsque le protocole d’authentification NTLMv2 est négocié. NTLM v2 utilise un salt de mot de passe, et le domaine de l’utilisateur est utilisé dans ce sel par le client.

Lorsque le serveur obtient les informations et trouve l’utilisateur dans la base de données locale, le serveur utilise le nom de la base de données LOCAL pour calculer le sel et le hachage. Par conséquent, si le « domaine source » envoyé par le client est vide ou est un domaine inconnu, le sel et par conséquent le hachage de mot de passe ne correspondent pas. Dans ce cas, la tentative d’authentification échoue avec une erreur « nom d’utilisateur inconnu ou mot de passe incorrect » (STATUS_LOGON_FAILURE). L’événement d’audit de la tentative signale « mot de passe incorrect », symbole STATUS_WRONG_PASSWORD.

Exemple d’événement :

Nom du journal : Sécurité
Source : Microsoft-Windows-Security-Auditing
ID d’événement : 4625
Catégorie de tâche : Ouverture de session
Niveau : Informations
Mots clés : Échec de l’audit
Ordinateur : server-computer1
Description :
Un compte n’a pas pu se connecter.

Objet:

ID de sécurité : SID NULL
Nom du compte : -
Domaine de compte : -
ID de connexion : 0x0

Type d’ouverture de session : 3

Compte pour lequel l’ouverture de session a échoué :

ID de sécurité : SID NULL
Nom du compte : ntadmin
Domaine de compte : client-ordinateur1

Informations sur l’échec :

Raison de l’échec : nom d’utilisateur inconnu ou mot de passe incorrect.
État : 0xc000006d
Sous-état : 0xc000006a
...

Informations d’authentification détaillées :

Processus d’ouverture de session : NtLmSsp
Package d’authentification : NTLM
Services transités : -
Nom du package (NTLM uniquement) : -
Longueur de la clé : 0

Pour éviter ce scénario, vous devez inclure explicitement le nom de domaine approprié sur le client. Pour un mappage de lecteur sur un scénario de groupe de travail, il s’agit des éléments suivants :
Net use x: \\server-computer1\data /u:server-computer1\ntadmin *

Si le domaine spécifié dans le SMB est inconnu par le serveur, par exemple, si un domaine a été spécifié mais n’a pas été reconnu par le serveur en tant que domaine approuvé ou son contrôleur de domaine, l’algorithme suivant est exécuté :

    It  will check its own account database for
        a matching account
    If  the server finds a matching account, then
        The SMB password is compared to the domain database password or the computer database password.
        If  the password matches, then
            The command completed successfully.
        If  the password does NOT match, then
            The user is prompted for a password.
                The password is retested as above.
            System error 1326 has occurred. Logon failure: unknown
            user name or bad password.
    End
    If  it does NOT find the account in the domain database then
        guest permissions are tested.
        If  the guest account is enabled
            The command completed successfully.
        If  the guest account is disabled
            System error 1326 has occurred. Logon failure:
            unknown user name or bad password.
    End

Si le domaine spécifié dans le SMB est NULL, c’est-à-dire qu’aucun domaine n’est spécifié, l’algorithme suivant est exécuté :

    The server will treat this as a local network logon. The server
        will test for a matching account in its own database.
    If  it finds a matching account, then
        The SMB password is compared to the SAM database password.
        If  the password matches, then
            The command completed successfully.
        If  the password does NOT match, then
            The user is prompted for a password.
                The password is retested as above.
            System error 1326 has occurred. Logon failure: unknown
            user name or bad password.
    End
    If  it does NOT find the account in the local SAM database AND
      LsaLookupRestrictIsolatedNameLevel=0 AND NeverPing=0, then (* See Note 4)
        The server will simultaneously ask each domain that it trusts whether it has account that
            matches the SMB account.
        The first trusted domain to reply is sent a request to
            perform pass-through authentication of the client
            information.
        The trusted domain will look in its own database.
        If  an account that matches the SMB account is found, then
            The trusted domain determines whether the account is a local or global
                account.
           Not for Windows 2000 and later versions:
            If  the account is local then
                Guest permissions on the original server are tested.
                If  the guest account is enabled
                    The command completed successfully.
                If  the guest account is disabled
                The user will be prompted for a password.
                Regardless of what password is entered, the user will receive
                    "Error 5: Access has been denied."
            End
            If  the account is global (the only option for Active Directory)
                The password that was specified in the SMB is compared
                    to the SAM database password.
                If  the password matches, then
                    The command completed successfully.
                If  the password does NOT match, then
                    The user is prompted for a password.
                        The password is retested as above.
                    System error 1326 has occurred. Logon failure:
                    unknown user name or bad password.
            End
    If  no trusted domains respond to the request to identify the
        account, then
        Guest permissions are tested on the original server,
            not the trusted server.
        If  the guest account is enabled
            The command completed successfully.
        If  the guest account is disabled
            System error 1326 has occurred. Logon failure:
            unknown user name or bad password.
    End

Notes

  1. Si le compte invité est désactivé et que l’utilisateur n’a pas de compte, le serveur demande toujours un mot de passe. Bien qu’aucun mot de passe ne réponde à ses exigences, le serveur demande toujours un mot de passe comme mesure de sécurité. Cette mesure de sécurité garantit qu’un utilisateur non autorisé ne peut pas faire la différence entre un cas où un compte existe et le cas où le compte n’existe pas. L’utilisateur est toujours invité à entrer un mot de passe, que le compte existe ou non.

  2. À ce stade, les informations suivantes sont retournées à partir du domaine approuvé dans la réponse : SID de domaine, ID utilisateur, Appartenances aux groupes globaux, Heure d’ouverture de session, Heure de déconnexion, KickOffTime, Nom complet, LastSet de mot de passe, Mot de passe peut changer l’indicateur, Indicateur De mot de passe doit changer, Script utilisateur, Chemin d’accès du profil, Répertoire de base et Nombre de mots de passe incorrects.

  3. Si aucun compte n’est trouvé sur le domaine approuvé, le système d’exploitation doit utiliser le compte invité local pour garantir un comportement cohérent pour l’authentification sur le serveur.

  4. Pour plus d’informations sur la façon de restreindre la recherche et l’ouverture de session de noms isolés dans des domaines approuvés à l’aide des entrées de Registre LsaLookupRestrictIsolatedNameLevel et NeverPing, consultez Le processus Lsass.exe peut cesser de répondre si vous avez de nombreuses approbations externes sur un contrôleur de domaine Active Directory.

    • Les comptes invités sur les domaines approuvés ne seront jamais disponibles.

    • Le processus interne réel est plus complexe que les algorithmes décrits ici.

    • Ces algorithmes ne traitent pas des mécanismes réels de l’authentification directe. Pour plus d’informations, consultez Authentification utilisateur NTLM dans Windows

    • Ces algorithmes ne traitent pas du processus de chiffrement de mot de passe utilisé dans Windows Server 2003, Windows XP et Windows 2000. Un objet BLOB (Binary Large Object) dérivé d’un hachage de mot de passe unidirectionnel est envoyé dans le cadre de la demande d’authentification. Le contenu de cet objet BLOB dépend du protocole d’authentification choisi pour l’ouverture de session.

    • Cet article ne traite pas du fonctionnement interne du module d’authentification Microsoft.

    • Ces algorithmes supposent que le compte invité, lorsqu’il est activé, n’a pas de mot de passe. Par défaut, le compte invité n’a pas de mot de passe dans Windows Server 2003, Windows XP et Windows 2000. Si un mot de passe de compte invité est spécifié, le mot de passe utilisateur envoyé dans le SMB doit correspondre au mot de passe du compte invité.

Exemples

Voici des exemples de ces algorithmes en action.

Exemple 1

Vous êtes connecté à l’ordinateur à l’aide du même nom de compte et mot de passe que dans la base de données du compte de domaine SCRATCH-DOMAIN. Lorsque vous exécutez la NET USE \\SCRATCH commande pour le contrôleur de domaine pour le domaine SCRATCH-DOMAIN, la commande s’exécute correctement. Lorsque vous exécutez la NET USE \\NET commande pour le contrôleur de domaine qui approuve le domaine SCRATCH-DOMAIN, le message d’erreur suivant s’affiche :

L’erreur système 1326 s’est produite. Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect.

Le compte \SCRATCH-DOMAIN\USER1 dispose d’autorisations sur \\NET.

Remarque

Cet exemple suppose les configurations suivantes.

Configurations

Ordinateur disposant d’une autorité de sécurité locale :

-Compte de connexion : USER1
-Mot de passe : PSW1
-Login Domain : LOCAL1

Contrôleur de domaine Active Directory :

-Nom du serveur : NET</WWITEM>
-Domaine : NET-DOMAIN</WWITEM>
-Trust : NET-DOMAIN Trust SCRATCH-DOMAIN (Par conséquent,
les comptes sur SCRATCH-DOMAIN peuvent se voir accorder des autorisations
dans le DOMAINE NET- ).

Le domaine NET-DOMAIN :

  • La base de données de compte de domaine pour le domaine NET-DOMAIN ne contient pas de compte pour USER1.
  • Le compte invité est désactivé.

Windows Server 2003 :

-Nom du serveur : SCRATCH
-Domaine : SCRATCH-DOMAIN
-Domain Database contient le compte : USER1
-Domain Database contient le mot de passe : PSW1

Dans cet exemple, l’ordinateur est connecté à son domaine local, et non au domaine SCRATCH-DOMAIN où réside le compte de domaine de l’ordinateur.

Exemple 2

Lorsque vous exécutez la NET USE x: \\NET\share commande , les étapes suivantes se produisent :

  1. L’ordinateur envoie les éléments suivants dans le SMB « Session Setup » :

    • account = « USER1 »
    • password = « PSW1 »
    • domain = « LOCAL1 »
  2. Le serveur \\NET reçoit le SMB et a examiné le nom du compte.

  3. Le serveur examine sa base de données de compte de domaine local et ne trouve aucune correspondance.

  4. Le serveur examine ensuite le nom de domaine SMB.

  5. Le serveur n’approuve pas « LOCAL1 », de sorte qu’il ne case activée pas ses domaines approuvés.

  6. Le serveur vérifie ensuite son compte invité.

  7. Le compte invité est désactivé de sorte que l’erreur système 1326 s’est produite. Échec d’ouverture de session : nom d’utilisateur inconnu ou mot de passe incorrect. » un message d’erreur est généré.

Exemple 3

Lorsque vous exécutez la NET USE x: \\SCRATCH\share commande , les étapes suivantes se produisent :

  1. L’ordinateur envoie les éléments suivants dans le SMB « Session Setup » :

    • account = « USER1 »
    • password = « PSW1 »
    • domain = « LOCAL1 »
  2. Le serveur \\SCRATCH reçoit le SMB et examine le nom du compte.

  3. Le serveur examine sa base de données de compte de domaine local et trouve une correspondance.

  4. Le serveur compare ensuite le mot de passe SMB au mot de passe du compte de domaine.

  5. Les mots de passe correspondent.

Par conséquent, le message « La commande se termine correctement » est généré. Dans les exemples 2 et 3, la relation d’approbation n’est pas disponible. Si l’ordinateur avait été connecté au domaine SCRATCH-DOMAIN, la NET USE x: \\NET\share commande aurait réussi.

La solution idéale est que tous les ordinateurs se connectent à un domaine. Pour se connecter, l’utilisateur doit spécifier le domaine, le compte et le mot de passe. Après cela, toutes les commandes NET USE -type passent les informations de domaine, de compte et de mot de passe appropriées. Les administrateurs doivent essayer d’éviter les comptes en double sur les ordinateurs et sur plusieurs domaines. Les ordinateurs Windows Server 2003, Windows XP et Windows 2000 permettent d’éviter cette configuration en utilisant des approbations entre domaines et en utilisant des membres qui peuvent utiliser des bases de données de domaine.

Solution de contournement

Il existe une solution de contournement qui peut être utilisée dans ces cas. À partir de l’ordinateur, vous pouvez exécuter la commande suivante :

NET USE X: \\NET\SHARE /USER:SCRATCH-DOMAIN\USER1 PSW1

Dans cette commande, voici la valeur true :

  • \\NET = nom d’ordinateur du contrôleur de domaine auquel vous accédez.
  • \SHARE = Nom du partage.
  • /USER : paramètre de ligne de commande qui vous permet de spécifier le domaine, le compte et le mot de passe qui doivent être spécifiés dans le SMB « Session Setup ».
  • SCRATCH-DOMAIN = nom de domaine du domaine où réside le compte d’utilisateur.
  • \USER1 = compte à valider.
  • PSW1 = mot de passe qui correspond au compte sur le domaine.

Pour plus d’informations sur cette commande, tapez la commande suivante à l’invite de commandes :

NET USE /?  

Noms de domaine NULL

Le client Microsoft SMB inclus dans Windows Server 2003, Windows XP et Windows 2000 envoie des noms de domaine NULL dans le SMB « Session Setup SMB [x73] ». Le client Microsoft SMB gère le nom de domaine en spécifiant le nom de domaine d’ouverture de session et en envoyant un caractère NULL si le nom de domaine n’est pas spécifié dans la commande NET USE. Le client Microsoft SMB présente également le comportement décrit dans l’exemple 1.

Remarque

  • Le nom de domaine par défaut est spécifié dans le fichier LANMAN.INI sur la ligne « DOMAINE = ». Cela peut être remplacé par le /DOMAIN: commutateur avec la NET LOGON commande .
  • Il existe généralement deux représentations pour « NULL » dans le SMB : un nom de domaine de longueur nulle et un nom de domaine d’un octet qui se compose du caractère de point d’interrogation ( ?). Le serveur SMB intercepte le point d’interrogation et le traduit en NULL avant de le transmettre à l’autorité de sécurité locale (LSA).

Résolution des problèmes

Un bon conseil pour résoudre les problèmes d’accès réseau consiste à activer l’audit en procédant comme suit.

Windows 2000 et versions ultérieures des contrôleurs de domaine Windows 2000

  1. À partir des Outils d’administration sur un contrôleur de domaine, démarrez Utilisateurs et ordinateurs Active Directory.
  2. Cliquez avec le bouton droit sur Unité d’organisation contrôleurs de domaine, puis cliquez sur Propriétés.
  3. Sous l’onglet stratégie de groupe, double-cliquez sur Stratégie de contrôleur de domaine par défaut.
  4. Dans le Rédacteur stratégie, cliquez sur Paramètres de l’ordinateur, sur Paramètres Windows, sur Paramètres de sécurité, sur Stratégies locales, puis sur Stratégie d’audit.
  5. Sélectionnez l’option Ouverture de session et ouverture de session du compte et l’option Échec .

Paramètres de domaine pour les serveurs et les membres Windows 2000

  1. À partir des Outils d’administration sur un contrôleur de domaine, démarrez Utilisateurs et ordinateurs Active Directory.
  2. Cliquez avec le bouton droit sur le nom de domaine, puis cliquez sur Propriétés.
  3. Sous l’onglet stratégie de groupe, double-cliquez sur Stratégie de domaine par défaut.
  4. Dans le Rédacteur Stratégie, cliquez sur Paramètres de l’ordinateur, sur Paramètres Windows, sur Paramètres de sécurité, sur Stratégies locales, puis sur Stratégie d’audit.
  5. Sélectionnez l’option Ouverture de session et ouverture de session du compte et l’option Échec .

Paramètres locaux pour les serveurs et les membres Windows 2000

  1. À partir des Outils d’administration, démarrez Stratégie de sécurité locale.
  2. Ouvrez La stratégie d’audit.
  3. Sélectionnez l’option Ouverture de session et ouverture de session du compte et l’option Échec . Désormais, chaque fois qu’un utilisateur réseau accède à ce serveur à distance, une piste d’audit est connectée observateur d'événements. Pour afficher ces événements dans observateur d'événements, cliquez sur Sécurité dans le menu Journal.

Pour plus d’informations sur les relations d’approbation, l’authentification directe, les autorisations utilisateur et les connexions de domaine, consultez « Technical Overview of Windows Server 2003 Security Services ».

Plus d’informations

Fondamentalement, les mêmes algorithmes de validation d’accès réseau sont appliqués à Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2.

Ce système d’exploitation dispose de plusieurs nouvelles fonctionnalités dans SMB.

Windows Server 2008

Windows Server 2012