Termes sensibles dans description Active Directory : DA et admin

Les termes sensibles dans description Active Directory peuvent révéler les identités qui méritent une attention particulière, même lorsque le texte ne contient aucun mot de passe. Ce guide distingue une revue manuelle élargie des libellés DA, admin et privileged des cinq motifs implémentés par etc-collector, puis explique comment inventorier, nettoyer et revérifier chaque description.

Ce que révèlent les termes sensibles dans description Active Directory

Une description telle que domain admin — backup operator indique la fonction d’un compte. L’interprétation de sécurité est qu’un lecteur pourrait s’en servir pour présélectionner des cibles potentielles. Elle ne démontre pas que le compte possède réellement des droits d’administration. Cet exemple est fictif : il ne constitue ni une observation en production ni une attaque confirmée.

La même distinction s’applique à DA, aux notes d’accès d’urgence et aux libellés de service. Un analyste peut y voir des indices sur le rôle d’une identité, mais la terminologie locale compte. admin peut désigner des tâches administratives en dehors de l’informatique. service client peut désigner un département métier. Une ancienne description peut subsister après un changement de fonctions. Demandez au propriétaire ce que signifie le texte avant de le considérer comme une preuve de privilèges actuels.

Cet article traite de l’identification de cibles sans secret. Pour les mots de passe exacts, les valeurs temporaires ou les indices sur des identifiants, suivez la procédure d’exposition des mots de passe, de rotation et d’investigation dans les descriptions AD. Supprimer un libellé de rôle et réagir à l’exposition d’un identifiant sont deux tâches différentes ; la découverte d’un secret change la réponse nécessaire.

Utilisez une fiche de revue qui distingue le texte observé, son interprétation et les preuves encore nécessaires. Par exemple, consignez séparément « la description contient privileged » et « le propriétaire a confirmé qu’il s’agit d’une identité d’administration ». Laissez le dossier ouvert si le propriétaire est inconnu. Ne transformez pas une correspondance lexicale en affirmation selon laquelle le compte est compromis, contourne la MFA ou appartient à Domain Admins.

Fonctionnement de l’accès en lecture à description

Le guide Microsoft des comptes et groupes privilégiés explique que les ACL accordent couramment à Authenticated Users l’accès aux informations générales des objets. Sa section sur les permissions inclut explicitement les propriétés générales des utilisateurs. Cela justifie de vérifier l’exposition de description avec une identité authentifiée ordinaire, plutôt que de supposer que le champ n’est visible que par les administrateurs. Authentifié ne signifie pas anonyme, et l’autorisation de lire n’implique pas celle de modifier.

La documentation historique sur les attributs confidentiels décrit également l’accès en lecture par défaut aux attributs et le rôle de READ_PROPERTY. L’accès réel dépend des permissions effectives de l’objet. Une modification locale des permissions peut changer ce qu’un lecteur reçoit ; vérifiez donc le déploiement au lieu de supposer que tous les objets suivent les valeurs par défaut.

La référence du schéma description identifie l’attribut LDAP comme description, avec searchFlags=0x00000000 et systemFlags=0x00000010. Ses remarques distinguent les descriptions à valeur unique des classes gérées par SAM, dont les principaux de sécurité, des valeurs potentiellement multiples sur d’autres classes. Une revue élargie des objets doit conserver ces valeurs plutôt que de supposer que chaque description est une seule chaîne de compte utilisateur.

Pour comparer utilement l’exposition, choisissez un objet connu dont le champ est renseigné et effectuez la même lecture délimitée avec un lecteur ordinaire et un analyste autorisé. Consignez l’identité utilisée, le contrôleur de domaine, la base de recherche, l’heure et les éventuelles erreurs. Il s’agit d’une procédure de mesure recommandée, pas d’une affirmation que ces tests ont été réalisés ici. Conservez les éléments de revue dans un emplacement à accès contrôlé ; un nettoyage ne doit pas créer une nouvelle liste d’identités sensibles largement partagée.

Détection

Étape 1 — Inventorier les descriptions utilisateur renseignées

Les commandes ci-dessous sont adaptées de Microsoft Learn, à partir des paramètres documentés de Get-ADUser et Get-ADObject. Elles n’ont pas été exécutées sur un annuaire pour cet article. Remplacez le DN et le serveur d’exemple, utilisez le module ActiveDirectory et sélectionnez le lecteur dont vous souhaitez mesurer l’accès. Chaque bloc constitue une mesure distincte.

Commencez par les descriptions utilisateur renseignées :

Get-ADUser -LDAPFilter '(description=*)' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Demander -Properties description sollicite l’attribut ; cela n’accorde pas l’accès. Une réponse vide nécessite une investigation. Vérifiez le périmètre, les permissions et le retour d’un objet connu dont le champ est renseigné avant de déclarer l’annuaire exempt de descriptions sensibles.

Étape 2 — Séparer les comptes activés et désactivés

L’exemple 5 de Get-ADUser de Microsoft utilise le test LDAP bit à bit du bit 2 de userAccountControl pour exclure les comptes désactivés. L’inventaire ci-dessous ajoute la condition sur description et utilise la forme NOT entre parenthèses documentée dans la syntaxe des filtres de recherche LDAP de Microsoft :

