Groupes restreints administrateurs locaux : vérifier avant déploiement

Ce que contrôlent réellement les stratégies de groupes restreints administrateurs locaux

L'examen des stratégies de groupes restreints administrateurs locaux commence par une question pratique : quelles identités doivent conserver un accès administratif sur chaque poste de travail ou serveur membre ? Une entrée de GPO n'est qu'un élément de preuve. Avant de déployer une configuration de référence des membres, comparez la population prévue au groupe réel, examinez les deux propriétés d'appartenance de la stratégie et démontrez quels ordinateurs la reçoivent.

Ce guide décrit une procédure de vérification et de déploiement, confrontée à la documentation Microsoft et à l'implémentation d'etc-collector le 4 octobre 2026. Les commandes sont des exemples de consultation destinés à un administrateur Windows autorisé ; aucune n'a été exécutée sur un domaine pour cet article. Aucun changement d'appartenance ni résultat de déploiement n'est revendiqué.

Microsoft documente deux opérations différentes dans Restricted Groups :

Microsoft prend en charge ce mécanisme pour les groupes locaux, pas pour gérer les membres des groupes de domaine. Ajouter un groupe de sécurité du domaine au groupe Administrators local d'un ordinateur est une opération différente de la modification des membres de ce groupe de domaine. Cette procédure concerne les postes de travail et les serveurs membres ; les contrôleurs de domaine nécessitent une conception d'administration distincte.

Le groupe local est également distinct de l'attribution des droits utilisateur. Examinez les privilèges GPO tels que SeDebug et SeTcb séparément des membres du groupe Administrators local. Une revue des membres ne peut pas certifier ces attributions de privilèges.

Fonctionnement : lire la stratégie avant d'interpréter le constat

Dans les fichiers SYSVOL de la GPO, examinez Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf, y compris la section [Group Membership] complète. Consignez le GUID de la GPO, son nom d'affichage, le contrôleur de domaine source, l'heure de collecte et la réussite ou l'échec de la lecture du fichier. Conservez les lignes brutes avec la vue de l'éditeur de stratégie.

Le modèle suivant est illustratif et reprend le format de clé lu par le collecteur. Les valeurs entre chevrons sont des espaces réservés, pas des SID valides ni une configuration de référence déployable :

[Group Membership]
*S-1-5-32-544__Members = *<approved-domain-group-SID>,*<approved-local-account-SID>

Identifiez le principal avant __, puis vérifiez si le fichier réel contient __Members, __Memberof, les deux ou aucun pour ce principal. Consignez séparément une valeur __Members explicitement vide et une clé absente. Un tableau de membres analysés vide ne permet pas, à lui seul, de retrouver ces distinctions.

La procédure Microsoft relative aux modèles de sécurité présente les deux zones d'édition : Members of this group et This group is a member of. Cet article décrit le fonctionnement historique du composant logiciel enfichable de Windows Server 2003 ; utilisez-le pour comprendre les propriétés, sans considérer son ancienne interface ni sa liste de plateformes comme des instructions de déploiement actuelles.

Privilégiez une revue fondée sur les SID lorsque les noms d'affichage varient selon la langue. La documentation Microsoft sur les identificateurs de sécurité identifie S-1-5-32-544 comme le groupe Administrators intégré. Conservez le SID et le nom résolu dans les preuves. Un nom localisé valide sous Windows n'est pas nécessairement reconnu par la comparaison de chaînes d'un collecteur.

Ne modifiez pas manuellement un fichier SYSVOL de production pour faire disparaître un constat d'audit. Examinez et créez la GPO prévue selon votre processus de gestion approuvé, puis inspectez le fichier obtenu et le comportement des machines.

Détection : établir les membres, le périmètre et les preuves de changement

Étape 1 — Relever l'état initial de la machine

Sur chaque poste de travail ou serveur membre sélectionné, relevez les membres directs actuels avant de modifier la stratégie. Microsoft fournit cet exemple Get-LocalGroupMember exact pour un nom de groupe anglais :

Get-LocalGroupMember -Group "Administrators"

Pour sélectionner le groupe indépendamment de la langue, cette même documentation définit le paramètre -SID. Cet exemple de consultation utilise ce paramètre documenté avec le SID du groupe intégré :

Get-LocalGroupMember -SID 'S-1-5-32-544'

Utilisez un contexte Windows PowerShell pris en charge ; Microsoft précise que le module LocalAccounts n'est pas disponible dans PowerShell 32 bits sur un système 64 bits. Enregistrez le résultat avec l'identité de l'ordinateur et l'horodatage. Si la commande échoue, conservez l'erreur et marquez cette machine comme non résolue, plutôt que de consigner un groupe vide.

