Comment trouver les utilisateurs bloqués dans Active Directory avec PowerShell

Est-ce que les utilisateurs dans votre organisation oublient parfois leurs mots de passe ? Sûrement pas ! Est-ce qu’un utilisateur du Active Directory a déjà bloqué son compte ? Certainement pas ! Voyons ce que nous pouvons faire pour trouver les utilisateurs bloqués dans l’Active Directory avec PowerShell !

Arrêtez de lutter avec les appels de réinitialisation de mot de passe et les blocages de compte dans l’Active Directory. Obtenez un essai GRATUIT de Specops uReset.

Votre réseau a-t-il déjà été infecté par un logiciel malveillant qui tente de s’authentifier avec autant de comptes d’utilisateur de domaine que possible ? J’espère que non, mais j’ai vu cela se produire quelques fois. Les utilisateurs et les vers ne sont que deux des raisons pour lesquelles un ou plusieurs comptes AD peuvent être bloqués. Selon votre politique de mot de passe, les blocages peuvent être fréquents ou se produire occasionnellement.

Indépendamment de la raison ou de la situation, les blocages de compte affectent vos utilisateurs. Comme ils dépendent de leur compte de domaine Active Directory pour presque tout, ils le remarqueront immédiatement lorsqu’il sera bloqué. Le compte peut être réactivé par votre service d’assistance, mais que se passe-t-il si cela se reproduit ? …et encore. …et encore. Il est important de comprendre la cause fondamentale de ce problème.

Une façon de faire cela est d’utiliser PowerShell et le module ActiveDirectory. En utilisant la cmdlet Search-AdAccount à l’intérieur du module Active Directory, vous pouvez facilement localiser tous les comptes actuellement verrouillés sur votre domaine.

Connexe: Comment installer le module PowerShell Active Directory

Trouver les utilisateurs verrouillés dans Active Directory avec PowerShell

Pour rechercher les comptes verrouillés, vous pouvez exécuter la commande Search-AdAccount en utilisant le paramètre LockedOut. Cela renverra tous les utilisateurs actuellement verrouillés, à condition que vous ayez le droit de voir cela.

Search-AdAccount -LockedOut

Cette commande est excellente, mais que faire si vous avez un compte qui se verrouille continuellement et que vous devez déterminer à partir de quel système cela se produit? C’est une tâche courante chaque fois que vous avez une infection par un logiciel malveillant quelque part sur votre réseau, ou peut-être lorsque vous avez un administrateur distrait qui a oublié de se déconnecter d’une session Bureau à distance. Cela n’est jamais arrivé, n’est-ce pas?

Pour trouver la source d’un verrouillage dans Active Directory, vous devrez d’abord vous assurer que vous interrogez le bon contrôleur de domaine. Dans ce cas, ce sera le contrôleur de domaine avec le rôle d’émulateur PDC.

Rechercher le détenteur du rôle PDCe

Toute l’authentification par mot de passe arrivera à ce contrôleur de domaine détenant le rôle PDCe, c’est donc toujours le meilleur endroit pour vérifier. Pour trouver le contrôleur de domaine avec le rôle PDCe, vous pouvez vérifier la propriété PDCEmulator retournée par la cmdlet Get-ADDomain.

$pdce = (Get-ADDomain).PDCEmulator

Parcourir le journal des événements pour les blocages

Une fois que vous avez le DC tenant le rôle PDCe, vous devrez ensuite interroger le journal d’événements de sécurité (journaux de sécurité) de ce DC pour l’événement ID 4740. L’événement ID 4740 est l’événement enregistré chaque fois qu’un compte est bloqué. Faites ceci avec la cmdlet Get-WinEvent.

Get-WinEvent -ComputerName $pdce -FilterHashTable @{'LogName' ='Security';'Id' = 4740}

Vous êtes tellement plus près de trouver ces utilisateurs bloqués dans Active Directory avec PowerShell!

Analyse du nom d’utilisateur et de l’emplacement

Cela renverra tous les événements de blocage mais ne montre pas immédiatement les noms d’utilisateur et les ordinateurs sur lesquels le blocage a été effectué. Pour trouver le nom d’utilisateur, vous devrez plonger un peu plus en profondeur dans une propriété que Get-WinEvent renvoie appelée Properties.

$filter = @{'LogName' = 'Security';'Id' = 4740}
$events = Get-WinEvent -ComputerName $pdce -FilterHashTable $filter
$events | Select-Object @{'Name' ='UserName'; Expression={$_.Properties[0]}}, @{'Name' ='ComputerName';Expression={$_.Properties[1]}}

Vous pouvez voir que j’ai déplacé le filtre hashtable pour éviter l’enrobage de code et, plus important encore, utilisé les propriétés calculées de Select-Object pour extraire le nom d’utilisateur et le nom de l’ordinateur de la propriété Properties. Dans chacun de ces événements, le nom d’utilisateur qui a été bloqué est toujours le premier élément dans le tableau Properties tandis que le deuxième élément est toujours le nom de l’ordinateur où le blocage a été effectué.

Exploiter PowerShell pour déverrouiller les comptes AD

Maintenant que vous avez trouvé vos utilisateurs AD bloqués, comment procédez-vous pour déverrouiller les comptes ? Le module ActiveDirectory de PowerShell propose la commande Unlock-ADAccount, qui permet de rétablir rapidement un client au travail. Comme indiqué ci-dessous, utilisez PowerShell pour déverrouiller les comptes AD. Cette commande fonctionne à la fois dans Windows PowerShell et PowerShell 7, une fois chargée via le module ActiveDirectory.

Unlock-ADAccount -Identity 'lockeduser'

Peut-être cherchez-vous à déverrouiller tous les utilisateurs bloqués en même temps. Utilisez Search-ADAccount avec le paramètre -LockedOut et faites suivre les résultats de la commande Unlock-ADAccount, comme illustré ci-dessous.

Search-ADAccount -LockedOut | Unlock-ADAccount

Réduisez les appels au service d’assistance et mettez à jour les informations d’identification du cache pour les utilisateurs distants même hors VPN avec une solution de réinitialisation de mot de passe en libre-service. Obtenez une démo de Specops uReset !

Résumé

À ce stade, vous devriez être en mesure d’identifier rapidement tous les comptes actuellement verrouillés dans votre domaine, ainsi que de consulter l’historique de tous les verrouillages de compte. Il est maintenant temps de parler sérieusement à Joe au sujet de laisser ces sessions RDP ouvertes…