Tracer la source d’un compte Active Directory qui se verrouille sans cesse
Suite a un changement de mot de passe, parfois, si vos utilisateurs lancent des scripts ou des tâches planifiés avec leur compte, alors ils peuvent retrouver leur compte Windows verrouillé / bloqué continuellement. Vous trouverez ci-dessous, une méthode qui vous permettra d’en savoir un peu plus sur la cause de ce désagrément.
Récupérer le nom du PDC
Pour commencer, il est nécessaire de récupérer le nom du contrôleur de domaine qui a le rôle de PDC (Primary Domain Controller). Pour cela, un petit coup de powershell permettra de récupérer cette info (nécessaire surtout si vous avez beaucoup de contrôleurs de domaine).
Get-ADDomain nom-du-domaine | Select-Object PDCEmulator
Analyser les logs
Maintenant, il va être nécessaire d’analyser ce qu’il se passe, pour ça, les logs sont le point d’entrée de tout problème. Le problème des logs, c’est chaque minute, quand ce n’est pas chaque seconde, de nouvelles informations viennent s’ajouter aux logs. Heureusement, l’observateur d’évennement est plutôt bien foutu et vous allez pouvoir filtrer ce que vous avez besoin.
Dans notre cas, nous allons filtrer sur l’événement ID 4740 dans les logs de sécurité.
Ce qui va nous permettre de sortir seulement les événements de comptes verrouillés, mais surtout de savoir depuis quel ordinateur le compte a été verrouillé.
Si avec ceci cela ne fonctionne toujours pas, vous pouvez essayer l’outil LockoutStatus de Microsoft, bien que très vieux, il permet d’avoir quelques infos intéressantes comme le nombre de mauvais mot de passe et les DC sur lequel le compte a été verrouillé.
Télécharger LockoutStatus
Ou encore avec Netwrix Account Lockout Examiner qui fonctionne très bien également.
Télécharger Netwrix Account Lockout Examiner
Si vous utilisez d’autres méthodes, n’hésitez pas à les partager dans les commentaires.
pour rester sur du 100% powershell, il y a aussi ce script : https://gallery.technet.microsoft.com/scriptcenter/Get-LockedOutLocation-b2fd0cab
Super, ça tombe bien je voulais en parler également sur la base de cet article : https://blogs.technet.microsoft.com/heyscriptingguy/2012/12/27/use-powershell-to-find-the-location-of-a-locked-out-user/
Mais le script sera également très utile. Thanks
De rien.
Surtout un grand merci pour tes articles toujours très intéressants et professionnels!
Merci pour cet article, ayant déjà eu le problème, une fois le pc trouvé impossible de savoir pourquoi il verrouille le compte. Auriez-vous une astuce (je précise que j’ai aussi regardé dans les events.)
J.
Une astuce non, effectivement, l’event viewer peut être une grande aide.
Après voici quelques pistes en fonction de mon vécu :
Cela peut être un lecteur réseau monté avec un utilisateur spécifique qui a changé son mot de passe.
Une tâche planifiée exécuté avec un utilisateur spécifique ayant changé son mot de passe.
Ou encore une authentification avec internet explorer sur un proxy.
Dans tous les cas, une reconstruction de la session utilisateur doit solutionner le problème.
Bonjour ,
comment faire une reconstruction de la session utilisateur ?
Bonjour,
Pour les verrouillages de comptes, j’utilise aussi lockoustatus. J’utilise aussi eventcombMT qui se base sur lockout, mais qui sait requeter directement sur les différents DC de l’infra, et permet de requêter sur une valeur. Il exporte dans un fichier de log/DC les entrées récupérées. Un must have pour ma part.
Depuis bientôt 2 ans j’ai pu m’apercevoir que les mots de passes (proxy, sites internet), viennent s’implémenter dans le coffre fort (gestionnaire d’identification). Dans notre groupe, nous supprimons tout ce qui est updater, taches planifiées, mdp dans coffre fort windows, démontage des lecteurs réseau non automatisés, démontage emplacement réseau, vérification qu’il n’y a pas d’info sur des gsm / tablettes / autres ordinateurs.
Autre outils pratique : tcpview, wireshark