Droits AD de nom DNS valide : revoir l’ACE avant la délégation

Ce que signifient les droits AD de nom DNS valide

Les droits AD de nom DNS valide encadrent une mise à jour contrainte de dNSHostName sur un objet d’annuaire. Une ACE contenant le GUID associé justifie l’examen d’une délégation. Avant de la modifier, déterminez qui reçoit l’autorisation, si son masque accorde réellement l’écriture validée, si elle s’applique à l’ordinateur et quelle opération de provisionnement en a besoin.

Microsoft identifie Validated-DNS-Host-Name par le GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. Cette autorisation permet un nom d’hôte DNS conforme aux contraintes de nommage de l’ordinateur et du domaine. Elle n’établit pas une autorisation de modifier une zone DNS et ne démontre pas qu’une personne a redirigé du trafic.

Le résultat utile de cette revue est une décision consignée : une délégation approuvée, un droit inutile confirmé à supprimer ou une question de collecte ou d’autorisation non résolue. Une liste de GUID correspondants ne suffit pas à prendre cette décision. Conservez ensemble l’identité de l’objet ordinateur, l’ACE et le processus légitime tout au long de l’investigation.

Fonctionnement : écriture validée et WriteProperty

La sémantique des écritures validées dans MS-ADTS distingue l’accès ordinaire RIGHT_DS_WRITE_PROPERTY des écritures validées. L’accès ordinaire en écriture sur une propriété autorise les valeurs admises par le schéma de l’attribut, sans les contrôles supplémentaires de valeur de l’écriture validée. Une ACE d’écriture validée combine le bit du masque d’accès RIGHT_DS_WRITE_PROPERTY_EXTENDED avec un GUID d’identification dans ObjectType ; une ACE sans GUID ObjectType peut couvrir toutes les écritures validées sur l’objet.

Ce GUID est également l’identifiant de schéma de l’attribut dNSHostName. Par conséquent, le GUID seul ne permet pas de distinguer une ACE portant sur l’écriture de cette propriété d’une ACE portant sur son opération d’écriture validée. Interprétez conjointement le masque et la portée.

Pour le chemin validé, MS-ADTS précise les contraintes de dNSHostName : l’objet doit être un ordinateur ou un serveur, ou une sous-classe ; dans AD DS, le nom d’hôte combine le sAMAccountName actuel sans son signe dollar final avec le nom DNS du contexte de nommage du domaine ou une valeur msDS-AllowedDNSSuffixes autorisée. Le demandeur doit détenir le droit d’écriture validée. Examinez ces éléments de nommage pour évaluer l’opération prévue.

Pour l’investigation plus large sur le propriétaire et la DACL, utilisez la revue de la DACL et de la propriété des objets ordinateur. La présente revue se concentre sur cette autorisation particulière d’écriture validée. Les transferts de zone DNS et la configuration des mises à jour dynamiques concernent une autre surface ; modifier une ACE d’objet ordinateur ne vérifie pas ces paramètres de zone.

Détection : collecter l’objet et examiner l’ACE complète

Étape 1 : définir le périmètre de collecte

Commencez par le DN concerné et la population d’ordinateurs visée. Consignez le contrôleur de domaine, l’heure de collecte, les identifiants utilisés pour la lecture, la base de recherche et les éventuelles OU exclues. Rapprochez la population du périmètre prévu par l’administrateur. La lecture réussie d’un objet n’établit rien au sujet des ordinateurs omis de l’inventaire.

Utilisez un poste d’administration Windows équipé du module PowerShell ActiveDirectory pour lire les objets. L’exemple suivant, fondé sur la documentation, utilise les paramètres pris en charge Identity, Server et Properties de Get-ADObject, avec des valeurs illustratives à remplacer pour votre environnement :

Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor

Confirmez le DN et la classe retournés avant d’interpréter les autorisations. Conservez le descripteur pour une inspection détaillée, avec les valeurs du compte et du nom d’hôte. Ne qualifiez pas un descripteur indisponible de DACL vide. Consignez séparément les échecs de lecture et recommencez avec une identité de collecte autorisée avant de conclure sur la couverture.

