GPP / GPO : groupe qui réapparaît dans « Administrateurs » après gpupdate & ILT introuvable — diagnostic et correctifs Windows Server

Un groupe réapparaît sans cesse dans Administrateurs après gpupdate ? Ou la boîte de dialogue d’Item‑Level Targeting refuse de parcourir vos groupes ? Voici un guide opérationnel et exhaustif pour diagnostiquer et corriger ces comportements liés aux Group Policy Preferences (GPP).

Sommaire

Le groupe de sécurité réapparaît dans Administrateurs locaux après gpupdate

Problème

Un GPO de préférences « Local Users & Groups » configuré en action Update ajoute un groupe global au groupe Administrateurs. Après :

avoir retiré le serveur du groupe utilisé pour l’Item‑Level Targeting (ILT) ;
avoir supprimé manuellement le groupe des Administrateurs locaux ;

le groupe est recréé à chaque traitement de stratégie (gpupdate ou cycle périodique).

Explications essentielles

Point clé	Pourquoi cela se produit
Action « Update »	Ce mode met à jour ou recrée l’élément à chaque cycle tant que le GPO s’applique. La suppression manuelle locale est ignorée : au prochain traitement, la CSE compare le XML GPP à l’état local et remet en conformité.
Le GPO s’applique toujours	Le serveur continue de recevoir le GPO via la liaison d’OU, le filtrage de sécurité, un groupe de sécurité commun, un filtre WMI, ou une autre condition ILT toujours vraie.
CSE « Local Users & Groups »	L’extension cliente lit le XML dans SYSVOL et synchronise la configuration locale à chaque traitement (90 min ± 30 min côté poste, ou sur demande via `gpupdate` / `gpupdate /force`).

Comment cela fonctionne en coulisses

Fichier de définition : la CSE lit \\<domaine>\SYSVOL\<domaine>\Policies\{GUID}\Machine\Preferences\Groups\Groups.xml (ou côté utilisateur User\Preferences\Groups\Groups.xml) pour connaître les membres cibles du groupe Administrators.
Comparaison d’état : pour une action Update, l’agent ajoute/maintient le membre requis. Pour Replace, il supprime d’abord l’existant puis recrée l’entrée telle que décrite.
Résultat : tant que le GPO est applicable, toute suppression locale manuelle est annulée au cycle suivant.

Résolution pas‑à‑pas

Vérifier l’applicabilité effective
Exécutez : gpresult /h C:\gp.html puis ouvrez le rapport pour identifier précisément quel GPO cible encore le serveur, et quelles conditions (filtrage de sécurité, ILT, WMI) sont évaluées à Vrai. À défaut, utilisez rsop.msc ou : Get-GPResultantSetOfPolicy -ReportType Html -Path C:\rsop.html Astuce : vérifiez également la provenance via « Liens » : un même GPO peut être lié à plusieurs OU ou au domaine, avec héritage non bloqué.
Corriger le ciblage
- Retirez le serveur de tous les groupes AD utilisés par l’ILT et par le filtrage de sécurité du GPO (onglet « Délégation »).
- Révisez les filtres WMI associés au GPO ; un filtre trop large (select * from Win32_OperatingSystem) peut maintenir l’applicabilité.
- Confirmez que le serveur n’est pas dans une OU héritant du lien GPO (contrôlez le « Blocage de l’héritage », « Appliquer » et les précédences).
Adapter l’action GPP Action Comportement Quand l’utiliser Remarques Create Crée si absent, n’altère pas si présent. Déploiement initial sans rigidité. Ne corrige pas les dérives. Update Met à jour/recrée tant que le GPO s’applique. Maintien continu de la conformité. Ignore les suppressions locales manuelles. Replace Supprime puis recrée systématiquement. Standardisation stricte et prévisible. Peut supprimer des membres ajoutés localement. Delete Supprime l’élément ciblé. Phase de retrait / désactivation. Associer à une condition ILT « contraire ». Modèles de correction :
- Remplacer Update par Replace pour nettoyer les états locaux hétérogènes, OU
- Ajouter un second élément « Delete » déclenché par une ILT opposée (ex. appartenance au groupe « Retired », OU « Hors‑prod », balise de registre), afin d’ôter proprement le membre avant d’arrêter l’application.
Option radicale : délier le GPO de l’OU du serveur (ou enlever l’autorisation « Appliquer la stratégie de groupe » via la délégation) si l’objet ne doit plus s’appliquer nulle part à ce serveur.
Contrôler et tracer
- Ouvrez l’Observateur d’événements → Applications et services → Microsoft → Windows → GroupPolicy → Operational.
- Filtrez sur l’ID 4096 (début du traitement GPP pour l’extension concernée) et 4098 (détail d’application de l’élément). L’absence ultérieure d’événements pour l’élément « Group » confirme sa non‑application.
- Sur le serveur, vérifiez l’appartenance locale : net localgroup administrators Get-LocalGroupMember -Group "Administrators"

