Active Directory et le verrouillage des comptes

I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer une stratégie de verrouillage des comptes Active Directory afin de protéger les comptes utilisateurs contre les tentatives de connexions malveillantes. Si quelqu'un cherche à utiliser votre compte Active Directory afin d'usurper votre identité et qu'il se trompe de mots de passe un trop grand nombre de fois, le compte sera verrouillé. Concrètement, c'est une mesure de protection contre les attaques de type brute force.

La stratégie de verrouillage des comptes n'est pas une fonctionnalité récente : l'Active Directory sous Windows Server 2003 (et peut-être même avant) intégrait déjà cette possibilité.

Au-delà de configurer la stratégie de verrouillage des comptes, nous verrons comment auditer le verrouillage des comptes et comment identifier la source du verrouillage. La mise en œuvre c'est une chose, l'exploitation en est une autre !

Pour ce tutoriel, je vais utiliser un contrôleur de domaine Active Directory sous Windows Server 2022 et un poste de travail sous Windows 11. Vous pouvez utiliser des versions plus anciennes (Windows Server 2016, Windows Server 2019, Windows 10, etc.).

Je vous recommande également de lire mon article sur les stratégies de mots de passe où je fais référence aux recommandations de l'ANSSI.

• Politique de mots de passe : comment appliquer les recommandations de l'ANSSI ?

II. La stratégie de verrouillage des comptes

Lors de la mise en place d'un Active Directory, la stratégie de verrouillage des comptes est définie dans la stratégie de groupe "Default Domain Policy". Cela signifie que cette configuration s'applique sur tous les ordinateurs (serveurs et postes de travail) membres de ce domaine. Sauf que si l'on regarde le contenu de cette stratégie, on peut voir qu'elle est définie sur "0 tentative d'ouvertures de session non valides" : ce qui signifie que, par défaut, le verrouillage des comptes n'est pas configuré. Dommage.

Pour configurer une stratégie de verrouillage des comptes via GPO sur le domaine, il y a trois choix :

• Configurer directement la GPO "Default Domain Policy"
• Créer une nouvelle GPO dédiée avec les paramètres de verrouillage en forçant l'application
• Créer une nouvelle GPO dédiée avec les paramètres de verrouillage sans forcer l'application
  • Cette solution implique que l'option "Définir ce paramètre de stratégie" soit décochée au sein du paramètre "Seuil de verrouillage du compte" de la GPO "Default Domain Policy"

Le résultat sera le même, ce n'est qu'une question de pratique. Personnellement, je préfère créer une GPO dédiée à la stratégie de verrouillage des comptes afin d'éviter de modifier la GPO par défaut du domaine.

A. Créer la GPO de verrouillage des comptes

À partir de la console de gestion des stratégies de groupe, créez une nouvelle GPO nommée "Verrouillage des comptes" liée directement à la racine de votre domaine afin de sécuriser l'ensemble des utilisateurs.

Modifiez la GPO et parcourez l'arborescence des paramètres de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de comptes > Stratégie de verrouillage du compte

A cet endroit, nous retrouvons 3 paramètres :

• Seuil de verrouillage du compte : au bout de combien de tentatives d'ouvertures de session non valides faut-il verrouiller le compte ?
• Réinitialiser le compteur de verrouillages du compte après : ce paramètre détermine l'intervalle de temps pendant lequel on doit compter les tentatives en échecs avant de remettre le compte à zéro. L'idée étant de ne pas compter indéfiniment, car sinon le compte finira forcément par se verrouiller si l'utilisateur se trompe de mot de passe une fois de temps en temps.
• Durée de verrouillage de comptes : pendant combien de temps faut-il verrouiller le compte ?

Commencez par modifier le paramètre "Seuil de verrouillage du compte" afin de l'activer en cochant "Définir ce paramètre de stratégie". Ensuite, indiquez "10" pour que le compte soit verrouillé après 10 tentatives en échecs.

Cette valeur n'est pas choisie au hasard : cette valeur et celles qui suivront sont conformes aux recommandations de Microsoft intégrée au Microsoft Security Compliance Toolkit, en matière de sécurité.

On vous propose de définir les deux autres paramètres sur "30 minutes", cliquez sur "OK".

Modifiez les deux autres paramètres en mettant 15 minutes à chaque fois. Vous devez obtenir cette configuration :

