Compte Active Directory verrouillé : trouver quel appareil utilise l’ancien mot de passe

Déverrouiller ne corrige pas la source

Un compte qui se verrouille après chaque changement de mot de passe peut être utilisé par une tâche, un service, un appareil ou une session qui conserve un ancien secret. C’est une hypothèse à confirmer, pas un diagnostic automatique : des tentatives malveillantes peuvent produire le même symptôme.

Ce guide vise Active Directory Domain Services. Un verrouillage local Windows et le Smart Lockout Microsoft Entra sont des mécanismes distincts. Commencer par préciser le compte, le domaine et le service qui refuse la connexion.

Préparer une collecte limitée

Noter l’heure du dernier verrouillage, le fuseau, le dernier changement de mot de passe et les appareils utilisés. Conserver une chronologie en UTC. Interroger une courte fenêtre avant et après l’incident plutôt que tous les journaux du domaine.

Utiliser un poste d’administration avec RSAT/ActiveDirectory et des droits de lecture AD. La lecture du journal Security nécessite une autorisation effective sur chaque machine; ne pas attribuer Domain Admin uniquement pour ce diagnostic. La collecte distante dépend aussi du pare-feu et du service de journalisation. Une erreur d’accès n’est pas une absence d’événements.

Trouver le PDC et la stratégie effective

Le PDC Emulator est un bon point de départ, mais ne constitue pas une archive centralisée de tous les événements du domaine. Si la piste est incomplète, rechercher sur les autres contrôleurs concernés.

Une stratégie de mot de passe affinée peut remplacer celle du domaine pour cet utilisateur. Lire le seuil, la durée et la fenêtre de remise à zéro; ne pas les augmenter pour masquer le problème. Les valeurs observées dépendent aussi du DC interrogé et du moment de lecture.

# Read-only; fictional account
Import-Module ActiveDirectory
$pdc = (Get-ADDomain).PDCEmulator
$user = Get-ADUser -Identity 'alice.martin' -Server $pdc -Properties LockedOut,PasswordLastSet
$user | Select-Object SamAccountName,SID,LockedOut,PasswordLastSet
$policy = Get-ADUserResultantPasswordPolicy -Identity $user -Server $pdc
if (-not $policy) { $policy = Get-ADDefaultDomainPasswordPolicy -Server $pdc }
$policy | Select-Object LockoutThreshold,LockoutDuration,LockoutObservationWindow

• Microsoft Learn ↗

Lire 4740 sans accuser trop vite le poste

L’événement Security 4740 indique un verrouillage. Utiliser le SID du compte cible pour éviter les homonymes. Le sujet de l’événement peut être SYSTEM : il ne désigne pas automatiquement la personne qui a saisi le mauvais mot de passe.

Caller Computer Name est une piste. Un serveur intermédiaire ou un champ vide ne permet pas d’identifier directement le terminal final. Corréler l’heure et les journaux du serveur indiqué avant toute correction.

