Revoir les metadonnees du descripteur de securite du schema AD

Ce que révèlent les métadonnées du descripteur de sécurité du schéma AD

Les métadonnées du descripteur de sécurité du schéma AD aident à qualifier la date de la dernière modification du descripteur de sécurité à la racine du contexte de nommage du schéma. Un horodatage récent justifie la collecte de preuves et l'examen du changement. Il n'établit ni qu'une permission est devenue dangereuse, ni qu'un administrateur a agi sans autorisation, ni que la forêt a été compromise.

Ce guide examine nTSecurityDescriptor sur l'objet exact renvoyé comme schemaNamingContext. Il n'examine pas defaultSecurityDescriptor sur les classes individuelles du schéma. Consignez cette distinction dans le dossier d'investigation : une modification du descripteur de l'objet racine et une modification du descripteur par défaut d'une classe constituent deux objets d'examen différents.

Microsoft décrit msDS-ReplAttributeMetaData comme des métadonnées maintenues par le système pour les attributs répliqués. Traitez ces informations comme une indication de provenance de réplication. Le serveur d'annuaire à l'origine du changement n'est pas le compte humain ou de service qui a demandé l'écriture. L'identification du compte demandeur exige des preuves distinctes.

Le résultat pratique est une fiche de qualification : objet interrogé, contrôleur de domaine ayant répondu, métadonnées renvoyées, caractère exploitable de l'horodatage et capacité d'une référence approuvée à expliquer les permissions actuelles. Ce processus d'investigation a été confronté à la documentation Microsoft le 4 octobre 2026 ; aucune commande présentée ici n'a été exécutée sur un annuaire client.

Détection : identifier l'objet avant d'interroger les métadonnées

Étape 1 : résoudre le contexte de nommage du schéma sur le DC choisi

Utilisez un poste d'administration Windows équipé du module PowerShell ActiveDirectory et un compte autorisé à lire les données d'annuaire concernées. Remplacez le serveur de l'exemple par un DC précis de votre forêt. Conservez le même serveur pour la découverte et la première requête de métadonnées.

L'exemple suivant utilise le paramètre documenté -Server de Get-ADRootDSE. Sa sortie comprend schemaNamingContext, defaultNamingContext, le nom d'hôte du serveur et l'heure actuelle.

$dc = 'dc01.example.com'
$root = Get-ADRootDSE -Server $dc -ErrorAction Stop
$root | Format-List dnsHostName, defaultNamingContext, schemaNamingContext, currentTime
$schemaDN = [string]$root.schemaNamingContext
if ([string]::IsNullOrWhiteSpace($schemaDN)) {
    throw 'Schema naming context was not returned; stop qualification.'
}

Consignez le DN renvoyé à l'identique. Comparez-le au DN de l'objet utilisé par votre outil d'audit. Dans le contexte d'un domaine enfant, vérifiez expressément si un DN construit à partir du DN du domaine courant correspond à RootDSE. Une divergence est un problème de collecte à résoudre avant d'interpréter le constat ; elle ne prouve pas que le descripteur a changé.

Étape 2 : récupérer les métadonnées de réplication de l'attribut

Get-ADReplicationAttributeMetadata accepte un nom distinctif via -Object, un DC via -Server et des noms d'attributs via -Properties. Cet exemple limite la requête à nTSecurityDescriptor et affiche toutes les métadonnées renvoyées, sans masquer de champs dans un tableau abrégé.

$metadata = @(Get-ADReplicationAttributeMetadata -Object $schemaDN -Server $dc -Properties nTSecurityDescriptor -ErrorAction Stop)
if ($metadata.Count -eq 0) {
    throw 'No metadata was returned; record insufficient evidence.'
}
$metadata | Format-List *

Conservez la sortie, notamment le nom de l'attribut, la version, la date du dernier changement d'origine et l'identité du serveur d'annuaire d'origine. Distinguez le DC interrogé du serveur identifié comme origine du changement. Conservez toute identité non résolue telle qu'elle a été renvoyée ; ne la remplacez pas par un nom d'administrateur supposé.

Étape 3 : qualifier l'horodatage et la fenêtre d'observation

Consignez l'heure et le fuseau horaire de la collecte avec l'horodatage brut. Vérifiez que la date est présente et correctement interprétée avant d'appliquer une fenêtre. Pour reproduire la décision de l'audit, utilisez l'heure de référence enregistrée par celui-ci, sans lui substituer silencieusement la date du jour lors d'une investigation ultérieure.

Si vous répétez la requête sur un autre DC, répétez également la découverte RootDSE sur celui-ci et enregistrez un relevé de collecte distinct. Ne fusionnez pas deux observations en un historique inventé. L'horodatage du dernier changement ne permet pas de reconstituer chaque état antérieur du descripteur ni chaque modification de la période examinée.

Remédiation : qualifier d'abord, corriger la dérive confirmée (Remediation)

Étape 1 : comparer le descripteur actuel à une référence approuvée

Obtenez le descripteur actuel de la racine exacte du schéma et comparez-le à une référence datée et approuvée pour ce même objet. Pour consulter les permissions sur le DC sélectionné, la commande suivante utilise la syntaxe documentée par Microsoft pour les objets distants de Dsacls. Exécutez-la dans un shell Windows élevé, avec Dsacls installé et un accès en lecture à l'objet cible. Sans option de modification, elle affiche l'ACL.

dsacls "\\$dc\$schemaDN"

Conservez la sortie de la commande et signalez tout échec. L'affichage d'une ACL permet d'examiner les permissions ; conservez un export complet du descripteur via vos outils d'annuaire approuvés si l'investigation exige aussi les informations de propriétaire, de groupe ou d'audit. Indiquez précisément les composants capturés pour ne pas présenter une vue partielle comme une comparaison complète du descripteur.

