Comprendre l'heritage et l'ordre d'application¶

L'analogie des couches de vetements¶

Ce chapitre est probablement le plus important de tout le livre. Comprendre l'heritage, c'est comprendre pourquoi une GPO s'applique ou ne s'applique pas. Sans cette base, vous passerez des heures a vous demander pourquoi un parametre ne fonctionne pas, alors que la reponse est souvent simple.

Avant de plonger dans la theorie, on va utiliser une image que vous n'oublierez jamais.

Imaginez que vous vous habillez le matin en plein hiver.

• D'abord, vous enfilez un sous-vetement. C'est la base. Vous le portez toujours, quoi qu'il arrive.
• Par-dessus, vous mettez un t-shirt. Il recouvre le sous-vetement.
• :material-hoodie: Ensuite, un pull. Il recouvre le t-shirt.
• :material-jacket-outline: Enfin, un manteau. C'est la couche la plus exterieure, celle qu'on voit.

Maintenant, posez-vous cette question : quelle couleur voit-on de l'exterieur ?

Celle du manteau. Toujours. Meme si votre t-shirt est rouge et votre pull est vert, c'est la couleur du manteau qui "gagne" visuellement. La derniere couche posee l'emporte.

Les GPO fonctionnent exactement de la meme facon.

Quand deux couches definissent la meme chose (par exemple, la couleur du fond d'ecran), c'est la derniere couche appliquee qui gagne. Comme le manteau qui cache le pull.

Et si une couche ne dit rien sur un sujet ? Alors la couche precedente reste visible. Si votre manteau n'a pas de capuche, c'est celle du pull qui depasse.

L'ordre LSDOU¶

L'analogie des vetements, c'est bien. Mais maintenant, donnons les vrais noms. L'ordre d'application des GPO suit un acronyme simple : LSDOU.

• L = Local
• S = Site
• D = Domain (Domaine)
• OU = Organizational Unit (Unite d'organisation)

Chaque lettre represente un niveau ou Windows va chercher des GPO a appliquer. Il les traite dans cet ordre precis, et le dernier parametre lu ecrase les precedents.

L -- La strategie locale¶

C'est la GPO que vous editez avec gpedit.msc directement sur un poste. Elle est stockee sur le disque dur de la machine, pas dans Active Directory.

Elle s'applique toujours, meme si le poste n'est pas membre d'un domaine. C'est le sous-vetement : la base, la couche la plus faible.

En entreprise, elle est presque systematiquement ecrasee par les GPO de domaine. Mais elle existe, et elle s'applique en premier.

Exemple concret : un technicien configure gpedit.msc sur un PC de la salle de reunion pour desactiver l'ecran de veille. Si aucune GPO de domaine ne definit l'ecran de veille, ce reglage local reste actif. Mais des qu'une GPO de domaine impose un ecran de veille, elle ecrase le reglage local.

S -- Le site¶

Un site Active Directory represente un emplacement physique : un batiment, une ville, un datacenter. On relie des GPO aux sites quand on veut appliquer une regle a toutes les machines d'un lieu, independamment de leur position dans l'arborescence OU.

En pratique, les GPO de site sont rarement utilisees. La plupart des entreprises preferent organiser leurs OU par site plutot que d'utiliser les sites AD pour les GPO.

Un cas d'usage typique : une entreprise avec un bureau a Paris et un bureau a Lyon. Le bureau de Lyon utilise un serveur proxy different. Plutot que de creer une OU par site, l'administrateur peut lier une GPO au site AD "Lyon" pour configurer le proxy. Mais encore une fois, c'est un scenario peu courant.

D -- Le domaine¶

Les GPO liees au domaine s'appliquent a tous les objets du domaine, sans exception. C'est ici qu'on met les regles universelles : politique de mots de passe, configuration de l'ecran de veille, interdiction d'installer des logiciels...

La Default Domain Policy que vous avez vue dans le chapitre precedent est liee a ce niveau.

C'est le niveau le plus utilise pour les regles qui concernent tout le monde. Si vous voulez que tous les utilisateurs du domaine aient un mot de passe d'au moins 12 caracteres, c'est ici que ca se passe.

OU -- L'unite d'organisation¶

C'est le niveau le plus proche des utilisateurs et des ordinateurs. Les GPO liees aux OU sont les dernieres appliquees, et donc celles qui gagnent en cas de conflit avec les niveaux precedents.

Si une OU contient des sous-OU, les GPO s'appliquent de la plus haute a la plus basse. La GPO liee a la sous-OU Comptabilite\Stagiaires s'applique apres celle liee a Comptabilite, et l'ecrase en cas de conflit.

Prenons un exemple concret avec une arborescence d'entreprise :

labo.local                          ← GPO-Domaine (mot de passe = 12 car.)
├── OU=Siege
│   ├── OU=Comptabilite             ← GPO-Compta (logiciel de facturation)
│   │   └── OU=Stagiaires           ← GPO-Stagiaires (USB desactive)
│   └── OU=RH                      ← GPO-RH (acces aux dossiers RH)
└── OU=Agences
    └── OU=Lyon                     ← GPO-Lyon (imprimante Lyon)

Un stagiaire de la comptabilite recoit, dans cet ordre :

1. La GPO du domaine (mot de passe = 12 caracteres)
2. La GPO de l'OU Comptabilite (logiciel de facturation)
3. La GPO de la sous-OU Stagiaires (USB desactive)

Il herite de toutes les GPO de ses OU parentes, plus celles de son propre niveau. Les trois s'appliquent car elles ne sont pas en conflit.

Le diagramme complet¶

Voici l'ordre d'application visualise. Lisez de haut en bas : la derniere GPO appliquee gagne.

flowchart TB
    L["<b>1. Strategie locale</b><br>gpedit.msc sur le poste<br><i>Priorite la plus faible</i>"]
    S["<b>2. Site</b><br>GPO liee au site AD"]
    D["<b>3. Domaine</b><br>GPO liee au domaine"]
    OU["<b>4. OU parente</b><br>GPO liee a l'OU de niveau superieur"]
    SOU["<b>5. Sous-OU</b><br>GPO liee a la sous-OU contenant l'objet<br><i>Priorite la plus forte</i>"]

    L --> S --> D --> OU --> SOU

    style L fill:#e0e0e0,stroke:#9e9e9e,color:#000
    style S fill:#bbdefb,stroke:#1976d2,color:#000
    style D fill:#c8e6c9,stroke:#388e3c,color:#000
    style OU fill:#fff9c4,stroke:#f9a825,color:#000
    style SOU fill:#ffcdd2,stroke:#d32f2f,color:#000

La fleche va du plus faible au plus fort. Si la strategie locale dit "fond d'ecran = bleu" et la sous-OU dit "fond d'ecran = rouge", c'est rouge qui s'affiche.

Que se passe-t-il quand deux GPO se contredisent ?¶

C'est la question que tout le monde se pose. Et la reponse est simple : la GPO la plus proche de l'objet gagne.

Un scenario concret¶

Imaginons cette situation :

• Au niveau du domaine, une GPO nommee GPO-FondEcran-Bleu definit le fond d'ecran sur bleu.
• Au niveau de l'OU Comptabilite, une GPO nommee GPO-FondEcran-Rouge definit le fond d'ecran sur rouge.

Marie travaille a la comptabilite. Son compte utilisateur est dans l'OU Comptabilite.

Quel fond d'ecran voit-elle ?

Rouge. Parce que la GPO de l'OU est appliquee apres celle du domaine. La derniere couche gagne.

Et si les deux GPO parlent de choses differentes ?¶

Si GPO-FondEcran-Bleu au niveau domaine definit le fond d'ecran, et que GPO-Ecran-Veille au niveau OU configure uniquement l'ecran de veille, il n'y a aucun conflit. Les deux s'appliquent. Marie a un fond d'ecran bleu ET un ecran de veille configure.

Les GPO ne se contredisent que lorsqu'elles touchent le meme parametre. Si elles parlent de sujets differents, elles se completent.

C'est un point fondamental. Beaucoup de debutants pensent que si une GPO de domaine et une GPO d'OU sont liees au meme objet, elles s'annulent. Pas du tout. Elles se fusionnent, et seuls les parametres en conflit sont resolus par la regle "le plus proche gagne".

Tableau des conflits¶

Voici quelques scenarios pour bien ancrer le concept :

L'ordre de liaison¶

On a vu que la GPO la plus proche de l'objet gagne. Mais que se passe-t-il quand plusieurs GPO sont liees a la meme OU ?

C'est la que l'ordre de liaison (Link Order) entre en jeu.

On est ici dans un cas de figure tres courant. Au fil du temps, les administrateurs ajoutent de nouvelles GPO a une OU sans forcement penser a l'ordre. Et un jour, deux GPO se contredisent au meme niveau. C'est l'ordre de liaison qui tranche.

Le principe¶

Chaque GPO liee a une OU recoit un numero d'ordre. Ce numero determine l'ordre de traitement. Mais attention, c'est contre-intuitif :

La GPO avec le numero d'ordre le plus BAS a la priorite la plus HAUTE.

• Ordre de liaison 1 = appliquee en dernier = gagne les conflits
• Ordre de liaison 2 = appliquee avant la 1 = perd en cas de conflit

C'est logique si on y reflechit : la GPO numero 1 est traitee en dernier, donc elle ecrase les autres. Exactement comme la derniere couche de peinture sur un mur.

Exemple¶

L'OU Comptabilite a trois GPO liees :

La GPO-General-Compta (ordre 3) est traitee en premier. Elle definit l'ecran de veille a 10 minutes.

Ensuite, GPO-Reseau-Compta (ordre 2) est traitee. Elle configure le proxy. Pas de conflit avec l'ecran de veille.

Enfin, GPO-Securite-Compta (ordre 1) est traitee en dernier. Elle redefinit l'ecran de veille a 3 minutes. Elle ecrase la valeur de GPO-General-Compta.

Resultat final : ecran de veille = 3 minutes, proxy = 10.0.0.1.

C'est exactement comme des couches de peinture sur un mur. La derniere couche est celle qu'on voit, mais les couches precedentes ne disparaissent pas : elles sont juste cachees. Si on "gratte" la derniere couche (en supprimant la GPO prioritaire), la couleur precedente reapparait.

Modifier l'ordre de liaison¶

Bloquer l'heritage¶

Jusqu'ici, tout est logique : les GPO du domaine descendent vers les OU, et les OU les plus proches de l'objet gagnent. Mais parfois, un administrateur veut qu'une OU ignore completement les GPO des niveaux superieurs.

C'est ce qu'on appelle bloquer l'heritage.

L'analogie du casque anti-bruit¶

Imaginez que vous travaillez dans un open space bruyant. Vos collegues parlent, le telephone sonne, la machine a cafe gronde. Tout ce bruit vient "d'au-dessus" -- de l'environnement qui vous entoure.

Vous mettez un casque anti-bruit. D'un coup, silence total. Vous n'entendez plus rien de ce qui vient de l'exterieur. Le casque bloque tout le bruit, sans distinction. La voix de votre collegue qui vous pose une question ? Bloquee. L'annonce importante du directeur ? Bloquee aussi. Tout y passe.

Bloquer l'heritage, c'est exactement ca. Quand vous activez cette option sur une OU, elle ignore toutes les GPO heritees des niveaux superieurs (domaine, site, etc.). Seules les GPO directement liees a cette OU s'appliquent.

Comment l'activer¶

Ce qui se passe concretement¶

Prenons un exemple. Avant le blocage :

• GPO du domaine : mot de passe = 12 caracteres
• GPO du domaine : ecran de veille = 5 min
• GPO de l'OU Developpement : proxy = 10.0.0.5

Les developpeurs recoivent les trois parametres.

Apres avoir bloque l'heritage sur l'OU Developpement :

• GPO du domaine : mot de passe = 12 caracteres Bloque
• GPO du domaine : ecran de veille = 5 min Bloque
• GPO de l'OU Developpement : proxy = 10.0.0.5 Appliquee

Les developpeurs n'ont plus que le proxy. Les regles de mot de passe et d'ecran de veille du domaine ne s'appliquent plus.

Le diagramme du blocage¶

flowchart TB
    DOM["<b>Domaine : labo.local</b><br>GPO-MotDePasse<br>GPO-EcranDeVeille"]
    OU1["<b>OU : Comptabilite</b><br>GPO-Compta<br><i>Heritage normal</i>"]
    OU2["<b>OU : Developpement</b><br>GPO-Dev<br><i>Heritage BLOQUE</i>"]

    DOM -->|"GPO heritees ✓"| OU1
    DOM -.-x|"GPO bloquees ✗"| OU2

    style DOM fill:#c8e6c9,stroke:#388e3c,color:#000
    style OU1 fill:#fff9c4,stroke:#f9a825,color:#000
    style OU2 fill:#ffcdd2,stroke:#d32f2f,color:#000

L'OU Comptabilite recoit normalement les GPO du domaine. L'OU Developpement les bloque toutes.

Pourquoi c'est rarement une bonne idee¶

# List all OUs with blocked inheritance
Get-GPInheritance -Target "dc=labo,dc=local" | Where-Object { $_.GpoInheritanceBlocked -eq $true }

Forcer une GPO (Enforced)¶

On vient de voir que bloquer l'heritage est comme un casque anti-bruit. Mais que se passe-t-il si quelque chose est tellement important qu'il doit traverser meme le casque anti-bruit ?

C'est le role de l'option Applique (Enforced).

Dans l'interface francaise de GPMC, cette option s'appelle Applique. Dans les documentations en anglais, vous la trouverez sous le nom Enforced. Les deux termes designent exactement la meme chose. Dans ce livre, on utilisera les deux de maniere interchangeable pour que vous soyez a l'aise avec les deux vocabulaires.

L'analogie de l'alarme incendie¶

Vous etes dans votre open space avec votre casque anti-bruit. Vous n'entendez plus rien. Soudain, l'alarme incendie se declenche.

L'alarme incendie est tellement forte, tellement vitale, qu'elle traverse le casque anti-bruit. Vous l'entendez quand meme. Elle est concue pour ne jamais etre ignoree. Peu importe votre casque, peu importe vos ecouteurs, peu importe a quel point vous essayez de l'ignorer : l'alarme passe.

C'est exactement ce que fait l'option Enforced sur une GPO. Une GPO forcee :

• S'applique meme si l'OU a bloque l'heritage
• Ecrase les GPO des niveaux inferieurs en cas de conflit
• Ne peut pas etre contournee par les OU enfants

C'est l'arme ultime de l'administrateur pour les regles non negociables.

Comment l'activer¶

Ce qui change avec Enforced¶

Sans Enforced, l'ordre normal s'applique : la GPO la plus proche de l'objet gagne.

Avec Enforced, la GPO forcee gagne toujours, meme si une GPO plus proche dit le contraire.

Quand utiliser Enforced ?¶

En un mot : rarement.

Enforced est reserve aux regles de securite critiques qui doivent s'appliquer partout, sans exception. Par exemple :

• Politique de mots de passe minimale (longueur, complexite)
• Configuration de Windows Update (les correctifs de securite doivent toujours s'appliquer)
• Parametres de pare-feu de base

Si vous forcez 15 GPO, vous avez un probleme d'architecture, pas un probleme de GPO.

Que se passe-t-il avec plusieurs GPO Enforced ?¶

Si deux GPO Enforced se contredisent, la regle est l'inverse des GPO normales : c'est la plus haute dans la hierarchie qui gagne.

Exemple : une GPO Enforced au domaine dit "ecran de veille = 5 min", et une GPO Enforced a l'OU dit "ecran de veille = 10 min". C'est 5 minutes qui gagne, parce que le domaine est plus haut que l'OU.

Pour les GPO normales, la plus proche gagne. Pour les GPO Enforced, la plus haute gagne. C'est logique quand on y pense : Enforced est fait pour que les administrateurs du domaine gardent le controle final.

La hierarchie complete des conflits¶

On a vu beaucoup de regles. Mettons tout a plat dans un tableau unique, de la priorite la plus haute a la plus basse.

Ce tableau est votre reference ultime. En cas de doute sur la priorite d'une GPO, revenez ici et trouvez son type dans la liste. Le numero le plus bas gagne toujours.

Exercice : predire quelle GPO gagne¶

Mettez vos connaissances a l'epreuve. Pour chaque scenario, essayez de predire le resultat avant de lire la solution.

Prenez votre temps. Dessinez l'arborescence sur un papier si ca vous aide. L'objectif n'est pas de repondre vite, mais de comprendre pourquoi une GPO gagne.

Scenario 1 -- Le conflit basique¶

Situation :

• GPO-A est liee au domaine : fond d'ecran = bleu
• GPO-B est liee a l'OU Ventes : fond d'ecran = vert
• L'utilisateur Pierre est dans l'OU Ventes
• Aucune GPO n'est forcee, pas de blocage d'heritage

Quel fond d'ecran voit Pierre ?

Scenario 2 -- Le blocage d'heritage¶

Situation :

• GPO-A est liee au domaine : ecran de veille = 5 min
• GPO-B est liee au domaine : proxy = 10.0.0.1
• L'OU Developpement a bloque l'heritage
• GPO-C est liee a l'OU Developpement : fond d'ecran = noir
• L'utilisateur Sophie est dans l'OU Developpement

Quels parametres s'appliquent a Sophie ?

Scenario 3 -- Enforced contre blocage¶

Situation :

• GPO-A est liee au domaine avec l'option Enforced : mot de passe = 14 caracteres minimum
• GPO-B est liee au domaine (normale) : ecran de veille = 5 min
• L'OU Direction a bloque l'heritage
• GPO-C est liee a l'OU Direction : mot de passe = 8 caracteres minimum
• L'utilisateur Marc est dans l'OU Direction

Quels parametres s'appliquent a Marc ?

Visualiser l'heritage dans GPMC¶

Deviner quelle GPO s'applique, c'est bien pour apprendre. Mais en situation reelle, il existe un outil qui vous donne la reponse directement : l'onglet Heritage de strategie de groupe dans GPMC.

C'est l'equivalent d'un rayon X pour vos GPO : au lieu de deviner quelle couche est visible, vous voyez directement le resultat final. Tout administrateur devrait avoir le reflexe de consulter cet onglet avant de creer ou modifier une GPO.

Ou le trouver¶

Ce que cet onglet vous dit¶

• Les GPO qui s'appliquent effectivement a cette OU, apres calcul de l'heritage
• L'ordre de priorite final (la ligne 1 gagne en cas de conflit)
• D'ou vient chaque GPO (domaine, OU parente, OU elle-meme)
• Si une GPO est forcee (Enforced)

Lire le resultat¶

Prenons un exemple. Vous cliquez sur l'OU Comptabilite\Stagiaires et vous ouvrez l'onglet Heritage de strategie de groupe. Voici ce que vous pourriez voir :

Comment lire ce tableau ? De haut en bas, par priorite decroissante. Si GPO-Stagiaires et Default Domain Policy definissent toutes les deux l'ecran de veille, c'est GPO-Stagiaires (priorite 1) qui gagne.

Notez que les GPO de l'OU parente (Comptabilite) apparaissent aussi dans la liste : c'est justement l'heritage en action. Les GPO des niveaux superieurs "descendent" vers les niveaux inferieurs.

Ce que cet onglet ne vous dit pas¶

• Il ne montre pas les GPO qui ont ete bloquees par le blocage d'heritage (elles ont disparu de la liste)
• Il ne montre pas les GPO qui sont liees mais desactivees
• Il ne montre pas le filtrage de securite (on verra ca dans un prochain chapitre)
• Il ne montre pas si un parametre specifique est defini ou non dans une GPO -- il montre juste la liste des GPO effectives

Quand utiliser quoi ?¶

On a vu trois mecanismes pour influencer l'heritage : l'ordre de liaison, le blocage d'heritage et le forcage (Enforced). Mais lequel utiliser, et quand ?

Le tableau de decision¶

La regle d'or de l'heritage¶

Le piege de la complexite¶

Chaque blocage ou forcage que vous ajoutez est une exception a la regle normale. Et chaque exception est un piege pour le futur :

• Dans 6 mois, vous aurez oublie pourquoi vous avez bloque l'heritage sur cette OU.
• Votre collegue qui reprend le poste ne comprendra pas le comportement de cette OU.
• Un ticket de support prendra 3 heures au lieu de 10 minutes parce que personne ne pensera a verifier le blocage.

La simplicite est une vertu en administration systeme. Moins d'exceptions = moins de surprises.

Un exemple d'architecture propre¶

Voici a quoi ressemble un domaine bien organise, sans blocage ni forcage excessif :

labo.local
│
├── GPO liees au domaine :
│   ├── Default Domain Policy        (mot de passe, verrouillage)
│   └── GPO-Securite-Base            (pare-feu, antivirus) ← Enforced
│
├── OU=Postes
│   ├── OU=Standards                 ← GPO-Config-Standard
│   ├── OU=Portables                 ← GPO-Config-Portable (VPN, BitLocker)
│   └── OU=Kiosques                  ← GPO-Kiosque (mode restreint)
│
└── OU=Utilisateurs
    ├── OU=Comptabilite              ← GPO-Compta
    ├── OU=Direction                 ← GPO-Direction
    └── OU=Stagiaires               ← GPO-Stagiaires

Dans cet exemple, une seule GPO est Enforced (GPO-Securite-Base), et il n'y a aucun blocage d'heritage. Chaque OU recoit les regles du domaine plus ses propres regles specifiques. Simple, lisible, maintenable.

Recapitulatif du chapitre¶

Vous avez couvert beaucoup de terrain dans ce chapitre. Pas de panique si tout n'est pas parfaitement clair du premier coup. L'heritage des GPO est un sujet que meme les administrateurs experimentes revisitent regulierement.

L'essentiel est de retenir les grands principes. Les details viendront avec la pratique.

Voici l'ensemble des concepts de ce chapitre, condenses en un seul tableau de reference.

flowchart TB
    subgraph Normal["Heritage normal"]
        direction TB
        N1["Strategie locale"] -->|"ecrasee par"| N2["Site"]
        N2 -->|"ecrase par"| N3["Domaine"]
        N3 -->|"ecrase par"| N4["OU parente"]
        N4 -->|"ecrase par"| N5["Sous-OU<br><b>= gagne</b>"]
    end

    subgraph Enforced["Heritage avec Enforced"]
        direction TB
        E1["<b>Enforced domaine</b><br>= gagne toujours"] -->|"ecrase"| E2["Enforced OU"]
        E2 -->|"ecrase"| E3["Normale sous-OU"]
        E3 -->|"ecrase"| E4["Normale OU"]
        E4 -->|"ecrase"| E5["Normale domaine"]
    end

    style N5 fill:#c8e6c9,stroke:#388e3c,color:#000
    style E1 fill:#ffcdd2,stroke:#d32f2f,color:#000

Dans le chapitre suivant, on passera a la pratique avec les parametres de securite essentiels a configurer en priorite via les GPO. Vous verrez comment appliquer les concepts d'heritage que vous venez d'apprendre pour deployer une politique de securite solide sur l'ensemble de votre domaine.