audit AD des privileges sensibles : échecs et réussites

Qu'est-ce que l'audit AD des privilèges sensibles ?

L'audit AD des privileges sensibles est un contrôle de visibilité à l'échelle de chaque hôte : Windows enregistre-t-il les demandes de privilèges sensibles sur chaque contrôleur de domaine, serveur membre ou poste de travail du périmètre ? Un export de GPO du domaine peut suggérer une réponse, mais les preuves nécessaires pour clôturer la revue sont la stratégie d'audit rapportée par l'hôte cible et les événements qui parviennent à votre plateforme de supervision.

Ce guide a été vérifié le 4 octobre 2026 à partir de Microsoft Learn et du commit source etc-collector 20268a321609c193b79c5da6764f3f56950449cb. Il part d'une limite précise : le contrôle EtcSec AUDIT_PRIVILEGE_USE_DISABLED accepte Failure seul. Un résultat sans constat comptabilisé ne permet donc pas d'établir que Success et Failure sont tous deux activés.

Microsoft recommande les deux résultats pour cette sous-catégorie sur les contrôleurs de domaine, les serveurs membres et les postes de travail. Success enregistre les tentatives réussies ; Failure enregistre les tentatives échouées. Consultez la recommandation Microsoft relative à Sensitive Privilege Use. Examinez votre référentiel approuvé et documentez les exceptions au lieu de considérer le seuil du produit comme l'exigence complète de la stratégie.

Comment fonctionne la vérification

Commencez par les machines que vous souhaitez couvrir. Répertoriez les contrôleurs de domaine, les serveurs membres concernés et les postes de travail privilégiés, ainsi que le responsable de la stratégie pour chaque population. Une requête réussie sur un DC n'établit pas l'état d'un autre DC ou d'un serveur membre. Consignez l'identité de l'hôte et l'heure d'observation à côté de chaque résultat.

La distinction entre configuration et état de l'hôte est expliquée dans notre guide sur la comparaison de la configuration d'audit des GPO avec les paramètres effectifs des hôtes. Cet article traite d'Account Logon, Account Management et Policy Change. Ici, la décision concerne le bit Success de Sensitive Privilege Use et la télémétrie qui en découle.

La vérification comporte trois étapes de validation. D'abord, identifiez le référentiel attendu et toute exception approuvée. Ensuite, interrogez la stratégie d'audit système sur l'hôte réel. Enfin, rapprochez les événements locaux pertinents de leurs copies centralisées et vérifiez les champs nécessaires à un analyste. Validez chaque étape avec ses propres preuves : l'approbation d'une exception ne remplace pas un contrôle de collecte échoué, et un journal d'événements rempli ne remplace pas la requête de stratégie.

Lorsque les preuves divergent, conservez cette divergence. Par exemple, une GPO collectée peut ne contenir que Failure alors qu'un hôte rapporte les deux résultats. L'étape utile consiste alors à identifier comment cet hôte est géré et si cet état est durable. Modifier une GPO uniquement pour rendre un export cohérent peut supprimer un paramètre local légitime ou laisser le véritable problème de configuration sans solution.

Détection : lire la stratégie sur chaque hôte

Exécutez la requête en lecture seule suivante sur chaque cible, avec un compte autorisé à lire sa stratégie d'audit. Ces commandes appliquent la syntaxe par nom ou GUID documentée dans la référence Microsoft d'auditpol get ; elles ont été vérifiées à partir de cette référence, sans être exécutées dans un environnement AD pour cet article.

auditpol /get /subcategory:"Sensitive Privilege Use"

Sur les hôtes dont la langue d'affichage est différente, effectuez la requête avec le GUID de Sensitive Privilege Use documenté par Microsoft, également utilisé par le collecteur :

auditpol /get /subcategory:"{0cce9228-69ae-11d9-bed3-505054503030}" /r