Étape 2 : inventorier l’ACL

La référence Dsacls de Microsoft documente l’affichage des ACE d’un objet en fournissant son DN entre guillemets, sans options de modification. Exécutez la commande depuis une invite de commandes Windows élevée, avec les autorisations de lecture de l’annuaire :

dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"

Il s’agit d’un exemple de syntaxe adapté à un DN d’ordinateur illustratif, et non d’un contrôle exécuté dans un environnement. Examinez les entrées d’autorisation complètes, en utilisant au besoin l’onglet Sécurité de l’objet pour détailler leur portée. Consignez le SID et l’identité résolue de chaque bénéficiaire, le type d’ACE, le masque d’accès, ObjectType, la source d’héritage et l’applicabilité. Conservez le descripteur original plutôt qu’un simple affichage filtré sur le GUID.

Étape 3 : résoudre le masque, le bénéficiaire et l’héritage

Les instructions Microsoft sur les autorisations de jonction au domaine illustrent l’ACE d’écriture validée DNS avec le masque 0x00000008, nommé ACTRL_DS_SELF, et le GUID du nom d’hôte DNS. Ce nom de masque est distinct du bénéficiaire nommé SELF : un compte de jonction peut également recevoir le bit d’écriture validée. Vérifiez si le bit pertinent est présent dans le masque collecté ; un masque différent ou combiné exige sa propre interprétation.

MS-ADTS Checking Access explique Principal Self, SID S-1-5-10 : sur un objet principal de sécurité, il représente le principal de cet objet et est remplacé par le SID de l’objet pendant le contrôle d’accès. Le DC évalue le contexte de sécurité du demandeur, l’accès demandé et le descripteur approprié. Résoudre un nom d’affichage ou voir une ACE d’autorisation ne constitue pas cette évaluation complète.

Examinez les bénéficiaires constitués de groupes au regard de l’identité réelle de jonction ou de provisionnement. Demandez au propriétaire du processus quelle identité réalise chaque étape et quelles machines elle peut gérer. Ne considérez pas qu’un groupe nommé d’après le déploiement prouve que tous ses membres ont besoin d’accéder à tous les ordinateurs.

Les règles d’héritage de Microsoft distinguent les ACE héritées des ACE limitées à l’héritage. Une entrée limitée à l’héritage ne s’applique pas à l’objet qui la porte. Remontez au conteneur source et à la portée de classe d’objet ; évaluez l’entrée telle qu’elle apparaît sur l’ordinateur cible, plutôt que de supposer qu’une entrée parente a une applicabilité identique partout.

Étape 4 : séparer les preuves attendues, observées et inconnues

Utilisez cette fiche pour chaque ordinateur concerné. C’est un modèle de revue, et non un rapport de résultats mesurés :

Remédiation : examiner le processus, puis modifier la délégation (Remediation)

Étape 1 : préserver l’état initial et établir la nécessité

Enregistrez le descripteur original et la fiche de revue. Convenez de l’opération requise avec les propriétaires des machines et du provisionnement avant toute modification. Distinguez la création d’un nouveau compte ordinateur de la réutilisation d’un compte existant. Les instructions Microsoft sur la jonction au domaine incluent l’autorisation d’écriture validée DNS parmi les droits nécessaires à l’identité de jonction lors de la réutilisation d’un compte ; la présence de ce droit peut donc être intentionnelle.

Pour une exception conservée, consignez le SID du bénéficiaire, le droit exact, la population d’objets, la source d’héritage, la finalité, le propriétaire et la date de revue. Incluez les preuves qui appuient cette décision et les questions en suspens. Une exception doit expliquer pourquoi la délégation est nécessaire sur ces ordinateurs, plutôt que simplement indiquer que le scanner l’avait déjà signalée.

Étape 2 : supprimer ou restreindre l’entrée inutile confirmée

Utilisez l’onglet Sécurité de l’objet pour modifier l’autorisation inutile précise. Si elle est héritée, examinez et corrigez la délégation source avec le propriétaire de l’OU, en vérifiant les autres destinataires avant d’appliquer le changement. Préservez les autorisations nécessaires au processus restant et vérifiez la portée de l’ACE obtenue.

