Auditer les comptes orphelins Active Directory

Auditer les comptes orphelins Active Directory

Un compte de départ non désactivé est une porte d’entrée, pas une anomalie administrative. L’audit doit rapprocher l’annuaire, le registre des départs et les droits réellement accordés, puis produire des actions traçables et réversibles. Le compromis central est net : désactiver vite réduit l’exposition, mais peut interrompre un service mal inventorié. La règle est donc de suspendre d’abord, supprimer après preuve.

Explication de la marmotte

Cet audit ressemble à la vérification des clés d’un immeuble après un déménagement : certaines clés devraient avoir été rendues, d’autres ouvrent des pièces où leur détenteur n’a plus rien à faire. Le but est de retirer les accès inutiles sans bloquer ceux qui travaillent encore.

→ Lire l’explication complète de la marmotte

Préparer les sources Active Directory et RH

Active Directory (AD) doit être interrogé depuis une station d’administration protégée, avec le module PowerShell ActiveDirectory installé via les outils d’administration de serveur distant. Le compte d’audit ne reçoit aucun droit d’écriture : déléguer la lecture sur le domaine suffit pour l’inventaire initial. Séparer lecture et remédiation évite qu’un script de diagnostic se découvre une vocation de tronçonneuse.

Prévoir avant l’export :

• un contrôleur de domaine joignable et synchronisé sur une source de temps fiable ;
• PowerShell 7 ou Windows PowerShell 5.1 avec le module ActiveDirectory ;
• un répertoire de travail chiffré, à accès restreint, pour les fichiers CSV (Comma-Separated Values, valeurs séparées par des virgules) ;
• un registre RH des départs comportant au minimum un identifiant stable, une date de sortie et un statut ;
• une table de correspondance entre l’identifiant RH et employeeID, userPrincipalName ou sAMAccountName dans AD ;
• une approbation du propriétaire métier pour chaque groupe à privilèges.

Le registre RH est la source d’autorité sur le départ d’une personne. AD n’est qu’une copie technique, souvent incomplète et parfois créative. Une date de dernière connexion ne prouve pas qu’un compte est légitime : un compte compromis peut rester actif sans se connecter, et un compte de service peut ne jamais ouvrir de session interactive.

Définir la fenêtre d’inactivité avant de commencer. Pour les comptes humains, 45 à 90 jours est généralement un seuil de tri acceptable, pas un motif automatique de désactivation. Pour les comptes de service, l’inactivité doit être mesurée sur les journaux applicatifs, les tâches planifiées, les services Windows et les authentifications réseau. Désactiver un compte de service parce que lastLogonTimestamp paraît vieux est une façon très efficace de découvrir une dépendance oubliée, généralement pendant une période où personne ne souhaite la découvrir.

Les attributs lastLogon et lastLogonTimestamp n’ont pas la même sémantique. lastLogon est précis mais local à chaque contrôleur de domaine. lastLogonTimestamp est répliqué, mais sa mise à jour est volontairement approximative, avec un délai pouvant atteindre environ 14 jours selon la configuration. Pour une décision de sécurité urgente, interroger tous les contrôleurs de domaine et retenir la date maximale.

Pour le durcissement de l’annuaire, compléter cet audit par la désactivation des binds LDAP en clair et anonymes. Un inventaire propre ne compense pas un annuaire exposé à des authentifications faibles.

Exporter les comptes actifs et les dernières connexions

Commencer par un export exhaustif, horodaté et immuable. Inclure les comptes activés, mais aussi les comptes désactivés pour détecter les réactivations anormales. Exclure explicitement les comptes intégrés et les comptes de service identifiés, sans les faire disparaître du rapport : les exclure du traitement automatique, pas de la visibilité.

L’exemple suivant exporte les comptes humains actifs d’un domaine AD. Il transforme lastLogonTimestamp en date lisible et marque les comptes dont la dernière activité répliquée dépasse 90 jours.

Exemple PowerShell d’export Active Directory

# Exécuter depuis une station d'administration avec le module ActiveDirectory.
Import-Module ActiveDirectory

