Revue ordinateur AD whenChanged : établir la provenance

Qu'est-ce qu'une revue whenChanged d'un ordinateur AD désactivé ?

Une revue whenChanged d'un ordinateur AD désactivé part d'un compte ordinateur actuellement désactivé et d'un ancien horodatage de modification dans l'annuaire. Elle cherche à déterminer si le compte doit rester dans Active Directory, qui est responsable de cette décision et quelles preuves justifient son retrait. L'horodatage aide à prioriser l'investigation ; il n'établit pas quand le compte a été désactivé.

Cette distinction compte lorsqu'une liste de nettoyage devient une file de suppression. Un compte désactivé peut appartenir à un poste retiré du service, une machine temporairement isolée, une identité de service ou une infrastructure en attente d'une procédure de mise hors service distincte. Un constat d'audit ne fournit aucune de ces décisions métier. Conservez séparément les preuves de l'état actuel du compte, de la provenance de sa désactivation et de l'approbation de son retrait.

La revue décrite ici fait suite au constat COMPUTER_DISABLED_NOT_DELETED d'etc-collector. Elle n'introduit aucun calendrier universel de suppression et ne déduit pas une attaque d'un ancien horodatage. Le résultat est une décision documentée pour un objet identifié : le conserver pour un motif dont un responsable répond, rechercher les preuves manquantes ou le retirer selon une procédure approuvée après résolution de ses dépendances.

Fonctionnement : la dernière modification n'établit pas la provenance de la désactivation

La référence Microsoft de l'attribut whenChanged définit cette valeur comme la date de dernière modification de l'objet. Le système la met à jour chaque fois que l'objet change. La valeur n'est pas répliquée : consignez donc le contrôleur de domaine qui a fourni l'observation et le moment de la lecture.

Définir l'état désactivé modifie l'objet, mais la valeur actuelle de whenChanged n'identifie pas cette opération. Une modification ultérieure peut remplacer l'horodatage précédent alors que le compte reste désactivé. Lire une valeur récente n'établit donc pas une désactivation récente ; lire une valeur ancienne n'en fournit ni l'auteur, ni le motif, ni l'approbation. Traitez l'attribut comme une observation de modification provenant du DC choisi, plutôt que comme un champ dédié à la date de désactivation.

Conservez ces distinctions dans le dossier de revue :

Notre guide d'hygiène des objets ordinateur Active Directory fournit le contexte plus large du cycle de vie, notamment les contrôleurs de domaine, LAPS et les objets ordinateur obsolètes. Ses cadences de nettoyage illustratives ne prouvent pas une date de désactivation et ne sont pas reprises comme seuils pour cette revue. Une observation de dernière connexion ou de mot de passe machine répondrait à une autre question ; aucune ne remplace ici les preuves de désactivation du compte.

Détection : établir l'état actuel et examiner la transition

Étape 1 : lire l'objet exact depuis un DC nommé

Utilisez le module ActiveDirectory sur un poste d'administration autorisé. La référence Microsoft de Get-ADComputer documente -Identity, -Properties et -Server. Demandez explicitement les attributs LDAP et nommez un serveur d'annuaire au lieu de dépendre d'une sélection implicite :

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

La projection utilise la syntaxe documentée de Select-Object de Microsoft. Conservez l'identité de l'ordinateur, le DC choisi, l'heure de lecture et le résultat de la collecte avec les champs affichés. Une requête échouée constitue une preuve incomplète. Un attribut indisponible n'est pas un résultat négatif fiable simplement parce que la collecte a renvoyé un objet.

Le parseur LDAP examiné déduit Disabled du bit ACCOUNTDISABLE, 0x0002, de userAccountControl dans l'annuaire. La propriété Enabled affichée et l'attribut brut fournissent des observations de l'état actuel à rapprocher. Ils n'enregistrent pas depuis combien de temps le compte est désactivé. Si la lecture actuelle contredit l'audit, examinez le moment de collecte, l'identité cible et les observations des DC avant d'agir sur l'ancien constat.

Étape 2 : utiliser l'événement 4742 uniquement lorsque ses preuves s'appliquent