Get-ADUser -LDAPFilter '(&(description=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Pour la revue complémentaire, conservez le test de bit sans négation :

Get-ADUser -LDAPFilter '(&(description=*)(userAccountControl:1.2.840.113556.1.4.803:=2))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Cela distingue l’état du compte, pas ses privilèges réels. Gardez les objets désactivés dans la file de nettoyage et examinez leur description avant toute réactivation prévue. N’interprétez pas l’indicateur de désactivation comme une preuve que personne ne peut lire l’objet ou que toutes les sessions antérieures ont été invalidées.

Étape 3 — Examiner les correspondances lexicales et les libellés locaux plus larges

Une présélection par sous-chaîne peut faciliter le premier passage :

Get-ADUser -LDAPFilter '(|(description=*admin*)(description=*privileged*))' -Properties description,Enabled -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Cette présélection LDAP n’équivaut pas aux regex du collecteur. Examinez l’inventaire initial des descriptions renseignées pour rechercher DA, break-glass, service, les abréviations locales et les termes dans d’autres langues. Sinon, une requête étroite peut masquer précisément les libellés que l’exercice manuel vise à évaluer.

Les motifs exacts du collecteur sont définis dans accounts/privileged/domain-admin-description.go:35–41, relativement à public/internal/audit/detectors/ad/ :

(?i)domain\s*admin
(?i)enterprise\s*admin
(?i)administrator
(?i)admin\s*account
(?i)privileged

Les cinq ignorent la casse. Ils ne comportent ni limite de mot ni ancrage de début ou de fin, et \s* autorise l’absence d’espace. Ainsi, domainadmin correspond au premier motif et unprivileged au dernier. Ce dernier terme peut décrire l’inverse de ce que l’analyste attend ; examinez la valeur complète au lieu de considérer la sous-chaîne trouvée comme un verdict.

Ces résultats découlent des motifs du code source ; ce ne sont pas des résultats rapportés d’un audit réel. Maintenez trois conclusions distinctes : le texte correspondant, la fonction confirmée par le propriétaire et l’accès vérifié indépendamment. Cette séparation permet d’expliquer un faux positif sans prétendre que l’inventaire élargi est complet.

Étape 4 — Élargir les objets et surveiller les modifications

Si les descriptions d’autres classes d’objets entrent dans le périmètre, utilisez un inventaire distinct :

Get-ADObject -LDAPFilter '(description=*)' -Properties description -SearchBase 'DC=corp,DC=example' -Server 'dc01.corp.example'

Il inclut toute classe d’objet retournée dont la description est renseignée. Il s’agit d’une extension manuelle au-delà des deux détecteurs utilisateur, pas d’une preuve que leur couverture automatique inclut ces objets. Conservez les valeurs multiples de description lorsque le schéma les autorise.

Pour surveiller la réintroduction de texte, la référence Microsoft de l’Event ID 5136 documente les modifications de l’annuaire. Configurez Audit Directory Service Changes et une SACL Write adaptée aux objets et attributs surveillés. Sélectionnez les événements où AttributeLDAPDisplayName=description ; examinez l’acteur, l’objet et la valeur. Lorsque les événements Value Deleted et Value Added sont tous deux disponibles, corrélez-les avec OpCorrelationID, pour le même objet et le même attribut.

L’absence d’événement 5136 ne prouve pas que personne n’a lu le texte précédent. Ces événements de modification et l’inventaire de posture répondent à des questions différentes : ce qui est écrit maintenant et la modification auditée qui a eu lieu.

Remédiation (Remediation)

Étape 1 — Convenir des informations de remplacement

Pour une divulgation portant uniquement sur le rôle, la procédure recommandée consiste à déplacer le contexte sensible vers un inventaire ou un runbook doté de contrôles d’accès adaptés. Faites approuver par le propriétaire ce qui doit rester dans AD. Une référence opaque telle que Managed record INV-01234 peut conserver un repère opérationnel sans nommer les privilèges ni la procédure d’urgence. Le système référencé doit lui aussi contrôler l’accès ; masquer le nom d’un enregistrement ne constitue pas une autorisation.

Définissez avec l’équipe qui provisionne les comptes des exemples de formulations acceptables et inacceptables. Incluez les libellés locaux que les contrôles automatisés manquent. Examinez les modèles du support, les consignes de passation et les personnes pouvant modifier les descriptions afin que la même note ne réapparaisse pas lors de la prochaine maintenance. Prenez une décision par objet au lieu de vider indistinctement toutes les descriptions renseignées.

Étape 2 — Prévisualiser et confirmer la modification d’un champ

Ces exemples adaptent les paramètres Clear, Description, WhatIf et Confirm documentés pour Set-ADUser. L’exemple 4 vide spécifiquement description. Choisissez la suppression ou le remplacement pour le compte sélectionné.

Prévisualisez la suppression :

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -WhatIf

Après approbation du propriétaire, demandez une confirmation pour la suppression réelle :

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Clear description -Server 'dc01.corp.example' -Confirm