# Read-only; run after the preceding block
$start = (Get-Date).AddHours(-2)
$end = Get-Date
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
  LogName='Security'; Id=4740; StartTime=$start; EndTime=$end
} -ErrorAction Stop | ForEach-Object {
  $event = $_
  $data = @{}
  ([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
    $data[$_.Name] = $_.'#text'
  }
  if ($data.TargetSid -eq $user.SID.Value) {
    [pscustomobject]@{
      TimeUTC=$event.TimeCreated.ToUniversalTime()
      DC=$event.MachineName; RecordId=$event.RecordId
      Account=$data.TargetUserName; Caller=$data.CallerComputerName
    }
  }
} | Sort-Object TimeUTC

• Microsoft Learn ↗

Corréler Kerberos, NTLM et ouverture de session

4771 concerne les échecs de préauthentification Kerberos sur les DC. Examiner le code d’échec et l’adresse cliente; tout 4771 n’est pas un mauvais mot de passe.

4776 concerne la validation NTLM sur l’autorité du compte : un DC pour un compte de domaine. Son poste source n’est pas une preuve complète du chemin réseau. Consulter ensuite 4625 sur la machine où l’ouverture de session échoue; type de connexion, statut, sous-statut et processus peuvent orienter la recherche.

Comparer les événements précédant le verrouillage avec ceux qui suivent : un refus parce que le compte est déjà verrouillé n’explique pas forcément la cause initiale. Ne pas additionner aveuglément les événements de plusieurs DC pour reconstruire le compteur de verrouillage.

• Microsoft Learn ↗
• Microsoft — 4776 ↗
• Microsoft — 4625 ↗

Inspecter la machine identifiée

Sur le serveur ou poste suspect, chercher les services et tâches exécutés avec ce compte. Les commandes suivantes lisent la configuration locale; les exécuter sur la machine identifiée avec les droits requis. Un compte configuré ne prouve pas qu’il a provoqué le verrouillage.

Vérifier aussi sessions RDP déconnectées, lecteurs réseau, Gestionnaire d’identifiants dans la session concernée, applications, téléphones et accès VPN/Wi-Fi. Un cmdkey /list exécuté sous votre compte administrateur ne représente pas les identifiants de tous les utilisateurs. Ne pas extraire ni afficher les secrets.

# Read-only local inventory; fictional identity
$account = 'CONTOSO\alice.martin'
Get-CimInstance Win32_Service | Where-Object StartName -eq $account |
  Select-Object Name,State,StartMode,StartName
Get-ScheduledTask | Where-Object { $_.Principal.UserId -eq $account } |
  Select-Object TaskPath,TaskName,State
# Also check UPN-form identities in the approved inventory.

Exemple : une tâche toutes les quinze minutes

Alice change son mot de passe à 8 h. Les verrouillages reviennent à 8 h 15 et 8 h 30. Un 4740 pointe vers APP01; les événements locaux et l’historique du Planificateur coïncident avec une tâche exécutée sous son compte. Cette corrélation rend la tâche suspecte; confirmer avec son propriétaire et un test contrôlé.

Si le serveur indiqué est NPS, RRAS ou une passerelle, consulter ses journaux pour retrouver le client d’origine. Le nom de la passerelle ne justifie pas de la redémarrer. Plusieurs comptes touchés par une source inconnue exigent une analyse de sécurité.

Correction contrôlée et retour arrière

Changement : après validation du propriétaire, corriger uniquement l’identifiant enregistré ou la configuration identifiée. Pour un service critique, prévoir une fenêtre et sauvegarder sa configuration sans exposer le secret. Ne pas arrêter toutes les tâches ni fermer toutes les sessions en masse.

Un déverrouillage autorisé peut suivre la correction avec Unlock-ADAccount sur le seul compte concerné, avec les droits délégués nécessaires. Ce changement ne réinitialise pas le mot de passe et ne supprime pas la source des essais. Aucun déverrouillage automatique en boucle.

Valider une connexion légitime et observer au moins le cycle qui déclenchait le problème, incluant le prochain traitement planifié. En cas de régression, restaurer la configuration documentée et garder le composant fautif dans un état maîtrisé; ne pas restaurer un ancien mot de passe utilisateur comme stratégie de retour arrière.

• Microsoft Learn ↗

Journaux manquants et suivi

Vérifier la stratégie d’audit effective : gestion des comptes utilisateurs pour 4740, service d’authentification Kerberos pour 4771, validation des informations d’identification pour 4776 et ouvertures de session pour 4625. Une activation ultérieure ne recrée pas les événements perdus. Ajuster la collecte par pilote, selon le volume et la rétention approuvée.

Centraliser les événements utiles dans WEF ou le SIEM. Protéger exports et fichiers EVTX, conserver l’heure de collecte et les identifiants des événements; éviter les captures contenant des informations internes dans des billets publics.

Documenter la cause confirmée, le propriétaire, la correction et la période de surveillance. Pour les applications compatibles, envisager un gMSA afin de réduire les secrets de service gérés manuellement. Un accompagnement Active Directory peut traiter ces dépendances; ce diagnostic ciblé ne remplace pas un audit complet.