Cas fréquents qui prolongent l’applicabilité

Filtrage de sécurité oublié : le serveur est encore membre de « Authenticated Users » avec « Appliquer » actif. Restreignez explicitement ou remplacez par un groupe dédié.
Lien multiples : le même GPO est lié au domaine et à une OU sœur ; l’héritage maintient l’application.
ILT combinées : une condition « OU » (ex. Ordinateur membre de Groupe A OU Version OS ≥ 10) reste vraie même après retrait de Groupe A. Inspectez la logique.
Latence AD/DFS : la suppression du membre ou la modification du GPO n’a pas encore convergé sur tous les DC. Forcer la réplication peut accélérer le test, mais n’en faites pas un palliatif.

Bonne pratique : stratégie de retrait contrôlée

Au lieu de « couper » brutalement un GPO, préférez un scénario en deux temps :

Déployer un élément Delete avec une ILT ciblant une balise (clé de registre, groupe « Retired », OU de quarantaine), qui retire le membre avant l’arrêt du GPO.
Après vérification (gpresult, journaux 4096/4098, audit du groupe local), supprimer/délier le GPO.

Exemple d’ILT « opposée » (registre)

Créez une clé témoin sur les machines à retirer :

HKLM\SOFTWARE\Company\GPP\Retired = 1 (REG_DWORD)

Dans l’élément Delete, ajoutez une ILT Registry Match « Valeur = 1 ». Seules les machines « Retired » appliqueront la suppression.

Audit et artefacts utiles

Historique local (Windows Server 2022 / Windows 10 21H2+) : C:\ProgramData\Microsoft\Group Policy\History\{GUID} stocke le XML et l’état appliqué pour faciliter la forensique.
Cache GPP : %windir%\System32\GroupPolicy\{Machine|User}\Preferences. Pour un test propre, videz le cache puis exécutez : gpupdate /force
Commande de contrôle rapide : whoami /groups | findstr /i "Domain Admins Administrators"

Alternative de conception

Restricted Groups (ou « Group Membership » via GPP) pour un contrôle strict des membres d’Administrators.
LAPS (Local Administrator Password Solution) : réduit le besoin d’ajouter des groupes étendus aux Administrateurs locaux en fournissant un compte admin local unique et géré.

Impossible de sélectionner un groupe d’utilisateurs dans l’ILT d’une préférence « Mise à jour de fichier » (Configuration Utilisateur)

Diagnostic rapide

Cause probable	Correctif proposé
Console GPMC ouverte avec un compte sans droits de lecture sur l’objet Groupe	Lancer l’Éditeur GPO depuis un poste/compte disposant au moins de l’autorisation Read sur le groupe (ACL AD) ou effectuer un Run as different user avec un compte d’administration de stratégie.
Conflit 32 / 64 bits de la MMC	Utiliser la console correspondant à l’architecture de l’OS (MMC 64 bits sur OS 64 bits) ou travailler depuis un contrôleur de domaine à jour.
Extension ILT manquante ou corrompue	Réinstaller la fonctionnalité « Group Policy Management » (RSAT) ou réparer les composants GPMC (ex. gptext.dll, bibliothèques ILT).
Correctif de sécurité limitant la navigation LDAP (durcissements post‑vulnérabilités)	Assurer un niveau de correctifs cumulatif récent côté poste d’admin et DC. Mettre à jour le client d’administration si des restrictions de canal LDAP/SMB ont été renforcées.

