Approbation des changements AD : attributs et valeurs 5136

Qu'est-ce que l'approbation des changements AD ?

Une revue d'approbation des changements AD portant sur un attribut relie une modification enregistrée d'un objet existant de l'annuaire à une décision autorisée de manière indépendante. Elle produit une trace de preuves : le GUID de l'objet, l'attribut modifié, les valeurs supprimées et ajoutées observées, l'identifiant de corrélation de l'opération, le compte demandeur, le contrôleur de domaine émetteur, l'heure de l'événement et les preuves d'approbation. Un nom d'administrateur familier ou un faible nombre de résultats d'audit de posture ne peut pas remplacer cette trace.

Utilisez cette procédure lorsqu'une modification de l'annuaire nécessite une explication avant de clore la revue ou d'approuver une correction. Commencez par un objet et un attribut. Conservez les événements d'origine, établissez les limites de collecte et demandez au décideur autorisé de confirmer si la modification de valeur observée correspond à la demande. La revue peut aboutir à une approbation étayée, à une modification non autorisée confirmée ou à une lacune de preuves non résolue ; ces résultats nécessitent des suites différentes.

Cet article concerne les modifications d'un objet existant. Pour les objets nouvellement provisionnés, utilisez le registre de création qui relie whenCreated et les preuves de création au provisionnement approuvé. Pour une comparaison plus large entre les accès prévus et les droits effectifs de groupe, d'ACL et de réplication, utilisez la démarche de revue et de revalidation de la dérive des accès privilégiés. Ici, le livrable est la trace de preuves de modification d'attribut, plutôt qu'un nouvel inventaire de comptes privilégiés.

Fonctionnement : établir ce que 5136 peut montrer

Microsoft documente l'événement 5136 pour les modifications d'objets du service d'annuaire. Pour que l'événement soit généré, l'audit des succès de Directory Service Changes doit s'appliquer et l'objet doit disposer d'une entrée SACL correspondante auditant l'écriture de l'attribut concerné. La sous-catégorie d'audit fonctionne sur les contrôleurs de domaine. Certaines modifications d'objets ou de propriétés ne sont pas auditées en raison de paramètres de schéma ; activer la stratégie ne suffit donc pas à établir une couverture complète. Microsoft Learn : événement 5136, Audit Directory Service Changes.

Pour un remplacement, Microsoft décrit un événement typique de suppression de valeur suivi d'un événement d'ajout de valeur. Traitez ce schéma comme une aide à la reconstruction. Il ne garantit pas que chaque revue dispose d'exactement deux enregistrements. Un attribut peut comporter plusieurs valeurs, une opération peut affecter plusieurs attributs et les enregistrements conservés peuvent être incomplets. Conservez chaque événement de valeur pertinent et expliquez sa contribution à la modification examinée.

Le champ XML OperationType distingue un ajout, %%14674, d'une suppression, %%14675. AttributeValue contient la valeur concernée par cet événement. Conservez à la fois le code brut de l'opération et sa signification. N'interprétez pas une valeur ajoutée comme l'ensemble complet des valeurs de l'attribut après modification lorsqu'elle peut représenter un seul élément d'un attribut multivalué. Microsoft Learn : description des champs de l'événement 5136.

OpCorrelationID relie les modifications appartenant à une opération LDAP. Il peut couvrir davantage que le seul attribut examiné. Combinez-le avec l'identité de l'objet et de l'attribut, la provenance et l'heure ; ce n'est pas une référence de ticket métier. Microsoft décrit AppCorrelationID comme inutilisé, avec un tiret pour valeur. Aucun de ces champs ne fournit la décision d'approbation de l'organisation.

Détection : recueillir un ensemble de preuves délimité