Vous pouvez également prévisualiser un remplacement neutre :

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -WhatIf

Confirmez ensuite ce remplacement séparément :

Set-ADUser -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Description 'Managed record INV-01234' -Server 'dc01.corp.example' -Confirm

-WhatIf n’applique pas la modification et ne prouve pas la compatibilité applicative. Conservez l’identité de l’objet sélectionné et l’action approuvée dans la fiche de changement, puis vérifiez la valeur écrite. Ces commandes sont des exemples documentés, pas un script global de remédiation ni un compte rendu de nettoyage réalisé.

Étape 3 — Éviter les raccourcis de confidentialité non pris en charge

Si des restrictions locales de lecture sont envisagées, faites d’abord réaliser une revue des permissions effectives et des dépendances. Les pages Microsoft sur les permissions et les attributs confidentiels expliquent les ACE, l’héritage et les contrôles de lecture ; elles ne valident pas une recette universelle d’ACL pour ce déploiement. Ajouter un lecteur dédié ne supprime pas un accès large déjà accordé. Ne retirez pas globalement l’accès en lecture d’Authenticated Users sans auditer les consommateurs et la délégation.

Privilégiez le stockage des informations opérationnelles confidentielles dans un système de référence protégé. Une extension du schéma ou une refonte du modèle de permissions nécessite son propre projet testé. Nettoyer les descriptions réduit un indice ; cela ne remplace pas la réduction des privilèges et ne masque pas toutes les autres propriétés de l’annuaire.

Validation après nettoyage

Utilisez la lecture Identity de Get-ADObject documentée pour examiner l’objet sélectionné après l’écriture autorisée :

Get-ADObject -Identity 'CN=ExampleAdmin,OU=Accounts,DC=corp,DC=example' -Properties description -Server 'dc01.corp.example'

La fiche d’acceptation recommandée doit préciser si la valeur prévue est présente, si le propriétaire peut utiliser la référence protégée et si les outils légitimes fonctionnent toujours. Revérifiez l’inventaire avec le même lecteur et le même périmètre qu’au départ. Tenez compte de la réplication entre contrôleurs de domaine lorsque vous comparez les serveurs d’annuaire, et conservez l’identité du DC afin d’investiguer les différences de lecture au lieu de les écarter.

Validez les libellés plus larges autant que les correspondances regex. Un résultat automatisé vierge après le remplacement de domain admin par DA laisserait l’indice de ciblage en place. À l’inverse, une formulation approuvée contenant unprivileged peut rester une correspondance lexicale dont le contexte est bénin. Consignez explicitement cette décision ; n’affirmez pas que chaque correspondance restante représente un accès dangereux ou que chaque résultat négatif prouve une formulation sûre.

Les droits réels nécessitent une revue distincte. La validation de la dérive des accès privilégiés examine les appartenances effectives, les chemins d’ACL déléguées et les droits de réplication par rapport à une référence. Utilisez cette procédure lorsqu’une description suggère un accès d’administration. Modifier la description ne prouve pas en soi que les droits du compte ont été réduits.

Enfin, vérifiez la configuration de surveillance des modifications avec un changement de test approuvé et contrôlez que les données 5136 attendues atteignent le processus de revue. Examinez toute nouvelle formulation sensible avec son propriétaire. Si un secret est découvert pendant la validation, orientez-le vers la procédure d’exposition d’identifiants au lieu de fermer le dossier après modification du champ. Désignez le responsable de la prochaine revue afin que les descriptions des identités désactivées soient également vérifiées avant réactivation.

Comment EtcSec détecte ce problème

Les deux implémentations d’etc-collector examinées pour cet article travaillent sur data.Users et la chaîne Description collectée. Toutes deux ignorent les descriptions vides et s’arrêtent au premier motif reconnu pour un utilisateur. Elles utilisent les mêmes cinq regex, tout en sélectionnant des populations d’états de compte opposées.

Le prédicat des comptes activés se trouve aux lignes 47–61 du premier fichier ; celui des comptes désactivés aux lignes 43–57 du second. Leurs constats comptent les utilisateurs concernés. Des entités de détail ne sont jointes que si IncludeDetails vaut true et qu’au moins un utilisateur est concerné, aux lignes 72–74 et 68–70 respectivement.

Aucun des deux Detect() ne lit memberOf, ne vérifie les droits réels, ne recherche des mots de passe ou n’analyse les événements de l’annuaire. L’identifiant DOMAIN_ADMIN_IN_DESCRIPTION décrit donc un contrôle d’exposition lexicale, pas une preuve qu’un utilisateur concerné appartient à Domain Admins. Les valeurs High/Low sont des classifications de politique du collecteur, pas des résultats d’attaque mesurés ni des niveaux de sévérité Microsoft.

Traitez ces constats comme des entrées de revue : examinez le texte, confirmez la fonction avec le propriétaire, nettoyez le champ approuvé et relancez le contrôle délimité. Un constat lexical négatif ne démontre pas l’absence de libellés sensibles, et supprimer un libellé ne démontre pas la suppression des privilèges.