PDB Help

Comment déverrouiller un compte utilisateur de domaine verrouillé lors d’une connexion Bureau à distance (RDP)

📅
🕑 5 minutes de lecture

Si vous vous êtes déjà connecté à un serveur Windows via le Bureau à distance et que votre compte a été verrouillé après seulement quelques tentatives, vous savez à quel point c’est agaçant. Généralement, cela se produit après la première session RDP réussie : lorsque vous essayez de vous reconnecter, vous recevez systématiquement le message de verrouillage et un code d’erreur comme 0xd07. C’est particulièrement frustrant lorsque l’événement 4740 apparaît dans l’Observateur d’événements, indiquant que le compte utilisateur a été verrouillé, sans aucune information supplémentaire. C’est d’autant plus agaçant que l’on a l’impression que Windows décide de verrouiller les comptes sans prévenir, même si le mot de passe est correct ou si le seuil de verrouillage n’a pas été atteint. La cause ? Le plus souvent, il s’agit d’une incompatibilité entre la configuration d’authentification du serveur et celle du contrôleur de domaine. Concrètement, le serveur utilise peut-être NTLM (version 1), tandis que le contrôleur de domaine préfère NTLMv2 (version 2).Cette incompatibilité provoque des tentatives d’authentification infructueuses répétées, ce qui entraîne le verrouillage rapide des comptes. Pour résoudre ce problème, il faut modifier certains paramètres du registre et s’assurer que le serveur et le contrôleur de domaine utilisent le même niveau d’authentification. Ce n’est pas très compliqué, mais pour une raison inconnue, Windows ne le rend pas évident, si bien que la plupart des utilisateurs ne s’en rendent compte qu’après avoir été bloqués à plusieurs reprises.

Comment résoudre l’erreur RDP « Le compte utilisateur a été verrouillé en raison d’un trop grand nombre de tentatives de connexion » sur Windows Server 2016/2019

Vérifiez et faites correspondre le « niveau d’authentification du gestionnaire LAN » sur le contrôleur de domaine (DC).

Pourquoi c’est important : Ce paramètre détermine la façon dont Windows gère les protocoles d’authentification hérités. Si le serveur et le contrôleur de domaine utilisent des niveaux différents (par exemple, si le contrôleur de domaine est configuré pour NTLMv2 uniquement et le serveur pour NTLM ou LM), les serveurs échoueront à s’authentifier de manière répétée, ce qui entraînera le verrouillage des comptes. Par conséquent, harmoniser ces paramètres permet d’éviter ces verrouillages inutiles.

Quand cela s’applique : En résumé, si le contrôleur de domaine n’accepte que NTLMv2 (ce qui est recommandé) mais que le serveur utilise toujours NTLMv1 ou LM par défaut, ce problème se manifestera. Vous constaterez des blocages après plusieurs tentatives de connexion RDP ou changements de mot de passe.

À quoi s’attendre : Une fois ce problème résolu, les erreurs de connexion disparaîtront, ou du moins, vous ne serez plus bloqué aussi rapidement. Vos tentatives de connexion devraient être plus stables.

Conseil de pro : Sur certaines configurations, les modifications peuvent ne pas être prises en compte immédiatement ; un redémarrage est donc généralement nécessaire. Parfois, un redémarrage complet suffit.

  • Ouvrir l’Éditeur du Registre : Appuyez sur Windows + R, tapez regedit, et appuyez sur Enter.
  • Accédez à : ` HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa `
  • Vérifiez la valeur : recherchez ou créez une valeur DWORD nommée ` lmcompatibilitylevel` lmcompatibilitylevel. Si elle n’existe pas, cliquez avec le bouton droit, choisissez Nouveau > Valeur DWORD (32 bits) et nommez-la ` lmcompatibilitylevel`.
  • Définissez la valeur : il est généralement recommandé de la définir sur 5 (valeur la plus sécurisée et compatible avec NTLMv2).Double-cliquez sur la valeur, modifiez-la en 5, puis enregistrez.

Faites correspondre les paramètres sur le serveur RDP

Pourquoi c’est utile : Cela harmonise les politiques d’authentification du serveur, empêchant ainsi ce dernier de recourir à des niveaux de sécurité inférieurs refusés par le contrôleur de domaine. En résumé, cela standardise le protocole et évite les incohérences susceptibles d’entraîner le verrouillage des comptes.

Cas d’application : Si votre serveur utilise encore un niveau d’authentification obsolète ou différent de celui du contrôleur de domaine, les tentatives de connexion peuvent échouer de manière répétée. La résolution de ce problème contribue à stabiliser vos sessions RDP.

Vous pouvez vous attendre aux mêmes résultats : une meilleure fiabilité de connexion, et plus de blocages de compte après plusieurs tentatives infructueuses.

Voici comment procéder :

  • Ouvrez à nouveau l’Éditeur du Registre et accédez à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
  • Vérifiez si lmcompatibilitylevelcette valeur diffère de celle du contrôleur de domaine. Si elle n’est pas égale à 5, double-cliquez dessus et modifiez-la à 5. Cliquez sur OK.
  • Fermez le registre, redémarrez le serveur, puis essayez de vous reconnecter via RDP.

Conseils et notes supplémentaires

Bien sûr, Windows propose d’autres méthodes pour contrôler cela, comme les paramètres de stratégie de groupe. Vous les trouverez sous Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité. Recherchez Sécurité réseau : Niveau d’authentification du Gestionnaire de réseau local. Modifiez-le à cet endroit si vous préférez une interface graphique à la modification du registre.

Aperçu rapide des niveaux d’authentification possibles pour LAN Manager (du plus faible au plus fort) :

  • 0 = Envoyer des réponses LM et NTLM (très peu sécurisé)
  • 1 = Envoyer LM et NTLM — utiliser NTLMv2 si négocié
  • 2 = Envoyer uniquement la réponse NTLM
  • 3 = Envoyer uniquement la réponse NTLMv2
  • 4 = Envoyer uniquement la réponse NTLMv2, refuser LM
  • 5 = Envoyer uniquement une réponse NTLMv2, refuser LM et NTLM (meilleur et plus sûr)

Il est donc généralement conseillé de définir à la fois le serveur et le contrôleur de domaine sur la valeur 5, en particulier dans les environnements récents.

J’espère que cela synchronisera tout et empêchera les blocages de compte. Je ne comprends pas pourquoi Windows complique autant les choses, mais bon… on y est.

Résumé

  • Vérifiez le niveau de compatibilité (lmcompatibilitylevel) dans le registre, à la fois sur le serveur et sur le contrôleur de domaine.
  • Réglez les deux sur 5 pour une sécurité et une compatibilité optimales.
  • Redémarrez vos systèmes et essayez de vous reconnecter sans rencontrer le problème de verrouillage.

Conclure

Aligner le serveur et le contrôleur de domaine sur le même niveau d’authentification résout généralement les problèmes de verrouillage à répétition. C’est assez étrange, car les paramètres Windows ne se synchronisent pas automatiquement, mais une fois alignés, tout fonctionne beaucoup mieux. Sur certaines machines, un redémarrage peut être nécessaire pour que les modifications soient pleinement prises en compte. Si cette solution a fonctionné pour vous, elle vous a probablement évité bien des heures de frustration ; en tout cas, ça a marché pour moi. J’espère que cela aidera d’autres personnes aussi.