Filtrage GPO MS16-072 : rétablir Read, préserver la portée

Qu’est-ce que le filtrage GPO MS16-072 ?

Le dépannage du filtrage GPO MS16-072 commence par deux questions distinctes : l’ordinateur peut-il récupérer la stratégie utilisateur, et l’utilisateur connecté est-il autorisé à l’appliquer ? Une stratégie destinée à un petit groupe d’utilisateurs peut cesser de fonctionner lorsque l’ordinateur perd l’autorisation Read. Rétablir une autorisation Apply étendue peut faire fonctionner la stratégie tout en modifiant son public prévu.

L’article de support MS16-072 de Microsoft décrit le changement introduit le 14 juin 2016 : Windows récupère les GPO utilisateur dans le contexte de sécurité de l’ordinateur plutôt que dans celui de l’utilisateur. La résolution consiste à accorder Read à Authenticated Users, ou à Domain Computers lorsque le filtrage de sécurité est utilisé. Le bulletin MS16-072 rattache la mise à jour à l’article 3163622 de la base de connaissances Microsoft ; les packages installables dépendent de la version de Windows. Il s’agit d’un changement établi du traitement, et non d’un problème nouvellement découvert.

L’objectif pratique est de rétablir la récupération tout en préservant les destinataires prévus. La même revue doit distinguer les stratégies qui ont leur place en production des paires AD/SYSVOL incomplètes, des stratégies désactivées avec des liens actifs, des objets inutilisés et des délégations discutables. Ces états exigent des décisions différentes ; faire appliquer toutes les stratégies n’est pas un objectif de remédiation utile.

Fonctionnement : Read, Apply et portée des liens

Les consignes actuelles de dépannage de Microsoft expliquent pourquoi retirer Authenticated Users de Security Filtering peut casser les stratégies utilisateur : cette action supprime à la fois Read et Apply Group Policy. Un groupe d’utilisateurs ciblé peut conserver ses autorisations alors que le compte ordinateur ne peut plus récupérer la GPO.

Read ajouté depuis l’onglet Delegation de GPMC diffère de l’entrée intitulée Read (from Security Filtering). Cette dernière inclut Apply ; Read seul rétablit la récupération sans accorder ce droit d’application. Conservez le groupe d’utilisateurs prévu dans Security Filtering et fournissez Read à la population d’ordinateurs appropriée via Delegation.

Le filtrage de sécurité s’exerce dans les emplacements atteints par les liens de la GPO. La référence sur le filtrage de sécurité de Microsoft explique que l’appartenance à un groupe ne suffit pas à faire entrer un utilisateur hors portée dans un site, domaine ou OU lié. Ajouter Apply étendu peut élargir les destinataires dans la portée des liens applicables ; cela n’applique pas automatiquement la GPO à tout le domaine. Cette page historique explique les mécanismes du filtrage et doit être lue avec les consignes actuelles sur Read pour les ordinateurs.

La documentation sur le traitement des stratégies de groupe de Microsoft décrit d’autres conditions : sections désactivées, filtres WMI et traitement en boucle. Merge ajoute la liste des stratégies utilisateur fondée sur l’ordinateur après celle de l’utilisateur ; Replace utilise la liste fondée sur l’ordinateur à sa place. Consignez le mode réel avant d’interpréter un résultat. Pour le bouclage Merge, l’article de support MS16-072 demande spécifiquement d’ajouter les utilisateurs et ordinateurs prévus sous Scope > Security Filtering. Validez séparément cette configuration ciblée ; la correction générale de Read pour les ordinateurs décrite ci-dessus ne constitue pas une procédure complète de bouclage.

Chaîne de défaillance et stratégies à examiner

Une séquence de défaillance courante est simple : un administrateur restreint une GPO utilisateur à un groupe métier, retire Authenticated Users, puis constate l’absence des paramètres utilisateur sur les ordinateurs concernés. Le groupe ciblé paraît toujours correct. La dépendance manquante est Read pour les ordinateurs. Réajouter Authenticated Users à Security Filtering peut masquer cette dépendance en rétablissant à la fois Read et Apply.

Microsoft décrit l’échec d’application de la stratégie utilisateur comme un symptôme ; son exemple de dépannage inclut une erreur dans le rapport de résultats. Ne supposez pas que cette défaillance est toujours silencieuse et ne considérez pas chaque paramètre manquant comme une preuve d’un problème d’autorisations MS16-072.

D’autres états de GPO méritent une décision séparée avant de les lier ou de les réactiver :

