La couverture PSO des comptes de service : tout vérifier

Ce que la couverture PSO des comptes de service doit prouver

La couverture PSO des comptes de service désigne les preuves que chaque identité de service du périmètre a été examinée selon son modèle réel de gestion des identifiants et le référentiel de mots de passe approuvé. Pour un utilisateur de domaine traditionnel exécutant un service, cela signifie lire le Password Settings Object (PSO) résultant, ou consigner la stratégie par défaut du domaine lorsqu'aucun PSO ne s'applique. Trouver une stratégie liée à un compte de service ne permet pas d'établir la couverture du reste de la population.

Le livrable concret est une matrice : compte, service, responsable, PSO résultant, preuves de la stratégie par défaut du domaine et décision de dérogation. Gardez les échecs de collecte visibles dans cette matrice. Une stratégie inaccessible constitue une lacune de preuve non résolue ; elle ne doit jamais devenir silencieusement « protégé » ou « aucune stratégie ».

Cette distinction compte pour interpréter un constat automatisé. L'implémentation d'etc-collector examinée ici recherche si un compte de service sélectionné possède un lien FGPP répondant aux critères. Elle ne détermine pas si chaque compte sélectionné reçoit une stratégie résultante approuvée. L'absence de constat nécessite donc un examen de couverture avant de pouvoir justifier une décision de clôture.

Différence entre un lien de stratégie et une stratégie résultante

La référence Microsoft de Get-ADUserResultantPasswordPolicy identifie msDS-ResultantPSO comme l'attribut de stratégie résultante. Les affectations directes sont prioritaires sur les stratégies liées à des groupes. Dans le niveau applicable, la valeur msDS-PasswordSettingsPrecedence la plus basse l'emporte ; les valeurs égales sont départagées par l'objectGUID le plus bas, comme le précise l'algorithme Microsoft du PSO résultant. Un lien vers une stratégie candidate ne prouve donc pas quelle stratégie l'emporte.

L'examen de couverture doit conserver l'identité et les paramètres de la stratégie retournée plutôt que déduire la stratégie gagnante d'un nom de groupe. Si une stratégie liée à un groupe, apparemment robuste, coexiste avec une autre affectation directe, examinez l'objet résultant avant d'accepter le groupe comme preuve de protection. Il s'agit d'un exemple de raisonnement, pas du compte rendu d'une mauvaise configuration observée.

Une autre question concerne les identités à inclure dans l'examen. Les recommandations Microsoft sur les comptes de service distinguent les comptes de service fondés sur des utilisateurs de domaine traditionnels des identités gérées et virtuelles. Elles décrivent la gestion automatique des mots de passe gMSA et ne définissent aucune longueur minimale universelle pour les comptes de service. L'examen doit préserver ces distinctions plutôt que traiter tout nom évoquant un service comme un utilisateur ordinaire dont le mot de passe est entretenu manuellement.

Détection et vérification : construire la matrice de couverture

1. Convenir de la population avec les responsables des services

Partez de l'inventaire des services et rapprochez-le des candidats de l'annuaire. Consignez l'identifiant stable du compte, les services associés, le responsable opérationnel, l'état d'activation, le type d'identité et la responsabilité de gestion des identifiants. Lorsqu'un compte sert plusieurs applications, conservez toutes les dépendances plutôt que choisir un seul nom de service pratique.

La liste de candidats du détecteur est une entrée utile, mais elle ne constitue pas l'inventaire de référence des services. Une heuristique de nommage peut inclure des utilisateurs sans rapport et manquer un service exécuté sous un nom inattendu sans SPN. Résolvez ces écarts avec les responsables. Notre examen du nommage des comptes et des stratégies effectives explique pourquoi les noms sélectionnent des candidats sans prouver la faiblesse d'un mot de passe ; utilisez ce tutoriel existant pour l'investigation plus large du nommage.

Gardez les comptes désactivés visibles avec une décision distincte : conservation pour une raison documentée, retrait en attente, ou exclusion du référentiel des services actifs avec approbation. Ne comptez pas la stratégie d'un compte désactivé comme preuve que la population des services actifs est couverte. Le détecteur ne fait pas cette distinction.

Pour les identités gérées, la capacité de filtrage documentée de Get-ADServiceAccount permet cette adaptation d'inventaire en lecture seule :

Get-ADServiceAccount -Filter * -Server dc01.contoso.com

La commande retourne des objets de comptes de service gérés, pas un inventaire complet de tous les services ou des comptes de service fondés sur des utilisateurs traditionnels. Utilisez l'identité et le type des objets pour rapprocher les résultats de l'inventaire des services. Ne demandez pas les données de mot de passe géré pour cet examen. Consignez les gMSA dans leur parcours de contrôle des identifiants gérés plutôt que les déclarer défectueux uniquement parce qu'un champ PSO d'utilisateur traditionnel est vide ou inapplicable.

2. Lire une stratégie résultante pour chaque compte utilisateur traditionnel

Exécutez l'adaptation suivante, documentée pour les paramètres d'identité et de serveur, sur chaque compte de service approuvé fondé sur un utilisateur traditionnel, en remplaçant le DN et le contrôleur de domaine illustratifs par la cible vérifiée :