Astuce : même si le bouton Parcourir est inopérant, saisissez directement DOMAINE\NomDuGroupe dans le champ de l’ILT. La console valide la chaîne à l’enregistrement et elle s’appliquera correctement côté client.

Pourquoi cela arrive

Parcours LDAP : le bouton Browse effectue une recherche LDAP à partir du contexte du compte qui exécute la console. Sans Read sur l’objet cible, la liste revient vide ou la fenêtre ne s’ouvre pas.
Interop MMC/RSAT : des décalages de versions entre RSAT et les DC (schéma, bibliothèques) peuvent casser certaines boîtes de dialogue ILT, notamment sur des systèmes non à jour.
Durcissements : les renforcements de signatures, de canaux LDAP/SMB et la désactivation de protocoles plus anciens dans l’environnement peuvent empêcher l’énumération graphique, alors que la chaîne DOMAINE\Groupe reste valide.

Procédure de réparation recommandée

Vérifier les droits AD
- Dans « Utilisateurs et ordinateurs AD », ouvrez l’onglet « Sécurité avancée » du groupe ciblé et confirmez la présence de Read (ou List contents) pour le compte/équipe d’édition GPO.
- Évitez les Deny hérités qui bloquent le parcours sans l’apparenter à une erreur évidente.
Standardiser l’environnement d’édition
- Utilisez une station d’admin dédiée, à jour, avec RSAT/GPMC installés et correspondants à votre version de Windows Server.
- Privilégiez la MMC 64 bits pour des forêts modernes, et évitez d’éditer depuis des OS obsolètes.
Réparer les composants GPMC
- Réinstallez la fonctionnalité Gestion des stratégies de groupe (RSAT).
- Si la console a été personnalisée, supprimez le fichier .msc local et regénérez‑le.
Valider par saisie directe
- Renseignez DOMAINE\NomDuGroupe. La validation se fera à l’enregistrement ; côté client, l’ILT vérifie l’appartenance via SID, indépendamment de l’énumération graphique.

Éléments à contrôler pour l’ILT « Mise à jour de fichier »

Contexte Utilisateur vs Machine : une préférence de configuration Utilisateur n’évalue pas les groupes ordinateurs. Vérifiez que vous ciblez les groupes utilisateurs appropriés.
Chaînes étendues : préférez le NomNetBIOS\Groupe ou UPN/nom canonique selon la convention d’affectation. En présence de trusts, utilisez des groupes globaux ou universels avec résolutions SID stables.
Filtres cumulés : rappelez‑vous que l’ILT combine par défaut ses conditions en logique ET. Une seule condition fausse invalide l’application.

Exemple d’ILT pratique

Préférence : User Configuration > Preferences > Windows Settings > Files
Action : Update
Cible : Copier \\fileserver\partage\readme.txt -> %USERPROFILE%\Desktop

Item‑Level Targeting :

* Security Group is “DOMAINE\Equipe‑Support” (User in group) = True
* OU de l’utilisateur “OU=Support,DC=contoso,DC=com” = True

Check‑list de débogage express

Vérification	Commande/Action	Critère de réussite
Le GPO est‑il appliqué à l’utilisateur ?	`gpresult /h C:\gp-user.html`	Le GPO apparaît sous User Details > Applied GPOs.
La condition ILT « Groupe » est‑elle vraie ?	`whoami /groups` ou `gpresult` (section ILT si détaillée)	Présence du SID/nom du groupe cible.
La console peut‑elle résoudre le groupe ?	Saisie directe `DOMAINE\Groupe` dans l’ILT	Enregistrement sans erreur et application côté client.
Les journaux GPP confirment l’item	Événements 4096/4098 (GroupPolicy/Operational)	Message d’application réussie (ou code d’erreur exploitable).

Informations complémentaires utiles

Les préférences GPP côté Machine et Utilisateur sont retraitées automatiquement toutes les 90 minutes ± 30 min.
Pour des tests immédiats, supprimez le cache GPP dans %windir%\System32\GroupPolicy\{Machine|User}\Preferences puis exécutez gpupdate /force.
Depuis Windows Server 2022 / Windows 10 21H2, le XML effectivement appliqué est archivé dans C:\ProgramData\Microsoft\Group Policy\History\<GUID>, facilitant l’audit et le dépannage.

