Partager via

Algorithmes et exemples de validation d’accès réseau pour Windows

  • Article

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

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 s’applique à toutes les autres applications serveur qui prennent en charge l’authentification NTLM. Cette discussion ne couvre pas les fonctions internes de ce processus. Avec ces informations, vous pouvez prédire le comportement de connexion 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 d’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 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 TCP/IP ou les connexions Internet UDP rapides (QUIC). Par exemple, lorsqu’un ordinateur client exécute une NET USE commande, une trame « SMB Session Setup and X » est envoyée.

Dans Windows, lors de l’utilisation de NTLM, 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 terminer 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 un domaine 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 un canal sécurisé n’est pas 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

Important

Les cas suivants décrivent les scénarios dans lesquels le client utilise un domaine utilisateur différent de celui dont le serveur dispose ou connaît. Il existe un problème avec cette incompatibilité lorsque le protocole d’authentification NTLMv2 est négocié. NTLM at v2 utilise un sel de mot de passe et le domaine 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 LOCALE 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 correspond 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-Audit
ID d’événement : 4625
Catégorie de tâche : Ouverture de session
Niveau : Information
Mots clés : Échec d’audit
Ordinateur : serveur-ordinateur1
Description :
Échec de connexion d’un compte.

Objet :

ID de sécurité : SID NULL
Nom du compte : -
Domaine du compte : -
ID d’ouverture de session : 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 les défaillances :

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 problème, vous devez inclure explicitement le nom de domaine correct 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 comme 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 a la valeur NULL, autrement dit, 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.           
    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 en tant que 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 quand 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 d’utilisateur, Appartenances aux groupes globaux, Heure de connexion, Heure de déconnexion, KickOffTime, Nom complet, Mot de passe LastSet, Mot de passe Peut changer d’indicateur, Mot de passe doit changer d’indicateur, Script utilisateur, Chemin d’accès du profil, Répertoire d’accueil 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. De plus, le correctif logiciel est disponible pour élargir la journalisation pour identifier les demandes de recherche de noms isolées dans Windows Server 2008 SP2.

    • 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 de la mécanique réelle de l’authentification directe. Pour plus d’informations, consultez l’authentification utilisateur NTLM dans Windows.
    • Ces algorithmes ne traitent pas du processus de chiffrement de mot de passe utilisé dans Windows. 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 des fonctionnements internes 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. 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 du mot de passe qui se trouve dans la base de données du compte de domaine CONTOSO-DOMAIN. Lorsque vous exécutez la NET USE \\CONTOSO commande pour le contrôleur de domaine pour le domaine CONTOSO-DOMAIN, la commande est terminée avec succès. Lorsque vous exécutez la NET USE \\NET commande du contrôleur de domaine qui approuve le domaine CONTOSO-DOMAIN, vous recevez le message d’erreur suivant :

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

Le compte \CONTOSO-DOMAIN\USER1 dispose des autorisations sur \\NET.

Note

Cet exemple suppose les configurations suivantes.

Configurations

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

  • Compte de connexion : USER1
  • Mot de passe : PSW1
  • Domaine de connexion : LOCAL1

Contrôleur de domaine Active Directory :

-Nom du serveur : NET
-Domaine : NET-DOMAIN
-Trust : APPROBATION NET-DOMAIN CONTOSO-DOMAIN (Par conséquent,
les comptes sur CONTOSO-DOMAIN peuvent recevoir des autorisations
dans LE DOMAINE NET.

Domaine NET-DOMAIN :

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

Domaine CONTOSO-DOMAIN :

  • Nom du serveur : CONTOSO
  • Domaine : CONTOSO-DOMAIN
  • La base de données de domaine contient le compte : USER1
  • La base de données de domaine contient un mot de passe : PSW1

Dans cet exemple, l’ordinateur est connecté à son domaine local, et non au domaine CONTOSO-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 ce qui suit dans le SMB « Configuration de session » :

    • account = « USER1 »
    • password = « PSW1 »
    • domain = « LOCAL1 »

  2. Le serveur \\NET 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 ne trouve pas de correspondance.

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

  5. Le serveur n’approuve pas « LOCAL1 », de sorte que le serveur ne vérifie 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 de connexion : nom d’utilisateur inconnu ou mot de passe incorrect. Le message d’erreur est généré.

Exemple 3

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

  1. L’ordinateur envoie ce qui suit dans le SMB « Configuration de session » :

    • account = « USER1 »
    • password = « PSW1 »
    • domain = « LOCAL1 »

  2. Le serveur \\CONTOSO 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 « Commande se termine correctement » est généré. Dans l’exemple 2 et l’exemple 3, la relation d’approbation n’est pas disponible. Si l’ordinateur avait été connecté au domaine CONTOSO-DOMAIN, la NET USE x: \\NET\share commande aurait réussi.

La solution idéale consiste à connecter tous les ordinateurs à un domaine. Pour vous connecter, l’utilisateur doit spécifier le domaine, le compte et le mot de passe. Une fois cette opération terminée, 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 plusieurs domaines. Windows permet d’éviter cette configuration à l’aide d’approbations entre les 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:CONTOSO-DOMAIN\USER1 PSW1

Dans cette commande, la commande suivante est vraie :

  • \\NET = Nom d’ordinateur du contrôleur de domaine accessible.
  • \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 ».
  • CONTOSO-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 ce qui suit à l’invite de commandes :

NET USE /?

Noms de domaine NULL

Le client Microsoft SMB inclus dans Windows envoie des noms de domaine NULL dans le SMB d’installation de session [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.

Note

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).

Dépannage

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

Contrôleurs de domaine Windows

  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 l’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 l’Éditeur de stratégie, cliquez sur Paramètres de l’ordinateur, sur Paramètres Windows, sur Paramètres de sécurité, sur Configuration avancée de la stratégie d’audit, puis sur Connexion au compte.
  5. Sélectionnez l’option Validation des informations d’identification d’audit et l’option Échec .

Paramètres de domaine pour 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 l’Éditeur de stratégie, cliquez sur Paramètres de l’ordinateur, sur Paramètres Windows, sur Paramètres de sécurité, sur Configuration avancée de la stratégie d’audit, puis sur Connexion au compte.
  5. Sélectionnez l’option Validation des informations d’identification d’audit et l’option Échec .

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

  1. À partir des outils d’administration, démarrez la stratégie de sécurité locale.
  2. Ouvrez la configuration avancée de la stratégie d’audit – Objet de stratégie de groupe local.
  3. Sélectionnez Ouverture de session du compte, puis l’option Audit Credential Validation et l’option Échec .
  4. À présent, chaque fois qu’un utilisateur réseau accède à ce serveur à distance, une piste d’audit est journalisée dans l’Observateur d’événements. Pour afficher ces événements dans l’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 la rubrique « Vue d’ensemble technique des services de sécurité Windows Server 2003 ».