Les commandes ci-dessous utilisent la syntaxe documentée des commandes et paramètres, adaptée à cette revue. Elles n'ont pas été exécutées sur un domaine réel. Effectuez les lectures d'événements depuis un hôte Windows autorisé ; utilisez le module Active Directory pour lire l'objet. Remplacez le DC, l'intervalle UTC et le GUID d'objet donnés en exemple par les données réelles du dossier. Consignez les erreurs d'autorisation et les journaux indisponibles comme des observations échouées, plutôt que comme des recherches vides réussies. Les lectures distantes Get-WinEvent nécessitent un accès à travers le pare-feu au service Windows Event Log ; la cmdlet ne dépend pas de PowerShell remoting. Microsoft Learn : Get-WinEvent ComputerName.

Étape 1 : consigner la couverture d'audit et de conservation

Sur chaque DC concerné par le dossier, examinez la sous-catégorie d'audit système actuelle. Le nom anglais ci-dessous nécessite une installation qui reconnaît ce nom ; la syntaxe documentée accepte aussi un GUID de sous-catégorie.

auditpol /get /subcategory:"Directory Service Changes" /r

La sortie attendue est un rapport de stratégie identifiant la sous-catégorie et ses paramètres de succès et d'échec. Enregistrez l'identité du DC, l'heure de collecte, la commande et le rapport renvoyé. Une requête réussie établit ce qui a été lu à cet instant. Elle ne prouve pas que le même paramètre s'appliquait au moment de la modification historique. La syntaxe de la commande et les exigences d'autorisation de lecture sont documentées dans Microsoft Learn : auditpol get.

Pour la configuration du journal, examinez le journal Security sur le même DC :

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

Le résultat décrit le journal, notamment son mode, sa taille maximale configurée et son nombre d'enregistrements. Une taille ou un nombre ne prouve pas que l'intervalle visé reste consultable. Vérifiez les enregistrements locaux conservés et les archives centrales pour cet intervalle, et documentez la couverture des sources, les lacunes de transfert et les preuves historiques disponibles de stratégie et de SACL. Microsoft Learn : Get-WinEvent.

Répondez explicitement à la première question de décision : quelle SACL d'écriture d'attribut et quelles preuves de conservation étayent cette reconstruction ? Consignez l'objet audité ou le périmètre hérité, l'action d'écriture concernée, le principal couvert et le paramètre de succès. Si seule la configuration actuelle est disponible, qualifiez la couverture historique de non démontrée. Ne déduisez pas de l'absence d'un événement historique que l'attribut n'a jamais été modifié.

Étape 2 : récupérer les événements sans limite arbitraire de paire

Utilisez un intervalle délimité incluant la modification examinée. L'exemple suivant sélectionne des événements Security par fournisseur, identifiant et heure :

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

Ces horaires sont illustratifs, pas une fenêtre de changement mesurée ni une durée de revue prescrite. Get-WinEvent documente ces clés de filtre et renvoie les enregistrements d'événements, les plus récents en premier par défaut. L'exemple ne demande volontairement pas seulement deux événements et ne plafonne pas le résultat avec -MaxEvents. Conservez la requête et son résultat avant de sélectionner l'objet et l'attribut dans le XML de l'événement. Microsoft Learn : paramètres de filtre Get-WinEvent.

Attendez-vous à zéro ou plusieurs enregistrements correspondants, pas à un nombre prédéterminé. Si la commande ne trouve aucun événement correspondant, distinguez ce résultat des erreurs d'accès ou de connexion, puis évaluez la couverture de conservation et de génération. Recherchez dans les archives autorisées au besoin ; la cmdlet documente aussi -Path pour les fichiers d'événements enregistrés. Une lecture échouée doit rester visible dans la trace du dossier.

Conservez l'export d'événements d'origine et le XML de chaque événement. Une capture d'écran de la valeur la plus récente ne suffit pas pour la reconstruction. Dans un SIEM, vérifiez que l'ingestion conserve les champs ci-dessous et maintient l'identité de l'événement source distincte de l'heure d'ingestion et des éventuelles copies transférées en double.