Microsoft documente l'événement 4742, modification d'un compte ordinateur, dans la sous-catégorie Audit Computer Account Management. Il est généré sur les contrôleurs de domaine. Examinez les journaux Security des DC pertinents ou leurs copies collectées, avec une configuration d'audit et une rétention suffisantes pour couvrir la transition présumée.

Dans un SIEM, limitez l'investigation à l'événement 4742 et au TargetSid du compte modifié. Examinez l'événement brut, pas seulement un résumé normalisé. Conservez l'heure de l'événement, le DC émetteur, l'identifiant de l'enregistrement, l'identité cible, l'identité du sujet, OldUacValue, NewUacValue et les informations de contrôle du compte modifiées. Comparez toute transition de désactivation alléguée au dossier approuvé de changement ou d'incident et à la lecture actuelle de l'annuaire. Un nom de compte correspondant apporte un contexte moins solide que le SID cible vérifié.

La documentation précise explicitement que certaines modifications ne génèrent pas d'événement 4742. D'autres événements peuvent afficher des tirets pour tous les attributs modifiés présentés, sans permettre d'identifier l'attribut modifié. Une entrée 4742 pour l'objet ne prouve donc pas automatiquement sa désactivation. Elle peut documenter une autre modification du compte, et une recherche dans les journaux peut ne pas couvrir le DC ou la période pertinents.

Les champs UAC ancien et nouveau de 4742 utilisent l'implémentation SAM des indicateurs de compte, dont les définitions diffèrent de celles de userAccountControl LDAP. N'appliquez pas le masque LDAP 0x0002 à ces champs d'événement pour affirmer une transition de désactivation. Interprétez la transition enregistrée selon les définitions des indicateurs de compte documentées pour l'événement et conservez les valeurs brutes pour la revue.

Étape 3 : rapprocher les preuves de la responsabilité

Demandez au responsable si la machine est encore nécessaire, temporairement isolée, remplacée ou officiellement mise hors service. Reliez sa réponse à l'identité exacte dans l'annuaire. Conservez séparément le motif de désactivation, les preuves disponibles de la transition et la décision de retrait. Lorsque les preuves historiques manquent, décrivez directement cette lacune au lieu de construire une date à partir de la dernière modification de l'objet.

Une modification inexpliquée touchant une identité critique nécessite une investigation avant le nettoyage du cycle de vie. À l'inverse, une décision de conservation approuvée peut être légitime même si le détecteur continue à signaler l'objet. Consignez qui réexaminera cette décision et quelle condition justifierait le retrait. Faire disparaître le constat ne constitue pas en soi une exigence métier de suppression du compte.

Remédiation : valider les dépendances avant une suppression approuvée (Remediation)

Étape 1 : classifier l'objet et résoudre les inconnues

Confirmez la classe de l'objet et son rôle opérationnel avant de choisir une procédure de retrait. Le détecteur n'exclut pas explicitement les contrôleurs de domaine ni les comptes de service administrés de groupe. Un contrôleur de domaine nécessite sa procédure adaptée de mise hors service ; une identité de service exige la vérification de ses dépendances de service. Un exemple générique de suppression de poste n'autorise pas à appliquer la même action à chaque objet renvoyé par le collecteur.

Rapprochez l'état actuel du compte, la réponse du responsable et les dossiers de mise hors service. Gardez les cas non résolus en attente avec une prochaine action attribuée à un responsable. Ce processus ne fixe pas de nouvelle durée générique de vieillissement : le temps écoulé ne peut pas établir que les besoins en services, en enregistrements ou en récupération ont pris fin.

Étape 2 : inventorier les enfants et les dépendances de récupération

Lisez les enfants immédiats de l'objet ordinateur vérifié à l'aide des paramètres de recherche documentés de Get-ADObject de Microsoft. Cet exemple utilise le $computer renvoyé plus haut et demande les identifiants et classes d'objet, plutôt que des secrets de récupération :

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel ne recherche que les enfants immédiats. Si un enfant possède ses propres descendants ou si l'inventaire est incomplet, examinez cette structure et son objectif avant de poursuivre. Un résultat vide avec une visibilité non vérifiée ne prouve pas l'absence d'objets dépendants. Consignez les échecs d'accès et les incertitudes de périmètre comme des points d'inventaire non résolus.

