Les erreurs classiques a eviter¶

Vous avez maintenant les bases solides pour administrer des GPO. Vous savez creer, lier, filtrer, diagnostiquer. Douze chapitres de technique pure.

Mais il existe un piege que personne ne vous dit : la plupart des catastrophes en production ne viennent pas d'un manque de connaissance technique. Elles viennent d'habitudes qui semblent raisonnables au debut, mais qui deviennent des bombes a retardement.

L'administrateur qui supprime accidentellement une GPO de securite sur 500 machines n'est pas incompetent. Il connait GPMC. Il sait ce qu'est une GPO. Il a simplement confondu deux operations qui se ressemblent visuellement. Une seconde d'inattention, une mauvaise lecture d'un menu contextuel.

L'administrateur qui surcharge la Default Domain Policy n'est pas paresseux. Il applique la logique qui dit "cette GPO s'applique a tout le monde, c'est exactement ce dont j'ai besoin". La logique est correcte. La pratique est dangereuse.

Ce chapitre est une liste de ces habitudes. Dix erreurs. Dix moments ou un administrateur bien intentionne fait quelque chose qui lui reviendra hanter a 3h du matin.

Lisez-le comme un recueil d'histoires vecues. Parce que ce sont exactement ca.

Comment utiliser ce chapitre¶

Vous pouvez le lire d'une traite, comme un roman. Ou vous pouvez le parcourir en diagonale, en ne lisant que les blocs !!! danger et !!! tip de chaque section.

Si vous administrez deja un domaine existant, utilisez ce chapitre comme une checklist d'audit. Parcourez votre GPMC en lisant chaque erreur, et demandez-vous : "Est-ce que ca me ressemble ?"

Vous serez surpris de ce que vous trouverez.

Erreur n°1 : Modifier la Default Domain Policy pour tout¶

Ce que font beaucoup d'administrateurs debutants¶

Ils ouvrent la GPMC, voient la Default Domain Policy tout en haut de la liste, et se disent : "C'est parfait, elle s'applique a tout le monde, je vais mettre mes parametres la."

Alors ils y ajoutent le fond d'ecran de l'entreprise. Le parametrage du proxy. La configuration de Windows Update. Les restrictions USB. Et tant qu'on y est, le message de bienvenue a l'ouverture de session.

Le domaine fonctionne. Tout semble bien.

Pourquoi c'est une bombe a retardement¶

La Default Domain Policy a un role tres precis et tres limite : contenir les parametres de securite qui s'appliquent a l'ensemble du domaine.

Default Domain Policy — contenu LEGITIME :
  └── Strategies de comptes (mot de passe, verrouillage)
  └── Strategie Kerberos

C'est tout. Rien d'autre ne devrait s'y trouver.

Le probleme avec tout le reste, c'est qu'on ne peut pas exclure des objets d'une GPO liee a la racine du domaine sans filtrage de securite. Vous voulez un fond d'ecran different pour les serveurs ? Impossible si c'est dans la Default Domain Policy — elle s'applique a tout le monde.

Pire : si vous cassez cette GPO — une faute de frappe, un parametre incompatible — vous cassez l'authentification de tout le domaine. Plus personne ne peut ouvrir une session. Serveurs, postes de travail, tout.

L'analogie de la Constitution¶

La Default Domain Policy, c'est comme la Constitution d'un pays. Elle pose les regles fondamentales qui s'appliquent a tous les citoyens, sans exception. On n'y inscrit pas les horaires d'ouverture des mairies locales ou le reglement interieur d'une ecole. Ces regles vont dans des textes moins fondamentaux, modifiables plus facilement, et applicables a une population precise.

Ne mettez pas vos "ordonnances locales" dans la Constitution.

Comment verifier l'etat de votre Default Domain Policy¶

Ouvrez GPMC, clic droit sur "Default Domain Policy" > Modifier. Naviguez dans l'arborescence et cherchez tout ce qui n'est pas sous Configuration ordinateur > Parametres Windows > Parametres de securite > Strategies de comptes.