Examinez les bénéficiaires modifiés, les droits, les GUID propres aux objets, l'héritage et la portée. Déterminez si chaque différence concerne la racine elle-même ou un autre objet. L'examen des permissions du schéma apporte un contexte connexe sur les permissions ; ce contrôle temporel ne démontre pas une modification de defaultSecurityDescriptor d'une classe.

Si aucune référence approuvée n'existe, consignez cette limite. Le descripteur actuel peut toujours être examiné au regard de la délégation voulue par l'organisation, mais un différentiel historique exact reste indisponible. Ne fabriquez pas un état antérieur à partir de l'horodatage et ne considérez pas une valeur par défaut générique comme la référence approuvée de votre forêt.

Étape 2 : corréler l'autorisation et les événements disponibles

Confrontez les preuves à un véritable ticket de changement : DN cible, permissions attendues, équipe responsable, fenêtre d'exécution approuvée et état obtenu. Un ticket mentionnant un déploiement lié au schéma ne suffit pas à lui seul ; vérifiez que le changement prévu explique l'objet observé et la différence de descripteur.

Microsoft documente l'événement de sécurité 5136 pour les modifications d'objets d'annuaire dans le cadre d'Audit Directory Service Changes. Sa génération exige une entrée d'audit adaptée aux écritures d'attributs dans la SACL de l'objet. Lorsque des événements existent, vérifiez ObjectDN et AttributeLDAPDisplayName, conservez les champs du compte Subject et corrélez les opérations correspondantes avec OpCorrelationID. Microsoft décrit des enregistrements typiques Value Deleted et Value Added, mais vérifiez les valeurs réellement disponibles dans vos preuves.

Utilisez le guide de supervision AD pour la collecte et la corrélation des événements pour examiner la chaîne de supervision environnante. Déterminez si l'audit, le transfert et la conservation couvraient le DC et la période concernés avant d'interpréter une recherche vide. Un compte Subject identifie le principal demandeur dans l'événement ; toute attribution à une personne précise exige encore des dossiers opérationnels à l'appui.

Étape 3 : choisir une conclusion défendable

Un horodatage inexpliqué, à lui seul, relève de la troisième branche. Un écart de permissions confirmé peut justifier une remédiation sans établir qui l'a causé. Explicitez la question de l'autorisation et l'évaluation de l'exposition actuelle, afin que la réponse ne dépende pas d'une attribution non étayée.

Étape 4 : corriger uniquement l'écart confirmé du descripteur

Demandez à l'équipe d'annuaire autorisée de préparer un changement sur le DN vérifié de la racine du schéma. Enregistrez le descripteur actuel, identifiez l'ACE ou le composant exact à corriger, documentez le résultat attendu et prévoyez une voie de restauration avant toute écriture. Appliquez le changement examiné avec votre éditeur d'ACL approuvé, en préservant la délégation légitime et les permissions nécessaires.

Évitez une réinitialisation globale pour écarter un horodatage récent. La référence Dsacls de Microsoft décrit /S comme rétablissant les valeurs par défaut de la classe et /R comme supprimant toutes les ACE d'un principal spécifié ; aucune de ces options ne remplace une correction ciblée appuyée par votre comparaison approuvée.

Après correction, répétez les lectures RootDSE, des métadonnées et des permissions. Vérifiez que l'état attendu du descripteur est présent et que les opérations d'annuaire nécessaires fonctionnent toujours. Consignez les nouvelles métadonnées et les éventuelles preuves d'audit collectées comme un nouveau changement autorisé. Un constat de changement récent peut rester positif après une correction légitime, car celle-ci est elle-même récente ; validez les permissions, et pas seulement la disparition du signal temporel.

Comment EtcSec détecte ce cas

Dans l'implémentation d'etc-collector examinée, SCHEMA_SD_RECENT_CHANGE produit un constat Info avec Count 1 lorsque SchemaSDLastChanged est non nul et strictement postérieur à data.Now.AddDate(0, 0, -90). Le seuil utilise une soustraction de jours calendaires. La borne exacte est exclue et il n'existe aucune borne supérieure à Now : une date future satisfait aussi le test. Sinon, le constat renvoyé a Count 0.

Le moteur construit CN=Schema,CN=Configuration, suivi de DomainInfo.DomainDN, demande les métadonnées de réplication et copie la date du changement de nTSecurityDescriptor. Comparez ce DN construit au véritable schemaNamingContext de RootDSE, notamment lorsque le contexte d'audit est un domaine enfant. Cet examen du code établit une exigence de validation, pas un échec mesuré dans votre forêt.

Le fournisseur LDAP recherche dans le sous-arbre avec des résultats limités à une entrée et lit msDS-ReplAttributeMetaData. Les réponses manquantes, les erreurs de requête, les balises XML absentes ou les horodatages non analysés peuvent laisser la date à zéro. L'analyseur d'horodatage prend en charge YYYY-MM-DDTHH:MM:SSZ et YYYY-MM-DDTHH:MM:SS. Ce chemin ne possède aucun état de sondage distinct établissant que la collecte a réussi.

Le détecteur ne compare pas un ancien descripteur à un nouveau, ne calcule pas de différentiel DACL, n'identifie pas de compte demandeur et n'établit pas d'abus. Utilisez son résultat Info pour commencer la qualification. Count 1 étaye le prédicat temporel implémenté ; Count 0 ne peut certifier ni un schéma inchangé ni une collecte réussie.