• Incohérence AD/SYSVOL : vérifiez l’objet d’annuaire et les fichiers correspondants, la réplication et les sauvegardes récupérables. Un constat d’orphelin ne justifie pas, à lui seul, la remise en service ou la suppression de la stratégie.
• Les deux sections sont désactivées, mais un lien est activé : établissez s’il s’agit d’une maintenance délibérée ou d’un lien obsolète. Ce constat ne signifie pas que des paramètres désactivés s’appliquent actuellement.
• Aucun lien inventorié : identifiez un brouillon, une stratégie de réserve ou un déploiement oublié. L’absence de lien est un signal d’inventaire, pas une preuve de compromission.
• Délégation discutable sur les stratégies et les liens : examinez les bénéficiaires et les objets concernés. Un constat d’autorisation ne prouve pas que quelqu’un a inséré un lien malveillant.

Pour la question distincte de savoir qui peut réécrire les paramètres, les mauvaises configurations GPO comme vecteur d’attaque expliquent l’exposition liée aux droits de modification des stratégies et aux configurations faibles. Pour une OU privilégiée, les ACL faibles des GPO sur le Tier 0 expliquent pourquoi bloquer l’héritage ne sécurise pas les autorisations de modification propres à la GPO liée. L’accès en lecture, l’accès de modification des stratégies et l’accès d’écriture des liens exigent chacun leurs propres preuves.

Détection : mesurer les autorisations et les résultats réels

Commencez par une GPO affectée, identifiée sans ambiguïté. L’exemple 3 de la référence Get-GPPermission de Microsoft fournit cette commande :

Get-GPPermission -Name "TestGPO" -All

Remplacez le nom de l’exemple par la stratégie réelle. La cmdlet indique les principaux disposant d’autorisations sur cette GPO ; elle ne simule pas entièrement le traitement des stratégies. Si les noms sont ambigus, utilisez le GUID de la GPO. Les requêtes individuelles suivantes adaptent les paramètres documentés :

Get-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "GPO-Users-Cible" -TargetType Group

Utilisez les noms résolus de votre domaine. Comparez Read pour les ordinateurs, l’autorisation Apply du groupe prévu et tout Apply étendu inattendu. Un résultat absent ou une erreur ne constitue pas un contrôle d’autorisation réussi. Examinez les autorisations personnalisées et les entrées Deny explicites plutôt que de déduire l’accès effectif d’un niveau résumé.

Pour le résultat du traitement, l’exemple de dépannage de Microsoft utilise :

gpresult /h gpresult.html

Exécutez un test utilisateur positif et un test négatif, puis examinez les rapports générés. Conservez l’ordinateur, l’utilisateur, l’identité de la GPO, les liens pertinents et toute erreur avec chaque résultat. La matrice de diagnostic ci-dessous aide à garder visibles les explications concurrentes :

Il s’agit de commandes documentées et d’une procédure de validation proposée. Aucun résultat de test AD ni aucune capture de journal d’événements n’est revendiqué ici.

Remédiation : rétablir Read sans élargir Apply (Remediation)

1. Consigner le public prévu et l’état actuel

Avant de modifier les autorisations, conservez l’état de la stratégie et établissez son propriétaire, les utilisateurs ciblés, les ordinateurs de connexion, la portée des liens et le mode de traitement. Déterminez la population d’ordinateurs qui a besoin de Read. Authenticated Users, Domain Computers ou un groupe d’ordinateurs adapté sont des choix à évaluer par rapport à cette population ; vérifiez séparément Deny explicite.

2. Accorder Read aux ordinateurs via Delegation

Dans GPMC, ouvrez l’onglet Delegation de la GPO affectée, sélectionnez Add, choisissez le groupe ou l’objet ordinateur, sélectionnez Read, puis confirmez. Conservez Apply sur le groupe d’utilisateurs prévu. La page de dépannage de Microsoft documente cette méthode et la distinction qui en résulte entre Read seul et Read issu de Security Filtering.

Pour un aperçu PowerShell, cet exemple utilise des paramètres de la documentation Set-GPPermission de Microsoft :

Set-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead -WhatIf

-WhatIf donne un aperçu de l’opération ; il n’applique pas le changement. Utilisez la GPO et le bénéficiaire réels, examinez l’aperçu et effectuez le changement approuvé sur cette seule stratégie selon la procédure choisie.

3. Corriger un octroi accidentel d’Apply étendu

Si Authenticated Users doit uniquement lire cette GPO ciblée, prévisualisez le remplacement de son niveau d’autorisation actuel :

Set-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace -WhatIf

La documentation indique qu’un niveau d’autorisation existant plus élevé reste inchangé sans -Replace. Demander simplement GpoRead peut donc laisser en place un octroi Apply existant. Le remplacement n’est approprié qu’après avoir confirmé que le principal doit perdre son autorisation supérieure sur cette GPO. Préservez l’autorisation Apply du groupe ciblé et l’état consigné pour le retour arrière.

4. Valider l’application et résoudre les constats d’inventaire