En résumé, s'il y a eu 10 erreurs de mots de passe dans un intervalle de 15 minutes, alors le compte est verrouillé automatiquement pendant 15 minutes.

La GPO est prête, mais si vous n'avez pas décoché l'option du paramètre "Seuil de verrouillage du compte" de la GPO "Default Domain Policy" (comme expliqué précédemment), vous devez penser à forcer la GPO pour qu'elle soit prioritaire. Pour cela, effectuez un clic droit sur la GPO puis "Appliqué".

B. Vérifier que la GPO s'applique bien

Rendez-vous sur un poste de travail où s'applique la GPO afin de se connecter avec un utilisateur. Avant toute chose, il faut effectuer un "gpupdate /force" et redémarrer la machine.

Ensuite, pour vérifier que la GPO est bien appliquée, on peut utiliser l'outil "Gpresult" mais aussi une commande bien pratique pour gagner du temps :

net accounts

On voit bien les trois options liées au verrouillage et les valeurs correspondent bien à notre GPO !

III. Compte verrouillé : que se passe-t-il dans l'AD ?

La protection est configurée, mais nous devons la tester. Pour cela, c'est simple : il suffit de se connecter en boucle sur une machine en saisissant des mots de passe bidon. Au bout de 10 tentatives en échecs, le compte va se verrouiller.

Windows affichera un message pour préciser que le compte est verrouillé. De mon côté, j'ai pris l'utilisateur "Vincent Timmes" comme cobaye et désormais quand j'essaie de me connecter, j'obtiens : "Par mesure de sécurité, le compte de l’utilisateur a été verrouillé suite à un nombre excessif de tentatives de connexion ou de modification du mot de passe. Attendez un peu avant de réessayer, ou contactez votre administrateur système ou votre service de support technique."

Au niveau de l'Active Directory, si je regarde les propriétés du compte utilisateur "Vincent Timmes", je peux voir dans l'onglet "Compte" que le compte est verrouillé : "Déverrouiller le compte. Ce compte est actuellement verrouillé sur ce contrôleur de domaine Active Directory". Pour déverrouiller le compte sans attendre la fin du temps imparti, il faut cocher l'option et valider. Une manipulation utile si c'est un utilisateur qui a verrouillé son compte par erreur.

Si l'on veut en savoir un peu plus sur ce verrouillage de compte, il faut basculer sur l'éditeur d'attributs. L'attribut "lockoutTime" indique la date et l'heure à laquelle a eu lieu cet incident de sécurité. Je remarque la valeur suivante :

132890901190781735

Lorsqu'un compte n'est pas verrouillé, l'attribut "lockoutTime" est égal à "0" contrairement à certains attributs qui sont en "non défini".

Ce timestamp peut-être converti avec la commande suivante :

w32tm.exe /ntte 132890901190781735

Vu la date et l'heure du verrouillage, cela ressemble à une action malveillante ! 😉

IV. Les commandes Search-ADAccount et Unlock-ADAccount

En utilisant PowerShell, on peut également lister facilement les comptes verrouillés en effectuant une recherche sur l'annuaire :

Search-ADAccount -LockedOut

Avec PowerSell, on peut utiliser Get-ADUser pour récupérer le lockoutTime de l'utilisateur et le convertir directement. On obtient la commande suivante :

Get-ADUser -Identity vincent.timmes -Properties lockoutTime | Select sAMAccountName,@{Name="LockoutTime";Expression={([datetime]::FromFileTime($_.lockoutTime).ToLocalTime())}}

En couplant l'utilisation de cette commande avec la présente, on peut sortir une liste des comptes verrouillés avec la date et l'heure de verrouillage. Pour chaque compte verrouillé, on récupère l'identifiant sAMAccountName et le lockoutTime. On va également classer les événements du plus récent au plus ancien, pour les avoir dans l'ordre chronologique.

Voici la commande :

Search-ADAccount -LockedOut | Get-ADUser -Properties lockoutTime | Select sAMAccountName,@{Name="LockoutTime";Expression={([datetime]::FromFileTime($_.lockoutTime).ToLocalTime())}} | Sort LockoutTime -Descending

Le résultat est plutôt sympa :

Enfin, on peut déverrouiller un compte utilisateur avec PowerShell avec Unlock-ADAccount :

Unlock-ADAccount -Identity vincent.timmes

V. Auditer le verrouillage des comptes