Étape 3 : constituer la trace de modification d'attribut

Utilisez ObjectGUID pour identifier l'objet et AttributeLDAPDisplayName pour identifier l'attribut. Consignez le DN et la classe comme contexte. Recueillez ensuite tous les événements de valeur candidats partageant l'identifiant de corrélation d'opération pour cet objet et cet attribut, en vérifiant le DC émetteur, le sujet et les heures. Si ces champs divergent, conservez la divergence pour investigation au lieu de forcer les enregistrements dans une seule paire.

Ces noms de champs d'événement proviennent du XML 5136 et de la description de ses champs. Les champs d'approbation constituent une proposition de trace de revue, pas de la télémétrie Windows supplémentaire.

Pour un remplacement de valeur unique avec des preuves complètes, le réviseur doit pouvoir décrire la suppression et l'ajout observés et référencer chaque enregistrement source. Pour un attribut multivalué, conservez les suppressions et ajouts individuels comme des ensembles d'opérations observées. N'inventez pas de valeurs inchangées et ne prétendez pas que l'ensemble d'événements est un instantané complet avant et après.

Pour comparer avec l'état actuel de l'annuaire, Get-ADObject accepte un GUID d'objet comme -Identity, des attributs supplémentaires comme -Properties et un serveur précis comme -Server. Cet exemple utilise le GUID de l'exemple d'événement 5136 de Microsoft ; remplacez-le, ainsi que l'attribut d'exemple, par les identifiants examinés.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Attendez-vous à l'objet trouvé et à la propriété demandée, ou à une erreur explicite de lecture ou de recherche. Conservez l'heure de collecte et le DC. L'état actuel peut aider à valider la remédiation, mais ne permet pas de récupérer une valeur historique ou une approbation manquante. Microsoft Learn : Get-ADObject.

Vérification : rendre la décision d'approbation indépendante

Demandez à l'autorité de changement désignée de faire correspondre la demande à cet objet, à cet attribut et à la modification de valeur prévue. Consignez qui est autorisé à décider, les preuves d'approbation et leur heure, et si ces preuves couvrent l'opération observée. L'explication d'une modification par un opérateur est une preuve utile, mais une explication n'est pas automatiquement une approbation indépendante.

Gardez l'acteur technique et le décideur dans des champs distincts. Si un compte d'automatisation a demandé la modification, consignez ce sujet sans deviner l'initiateur humain. Établissez toute attribution à un opérateur au moyen d'enregistrements indépendants. De même, ne rattachez pas une demande métier à un événement simplement parce que les horodatages sont proches ou que les deux descriptions mentionnent une « maintenance de l'annuaire ».

Classez explicitement les cas difficiles :

Ce tableau propose des résultats de revue. Il ne prétend pas que chaque événement sans correspondance est malveillant. Répondez aux questions de décision restantes avant clôture : qui confirme l'autorisation indépendamment de l'acteur technique, et comment qualifier les preuves manquantes, multivaluées ou limitées à une suppression ? Attribuez à chaque élément non résolu un responsable et la prochaine demande de preuves.

Remédiation : résoudre la décision et valider la couverture (Remediation)

Conservez les preuves historiques avant d'effectuer une modification corrective de l'annuaire. Pour une modification approuvée étayée, joignez la décision à la trace de revue. Pour une divergence d'approbation ou une modification non autorisée confirmée, demandez aux responsables de l'identité et des services concernés d'évaluer l'exposition et les dépendances, de décider du confinement ou de la correction et de consigner l'état cible autorisé. Évitez de restaurer aveuglément une valeur supprimée : des modifications légitimes ultérieures ou des dépendances multivaluées peuvent rendre cette action incorrecte.