Répétez les mesures d’autorisations et les deux tests utilisateur. Vérifiez l’application attendue, l’exclusion des utilisateurs non ciblés et les conditions de traitement pertinentes. Pour les orphelins, validez les deux composants de stockage avant restauration ou retrait. Pour les stratégies désactivées mais liées, confirmez l’intention et supprimez les liens obsolètes si nécessaire ; ne réactivez pas automatiquement les paramètres. Examinez les octrois discutables avec leur propriétaire, y compris les droits d’écriture des liens indépendamment des autorisations du conteneur de stratégies.

Comment EtcSec détecte ces problèmes

Les descriptions suivantes reflètent sept implémentations Detect() examinées dans etc-collector au commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f. Elles décrivent des signaux de configuration, pas sept attaques prouvées ni un test exécuté sur cet environnement.

Contrôles du filtrage

GPO_AUTHENTICATED_USERS_APPLY sélectionne les GPO avec un lien activé et une entrée ACL Authenticated Users portant le bit Apply. L’adaptateur LDAP associe ce bit au droit étendu pertinent ; Microsoft documente Apply Group Policy comme le droit utilisé pour déterminer l’application. Le Detect() lui-même ne rejette pas les entrées Deny, ne calcule pas l’accès effectif, n’évalue pas WMI et ne vérifie pas les sections désactivées. Une stratégie de référence volontairement large peut légitimement produire un signal de revue.

GPO_NO_SECURITY_FILTERING recherche les GPO liées et activées avec Apply pour Everyone ou Authenticated Users, sans autre bénéficiaire Apply spécifique, en excluant Domain Computers de ce test de bénéficiaire spécifique. Un groupe spécifique n’annule pas un octroi Apply étendu : le détecteur peut donc manquer un élargissement lorsque les deux coexistent. Il ne calcule pas non plus l’accès effectif ni l’état des sections. Ces deux contrôles se recoupent et doivent être examinés comme une seule préoccupation de filtrage, plutôt que comptés comme des preuves indépendantes d’exposition.

Aucun des deux prédicats n’établit l’absence de Read pour les ordinateurs. Utilisez les mesures d’autorisations et les tests de traitement ci-dessus pour le diagnostic MS16-072.

Contrôles d’inventaire

GPO_ORPHANED consomme les constats SYSVOL fournis de type orphaned_ldap ou orphaned_sysvol. Si aucun constat d’orphelin correspondant n’est retourné, son repli LDAP signale un chemin de fichier vide ou un objet dont DisplayName et CN sont tous deux vides. Ce repli peut s’exécuter même lorsque d’autres constats SYSVOL ont été fournis. Un objet LDAP complet dont le dossier SYSVOL a disparu peut échapper à ce repli. Consignez si des preuves SYSVOL ont été fournies ; ce n’est pas un détecteur de gPLink référençant une GPO manquante.

GPO_DISABLED_BUT_LINKED exige Flags = 3, ce qui signifie que les deux sections sont désactivées, ainsi qu’un lien activé. Il identifie un état d’inventaire à expliquer, pas des paramètres désactivés actuellement appliqués.

GPO_UNLINKED trouve les GPO sans aucun lien inventorié, en incluant les liens désactivés dans l’ensemble des GPO liées, et exclut les deux GUID des GPO par défaut. Cela ne signifie pas la même chose qu’un lien désactivé, des sections désactivées ou un orphelin AD/SYSVOL. Examinez le cycle de vie et l’intention avant de lier ou de retirer l’objet.

Contrôles de délégation

GPO_MODIFY_RIGHTS vérifie l’appartenance directe ou résolue via le groupe principal à Group Policy Creator Owners, identifié par le RID 520. Il ne suit pas les appartenances imbriquées. La référence sur les identifiants de sécurité de Microsoft décrit la capacité de ce groupe à créer des GPO et la propriété des nouveaux objets par leur créateur. L’appartenance seule ne prouve ni des droits de modification sur toutes les GPO existantes ni l’autorisation de les lier. Examinez les membres et les stratégies et délégations qu’ils possèdent.

GPO_LINK_POISONING sélectionne les ACE d’octroi dont le DN d’objet contient CN=Policies,CN=System et dont le masque inclut GenericAll, GenericWrite ou WriteDACL. Le Detect() n’exclut pas lui-même les administrateurs, n’examine pas l’ACL de chaque GPO, n’établit pas l’accès en écriture au gPLink d’une OU et n’identifie pas un lien malveillant existant. Son Count représente des objets distincts ; TotalInstances peut inclure plusieurs ACE. Validez le bénéficiaire et la délégation, puis examinez séparément les autorisations des liens du site, domaine ou de l’OU concerné. La documentation sur la portée de Microsoft situe gPLink sur ces objets, et sa procédure de délégation gère les autorisations Link GPOs à cet endroit.