Incluez les informations de récupération BitLocker dans la revue des dépendances. Notre guide de vérification de la récupération BitLocker dans AD : faire correspondre l'enregistrement d'annuaire au protecteur actuel du volume explique pourquoi un objet de récupération doit correspondre au protecteur de récupération réellement présent sur le volume. Sa seule présence n'établit pas une récupération utilisable, et sa date n'établit pas quand le compte ordinateur a été désactivé.

Convenez de la manière dont les informations de récupération nécessaires et les autres données enfants resteront disponibles selon le processus approuvé de récupération et de rétention de l'organisation, avant de supprimer l'ordinateur. Excluez les secrets des tickets de nettoyage et des enregistrements SIEM. Consignez la décision concernant les dépendances et son responsable, plutôt que de copier les mots de passe de récupération dans les preuves. Il s'agit d'une vérification des dépendances du retrait ; le guide lié fournit la procédure distincte de vérification du volume et du protecteur.

Étape 3 : prévisualiser et effectuer uniquement la suppression approuvée d'un objet unique

Après les vérifications du responsable, de la mise hors service, des dépendances et de la récupération, utilisez la syntaxe Microsoft de Remove-ADComputer pour l'objet vérifié. La documentation prend en charge une identité GUID, un serveur explicite et -WhatIf. La prévisualisation suivante n'exécute pas la suppression :

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Comparez la cible et la prévisualisation au dossier de retrait approuvé. Une prévisualisation ne vérifie ni que la machine est inutilisée, ni que les données de récupération sont préservées, ni que l'action a été approuvée. Relisez l'objet actuel avant l'opération autorisée si les preuves ont pu changer.

Uniquement après cette validation, la commande sur un objet unique conserve une demande explicite de confirmation :

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

Si des enfants, une protection ou une autre erreur empêchent la suppression, arrêtez-vous et résolvez la cause précise selon la procédure approuvée. Ne transformez pas un échec en suppression récursive de l'ordinateur et de ses descendants. Conservez le résultat réel de la commande ; une opération tentée ne prouve pas que le compte a été supprimé.

Étape 4 : clôturer la revue avec des preuves

Consignez la décision finale, l'approbateur, les décisions concernant les dépendances et le résultat de l'opération. Vérifiez le résultat dans l'annuaire par une lecture autorisée de l'identité exacte sur le DC enregistré, en conservant toute erreur et sa signification. Confirmez que les informations de récupération nécessaires restent disponibles selon le processus convenu. Pour un objet conservé, documentez le motif de conservation et l'investigation restante au lieu de déclarer la remédiation terminée.

Comment EtcSec détecte ce cas

Au commit du collecteur examiné 20268a321609c193b79c5da6764f3f56950449cb, COMPUTER_DISABLED_NOT_DELETED est un constat de sévérité Low. Son Detect() examine les ordinateurs collectés et n'inclut un objet que si Disabled vaut true, si WhenChanged n'est pas nul et si WhenChanged.Before(Now.AddDate(0, 0, -30)) vaut true. La comparaison est stricte : un horodatage égal au seuil est exclu.

Le seuil retranche 30 jours calendaires au Now de l'audit. C'est un repère d'hygiène opérationnelle d'etc-collector, pas une échéance de suppression exigée par Microsoft ou une autre norme nommée. Une modification ultérieure de l'objet avance whenChanged et peut retarder ce signal alors que le compte reste désactivé.

Dans le fournisseur LDAP examiné, un whenChanged absent ou invalide devient une date nulle, que ce détecteur ignore. Un userAccountControl absent ou syntaxiquement invalide devient zéro : le parseur ne marque donc pas cet objet comme désactivé. Le filtre ordinateur par défaut est (objectClass=computer). Bien que le parseur puisse identifier une classe gMSA, ce Detect() n'exclut explicitement ni les contrôleurs de domaine ni les gMSA.

Le détecteur n'établit ni la date de désactivation, ni le responsable, ni l'approbation de mise hors service, ni les objets enfants, ni les dépendances de récupération, ni un historique d'événements à l'appui. Un constat positif ouvre la revue des preuves décrite ci-dessus. Un nombre nul ne permet pas de clore ces questions indépendantes, surtout lorsque la collecte ou la disponibilité des attributs est incertaine.