Si la couverture de génération est insuffisante, les administrateurs autorisés doivent corriger la stratégie d'audit applicable et la SACL d'écriture d'attribut. Microsoft documente l'audit des succès pour Directory Service Changes et l'absence d'événements Failure dans cette sous-catégorie. Exécutez la commande suivante localement sur le DC sélectionné. Elle utilise la syntaxe documentée auditpol /set pour activer l'audit des succès, modifie la configuration et doit s'inscrire dans une procédure administrative approuvée.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Un résultat de commande réussi est suivi de la lecture auditpol /get ci-dessus et de la SACL correspondante vérifiée séparément. La commande ne configure pas une SACL, ne prouve pas la persistance d'une stratégie gérée centralement et ne recrée pas les événements passés. Coordonnez-la avec le responsable de la stratégie et conservez les preuves de configuration obtenues. Microsoft Learn : auditpol set, Audit Directory Service Changes.

Validez la couverture future au moyen d'une modification pilote approuvée sur un objet de test hors production et un attribut approprié. Consignez l'intention autorisée concernant les anciennes et nouvelles valeurs avant le test. Vérifiez que les événements générés et conservés contiennent l'objet, l'attribut et les opérations de valeur attendus, que le transfert préserve leur identité et que la revue peut les relier à l'approbation du test. Aucun test de ce type sur un domaine n'a été réalisé pour cet article.

Après une correction autorisée, répétez la lecture ciblée de l'objet et la revue des événements. Conservez l'état actuel, les preuves de l'opération corrective et la décision indépendante. Ne clôturez que les parties étayées du dossier ; reportez les lacunes de reconstruction historique avec une décision documentée.

Comment EtcSec détecte ce problème

Au commit du collecteur bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, CHANGE_MANAGEMENT_BYPASS est une heuristique de posture de sévérité Medium. Son Detect() lit les utilisateurs LDAP collectés. Il compte les utilisateurs activés dont les entrées directes memberOf contiennent les noms anglais Domain Admins ou Enterprise Admins, par correspondance de sous-chaînes insensible à la casse. Plus de 10 utilisateurs de ce type crée un problème. Un décompte distinct inclut les utilisateurs ayant au moins un SPN et adminCount=1 ; plus de 5 crée un autre problème. Ce second décompte n'exclut pas les utilisateurs désactivés.

Si l'une des conditions est remplie, le résultat renvoyé a Count=1 ; sinon, il a Count=0. Un est l'indicateur du résultat d'audit, pas le nombre de modifications non approuvées. Les détails incluent les deux compteurs agrégés. Les seuils sont des heuristiques du produit sans autorité normative, pas des exigences d'approbation de Microsoft, de l'ANSSI ou de HDS.

Le fournisseur LDAP fournit memberOf, servicePrincipalName et adminCount. Ce détecteur ne développe pas les appartenances imbriquées aux groupes. Des noms de groupes privilégiés renommés ou localisés peuvent empêcher la correspondance sur le nom anglais ; une correspondance de sous-chaînes n'est pas un test stable de SID de groupe. Microsoft documente que adminCount peut rester à 1 après qu'un compte a quitté un groupe protégé ; cet indicateur n'établit donc pas les privilèges effectifs actuels. Un SPN peut être enregistré sur un compte utilisateur ou ordinateur ; sa présence seule n'établit donc pas l'usage opérationnel actuel du compte. Microsoft Learn : comptes protégés et adminCount, enregistrement des SPN. Le périmètre et les limites de collecte restreignent aussi les populations examinées.

Ce contrôle ne lit aucun événement 5136, aucune valeur supprimée ou ajoutée, aucun identifiant de corrélation, aucune SACL, aucun enregistrement de conservation ni aucun processus d'approbation. Un résultat positif peut déclencher une revue de gestion des changements, mais ne peut pas prouver un contournement, identifier cette modification d'attribut ou décider de l'autorisation. Un décompte nul ne permet pas de valider la trace de preuves. Achevez la reconstruction des événements et la décision indépendante ci-dessus avant de clore la revue.