Par défaut, lorsqu'un compte est verrouillé, Windows génère un événement dans l'Observateur d'événements afin de consigner l'incident. Néanmoins, pour être sûr que cette configuration d'audit soit appliquée sur les contrôleurs de domaine, nous allons créer une deuxième GPO : "Verrouillage des comptes - Audit".

Modifiez la GPO et parcourez l'arborescence des paramètres de cette façon :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de l'audit > Ouvrir/fermer la session

A cet endroit, nous retrouvons plusieurs paramètres à activer comme sur l'image ci-dessous :

• Auditer le verrouillage du compte
• Auditer la fermeture de session
• Auditer l'ouverture de session

D'une part pour surveiller les verrouillages de comptes, mais aussi pour suivre les ouvertures et fermetures de session. Ce sera utile pour investiguer plus précisément en cas d'incident.

La GPO "Verrouillage des comptes - Audit" est directement appliquée sur l'OU "Domain Controllers". Voici les paramètres à activer au final (à reproduire sur votre GPO). Le paramètre "Audit : forcer les paramètres des sous-catégories..." doit être activé lorsque l'on souhaite utiliser l'audit avancé.

Voyons ce que ça donne au niveau des logs Windows.

VI. Voir la source d'un verrouillage de compte

Après avoir effectué un nouveau verrouillage d'un compte, il faut se rendre au sein de l'observateur d'événements de Windows : Journaux Windows > Sécurité.

L'idée, c'est de filtrer le journal pour afficher uniquement les événements avec l'ID "4740". Pour cela, effectuez un clic droit sur "Sécurité" puis "Filtrer le journal actuel" et indiquez l'ID "4740".

De mon côté, j'obtiens plusieurs événements, voici un exemple :

Nous pouvons voir plusieurs informations intéressantes :

• Compte verrouillé avec le nom du compte
• La date et l'heure de l'événement
• Nom de l'ordinateur appelant : c'est la source de l'attaque, cela permet de savoir d'où provient la tentative de connexion !

Au sujet des événements 4740, vous devez savoir ce qui suit :

L'événement 4740 sera généré sur le contrôleur de domaine auprès duquel l'utilisateur a essayé de s'authentifier. Généralement, cela correspond au contrôleur de domaine le plus proche. Dans le cas où l'on a plusieurs DC, les événements peuvent être éparpillés entre vos contrôleurs de domaine. Fort heureusement, le processus d'authentification intègre un mécanisme qui, en cas de tentatives d'authentification en échecs, oblige le DC d'origine à contacter le DC qui détient le rôle FSMO d'Emulateur PDC. C'est ce DC qui traite le verrouillage des comptes. Le contrôleur de domaine avec le rôle d'émulateur PDC va centraliser les événements 4740 de tous les contrôleurs de domaine.

Remarques : le contenu du journal sera influencé en cas d'indisponibilité du DC émulateur PDC et dans ce cas, il pourra manquer des événements. Malgré tout, en cas d'indisponibilité, le compte sera bien verrouillé par le DC qui traite les requêtes d'authentification, ce qui est rassurant.

Par ailleurs, dans les infrastructures avec un grand nombre de DC, il me semble pertinent d'augmenter la taille du journal "Sécurité" sur l'émulateur PDC. Enfin, vos journaux sont peut-être collectés et analysés par un SIEM directement.

Si vous ne savez pas trop quel est l'émulateur PDC sur votre infra, exécutez cette commande :

(Get-AdDomain).PDCEmulator

Pour aller plus loin dans la consultation de ces événements, il y a plusieurs possibilités, dont :

• Utiliser PowerShell pour consulter l'observateur d'événements d'un ou plusieurs DCs (l'exemple ci-dessous récupère le dernier log avec l'ID 4740).

Get-EventLog -LogName Security -InstanceId 4740 -Newest 1 | fl

• Utiliser l'outil gratuit "Microsoft Account Lockout and Management Tools" qui, bien que très vieux, peut être utile pour afficher quelques informations, dont le nombre de mauvais mots de passe, etc... Simplement.

• Utiliser l'outil gratuit "Netwrix Account Lockout Examiner" qui, pour un compte précis, va rechercher les logs correspondants sur les différents DC et indiquer la source.

Grâce à cet article, vous êtes en mesure de mettre en place une stratégie de verrouillage de comptes et de consulter les journaux d'audit en cas d'incident.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio