Périmètre du score de conformité AD : rapprocher cinq déductions

Périmètre du score de conformité AD : ce que le chiffre peut établir

Le périmètre du score de conformité AD détermine ce qu'un chiffre peut étayer dans un audit. Dans l'implémentation d'etc-collector examinée le 4 octobre 2026, le score part de 100 et retire des points pour quatre valeurs de la stratégie de mots de passe du domaine et un décompte des utilisateurs activés portant adminCount=1. Il n'agrège pas tous les constats et n'évalue pas un référentiel de conformité complet.

Un score de 100 signifie qu'aucune de ces cinq conditions de déduction ne s'est déclenchée sur les entrées fournies. Il ne certifie pas Active Directory, ne prouve pas que tous les objets pertinents ont été collectés et n'établit pas que les contrôles indépendants ont été satisfaits. Avant d'utiliser ce chiffre dans un rapport, reconstituez ses entrées et les preuves de leur collecte.

Cette analyse est rattachée à la révision du collecteur 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, précisément à public/internal/audit/detectors/ad/compliance/score.go, à partir de Detect() à la ligne 23. Les exemples ci-dessous sont des calculs issus de ce code, pas des mesures d'un domaine réel. Aucune commande Windows n'a été exécutée sur un environnement pour cet article.

Fonctionnement des cinq déductions

Avec un DomainInfo non nul, chaque condition est évaluée indépendamment. La cinquième entrée est dérivée de la collection Users fournie. Il s'agit de seuils du produit ; les utiliser pour reproduire un résultat n'établit pas qu'ils constituent la référence approuvée de l'organisation.

L'égalité compte : une longueur de 14, un historique de 24, un seuil de verrouillage de 10, un âge maximal de 90 jours et un décompte de 20 ne déclenchent pas leurs déductions respectives. Le compteur compte une fois chaque objet répondant aux critères ; il ne calcule pas un ratio d'administrateurs par rapport aux utilisateurs.

Si DomainInfo est nul, le détecteur ignore les quatre conditions de stratégie et retire 15 sous no_domain_info. Il évalue ensuite la même condition de décompte des utilisateurs. Un objet nul constitue donc une branche de calcul distincte, pas quatre échecs de stratégie confirmés.

Démontrer la plage atteignable

Avec DomainInfo présent, la déduction maximale possible est 10 + 5 + 5 + 5 + 10 = 35. La minimale est zéro. Les scores vont donc de 65 à 100, par pas de cinq points. La borne défensive à zéro n'est jamais atteinte par ces conditions.

Sans DomainInfo, le score est 85 lorsque le nombre d'utilisateurs répondant aux critères est au plus de 20, ou 75 lorsqu'il dépasse 20. Il ne peut prendre aucune autre valeur dans cette branche.

Par exemple, le déclenchement des quatre conditions de stratégie avec un décompte de 20 produit 75 ; un décompte de 21 produit 65. Un objet de domaine nul avec un décompte de 20 produit 85. Ces cas hypothétiques expliquent pourquoi un chiffre en apparence meilleur peut s'accompagner de preuves de stratégie plus faibles.

Le constat comprend des bandes d'interprétation telles que 50-69 et 0-49. Seul 65 est atteignable dans la première ; la seconde est entièrement inaccessible. Les valeurs inférieures à 65 ne peuvent pas résulter de ce seul calcul. Ces libellés d'affichage n'étendent pas la couverture du détecteur et ne transforment pas sa bande supérieure en verdict de conformité.

Détection : rapprocher les entrées de lectures indépendantes

Commencez par le domaine, le contrôleur de domaine choisi, l'heure de collecte et le périmètre d'inventaire. Une lecture indépendante récente depuis un autre DC ou une base de recherche plus restreinte peut décrire des éléments différents. Consignez ces différences avant de considérer un écart comme une erreur du détecteur.

Microsoft documente Get-ADDefaultDomainPasswordPolicy comme récupérant la stratégie par défaut d'un domaine. Cet exemple en lecture seule utilise ses paramètres documentés -Identity et -Server. Remplacez le domaine et le DC illustratifs par les cibles examinées :

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' -Server 'dc01.example.com'

Conservez l'objet retourné complet et comparez la longueur minimale, l'historique des mots de passe, le seuil de verrouillage et l'âge maximal aux entrées du collecteur. Préservez les unités de durée : le fournisseur convertit l'intervalle d'âge maximal de l'annuaire en jours entiers. Ne comparez pas directement un intervalle brut de l'annuaire ou une chaîne de durée formatée à l'entier 90.

Le collecteur lit ces attributs de stratégie dans l'objet du domaine. Il n'utilise pas l'objet de paramètres de mots de passe résultant (PSO) de chaque utilisateur pour ce score. Microsoft documente Get-ADUserResultantPasswordPolicy pour cette question distincte au niveau du compte. Gardez ces preuves en dehors du score reproduit, au lieu de substituer la stratégie d'un utilisateur sélectionné aux entrées du domaine.

Lire adminCount sans renommer la population

La définition Microsoft de l'attribut adminCount décrit un objet dont les ACL ont été renforcées par le système en raison de son appartenance directe ou transitive à un groupe administratif. Cela décrit un historique de protection ; il ne s'agit pas d'une requête d'appartenance actuelle au groupe Domain Admins.

Le fournisseur convertit la chaîne LDAP exacte "1" en booléen utilisateur AdminCount=true. Le détecteur exclut ensuite les utilisateurs désactivés. Bien que la description et le texte du périmètre du constat indiquent « Domain Admins count », le prédicat réel ne résout jamais ce groupe. Préservez cette distinction dans l'explication du résultat.

Utilisez les paramètres documentés de recherche et de propriétés de Get-ADUser pour conserver les enregistrements utilisateurs sous-jacents :

Get-ADUser -Filter * -SearchBase 'DC=example,DC=com' -Server 'dc01.example.com' -Properties adminCount,Enabled

Il s'agit d'un exemple adapté de la documentation, pas d'un inventaire exécuté. À partir des enregistrements retournés, rapprochez les utilisateurs activés dont l'attribut brut adminCount vaut 1 de la population retenue par le collecteur. Conservez les identités des objets et les exceptions, pas seulement le total final. Un attribut absent, une base restreinte ou une limite de collecte doit être qualifié avant d'interpréter un faible décompte.

Construire une fiche de calcul et de provenance

Pour un audit réel, renseignez la fiche suivante avec les valeurs observées. « Collecte confirmée » signifie que la réponse et les attributs requis ont été lus avec succès pour le périmètre indiqué ; une structure non nulle ne suffit pas à l'établir.

Ajoutez à chaque ligne la valeur réelle, le résultat de la collecte, la valeur indépendante et la déduction résultante. Lorsque les preuves manquent, écrivez « inconnu » dans la colonne des preuves tout en préservant l'entrée numérique consommée par le code. Ne remplacez pas silencieusement l'entrée par une valeur supposée.

Remédiation : résoudre les lacunes de preuve avant de modifier la stratégie (Remediation)

Rapprochez d'abord le calcul. Conservez le score du constat, sa table de déductions, les statistiques utilisateurs et la révision du collecteur. Recalculez le résultat avec les entrées fournies et identifiez si l'objet du domaine était présent, partiel ou nul. Cela distingue un écart arithmétique d'une observation incomplète.

Qualifiez ensuite la collecte. Un zéro peut représenter une valeur configurée ou une valeur absente/non analysée dans ce fournisseur. Obtenez la réponse du domaine pertinente et une lecture indépendante sur le DC consigné. Pour les utilisateurs, rapprochez le périmètre et les limites de recherche de la population visée. Un appel GetUsers réussi constitue une preuve nécessaire, mais ne démontre pas à lui seul qu'un inventaire volontairement limité couvre tout le domaine.

Si la collecte est incomplète, résolvez le problème de collecte précis et lancez un nouvel audit. Conservez le résultat précédent comme observation incomplète. Ne décrivez pas le passage de 85 à 100 après récupération des informations du domaine comme quatre contrôles de stratégie remédiés sans preuves de stratégie avant et après.

Identifiez ensuite la référence de l'organisation ainsi que son édition, son responsable et ses exceptions. Notre comparaison des prédicats ANSSI et CIS de stratégie de mots de passe explique pourquoi des contrôles différents peuvent diverger sur des attributs communs. Les cinq déductions de ce score sont un calcul distinct du produit ; elles ne constituent pas une troisième référence de conformité.

Pour une lacune de configuration confirmée, appliquez la modification de stratégie approuvée par le processus d'administration établi, conservez la trace du changement, répétez la lecture indépendante et réauditez le même périmètre. Pour un écart lié à adminCount, examinez séparément les objets réels et les appartenances privilégiées actuelles. Effacer le marqueur uniquement pour réduire le compteur n'établit pas que les privilèges ou la protection des ACL sont corrects.

Joignez enfin les preuves des contrôles indépendants. Notre correspondance des exigences de conformité AD et Azure avec des contrôles d'identité nommés apporte du contexte à ce travail. La journalisation, les protections des protocoles, la gouvernance des accès et les contrôles Entra nécessitent leurs propres résultats. Ce score n'inspecte pas ces contrôles et ne peut pas combler leurs lacunes de preuve.

Comment EtcSec détecte ce cas

COMPLIANCE_SCORE est le seul détecteur traité ici. Sa méthode Detect() lit DomainInfo et Users, applique les cinq conditions ci-dessus et retourne toujours un constat Info avec Count=1, y compris au score 100. Count 1 désigne le constat de score retourné, pas un utilisateur affecté ou un contrôle échoué.

Les détails comprennent score, maxScore=100, deductions, totalUsers, enabledUsers et adminCount. Les totaux utilisateurs décrivent la collection fournie. Ils n'établissent pas une couverture complète de l'annuaire.

Les chemins du fournisseur expliquent les limites :

• public/internal/providers/ldap/client.go:569 crée un objet d'informations du domaine avant d'interroger RootDSE et le domaine. Des réponses échouées ou vides peuvent laisser un objet partiel avec des valeurs à zéro. Les quatre valeurs de stratégie viennent de l'objet du domaine, pas d'un PSO résultant par utilisateur.
• public/internal/providers/ldap/parser.go:155 définit l'attribut utilisateur AdminCount par la comparaison exacte de chaînes adminCount == "1". Sa fonction auxiliaire d'entiers retourne zéro pour les valeurs absentes et ignore les erreurs d'analyse des entiers.
• public/internal/audit/engine.go:512 traite une erreur retournée par GetDomainInfo comme non fatale et fournit des informations de domaine nulles. Cette branche donne 85 avant la déduction optionnelle de 10 points liée à adminCount. En revanche, le chemin d'erreur antérieur de GetUsers interrompt la collecte.
• Les valeurs atteignables du calcul sont 65–100 avec un objet de domaine, ou 75/85 sans lui. Un objet non nul ne prouve pas que les attributs ont été collectés avec succès, et les bandes d'interprétation inférieures à 65 sont inaccessibles pour ce détecteur.

Toutes les références de code ci-dessus sont rattachées à la révision examinée. Présentez la sortie comme un indicateur partiel du produit étayé par des entrées qualifiées. Un score de 100 établit uniquement que ces cinq conditions de déduction ne se sont pas déclenchées ; la conformité globale et la certification exigent des contrôles et des preuves définis indépendamment.