Si vous voyez des parametres dans "Modeles d'administration", des preferences, ou d'autres branches de securite que les strategies de comptes — c'est a nettoyer.

Erreur n°2 : Creer une GPO par parametre¶

Comment ca commence¶

Un administrateur cree "GPO-Wallpaper" pour le fond d'ecran. Puis "GPO-Screensaver" pour l'ecran de veille. "GPO-Proxy" pour le proxy. "GPO-WindowsUpdate" pour les mises a jour. "GPO-USB-Block" pour bloquer les USB. "GPO-IE-Settings" pour Internet Explorer.

Chaque GPO fait une chose, une seule chose. Ca semble propre et organise.

Pourquoi c'est un desastre a long terme¶

Windows applique les GPO une par une, dans un ordre precis. Chaque GPO a un cout : elle doit etre telechargee depuis le controleur de domaine, parsee, et appliquee.

Avec 5 GPOs, c'est negligeable. Avec 200 GPOs, le demarrage d'un poste peut prendre plusieurs minutes supplementaires. Les utilisateurs se plaignent. Les serveurs souffrent.

Mais le vrai probleme, c'est la lisibilite. Au bout de six mois, vous avez :

• GPO-Config-V2
• GPO-Config-V2-Final
• GPO-Config-V2-Final-VRAIMENT-FINAL
• GPO-Config-Test-Ne-Pas-Supprimer
• GPO-237 (personne ne sait ce que c'est)

Aucun administrateur ne peut maintenir ca serieusement.

L'impact mesurable sur les performances¶

Windows mesure le temps de traitement de chaque GPO pendant le demarrage (mode foreground) et au rafraichissement en arriere-plan. Vous pouvez le consulter dans l'observateur d'evenements, sous Applications et services > Microsoft > Windows > GroupPolicy.

Avec 200 GPOs, les evenements de demarrage montrent souvent des temps de traitement de 2 a 5 minutes. Sur des machines avec des profils itinerants, ca peut atteindre 10 minutes. Les utilisateurs s'en souviennent — et ils en parlent.

Une infrastructure bien concue avec une vingtaine de GPOs bien organisees arrive en dessous de 30 secondes de traitement.

L'analogie du classeur¶

Imaginez un classeur de bureau avec 200 pochettes transparentes, une par facture. Personne ne retrouve rien. Le bon classeur a des intercalaires par categorie : Fournisseurs, Clients, Contrats, Banque. Chaque intercalaire contient plusieurs documents du meme type.

Les GPO, c'est pareil. Groupez par fonction et par audience.

Erreur n°3 : Oublier le filtrage de securite¶

Le scenario classique¶

Un administrateur cree une GPO pour configurer le bureau des utilisateurs du service comptabilite. Il la lie... a la racine du domaine, parce que "c'est plus simple". Il ne configure pas de filtrage de securite.

Le lendemain matin, les controleurs de domaine ont un fond d'ecran avec le logo de la comptabilite, des restrictions logicielles qui empechent l'execution de certains outils d'administration, et un message de connexion destine aux comptables.

Ce n'est pas dramatique ici. Mais remplacez "fond d'ecran" par "desactiver le bureau a distance" ou "bloquer certains ports reseau", et ca devient catastrophique.

Ou pire encore : une GPO de parametres de securite qui definit des droits utilisateur et qui s'applique aux controleurs de domaine avec des valeurs incompatibles. Dans ce cas, les DCs peuvent refuser les connexions des administrateurs. Vous vous retrouvez a essayer de reprendre la main sur votre propre infrastructure.

Pourquoi ca arrive¶

Quand vous creez une GPO et que vous l'appliquez a une OU, le filtrage de securite par defaut est :

Authenticated Users — Lire + Appliquer la strategie de groupe

Cela signifie que tout compte authentifie — utilisateur, ordinateur, compte de service — dans la portee de la GPO est soumis a cette GPO.

La question a toujours se poser¶

Avant de lier une GPO, posez-vous systematiquement cette question :

"A qui cette GPO doit-elle s'appliquer, et a qui ne doit-elle PAS s'appliquer ?"

Si la reponse inclut "pas aux serveurs" ou "pas aux DC", configurez le filtrage avant de lier.

L'exception : les GPOs de configuration utilisateur¶

Attention : pour les GPOs de configuration utilisateur, le filtrage s'applique sur les comptes utilisateur, pas sur les comptes ordinateur. Si vous creez une GPO qui configure le bureau d'un utilisateur, le filtrage doit inclure les comptes utilisateur des personnes concernees — pas les comptes machine.

Les deux filtres (utilisateur ET ordinateur dans la meme GPO) fonctionnent independamment. Une GPO avec des parametres ordinateur ET des parametres utilisateur peut necessiter deux groupes de filtrage differents. C'est l'une des raisons pour lesquelles il vaut mieux separer les GPOs "postes" des GPOs "utilisateurs".

Erreur n°4 : Confondre supprimer le lien et supprimer la GPO¶

Comprendre la structure : GPO vs Lien¶

Une GPO est un objet unique stocke dans Active Directory (dans le dossier SYSVOL et dans la partition de configuration). Elle peut etre liee a plusieurs OUs, plusieurs sites, ou plusieurs domaines.

Voici ce que ca donne en pratique :

flowchart TD
    GPO["GPO : CFG-Securite-Postes\n(un seul objet AD)"]

    GPO -->|"Lien 1"| OU1["OU : Paris"]
    GPO -->|"Lien 2"| OU2["OU : Lyon"]
    GPO -->|"Lien 3"| OU3["OU : Bordeaux"]

    OU1 --> PC1["200 postes\nParis"]
    OU2 --> PC2["150 postes\nLyon"]
    OU3 --> PC3["100 postes\nBordeaux"]

Supprimer le lien sur "Paris" : les 200 postes de Paris ne recoivent plus cette GPO. Les 250 postes de Lyon et Bordeaux continuent normalement. L'objet GPO existe toujours dans AD.

Supprimer la GPO : l'objet AD est detruit. Les trois liens disparaissent. Les 450 postes ne recoivent plus la GPO. Au prochain gpupdate, les parametres qu'elle definissait sont supprimes des machines.

L'histoire d'horreur¶

Un administrateur veut retirer une GPO de securite de l'OU "Lyon", parce que Lyon passe sous une autre politique. Il ouvre GPMC, fait un clic droit sur la GPO dans le panneau central... et au lieu de cliquer sur "Supprimer le lien", il clique sur "Supprimer".

Confirmation : "Voulez-vous supprimer cette GPO ?" Il clique Oui sans lire attentivement.

Resultat : 500 postes perdent leurs parametres de securite. Les comptes locaux ne sont plus verrouilles. Les audits sont desactives. Le pare-feu est reconfigure aux valeurs par defaut.

Il faudra plusieurs heures pour restaurer la GPO depuis la sauvegarde — en esperant qu'elle existe et qu'elle est recente.

L'analogie du document partage¶

Imaginez un document Word partage en reseau, dans trois dossiers differents — pas une copie, mais le meme fichier avec trois raccourcis qui pointent vers lui. Si vous supprimez un raccourci du dossier "Marketing", le fichier existe toujours et les raccourcis de "Finance" et "Direction" fonctionnent encore. Mais si vous supprimez le fichier lui-meme, les trois raccourcis deviennent invalides.

Une GPO, c'est le fichier. Les liens, ce sont les raccourcis.

Comment distinguer les deux operations dans GPMC¶

Dans GPMC, quand vous faites un clic droit sur une GPO dans l'arborescence des OU (sous l'OU ou elle est liee), vous obtenez l'option "Supprimer le lien".