Get-ADUserResultantPasswordPolicy -Identity "CN=svc-sql,OU=Service Accounts,DC=contoso,DC=com" -Server dc01.contoso.com -ErrorAction Stop

La référence de la cmdlet documente ces paramètres, la gestion courante des erreurs et les erreurs de permissions d'annuaire. Conservez la commande, l'identité interrogée, le serveur, l'horodatage, l'objet retourné et l'enregistrement d'erreur. Une réponse réussie contenant un objet de stratégie fournit l'identité et les paramètres du PSO résultant. Une erreur fournit la preuve d'une lecture infructueuse ; elle ne fournit aucun verdict de couverture.

Répétez la lecture pour chaque compte de la population des utilisateurs traditionnels. Conservez les lignes réussies lorsqu'un autre compte échoue, et gardez la ligne en échec ouverte. Ne convertissez pas un appel en échec en valeur de stratégie nulle dans un export, et n'omettez pas les lignes en échec du dénominateur. Toute automatisation de collecte de la matrice doit porter un champ d'état de lecture distinct à côté du champ de stratégie.

3. Consigner la stratégie par défaut du domaine et expliquer les liens concurrents

Utilisez l'exemple d'identité et le paramètre de serveur documentés par Get-ADDefaultDomainPasswordPolicy, adaptés au domaine visé :

Get-ADDefaultDomainPasswordPolicy -Identity contoso.com -Server dc01.contoso.com

Conservez la stratégie par défaut comme preuve à l'échelle du domaine. Pour une lecture utilisateur réussie sans PSO retourné, vérifiez l'identité et le contexte de requête, puis consignez la stratégie par défaut applicable et son évaluation par rapport au référentiel. Laissez la ligne non résolue si l'exhaustivité de la lecture ou les permissions restent incertaines. Un champ PSO vide ne suffit pas, à lui seul, pour approuver la ligne.

Pour examiner les liens vers des stratégies candidates, utilisez la capacité de filtrage documentée de Get-ADFineGrainedPasswordPolicy :

Get-ADFineGrainedPasswordPolicy -Filter * -Server dc01.contoso.com

Examinez les valeurs AppliesTo, Precedence et les paramètres retournés en parallèle du résultat par utilisateur. L'inventaire des stratégies explique les affectations candidates ; il ne remplace pas la lecture résultante. N'enregistrez que les preuves de stratégie et d'identité nécessaires à l'examen.

Si un chemin d'appartenance imbriquée est pertinent, documentez la chaîne du compte au groupe, la cible de la stratégie, les preuves d'appartenance obtenues avec autorisation et la stratégie résultante retournée. Marquez une chaîne incomplète comme non vérifiée. Ne déduisez pas un PSO effectif d'un schéma d'apparence récursive ou de la comparaison des membres directs par le détecteur. Demandez au responsable de l'annuaire de rapprocher les preuves incohérentes d'appartenance et de stratégie résultante avant de clôturer cette ligne.

4. Utiliser des résultats explicites par ligne

Voici une proposition de schéma de preuve, pas un échantillon de comptes réels ou de résultats de tests :

Une ligne complétée peut être approuvée au moyen d'un PSO résultant vérifié, d'une stratégie par défaut du domaine approuvée, ou d'un parcours de contrôle d'identité gérée justifié séparément. Ces résultats sont différents. « Refus », « échec » et « applicabilité en attente » restent des lacunes de preuve ouvertes. Une dérogation est une décision documentée, pas une réussite automatique.

Rapprochez la matrice de la population convenue avant de la synthétiser. Signalez explicitement les lectures non résolues et les identités exclues. L'absence de constat automatisé ne doit pas effacer ces lignes.

Remédiation : résoudre l'écart au référentiel de chaque compte (Remediation)

1. Approuver les paramètres selon le contexte du service

Utilisez la matrice pour identifier les comptes traditionnels qui ne respectent pas leur référentiel approuvé. Faites convenir les responsables du service et de l'annuaire des paramètres de mots de passe requis, de la compatibilité opérationnelle, de l'entretien des identifiants et du plan de déploiement. Examinez l'ensemble des paramètres retournés ; comparer seulement la longueur minimale ne suffit pas pour un référentiel approuvé localement.

La valeur 20 du détecteur est un seuil d'implémentation. N'en faites pas une exigence Microsoft pour tous les services, et ne copiez pas des paramètres de stratégie de démonstration comme recommandations de production. Conservez le référentiel approuvé du service et sa justification dans la ligne du compte.

2. Corriger délibérément les affectations et les lacunes de preuve

Lorsqu'une FGPP approuvée est prévue, planifiez la correction nécessaire d'affectation ou de priorité via le processus de changement de l'annuaire. Prenez en compte les affectations directes concurrentes et les consommateurs de stratégies partagées avant de modifier quoi que ce soit. Évitez de créer un seul lien répondant aux critères uniquement pour diminuer le compteur du détecteur.