Sans /user, auditpol interroge la stratégie système. Conservez la sortie, l'hôte, l'horodatage, la commande et toute erreur. Une erreur d'autorisation constitue un résultat inconnu nécessitant un accès autorisé ; elle ne signifie pas que la stratégie est désactivée. Examinez séparément la stratégie par utilisateur lorsqu'elle est pertinente pour un compte donné ou un résultat d'événement inattendu.

Séparez le résultat de stratégie de l'échantillon d'événements. D'anciens événements peuvent subsister après un changement de stratégie : un événement observé avant la requête ne prouve donc pas le paramétrage actuel. À l'inverse, une fenêtre d'observation calme peut ne contenir aucune opération pertinente. Consignez la fenêtre et l'activité attendue avant de décider si l'absence d'événements indique un problème de génération ou de collecte.

Détection : valider 4673/4674 dans la chaîne de collecte

Microsoft documente 4673 comme un appel à un service privilégié et 4674 comme une tentative d'opération sur un objet privilégié. Tous deux peuvent aussi relever de Non Sensitive Privilege Use. Examinez le privilège et le contexte de l'opération ; le numéro d'événement seul n'identifie pas la sous-catégorie sensible.

Utilisez cette requête locale du journal Security pour examiner le XML. Elle applique les options de requête, d'ordre inverse et de format de sortie de la référence Microsoft de wevtutil :

wevtutil qe Security /q:"*[System[(EventID=4673 or EventID=4674)]]" /rd:true /f:xml

Choisissez une fenêtre d'observation bornée, adaptée à votre revue, pour les recherches centralisées. Rapprochez les enregistrements locaux de leurs copies reçues à l'aide de l'identité de l'hôte, de l'heure, de l'ID d'événement et de l'ID d'enregistrement lorsqu'il est conservé. Vérifiez la normalisation des résultats d'audit et des noms de privilèges par le connecteur à partir du XML original, notamment lorsque la vue centrale fusionne des champs ou supprime les valeurs vides.

Le guide complémentaire sur la collecte centralisée des événements et la validation des parseurs accompagne ce travail de transport et de correspondance des champs. Conservez un exemple de chaque type d'événement pertinent réellement observé. Si un exemple requis n'est pas disponible, documentez le cas non testé au lieu d'affirmer que la couverture est complète.

Cette distinction figure explicitement dans la documentation Microsoft de 4672. Utilisez 4672 pour son contexte d'ouverture de session, en maintenant séparés les contrôles de génération et de transfert de 4673/4674. Évaluez les comptes, privilèges et processus inattendus au regard de l'activité administrative approuvée avant de faire remonter un événement comme un possible abus.

Corriger : vérifier Failure et Success après le déploiement (Remediation)

1. Corriger la sous-catégorie gérée

Lorsque le référentiel approuvé exige les deux résultats, configurez Audit Sensitive Privilege Use sous Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use. Sélectionnez Success et Failure dans la GPO ou le système de configuration qui gère réellement la population cible.

Documentez le responsable du changement, les hôtes cibles, la liste des exceptions, la configuration précédente et la décision de retour arrière. Testez le changement sur des machines représentatives avant de l'étendre au reste du périmètre. Le déploiement doit suivre la population d'hôtes et les limites de gestion identifiées, sans supposer que tous les ordinateurs concernés sont contrôlés par la même stratégie par défaut.

2. Contrôler la priorité sur l'audit hérité et relire l'état des hôtes

Examinez Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Microsoft recommande de laisser ce paramètre activé et documente SCENoApplyLegacyAuditPolicy comme empêchant l'application d'une stratégie au niveau des catégories. Consultez la référence Microsoft du paramètre de priorité sur l'audit hérité pour rapprocher les paramètres d'audit de base et avancés.

Une fois le changement géré appliqué à chaque hôte, répétez la requête auditpol par GUID ci-dessus. Comparez les sorties avant et après. Si un hôte présente toujours une différence, examinez la source de gestion applicable et le traitement des stratégies ; ne déclarez pas la remédiation terminée sur la seule foi de l'éditeur de GPO.

3. Garder Backup/Restore comme décision distincte