Pour chaque principal retourné, consignez son SID, le compte ou groupe résolu, le responsable opérationnel et la justification de l'accès. Lorsqu'un groupe de domaine est présent, examinez séparément les personnes et les groupes imbriqués qui obtiennent des droits par son intermédiaire. La liste des membres locaux directs ne suffit pas à identifier qui bénéficie finalement de l'accès via ce groupe.

Étape 2 — Démontrer que l'ordinateur reçoit la stratégie prévue

Examinez les liens de GPO, l'état de la configuration ordinateur, le filtrage de sécurité, le filtrage WMI et l'héritage. Incluez des machines représentatives du périmètre prévu et des machines qui doivent en rester exclues. Ne déduisez pas l'application de la stratégie du nom descriptif d'une GPO ni de la présence de son fichier dans SYSVOL.

Microsoft documente gpresult pour obtenir les informations du jeu de stratégie résultant. Ces exemples en lecture seule combinent son périmètre ordinateur et ses options de sortie documentés :

gpresult /scope computer /r
gpresult /scope computer /h computer-policy.html

Le premier affiche un résumé ; le second enregistre un rapport HTML. Exécutez-les dans un contexte autorisé à obtenir les données de stratégie ordinateur. Conservez les preuves des GPO appliquées et refusées, l'horodatage et les éventuelles erreurs du rapport. Sur ARM64, la page Microsoft précise qu'il faut utiliser l'exécutable gpresult de SysWow64 pour l'option HTML.

Utilisez RSoP pour étudier l'application et la priorité, puis corroborez les membres réels sur la machine. Ni un rapport ni un modèle lisible ne remplacent cette observation finale.

Étape 3 — Identifier les autres mécanismes qui modifient les membres

Inventoriez les éléments Local Users and Groups des préférences de stratégie de groupe, leurs actions et leur ciblage. La référence Microsoft sur les préférences de stratégie de groupe présente cette extension comme un mécanisme de modification des utilisateurs et groupes locaux. Interrogez aussi le responsable de la gestion des appareils sur les scripts et profils MDM qui agissent sur le même groupe.

Pour les appareils gérés par MDM, inspectez le CSP de stratégie LocalUsersAndGroups. Son action Update peut ajouter ou supprimer les membres spécifiés tout en conservant ceux qui ne le sont pas ; Restrict remplace les membres. Pour l'action Restrict de ce CSP sur le groupe Administrators intégré, incluez le compte Administrator intégré dans la liste des membres à ajouter ; Microsoft documente une erreur si un remplacement tente de le supprimer. La documentation avertit que l'application simultanée des stratégies CSP LocalUsersAndGroups et RestrictedGroups sur un même appareil n'est pas prise en charge. Cet avertissement concerne ces deux stratégies CSP nommées ; il ne constitue pas une règle universelle de priorité pour toutes les combinaisons GPO/MDM.

Documentez le système responsable des membres pour chaque population d'appareils. Résolvez les instructions qui se chevauchent avant le pilote ; ne devinez pas quel mécanisme produira l'état final souhaité.

Étape 4 — Surveiller les ajouts et les suppressions

Les pages d'événements Microsoft confirment ces entrées du journal Security sous Audit Security Group Management :

Collectez les événements sur les machines concernées, pas uniquement sur les contrôleurs de domaine. Pour cette procédure, sélectionnez les événements dont TargetSid vaut S-1-5-32-544 et conservez l'ordinateur, l'heure, MemberSid, l'identité du sujet et SubjectLogonId. Vérifiez le bon fonctionnement de la collecte et du transfert des journaux d'audit avant de vous appuyer sur une absence d'événements.

Comparez les changements avec le dossier de déploiement et les tests applicatifs. Un ajout inattendu après une actualisation de stratégie peut justifier une recherche d'une autre source de gestion ou d'une modification manuelle ; il n'identifie pas, à lui seul, la GPO responsable et n'établit pas une attaque. Ces événements décrivent des changements de membres, pas la liste complète des membres actuels.

Déployer une configuration de référence approuvée des membres (Remediation)

Étape 1 — Approuver la population autorisée

Créez des configurations de référence distinctes lorsque les postes de travail et les rôles de serveur ont des besoins différents. Pour chaque principal conservé, exigez un responsable, un objectif et un périmètre. Pour chaque suppression proposée, demandez au responsable de l'application ou du support concerné d'en valider l'impact. Consignez les exceptions avec leur population d'appareils, leur justification et leur date de revue.