Quand vous faites un clic droit sur une GPO dans le conteneur "Objets de strategie de groupe", vous obtenez l'option "Supprimer" — qui supprime l'objet lui-meme.

Erreur n°5 : Ne pas tester en OU de test¶

La tentation du raccourci¶

Modifier une GPO existante et l'appliquer directement en production semble rapide. C'est souvent ce qu'on fait quand on est sous pression, quand le changement parait trivial, ou quand on est confiant dans sa connaissance du parametre.

C'est presque toujours a ce moment-la que les incidents se produisent.

Le cas du "simple" parametre reseau¶

Un administrateur doit changer l'adresse du serveur proxy de l'entreprise. Parametre simple, une ligne de configuration, il connait ca par coeur. Il modifie la GPO en production.

Ce qu'il ne savait pas : certaines machines dans la meme OU avaient un logiciel de supervision reseau qui utilisait le proxy pour ses communications. Ce logiciel n'avait pas de gestion d'erreur propre en cas de changement de proxy. La modification a provoquer des alertes erronees pendant deux jours avant que quelqu'un fasse le lien.

Un test sur une seule machine dans une OU de test aurait revele le probleme en 20 minutes.

L'analogie du medicament¶

Aucun medicament n'est mis sur le marche sans passer par des phases d'essais cliniques — meme quand les chercheurs sont convaincus que ca marche, meme quand c'est urgent. Pas parce qu'on doute de leur competence, mais parce que les systemes complexes ont des interactions imprevues.