L'audit de l'utilisation des privilèges Backup et Restore dépend également de Audit: Audit the use of Backup and Restore privilege. Microsoft déconseille d'activer ce paramètre distinct, car il peut produire un volume important d'événements. Ne l'activez pas partout comme raccourci pour clôturer cette revue. Consignez la visibilité requise, la charge de travail, la capacité opérationnelle et la décision du responsable pour toute exception à cette recommandation.

4. Confirmer la réception avant de clôturer la revue

Après le déploiement, vérifiez à nouveau la génération locale et l'analyse centrale avec une activité approuvée et contrôlée, pertinente pour le privilège visé. Convenez de l'événement attendu avec le responsable de la supervision avant le test. Une action administrative générique ne garantit pas l'apparition des deux ID d'événement ou des deux résultats.

Si les événements locaux existent mais que leurs copies centrales manquent, examinez l'abonnement de transfert, les filtres de l'agent, les erreurs d'ingestion et la configuration du parseur. Si les événements locaux manquent, vérifiez d'abord l'opération, le paramétrage d'audit et la fenêtre d'observation. Il s'agit de défaillances distinctes, avec des responsables différents. Fixez une date de suivi pour les cas non résolus et vérifiez à nouveau après les reconstructions d'hôtes ou les changements de la stratégie qui les gère.

Comment EtcSec détecte ce problème

Au commit source examiné ici, AUDIT_PRIVILEGE_USE_DISABLED lit advancedAuditLevel. Cet auxiliaire utilise une table de GPO d'audit avancé sélectionnée ou se rabat sur les données EventAudit héritées. Avec une valeur connue inférieure à 2, le détecteur émet un constat de sévérité Medium avec Count 1. La valeur 2 signifie Failure seul et la valeur 3 signifie Success et Failure : les deux passent son seuil. Ce détecteur n'exige pas Success.

Lorsque ni l'une ni l'autre des sources sélectionnées ne fournit le paramètre, ok=false renvoie Count 0, conserve la sévérité Medium initialisée et inclut des détails expliquant que le paramètre n'est pas configuré via GPO. La stratégie effective de l'hôte reste inconnue ; ce n'est une preuve ni de conformité ni de désactivation de l'audit.

La sélection des sources présente d'autres limites :

• La sélection de l'audit avancé privilégie Default Domain Controllers Policy, puis Default Domain Policy, puis la première entrée de table disponible. La sélection d'EventAudit hérité privilégie Default Domain Policy, puis Default Domain Controllers Policy, puis la première entrée disponible. Ces ordres de priorité diffèrent.
• L'absence d'une sous-catégorie dans la table avancée sélectionnée ne déclenche pas de recherche dans les autres tables avancées. L'auxiliaire peut alors se rabattre sur la catégorie héritée sélectionnée.
• Le fournisseur SMB ignore les échecs de lecture de GptTmpl.inf et d'audit.csv pendant la collecte des stratégies. Une section EventAudit contenant un autre champ peut laisser le champ Privilege Use manquant à sa valeur zéro.
• Le parseur d'audit.csv extrait les paires GUID/valeur ; il n'atteste pas qu'une stratégie a été appliquée à un hôte et ne conserve pas un dossier complet de provenance de l'application.

Ce chemin ne calcule pas le Windows Resultant Set of Policy et ne prend pas entièrement en compte SCENoApplyLegacyAuditPolicy. Il ne prouve pas non plus la génération, le transfert ou l'analyse des événements. Utilisez le constat pour prioriser l'investigation, puis clôturez la revue avec la sortie auditpol de chaque hôte et les preuves de collecte.

Dossier de revue

Conservez la décision relative au référentiel, l'inventaire des hôtes du périmètre, la sortie de stratégie de chaque hôte, les exceptions approuvées, la comparaison avant/après et les échantillons d'événements locaux rapprochés de leurs copies centrales. Attribuez un responsable à chaque résultat inconnu. La revue est terminée lorsque chaque hôte du périmètre dispose d'un résultat documenté et que la télémétrie requise a été vérifiée, toute exception restante étant explicitement acceptée par son responsable.