Foire aux questions ciblée

Supprimer localement suffit‑il ?

Non, si l’action GPP reste Update et que le GPO s’applique, l’agent recréera la relation. Il faut retirer l’applicabilité ou modifier l’action.

Dois‑je préférer « Replace » à « Update » ?

Replace offre une mise en conformité plus déterministe (nettoyage puis création) au prix de la perte de modifications locales. En production, associez‑le à des rapports (gpresult, journaux) et à une fenêtre de maintenance.

Comment retirer en toute sécurité des droits Admin locaux déployés par GPP ?

Déployez d’abord un élément Delete conditionnel (ILT inversée), vérifiez l’efficacité, puis retirez le GPO. Cette approche évite de laisser des membres orphelins dans Administrators.

Pourquoi la sélection de groupe ILT échoue en « User Configuration » alors qu’elle fonctionne côté Machine ?

Les boîtes de dialogue reposent sur des parcours et bibliothèques légèrement différents. La saisie directe DOMAINE\Groupe contourne la limitation, tant que le compte d’édition possède les droits de lecture requis.

Exemples concrets à adapter

Retrait contrôlé d’un groupe Admin local via ILT « Retired »

GPP 1 (Delete)
  Targeting: Registry HKLM\SOFTWARE\Company\GPP\Retired == 1
  Action: Delete "DOMAINE\Groupe‑Admins‑Locaux" from Administrators

GPP 2 (Update)
Targeting: NOT (Registry HKLM...\Retired == 1)
Action: Update (maintien provisoire)

Étapes :

1. Poussez la clé Registre (SCCM/Intune/GPO reg prefs) sur les serveurs à retirer
2. Attendez confirmation (logs 4098, gpresult)
3. Supprimez/déliez le GPO

Exemple de filtre WMI trop large à corriger

Avant	Après	Objectif
`select * from Win32_OperatingSystem where Version like "10.%" and ProductType = 3`	`select * from Win32_ComputerSystem where Domain = "contoso.local" and Name = "SRV‑APP‑01"`	Limiter l’application au serveur ciblé uniquement pendant la phase de retrait.

Modèle de procédure de correction (copiable)

Exécuter gpresult et/ou RSOP ; archiver le rapport.
Identifier les liens GPO et la délégation (Authenticated Users vs groupe dédié).
Revue des ILT : logique ET/OU, groupes, WMI, OU, Registre.
Basculer l’action Update → Replace ou ajouter un Delete conditionnel.
Déployer la clé/regroupement « Retired » pour les cibles à nettoyer.
Vider le cache GPP local, lancer gpupdate /force.
Auditer journaux 4096/4098, vérifier groupe local.
Supprimer/délier le GPO à la fin de la fenêtre de changement.

Pièges et subtilités

Groupes imbriqués : si vous ajoutez un groupe A dans Administrators et qu’un autre GPO ajoute B (A ⊂ B), retirer A seul peut être insuffisant.
Renommage de groupe : la CSE travaille sur le SID. Un renommage AD est transparent, mais l’ILT basée sur le nom peut nécessiter une mise à jour.
Conflit de GPO : deux GPP contradictoires (Update vs Delete) s’appliquant à la même machine donnent un résultat dépendant d’ordre ; standardisez la priorité ou fusionnez la logique.
Serveurs multirôles : évitez des ILT « OU » trop permissives lors de déploiements transverses (RDS, SQL, File). Préférez des groupes AD spécifiques par rôle.

Résumé opérationnel

Si un membre réapparaît dans Administrators après gpupdate, c’est quasi toujours parce que le GPO s’applique encore et que l’action Update restaure l’état défini. La solution passe par : constater l’applicabilité (gpresult), corriger le ciblage (ILT/liaison/délégation), puis adapter l’action (Replace ou Delete conditionnel). Pour l’ILT « Mise à jour de fichier », si la sélection de groupe échoue, vérifiez les droits de lecture AD, la cohérence RSAT/MMC, et n’hésitez pas à saisir directement DOMAINE\Groupe.

GPP / GPO : groupe qui réapparaît dans « Administrateurs » après gpupdate & ILT introuvable — diagnostic et correctifs Windows Server