Une lecture refusée nécessite un accès autorisé ou un autre parcours approuvé de collecte de preuves avant toute décision de couverture. Conservez ensemble l'erreur initiale et la lecture réussie ultérieure. Corriger la collecte est un préalable à l'interprétation de la stratégie ; cela ne corrige pas en soi les identifiants du compte.

Pour les dérogations maintenues, consignez la dépendance du service, le responsable, les mesures compensatoires, l'approbateur et la prochaine date de réexamen. Gardez la dérogation de la ligne visible dans les futurs rapports de couverture. Une dérogation sans responsable ou expirée doit retourner en examen.

3. Séparer les décisions de compte géré et de retrait

Pour un service éligible à gMSA, évaluez une migration vers une identité gérée avec son responsable, puis validez la compatibilité et la récupération autorisée des identifiants. Ce changement est distinct de l'affectation d'une FGPP à un compte traditionnel. Conservez la décision de classification et les preuves de migration dans la matrice.

Pour les identités désactivées, résolvez les dépendances et la raison de conservation avant le retrait. Ne supprimez pas des comptes en masse parce qu'ils apparaissent dans un examen de couverture. Inversement, ne laissez pas une identité inutilisée mais répondant aux critères masquer les lacunes des services actifs.

Pour l'exposition aux attaques, notre guide Kerberoasting sur les tickets de service et les secrets des comptes de service couvre l'investigation distincte des tickets, secrets et privilèges. Cette matrice établit la couverture de l'examen des stratégies ; elle ne prouve ni la résistance au cassage hors ligne ni l'absence d'activité malveillante.

4. Répéter les lectures après les changements approuvés

Réexécutez la commande de stratégie résultante par utilisateur et les lectures d'inventaire pertinentes après le changement approuvé. Joignez les preuves avant et après à chaque ligne affectée, puis faites valider par les responsables le fonctionnement du service et le plan d'entretien des identifiants. Un résultat PSO modifié prouve un résultat de stratégie, pas la qualité d'un secret existant.

Comment EtcSec détecte ce problème

Le contrôle d'etc-collector SERVICE_ACCOUNT_WEAK_PASSWORD_POLICY relève de la catégorie Password et de la sévérité Medium. Cette description provient de public/internal/audit/detectors/ad/password/service-account-password-policy.go:39 au commit du collector 0423094759d50002457031317098417993e19510.

Il sélectionne les utilisateurs collectés possédant un SPN ou un nom probable de service : préfixes svc_, svc-, sa_, sa-, sql, iis ou app, ou sous-chaîne service, après conversion de sAMAccountName en minuscules. Les comptes sélectionnés doivent avoir un DN non vide. L'ensemble de DN résultant est dédupliqué sans exclure les comptes désactivés ni séparer les gMSA.

Le contrôle recherche ensuite les FGPP collectées dont la longueur minimale est au moins 20. Une correspondance directe de AppliesTo avec un compte sélectionné, ou une correspondance avec la liste de Members directs d'un groupe contenant un tel compte, active son indicateur de couverture. La recherche s'arrête après la première relation répondant aux critères.

Par conséquent, Count=1 signifie que des comptes sélectionnés existent et qu'aucune relation répondant aux critères n'a été trouvée dans les données collectées. Count=0 signifie qu'aucun compte n'a été sélectionné ou qu'au moins une relation répondant aux critères a été trouvée. Count est binaire, ce n'est pas le nombre de comptes non couverts. Les détails incluent serviceAccountCount, qui représente la taille de l'ensemble des DN sélectionnés, pas un total de couverture.

Le contrôle ne lit pas msDS-ResultantPSO, ne calcule pas la priorité effective, ne développe pas les groupes imbriqués, ne compare pas chaque compte à un référentiel, n'inspecte pas un mot de passe existant et ne vérifie pas MFA. Son texte descriptif ne doit pas être considéré comme une preuve que ces contrôles ont été testés.

La collecte limite également la conclusion. Dans public/internal/providers/ldap/client.go:1835, GetFGPPs retourne nil, nil lorsque sa recherche dans le conteneur de stratégies échoue. Le moteur accepte une erreur nil dans public/internal/audit/engine.go:557 ; ce chemin ne distingue pas un conteneur inaccessible d'une liste de stratégies vide pour ce détecteur. Avec des comptes sélectionnés, cette entrée vide peut conduire à Count=1. Examinez la collecte avant d'affirmer qu'aucune stratégie n'existe.

Décisions à consigner avant la clôture

Résolvez trois questions avec les responsables redevables :

1. Quelles identités exécutent réellement des services, y compris les comptes désactivés et gérés, et quel parcours de contrôle s'applique à chacune ?
2. Comment les lectures refusées, les requêtes en échec et les appartenances imbriquées pertinentes ont-elles été consignées et rapprochées ?
3. Quel référentiel est approuvé pour chaque service, et quelles dérogations maintenues disposent d'un approbateur et d'une date de réexamen ?

Conservez ensemble la définition de la population, les lectures de stratégies, les explications d'appartenance, les preuves de changement et les décisions, sans exporter de secrets. La déclaration finale de couverture doit décrire les comptes réellement examinés et les lacunes encore ouvertes. Elle ne doit jamais déduire une protection universelle d'une seule relation FGPP répondant aux critères.