Un domaine Active Directory avec 500 machines et 50 applications est un systeme complexe. Le "test clinique", c'est votre OU de test.

Ce que doit contenir une OU de test¶

Toute infrastructure GPO serieuse dispose d'au moins une OU de test. Cette OU contient :

• Un poste de travail de test representatif (meme OS, meme logiciels que la production)
• Un compte utilisateur de test (pas le compte admin, un compte utilisateur standard)
• Parfois un serveur de test si les GPO s'appliquent aussi aux serveurs

L'OU de test recoit les GPOs en premier, avant n'importe quelle OU de production.

Erreur n°6 : Ignorer l'heritage et les conflits¶

Rappel sur l'heritage GPO¶

Les GPOs s'appliquent dans un ordre precis, du niveau le plus haut au niveau le plus bas :

0. Locale (`gpedit.msc`)
1. Site
2. Domaine
3. OU parente
4. OU enfant
5. OU petite-enfant
...

En cas de conflit, la GPO la plus proche de l'objet gagne. Une GPO liee a l'OU "Comptabilite" ecrase une GPO liee au domaine si elles definissent le meme parametre.

L'erreur courante¶

Un administrateur veut configurer Windows Update pour l'OU "Serveurs". Il cree une GPO et la lie a l'OU Serveurs. Mais il ne sait pas qu'une autre GPO liee au domaine definit deja les memes parametres Windows Update, avec des valeurs differentes.

Les serveurs recoivent les deux GPOs. Laquelle gagne ? Celle de l'OU Serveurs, parce qu'elle est plus proche. Mais l'administrateur pensait que c'etait celle du domaine qui s'appliquait. Il depanne pendant une heure quelque chose qui "ne marche pas" alors que ca marche — juste pas comme il le croit.

Verifier avant et apres¶

La commande gpresult est votre meilleure amie pour comprendre ce qui s'applique reellement.

rem Generate an HTML report of applied GPOs and winning settings
gpresult /h "C:\temp\rapport-gpo.html" /f

rem Show a summary directly in the console
gpresult /r

Lisez le rapport avant de faire un changement pour comprendre l'etat actuel. Lisez-le apres pour verifier que votre changement a produit l'effet attendu.

Les conflits silencieux¶

Le cas le plus dangereux est celui ou un parametre semble s'appliquer correctement, mais une GPO plus haute dans la hierarchie le remplace silencieusement. L'administrateur modifie la GPO de son OU, ne voit aucun effet, et cherche un probleme technique alors que c'est simplement un conflit d'heritage.

L'onglet Parametres resultants dans GPMC¶