Utilisez le modèle d'administration par tiers pour définir les responsables, les populations administratives et les frontières de connexion. Une configuration de référence des membres locaux s'inscrit dans cette architecture ; elle ne remplace pas la décision sur les endroits où ces identités peuvent ouvrir une session.

Étape 2 — Établir une voie de récupération utilisable

Avant le remplacement, testez le processus de récupération approuvé sur les appareils pilotes. Confirmez le compte administratif local désigné, ses appartenances requises et la capacité de l'équipe autorisée à récupérer l'accès si l'administration habituelle du domaine échoue. Excluez les identifiants secrets des exports de revue de stratégie et des fichiers de preuve partagés.

Windows LAPS gère et sauvegarde les mots de passe des comptes administrateurs locaux sur les appareils joints pris en charge. Pour un compte de récupération géré par LAPS, vérifiez la gestion du mot de passe et sa récupération autorisée séparément de l'appartenance du compte et de la voie de connexion utilisable. La seule présence d'une stratégie LAPS ne termine pas le test de récupération.

Étape 3 — Préparer la stratégie et les critères du pilote

Sauvegardez la GPO existante et conservez les observations antérieures des membres. Préparez la liste approuvée dans l'éditeur de stratégie, examinez le modèle obtenu et définissez les liens et filtres exacts du pilote. Convenez des responsabilités de retour arrière et d'une procédure de restauration des membres, pas uniquement de la configuration de la GPO.

Ne supposez pas que supprimer un lien de GPO recréera tous les membres supprimés lors de son application. Exigez une procédure de récupération testée qui rétablit les accès nécessaires et traite le mécanisme faisant autorité sur les membres. Suspendez le déploiement si la collecte, les responsabilités, la résolution des noms ou le périmètre restent incertains.

Étape 4 — Valider après application

Déployez sur la population pilote selon le processus de changement approuvé. Une fois la stratégie traitée, répétez les commandes de consultation des membres et gpresult ci-dessus. Comparez les SID avant et après avec la liste approuvée et le comportement documenté du compte intégré. Examinez les ajouts et les suppressions pendant la fenêtre prévue.

Demandez aux responsables des applications et du support de tester leurs tâches administratives réelles, leurs travaux de maintenance et leurs accès de récupération. Répétez les observations après les traitements de stratégie ou activités de gestion des appareils ultérieurs pour révéler les mécanismes concurrents. Un appareil inaccessible ou un test applicatif en échec reste un critère de déploiement non satisfait.

Étape 5 — Étendre uniquement à partir de preuves consignées

Progressez par rôle d'appareil ou population administrative après acceptation des résultats par le responsable du pilote. Conservez explicitement les exceptions, plutôt que de les masquer dans un groupe plus large. Planifiez des revues ultérieures des membres et des alertes en cas d'écart par rapport à l'état approuvé. Gardez les appareils exclus et non observés visibles dans le rapport.

Comment EtcSec détecte cette configuration

Le contrôle M29_LOCAL_ADMIN_NOT_RESTRICTED d'EtcSec est un signal de revue de configuration. Le code source d'etc-collector a été lu au commit 15fc6399c215eabc415c370b762303cfcd7a353a, notamment m29_local_admin.go:38, gptmpl_parser.go:367 et les lignes client.go:154 et :214 du module SMB.

Les branches réelles de Detect() sont les suivantes :

Count 1 est le signal de ce détecteur, pas un nombre d'ordinateurs concernés. La comparaison n'accepte pas d'autres noms localisés. Elle n'évalue ni MembersSIDs, ni MemberOfSIDs, ni la population autorisée approuvée, ni les liens ou l'applicabilité des GPO, ni les membres réels des machines.

Le parseur agrège Members et Memberof dans une seule spécification par principal et crée cette spécification avant de vérifier le suffixe. Une valeur Members vide et une propriété Members absente sont indiscernables dans le tableau de membres obtenu. Une spécification correspondante contenant uniquement Memberof peut donc supprimer le constat sans établir une configuration de référence de remplacement par Members.

Le fournisseur SMB renseigne les valeurs de stratégie lorsque la lecture de GptTmpl.inf réussit. Il insère tout de même un objet de stratégie si cette lecture échoue. Pour ce contrôle, un échec de lecture peut ressembler à une configuration absente ; le constat ne présente pas de distinction dédiée à la réussite de la collecte. Une entrée correspondante dans une GPO hors du périmètre effectif d'un ordinateur peut également supprimer le signal.

La décision de déploiement doit identifier la stratégie exacte, les populations approuvées, les observations du pilote, le test de récupération et les appareils non résolus. Le silence du détecteur ne suffit pas, à lui seul, à clôturer cette décision.