La documentation indique que dsacls /R supprime toutes les ACE du bénéficiaire spécifié. Cette commande ne convient pas pour supprimer uniquement l’accès d’écriture validée DNS d’un bénéficiaire qui doit conserver d’autres autorisations. Ne remplacez pas une modification d’ACE examinée par la suppression de toutes les entrées d’un bénéficiaire, et ne réinitialisez pas tout le descripteur de sécurité de l’objet pour faire disparaître un constat.

Étape 3 : vérifier les autorisations et l’opération prévue

Relisez l’ordinateur et son ACL auprès du DC choisi. Comparez le descripteur obtenu à l’état initial et documentez précisément l’entrée modifiée. Confirmez que le bénéficiaire examiné ne détient plus l’autorisation effective indésirable par une autre entrée applicable. Pour les changements hérités, échantillonnez la population de destinataires pertinente et vérifiez la limite de classe d’objet prévue.

Testez le processus approuvé de jonction ou de provisionnement sur un ordinateur de test représentatif, avec l’identité réellement déléguée. Consignez l’opération exécutée, sa réussite éventuelle et les erreurs d’annuaire. Sur un membre du domaine, le test du canal sécurisé de Microsoft fournit un contrôle fonctionnel supplémentaire, à exécuter localement dans Windows PowerShell élevé :

Test-ComputerSecureChannel -Verbose

Ce contrôle vérifie la relation du membre avec le domaine ; il n’établit ni que le provisionnement du nom d’hôte fonctionne, ni que la revue de l’ACL est complète. Microsoft avertit que la cmdlet retourne des erreurs faussement positives sur les contrôleurs de domaine. Ces commandes ont été citées depuis la documentation, et non exécutées dans un environnement client.

Comment EtcSec détecte ce cas

Le contrôle etc-collector ACL_COMPUTER_WRITE_VALIDATED_DNS, examiné au commit 15fc6399c215eabc415c370b762303cfcd7a353a, construit un ensemble insensible à la casse des DN d’ordinateurs collectés. Il conserve les enregistrements ACLEntry dont ObjectType vaut 72e39547-7b18-11d1-adef-00c04fd8d5cd et dont ObjectDN appartient à cet ensemble. Count représente les ordinateurs distincts concernés ; lorsqu’il diffère, TotalInstances consigne le nombre d’entrées correspondantes.

Detect() ne filtre ni SELF ni les autres bénéficiaires, ne teste pas le masque d’écriture validée, n’évalue pas l’applicabilité des entrées limitées à l’héritage et ne calcule pas les droits effectifs. Sa sortie constitue le point de départ d’un inventaire pour la revue ci-dessus. La description du détecteur mentionne l’usurpation DNS et le MITM, mais le prédicat implémenté ne prouve aucun de ces résultats.

La collecte limite également l’interprétation. Le fournisseur LDAP demande OWNER, GROUP et DACL avec les indicateurs de descripteur de sécurité 0x07, sans la SACL. Il ignore les erreurs par objet et les descripteurs manquants ; les erreurs réseau interrompent en revanche l’appel principal et peuvent déclencher une reconnexion et une nouvelle tentative. L’analyseur conserve les ACE d’autorisation standard et d’objet, en préservant le masque, l’état hérité et InheritOnly, tout en excluant les ACE de refus. Le détecteur n’utilise pas ces distinctions pour mener un contrôle d’autorisation complet.

GetComputers et son analyseur fournissent les DN utilisés pour la jointure. Un inventaire incomplet des ordinateurs laisse un périmètre de détection incomplet. Un résultat nul signifie qu’aucune entrée correspondante n’existe dans les données fournies ; il ne prouve pas que tous les ordinateurs ont été lus ou qu’aucun principal ne peut modifier l’attribut. Les entrées générales d’écriture validée sans ce GUID précis échappent également au prédicat de correspondance. Rapprochez les échecs de collecte et le périmètre avant d’accepter un résultat nul, et consignez la décision d’autorisation séparément du décompte du scanner.