Comment suivre et résoudre un compte Active Directory verrouillé ? Découvrez ce qui se passe, comment trouver des événements spécifiques et comment analyser les événements.
Active Directory (AD) est un service merveilleux. Vous pouvez vous connecter de n’importe où sur le réseau en utilisant le même nom d’utilisateur et le même mot de passe. Cela ne pourrait pas être plus facile — c’est-à-dire, jusqu’à ce que vous oubliez de fermer une session de bureau à distance, ou qu’un ver se propage sur le réseau, ou que vous oubliez que vous exécutez une tâche planifiée en tant que votre compte d’utilisateur, ou…. Eh bien, vous avez compris. AD est un produit extrêmement utile ; c’est pourquoi son taux d’adoption est si élevé. Le problème est lorsqu’un compte commence à se verrouiller sans aucune raison. Ou du moins, c’est ce que vous pensez.
Politiques de verrouillage des comptes AD
De nombreuses organisations ont (ou devraient avoir) des politiques de verrouillage des comptes. Cette politique est une mesure de sécurité pour empêcher les parties non autorisées d’essayer de deviner le mot de passe en permanence ou de forcer un mot de passe par force brute. Les politiques de verrouillage des comptes sont courantes dans Active Directory et consistent en une approche simple pour lutter contre un problème de sécurité majeur. Tentez d’entrer un mauvais mot de passe un certain nombre de fois, et le compte est inutilisable jusqu’à ce qu’un administrateur le réactive manuellement. L’intention est vraie, mais dans certains cas, la mise en œuvre ne l’est pas.
Dans certaines situations, notamment lorsqu’un mot de passe est modifié, un compte peut soudainement commencer à être verrouillé de façon constante sans raison apparente. Un utilisateur appelle le service d’assistance, le service d’assistance réactive le compte, et un peu plus tard, le compte est à nouveau verrouillé. C’est une expérience frustrante tant pour l’utilisateur que pour le service d’assistance. Parfois, le problème est exacerbé par l’origine inconnue des verrouillages. Quelque part, il y a une personne, un script ou un processus qui essaie continuellement le même mauvais mot de passe, mais personne ne sait où.
Alors, comment repérer ces verrouillages gênants ? Une façon de le faire est d’utiliser un script PowerShell. Mais d’abord, passons en revue ce qui se passe lorsqu’un compte est verrouillé.
Résoudre un compte AD verrouillé
Dans un environnement Windows Server 2008 ou ultérieur, il y a un court va-et-vient entre le système client, le contrôleur de domaine du système client et le contrôleur de domaine détenant le rôle d’émulateur de contrôleur de domaine primaire (PDC). Cela se produit comme suit :
- Chaque fois qu’une authentification de compte utilisateur est tentée, les informations d’identification sont envoyées vers le haut au contrôleur de domaine approprié pour le sous-réseau du système client.
- Si le mot de passe est incorrect, le contrôleur de domaine du système client transmet la demande au contrôleur de domaine détenant le rôle d’émulateur PDC. Cela est dû au fait que le contrôleur de domaine du système client pourrait ne pas avoir le mot de passe le plus récent et, en tant que caractéristique de conception d’Active Directory, le contrôleur de domaine détenant le rôle d’émulateur PDC l’aura toujours.
- L’émulateur PDC essaie à nouveau le mot de passe, et s’il s’avère toujours qu’il est erroné, l’émulateur PDC incrémente l’attribut badPwdCount sur le compte utilisateur.
- Un événement ID 4740 est généré sur l’émulateur PDC avec l’adresse IP du système client qui a initié la requête originale et avec le compte utilisateur.
- L’émulateur PDC informe alors le contrôleur de domaine du système client que le mot de passe est, en fait, erroné.
- Le contrôleur de domaine du système client notifie alors le système client que le mot de passe était erroné.
Où serait le meilleur endroit pour trouver la source ? La réponse est à l’émulateur PDC. La raison en est que chaque verrouillage de compte y est enregistré dans le journal des événements de sécurité. L’émulateur PDC est un endroit central qui peut être interrogé pour tous les événements de verrouillage de compte.
Utiliser PowerShell pour retrouver la source des verrouillages de compte AD
Pour interroger l’émulateur PDC, nous utiliserons la cmdlet Get-WinEvent de PowerShell. Il s’agit d’une cmdlet extrêmement utile pour analyser rapidement un ou plusieurs journaux d’événements sur un serveur. Nous recherchons un événement dont l’ID est 4740. Tout d’abord, nous devons trouver le contrôleur de domaine qui détient le rôle d’émulateur PDC. Une façon de le faire est d’utiliser la cmdlet Get-AdDomain.
Une fois que nous connaissons l’émulateur PDC, alors il s’agit juste d’interroger son journal d’événements de sécurité pour l’ID d’événement 4740.
J’ai un compte appelé abertram qui est verrouillé. Voyons comment retrouver le coupable.
Nous avons maintenant l’émulateur PDC, alors interrogeons son journal de sécurité avec un script PowerShell.
## Définir le nom d’utilisateur qui est verrouillé
$Username = ‘abertram’
## Trouver le rôle PDCe du contrôleur de domaine
$Pdce = (Get-AdDomain).PDCEmulator
## Construire les paramètres à passer à Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = « * and EventData=’$Username’]] »
}
## Interroger le journal des événements de sécurité
$Events = Get-WinEvent @GweParams
Cela nous donne l’événement de verrouillage.
Mais nous n’avons pas encore le système client d’origine. Pour l’obtenir, nous devrons creuser un peu plus profondément. Le nom d’utilisateur réel est enterré dans la valeur des propriétés de chaque événement. Pour trouver le nom d’utilisateur dans chaque événement, nous pouvons simplement utiliser cette ligne.
$Events.Properties.Value
Ceci trouve le nom d’utilisateur dans le premier événement et dans la première instance de la valeur Properties. Heureusement, le système client se trouve juste dans la deuxième instance de Properties.
$Events.Properties.Value
Une fois que vous savez où se trouve le nom du système client, il suffit de l’insérer dans une boucle, et nous avons trouvé le coupable.
Maintenant vous êtes armé et prêt à partir la prochaine fois que le service d’assistance vous appelle avec cet incessant compte utilisateur AD qui ne cesse d’être verrouillé.