$seuilInactivite = (Get-Date).AddDays(-90)
$horodatage = Get-Date -Format "yyyyMMdd-HHmmss"
$sortie = "C:\Audit-AD\comptes-actifs-$horodatage.csv"

Get-ADUser -Filter 'Enabled -eq $true' `
  -Properties employeeID, department, title, whenCreated, lastLogonTimestamp,
              passwordLastSet, servicePrincipalName, adminCount |
  Where-Object {
    # Exclure du traitement humain les comptes portant un SPN de service,
    # mais conserver ces objets dans un export distinct.
    $_.servicePrincipalName.Count -eq 0
  } |
  Select-Object `
    SamAccountName,
    UserPrincipalName,
    EmployeeID,
    Name,
    Department,
    Title,
    Enabled,
    WhenCreated,
    PasswordLastSet,
    AdminCount,
    @{Name = 'DerniereConnexionReplice'; Expression = {
      if ($_.lastLogonTimestamp) {
        [DateTime]::FromFileTime($_.lastLogonTimestamp)
      }
    }},
    @{Name = 'InactifPlusDe90Jours'; Expression = {
      if ($_.lastLogonTimestamp) {
        [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt $seuilInactivite
      } else {
        $true
      }
    }} |
  Export-Csv -Path $sortie -NoTypeInformation -Encoding UTF8

Write-Host "Export créé : $sortie"

Conserver le hachage cryptographique du fichier exporté, son horodatage et l’identité de l’opérateur. Un fichier modifié après coup sans trace ne sert qu’à produire une discussion circulaire, cette espèce invasive des comités d’audit.

Pour obtenir une dernière connexion exacte, parcourir chaque contrôleur de domaine avec Get-ADDomainController -Filter *, lire lastLogon pour chaque compte, puis conserver la valeur la plus récente. Cette opération est coûteuse dans les grands domaines. La réserver aux comptes candidats à désactivation et aux membres de groupes privilégiés, plutôt qu’à l’ensemble de l’annuaire à chaque exécution.

Dans Microsoft Entra ID, anciennement Azure Active Directory, exporter les utilisateurs actifs et l’activité de connexion via Microsoft Graph. La propriété de dernière connexion dépend de la rétention des journaux et des licences disponibles. Ne jamais interpréter une absence de donnée comme une absence d’activité : c’est souvent une limite de collecte, pas une preuve.

Croiser les départs RH avec les identités d’annuaire

Normaliser d’abord les identifiants. Les espaces, accents, changements de nom et adresses électroniques secondaires font échouer les jointures approximatives. Le meilleur pivot est employeeID, alimenté à la création du compte depuis le système RH. À défaut, utiliser une table de correspondance versionnée, validée par les équipes RH et identité.

Produire trois listes distinctes :

1. les départs RH avec un compte AD encore actif ;
2. les comptes actifs sans identifiant RH ni propriétaire déclaré ;
3. les comptes RH actifs sans compte correspondant, utiles pour repérer un défaut de provisioning ou un usage d’identité partagée.

Le premier groupe est prioritaire. Un départ daté, un compte activé et une authentification récente forment un signal critique. Une authentification absente ne réduit pas la priorité : un mot de passe connu, un jeton déjà émis ou une boîte aux lettres surveillée peuvent suffire à l’attaquant.

Contrôler aussi les identités non humaines : comptes de service, comptes d’administration séparés, comptes de secours et comptes techniques de synchronisation. Aucun d’eux ne doit être exempté parce que son nom commence par svc_. Ce préfixe ne confère aucun pouvoir magique, malgré une longue carrière dans les conventions de nommage.

La désactivation d’un compte de départ doit invalider les accès associés : sessions de fédération, jetons d’actualisation, clés d’accès cloud, certificats utilisateur, boîtes partagées et appareils enregistrés. La gestion des identités doit définir quelle source pilote chaque révocation. Désactiver uniquement l’objet AD laisse les accès fédérés et les secrets hors annuaire continuer leur petite existence administrative.

Examiner les groupes à privilèges élevés

Les groupes à examiner en priorité comprennent Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Group Policy Creator Owners et les groupes locaux administrateurs distribués par stratégie de groupe. Ajouter les groupes donnant accès aux coffres de secrets, aux consoles de sauvegarde, aux plateformes de virtualisation et aux rôles cloud à privilèges.

L’appartenance directe ne suffit pas. Les groupes imbriqués accordent des privilèges effectifs sans apparaître dans une lecture superficielle. Interroger les membres récursivement, puis conserver le chemin d’appartenance : compte, groupe intermédiaire, groupe privilégié. Sans ce chemin, la remédiation retire souvent le mauvais maillon et le droit revient par une autre branche.

Pour chaque identité privilégiée, exiger quatre preuves :

• une fonction actuelle justifiant le privilège ;
• un propriétaire métier nommément désigné ;
• une date de revue et une date d’expiration si l’accès est temporaire ;
• une identité d’administration séparée de l’identité bureautique.

adminCount=1 est un indicateur à inspecter, pas une liste de privilèges. Cet attribut peut rester positionné après retrait d’un groupe protégé. Les contrôles d’accès réels dépendent des listes de contrôle d’accès, des groupes locaux, des délégations d’unités organisationnelles et des rôles cloud. L’article sur la persistance IAM dans AWS illustre le même problème côté cloud : le privilège durable se cache rarement dans un seul tableau de membres.

Remédier sans casser les accès nécessaires

Désactiver avant de supprimer. La désactivation bloque les nouvelles authentifications tout en conservant les attributs, les appartenances et les éléments nécessaires à une enquête ou à une restauration. Appliquer un délai de quarantaine de 30 à 90 jours selon les obligations internes et les sauvegardes disponibles. La suppression définitive intervient seulement après validation RH, expiration du délai et vérification des dépendances.

Pour un compte de départ, exécuter dans cet ordre :

1. désactiver le compte ;
2. révoquer les sessions et jetons dans les systèmes fédérés ;
3. retirer les groupes privilégiés et les accès applicatifs ;
4. tourner les secrets, mots de passe de service, clés d’interface et certificats auxquels le compte pouvait accéder ;
5. déplacer l’objet vers une unité organisationnelle de quarantaine avec une stratégie restrictive ;
6. documenter le motif, l’approbateur, la date, les groupes retirés et le ticket de changement.

La rotation est indispensable après une exposition potentielle. Désactiver un compte ne retire pas les clés privées exportées, les mots de passe déposés dans un coffre personnel ou les jetons copiés dans une machine compromise. Un annuaire ne peut pas révoquer ce qu’il n’a jamais contrôlé. C’est précisément la limite que les présentations sur la « gouvernance des identités unifiée » préfèrent traiter en police de taille huit.

Ne supprimer ni boîte aux lettres, ni profil, ni dossier personnel dans le même changement. Ces données relèvent de politiques de conservation, de transfert métier et parfois d’investigations. La suppression d’identité est une action technique ; la conservation des données est une décision de gouvernance.

Supervision, preuves et revue récurrente

Journaliser les modifications de comptes, de groupes privilégiés et de stratégies de groupe dans les journaux de sécurité Windows, puis les envoyer vers une plateforme de centralisation. Surveiller au minimum les créations, activations, désactivations, réinitialisations de mot de passe, ajouts à un groupe privilégié et changements de délégation. Une alerte sur l’ajout à Domain Admins après plusieurs heures n’est pas une détection, c’est une archive avec un gyrophare.

Planifier deux cadences :

• quotidiennement, rapprocher les départs RH des comptes actifs et déclencher une alerte ;
• mensuellement, revoir les privilèges élevés avec un propriétaire métier ;
• trimestriellement, certifier les accès ordinaires par responsable hiérarchique ;
• annuellement, tester la restauration d’un compte supprimé depuis les sauvegardes d’annuaire.

Sauvegarder l’état avant remédiation : export des attributs, appartenances de groupes, délégations et listes de contrôle d’accès. Tester la restauration dans un environnement isolé. Une sauvegarde d’AD qui n’a jamais été restaurée est une hypothèse réconfortante, pas un plan de reprise.

L’audit ne garantit pas l’absence de comptes compromis, de privilèges applicatifs invisibles ou d’accès physiques. Il réduit l’exposition liée aux identités connues. La détection d’activité suspecte, le durcissement des protocoles d’authentification et la protection des comptes à privilèges restent nécessaires, notamment face aux faiblesses de NTLM et de son durcissement.

🐝 Ce qui arrive si on s’en passe

Sans ce rapprochement récurrent, l’annuaire devient une accumulation de comptes dont plus personne ne connaît le propriétaire. Un compte de départ resté actif conserve son mot de passe, ses appartenances et ses jetons : il s’authentifie sans déclencher la moindre alerte, puisqu’il fait partie du décor. Les groupes imbriqués prolongent silencieusement des privilèges que personne ne relit, et un attaquant qui obtient une de ces identités hérite d’un accès légitime plutôt que d’une intrusion détectable. L’absence d’export horodaté et de sauvegarde des appartenances coûte aussi la traçabilité : impossible, après incident, de déterminer quels droits un compte détenait à une date donnée, ni de restaurer un objet supprimé par erreur. La revue des privilèges devient alors une reconstruction approximative, menée sous pression, sans état de référence.

🦫 Explication de la marmotte 🍫

Un annuaire d’entreprise conserve les comptes qui permettent aux personnes et aux programmes de se connecter aux outils. L’audit commence par extraire la liste des comptes encore actifs, avec leur dernière utilisation connue, leur service et les groupes auxquels ils appartiennent. Cette liste est comparée au registre des départs fourni par les ressources humaines. Si une personne est partie mais que son compte est encore actif, le compte devient un candidat prioritaire à la suspension.

La date de dernière connexion aide à repérer les comptes oubliés, mais elle ne suffit pas pour décider. Certaines dates sont mises à jour avec retard, et certains programmes fonctionnent sans connexion interactive. Il faut donc vérifier le rôle du compte et son propriétaire.

Ensuite, la vérification porte sur les groupes qui donnent des pouvoirs élevés, par exemple modifier des comptes, lire des sauvegardes ou administrer des serveurs. Chaque membre doit avoir une fonction actuelle qui justifie cet accès. Il faut aussi rechercher les groupes inclus dans d’autres groupes, car un droit peut être obtenu indirectement.

Quand un accès n’est plus justifié, le compte est d’abord désactivé plutôt que supprimé. Les accès associés sont retirés, les secrets potentiellement exposés sont changés, et chaque action est enregistrée. Après un délai défini et après contrôle des dépendances, la suppression peut être décidée. Si le rapprochement avec les départs cesse ou si les journaux ne sont pas surveillés, les comptes inutiles reviennent : l’audit doit donc être répété automatiquement.

À lire aussi

• Configurer Windows Hello for Business sans mot de passeGuide pratique de déploiement de l’authentification sans mot de passe sur Active Directory avec Windows Hello for Business.
• Comment automatiser la recertification des accès sensiblesGuide pratique pour mettre en place une revue d'accès périodique, du premier cycle manuel à la désactivation automatisée des droits non recertifiés.
• Active Directory délégations et chemins d’attaqueComprendre la structure Active Directory, les délégations abusables et les chemins d’attaque vers les privilèges de domaine.
• L'administration Active Directory en tiers en une pageTiers 0, 1 et 2 : pourquoi un admin du domaine connecté sur un poste de travail expose tout le domaine, et les cloisons qui l'en empêchent : un compte par tier, poste d'administration dédié, LAPS, Protected Users.

Pages voisines

La citent

• Comment sécuriser un mainframe qu’on n’ose plus toucher
• Les comptes de service oubliés

Auditer les comptes orphelins Active Directory

Elle cite

• ⇄Lien dans les deux sens :Comment auditer les comptes orphelins après un départ
• Auditer l'héritage des permissions et le droit effectif
• Gouverner les comptes de service et agents autonomes
• Grand-père Castor raconte : bind LDAP en clair, corrigé
• NTLM : protocole authentification LAN Manager New Technology Microsoft

⇄ : les deux pages se citent l’une l’autre.