GPMC dispose d'une fonctionnalite tres utile : le Modeleur de strategie de groupe (Group Policy Modeling) et les Resultats de strategie de groupe. Ces deux outils simulent ou rapportent les GPOs effectivement appliquees a un objet, en tenant compte de tout l'heritage.

Dans GPMC, clic droit sur Resultats de strategie de groupe > Assistant. Choisissez un ordinateur et un utilisateur. Le rapport resultant vous montre exactement quelles GPOs s'appliquent, dans quel ordre, et pour chaque parametre en conflit, quelle GPO a "gagne".

C'est votre meilleur outil pour diagnostiquer les conflits d'heritage avant qu'ils deviennent des incidents.

Erreur n°7 : Activer trop de parametres d'audit¶

La tentation de l'audit total¶

Quand un administrateur decouvre les parametres d'audit, il est tente d'activer tout ce qu'il peut. "Audit des acces aux objets" sur tous les serveurs ? Active. "Audit des changements de strategie" ? Active. "Audit des evenements systeme" ? Active. "Audit des connexions" ? Active en mode succes et echec.

Dans un domaine de 500 machines, ca peut generer plusieurs millions d'evenements par jour.

Ce que ca provoque concretement¶

Le journal de securite de Windows a une taille maximale configurable. Quand il est plein, soit les nouveaux evenements ecrasent les anciens (et vous perdez l'historique), soit le systeme s'arrete (pour eviter de perdre des preuves — comportement configurable).

Dans le meilleur cas, votre SIEM (systeme de collecte de logs) est submerge et les equipes securite n'arrivent plus a distinguer les vraies alertes du bruit de fond.

Dans le pire cas, un evenement critique — une tentative d'intrusion, une escalade de privileges, une exfiltration de donnees — passe completement inapercu parce qu'il est noye dans 50 000 evenements d'acces aux fichiers.

L'analogie de l'alarme incendie¶

Imaginez un systeme d'alarme incendie qui se declenche chaque fois qu'une porte s'ouvre, chaque fois que quelqu'un marche dans le couloir, chaque fois qu'une fenetre bouge. Au bout de quelques jours, les employes eteignent l'alarme des qu'elle sonne — y compris le jour ou il y a un vrai incendie.

Un audit qui produit trop de bruit est pire qu'aucun audit.

Les parametres d'audit minimalistes et efficaces¶

Commencez avec uniquement ces deux categories :

Quand vous etes plus a l'aise et que vous avez verifie que ces deux categories ne surchargent pas vos journaux, vous pouvez envisager d'ajouter :

Ajoutez des categories supplementaires uniquement quand vous avez une raison precise — une exigence de conformite, une investigation en cours, ou une recommandation de votre equipe securite.

rem Show current audit configuration by subcategory
auditpol /get /category:*

Erreur n°8 : Utiliser les preferences pour des parametres de securite¶

Rappel sur la difference fondamentale¶

Vous avez vu ca en detail dans le chapitre 10. Voici l'essentiel :

Les strategies (Policies) ecrivent dans les branches protegees du registre (HKLM\SOFTWARE\Policies\...). Quand la GPO est supprimee, Windows supprime automatiquement ces valeurs.

Les preferences ecrivent n'importe ou dans le registre. Quand la GPO est supprimee, les valeurs restent. C'est le tatouage.

Pourquoi c'est particulierement dangereux pour la securite¶

Imaginons que vous deployez via une preference le parametre qui desactive l'ouverture automatique de session. Six mois plus tard, la GPO est reorganisee. Un administrateur supprime l'ancienne GPO de preferences. Le parametre d'ouverture de session reste configure sur les machines — mais personne ne sait pourquoi ni comment il a ete mis la.

Maintenant imaginez le cas inverse : vous activez via une preference un parametre de securite important. Mais vous liez la GPO a la mauvaise OU, ou a une OU temporaire. Quand vous supprimez le lien, vous pensez avoir retire la configuration. En realite, elle est tatouee sur toutes les machines qui ont recu la preference. Votre perimetre de securite est different de ce que vous croyez.

Comment detecter les preferences de securite deja en place¶

Si vous reprenez un domaine existant, comment savoir si des preferences ont ete utilisees pour des parametres de securite ?

La commande gpresult /h rapport.html vous montre les preferences appliquees, mais pas facilement ce qu'elles contiennent. La methode la plus fiable est d'ouvrir chaque GPO suspecte dans l'editeur et de naviguer dans Configuration ordinateur > Preferences et Configuration utilisateur > Preferences pour voir ce qui a ete configure.

Cherchez particulierement dans : Parametres Windows > Registre, Parametres Windows > Securite locale (si disponible), et Parametres du panneau de configuration.

La regle simple¶

Pour tout ce qui concerne la securite, utilisez des strategies (Policies), jamais des preferences.

Les preferences sont utiles pour : les lettres de lecteur reseau, les imprimantes, les raccourcis, les fichiers a deployer, les parametres de confort utilisateur. Pas pour la securite.

Erreur n°9 : Ne pas documenter ses GPO¶

Le cimetiere des GPOs orphelines¶

Apres quelques annees d'administration, un domaine accumule inevitablement des GPOs dont personne ne connait plus l'origine, la raison, ou la cible.

• GPO-Config-V2-Final-VRAIMENT-FINAL : version de quoi ? Finale depuis quand ?
• GPO-Test-Jean : qui est Jean ? Est-ce que ca s'applique encore a quelque chose ?
• GPO-237 : mystere complet.
• GPO-Temporaire-Migration : la migration est terminee depuis 2019, la GPO est toujours liee.

Ces GPOs creent trois problemes : elles allongent inutilement le temps de traitement, personne n'ose les supprimer de peur de casser quelque chose, et elles rendent les audits de securite cauchemar esques.

Identifier et nettoyer les GPOs orphelines¶

Une GPO orpheline est une GPO qui existe dans Active Directory mais qui n'est liee a aucune OU, aucun site, aucun domaine. Elle ne s'applique a rien — mais elle occupe de l'espace et ajoute du bruit.

Dans GPMC, le conteneur Objets de strategie de groupe liste toutes les GPOs du domaine. Pour chaque GPO, l'onglet Etendue vous montre ou elle est liee. Une GPO avec une liste de liens vide est orpheline.

Vous pouvez aussi utiliser PowerShell pour lister toutes les GPOs non liees :

# List all GPOs that have no links in any OU, site, or domain
Import-Module GroupPolicy
Get-GPO -All | Where-Object {
    # Get-GPOReport returns an XML; check if no SOM links exist
    ([xml](Get-GPOReport -Guid $_.Id -ReportType Xml)).GPO.LinksTo -eq $null
} | Select-Object DisplayName, CreationTime, ModificationTime

Ce script vous donne une liste de GPOs candidates au nettoyage. Verifiez chacune avant de supprimer — une GPO peut etre "en attente de lien" pour une raison valide.

L'analogie du code sans commentaires¶

Un programmeur qui ecrit du code sans commentaires est considere comme un mauvais collegue. Il impose a tous ceux qui liront son code apres lui de deviner ses intentions. La meme logique s'applique aux GPO.

Une GPO non documentee est de la dette technique.

Le probleme du "je m'en souviendrai"¶

Quand on cree une GPO, on est en contexte. On sait pourquoi on la cree, pour qui, dans quel cadre. Il semble evident qu'on s'en souviendra.

Trois mois plus tard, on a cree 15 autres GPOs, gere 30 tickets, fait evoluer l'infrastructure. Le contexte a disparu. La GPO de trois mois ressemble maintenant a toutes les autres GPOs mysterieuses du domaine.

Ce n'est pas une question de memoire. C'est une question de volume. Personne n'est capable de maintenir le contexte de toutes les decisions techniques d'un domaine Active Directory. La documentation est la memoire externe du systeme.

Les trois outils de documentation disponibles¶

1. Le champ Description dans GPMC

Chaque GPO a un champ "Description" que vous pouvez modifier. C'est le minimum. Mettez-y :

• L'objectif de la GPO (en une phrase)
• La population cible (exemple : "Postes utilisateurs standard hors serveurs")
• La date de creation et l'auteur
• Les changements majeurs (avec date)

2. La convention de nommage

Un bon nom de GPO repond a trois questions sans qu'on ait besoin d'ouvrir la GPO :

[Environnement]-[Population]-[Fonction]

Exemples :
  CFG-Postes-EnvironnementBureau
  SEC-Serveurs-AuditAvance
  CFG-DC-NTPConfiguration

3. Un changelog externe

Pour les domaines d'une certaine taille, maintenez un document externe (wiki, SharePoint, fichier Excel) avec une ligne par GPO : nom, description, date de creation, auteur, derniere modification, lien vers le ticket de changement.

Erreur n°10 : Oublier la replication AD¶

Ce qui se passe quand vous sauvegardez une GPO¶

Quand vous modifiez et sauvegardez une GPO dans GPMC, la modification est ecrite sur le PDC Emulator (le controleur de domaine primaire emule). C'est lui qui fait autorite pour les GPOs.

Mais vos autres controleurs de domaine ne recoivent pas la modification immediatement. La replication Active Directory entre DCs d'un meme site prend entre 15 secondes et 5 minutes dans des conditions normales. Entre des sites connectes par des liens lents, ca peut etre bien plus long — jusqu'a l'intervalle de replication configure, qui est souvent de 15 a 180 minutes.

Le scenario qui trompe¶

Vous modifiez une GPO pour corriger un probleme urgent. Vous allez immediatement sur un poste de test et lancez gpupdate /force. Ca ne fonctionne pas. Vous verifiez la GPO dans GPMC — elle est correcte. Vous refaites gpupdate /force. Toujours rien.

Vous commencez a douter de votre modification. Vous la refaites. Vous creez une deuxieme GPO. Vous redebutez tout. Vous passez 45 minutes a deboguer...

...alors que le probleme est simplement que le poste de test a contacte un DC qui n'a pas encore recu la replication.

Verifier l'etat de la replication¶

Avant de conclure qu'une GPO ne s'applique pas, verifiez l'etat de la replication :

rem Show replication status between all domain controllers
repadmin /showrepl

rem Force replication from all partners immediately
repadmin /syncall /AdeP

rem Show which DC a machine is currently using
nltest /dsgetdc:votre-domaine.com

La commande repadmin /showrepl affiche l'etat de la derniere replication entre chaque paire de DCs. Si une replication est en echec ou en retard, c'est votre piste.

Forcer la replication manuellement¶

Pour qu'une modification urgente se propage immediatement :

rem Force replication from all partners to all DCs
repadmin /syncall /AdeP

Attendez une minute, puis forcez l'application de la GPO sur le poste de test :

rem Force immediate group policy refresh
gpupdate /force

Comment savoir depuis quel DC une machine a obtenu sa GPO¶

Apres un gpupdate /force, lancez gpresult /r. Regardez la ligne qui indique le controleur de domaine utilise pour les GPOs ordinateur et utilisateur. Si c'est un DC secondaire qui n'a pas encore recu la replication, vos modifications ne sont pas encore visibles.

rem Show which DC provided group policies for the current session
gpresult /r | findstr /i "controleur\|controller\|DC"

Si le DC source n'a pas recu la replication, deux options : attendre, ou forcer le poste a utiliser un DC specifique :

rem Force the machine to use a specific DC for the next gpupdate
gpupdate /force /target:computer

(Cette commande ne force pas le choix du DC, mais vous pouvez utiliser nltest /server:NOM-DC pour des operations specifiques sur un DC precis.)

rem Check DFS-R replication status for SYSVOL
dfsrdiag replicationstate

Checklist d'audit rapide¶

Avant de passer au tableau final, voici une checklist que vous pouvez utiliser pour auditer votre propre domaine. Ouvrez GPMC et cochez chaque point.

Audit de la Default Domain Policy

• La DDP ne contient que des strategies de comptes et Kerberos
• Aucun parametre de Modeles d'administration dans la DDP
• Aucune preference dans la DDP

Audit des GPOs existantes

• Toutes les GPOs ont un nom qui respecte une convention lisible
• Toutes les GPOs ont un champ Description rempli
• Aucune GPO avec un nom "Final", "V2", "Test", "Temp" sans explication
• Les GPOs liees a la racine du domaine ont un filtrage de securite explicite

Audit du filtrage de securite

• Aucune GPO de postes n'est liee a une OU contenant des DCs sans filtrage
• Les GPOs de serveurs ne s'appliquent pas aux postes de travail

Audit technique

• Une OU de test existe avec un poste representatif
• La replication AD est saine (repadmin /showrepl ne montre pas d'erreurs)
• Les journaux de securite ont une taille configuree adequatement

Recapitulatif des dix erreurs¶

Ce tableau est votre aide-memoire. Imprimez-le, affichez-le, envoyez-le a vos collegues.

Et maintenant ?¶

Vous venez de parcourir les dix erreurs qui font la difference entre un administrateur GPO qui subit son infrastructure et un qui la maitrise.

Ces erreurs ne sont pas des anecdotes inventees. Elles sont le resume de milliers d'heures d'incidents de production, de nuits de depannage, et de sessions de post-mortem.

La bonne nouvelle : maintenant que vous les connaissez, vous pouvez les eviter. Et vous pouvez reconnaitre dans votre propre domaine celles qui sont peut-etre deja en train de se developper.

Dans le chapitre 14, on quitte les fondamentaux pour aborder les specificites de Windows 11 et des environnements modernes : le comportement des GPOs dans les domaines hybrides Azure AD, les nouveaux modeles ADMX pour Windows 11, et ce qui change quand vos machines sont comanagees par Intune.

Les GPOs que vous avez apprises dans ce livre continuent de fonctionner dans ces environnements modernes — mais avec quelques nuances importantes. Le chapitre 14 vous donnera les cles pour adapter vos pratiques.

Pour aller plus loin¶

Ce chapitre couvre les erreurs les plus frequentes, mais l'administration GPO est un domaine vaste. Voici quelques pistes pour continuer a progresser.

Les outils de diagnostic avances¶

Au-dela de gpresult et repadmin, deux outils meritent votre attention :

Group Policy Modeling (dans GPMC) simule l'application des GPOs pour un utilisateur ou un ordinateur avant de faire le moindre changement. C'est l'equivalent d'un "mode preview" pour votre configuration GPO. Vous pouvez tester "que se passerait-il si je deplacais cette machine dans cette OU ?" sans bouger quoi que ce soit.

Group Policy Results (dans GPMC) genere un rapport complet des GPOs effectivement appliquees a une machine ou un utilisateur, depuis le controleur de domaine. C'est plus complet que gpresult /r local, car il va chercher l'information directement dans AD.

Les journaux d'evenements GPO¶

Windows enregistre les evenements de traitement GPO dans l'observateur d'evenements, sous :

Journaux des applications et des services
  └── Microsoft
        └── Windows
              └── GroupPolicy
                    └── Operational

Ce journal contient un evenement pour chaque cycle de traitement GPO. Si une GPO echoue a s'appliquer, la raison est consignee ici avec un code d'erreur et un message explicatif. C'est votre premier reflexe quand gpresult ne suffit pas.

rem Open the Group Policy Operational log in Event Viewer
wevtutil qe Microsoft-Windows-GroupPolicy/Operational /f:text /c:20 /rd:true

La documentation Microsoft officielle¶

La reference officielle des parametres GPO est disponible via les fichiers ADMX et leur documentation associee. Pour chaque parametre, la description dans l'editeur GPO explique son comportement, les valeurs possibles, et les versions de Windows supportees.

Prenez l'habitude de lire cette documentation avant d'activer un parametre que vous ne connaissez pas. Un parametre mal compris vaut autant que dix erreurs de ce chapitre reunies.