Item-Level Targeting avancé¶

Qu'est-ce que l'ILT ?¶

Un mécanisme de filtrage par item, pas par GPO¶

Group Policy Preferences (GPP) est la couche de configuration flexible de Group Policy. Elle gère les lecteurs réseau, les imprimantes, les entrées de registre, les raccourcis, les tâches planifiées et une vingtaine d'autres catégories.

Chacun de ces éléments — chaque item GPP — peut avoir ses propres règles de filtrage. C'est l'Item-Level Targeting (ILT).

Le Security Filtering et les WMI Filters opèrent au niveau de la GPO entière. L'ILT est orthogonal : il s'applique à chaque item individuellement, à l'intérieur d'une GPO qui a déjà passé les autres filtres.

Qui évalue l'ILT ?¶

La DLL gpprefcl.dll est la CSE qui traite toutes les préférences GPP. C'est elle, et elle seule, qui implémente la logique ILT.

Lors du traitement d'une GPO, gpprefcl.dll parcourt chaque item. Pour chaque item, si une section <filters> est présente, elle évalue les conditions avant d'écrire quoi que ce soit sur le système. Si les conditions ne sont pas satisfaites, l'item est silencieusement ignoré.

Aucune trace n'est écrite dans le journal des événements pour un item ignoré par ILT — c'est un comportement normal, pas une erreur.

Ce que l'ILT rend possible¶

Sans ILT, un lecteur réseau mappé par GPP s'applique à tous les objets dans la portée de la GPO. Avec l'ILT, ce même lecteur peut ne s'appliquer qu'aux machines portables, membres d'un groupe AD spécifique, sous Windows 11, situées dans un sous-réseau particulier.

Une seule GPO peut contenir :

• Un item qui s'applique uniquement aux portables (condition Battery Present)
• Un item qui s'applique uniquement aux postes fixes en salle de conférence (condition Computer Name = CONF-*)
• Un item qui s'applique uniquement aux membres du groupe GRP-Ingénieurs sous Windows 11 (conditions Security Group + OS Version)

Architecture de l'ILT dans le XML GPP¶

:material-file-xml: Où vivent les conditions¶

Les fichiers GPP sont des fichiers XML stockés dans SYSVOL, sous le dossier User\Preferences ou Machine\Preferences de chaque GPO. Chaque catégorie a son propre fichier : Drives.xml, Printers.xml, Registry.xml, etc.

Un item GPP sans ILT ressemble à ceci :

<Drive clsid="{935D1B74-9CB8-4E3C-9914-7DD559B7A417}"
       name="H:" status="H:" image="2" changed="2024-01-15 09:00:00"
       uid="{A1B2C3D4-...}">
  <Properties action="U" path="\\srv-fichiers\home\%USERNAME%"
              letter="H" label="Dossier personnel"
              persistent="1" useLetter="1"/>
</Drive>

Dès qu'une condition ILT est ajoutée, une section <filters> apparaît :

<Drive clsid="{935D1B74-9CB8-4E3C-9914-7DD559B7A417}"
       name="H:" status="H:" image="2" changed="2024-01-15 09:00:00"
       uid="{A1B2C3D4-...}">
  <Properties action="U" path="\\srv-fichiers\home\%USERNAME%"
              letter="H" label="Dossier personnel"
              persistent="1" useLetter="1"/>
  <filters>
    <!-- Condition 1: member of security group (AND, not negated) -->
    <filterGroup bool="AND" not="0"
                 name="CONTOSO\GRP-Employes-Permanents"
                 sid="S-1-5-21-3456789012-987654321-1234567890-1234"
                 localGroup="0" primaryGroup="0" userContext="1"
                 filterType="GROUP"/>
    <!-- Condition 2: OS range Windows 10/11 (AND, not negated) -->
    <filterOsRange bool="AND" not="0"
                   type="WINDOWS" edition=""
                   versionUpper="11.99.99999"
                   versionLower="10.0.0"/>
  </filters>
</Drive>

Les attributs clés de chaque condition¶

Les 22 types de conditions ILT¶

Table de référence complète¶

La condition Battery Present¶

Battery Present est l'une des conditions les plus simples et les plus utiles. Elle évalue si Win32_Battery retourne au moins un objet.

Elle est idéale pour distinguer portables et fixes sans requête WMI explicite — c'est une requête WMI interne, mais déjà optimisée par Windows.

<filterBattery bool="AND" not="0"/>

La condition IP Address Range¶

IP Address Range compare la première adresse IP routable de la machine avec une plage définie. Elle ne supporte pas nativement la notation CIDR — vous saisissez une adresse de début et une adresse de fin.

Pour 192.168.10.0/24, vous entrez : début 192.168.10.1, fin 192.168.10.254.

<filterIpRange bool="AND" not="0"
               ipLow="192.168.10.1"
               ipHigh="192.168.10.254"/>

La condition Security Group¶

Security Group vérifie l'appartenance d'un utilisateur ou d'un ordinateur à un groupe AD. C'est l'une des conditions les plus utilisées et l'une des moins coûteuses.

L'appartenance aux groupes AD est mise en cache dans le token Kerberos. L'évaluation ne génère pas d'appel LDAP supplémentaire — elle lit le token déjà présent en mémoire.

<filterGroup bool="AND" not="0"
             name="CONTOSO\GRP-Postes-DevOps"
             sid="S-1-5-21-3456789012-987654321-1234567890-4567"
             localGroup="0" primaryGroup="0"
             userContext="0" filterType="GROUP"/>

L'attribut userContext="0" signifie que le groupe est évalué dans le contexte machine. userContext="1" évalue dans le contexte utilisateur.

:material-logic-and: Logique booléenne AND/OR/NOT¶

Ce que GPMC affiche vs ce que le XML contient¶

Dans la GPMC, l'éditeur ILT présente les conditions dans une liste. Ce que l'interface appelle un "groupe de conditions" correspond à un bloc AND. Les blocs eux-mêmes sont combinés par OR.

Chaque condition a une case "NOT" qui correspond à l'attribut not="1" dans le XML.

La règle de lecture est la suivante :

Résultat = (Bloc1_Condition1 AND Bloc1_Condition2 AND ...) 
        OR (Bloc2_Condition1 AND Bloc2_Condition2 AND ...)
        OR ...

:material-example: Exemples de combinaisons courantes¶

Cas 1 : Portables membres d'un groupe

Condition 1 : Battery Present          [bool=AND, not=0]
Condition 2 : Security Group = GRP-Portables  [bool=AND, not=0]

Résultat : la machine doit avoir une batterie ET appartenir au groupe.

Cas 2 : Exclure les kiosques

Condition 1 : Computer Name = KIOSK-*  [bool=AND, not=1]

Résultat : s'applique à toutes les machines dont le nom ne commence pas par KIOSK-.

Cas 3 : Windows 10 OU Windows 11

Bloc 1 — Condition 1 : OS Version = 10.0.x  [bool=AND, not=0]
                        [OR entre blocs]
Bloc 2 — Condition 1 : OS Version = 11.x    [bool=AND, not=0]

Dans la GPMC, cela se traduit par deux blocs séparés dans l'éditeur ILT, reliés par le bouton "OR".

Diagramme d'évaluation ILT¶

Le diagramme suivant représente le flux d'évaluation exécuté par gpprefcl.dll pour chaque item GPP contenant une section <filters>.

flowchart TD
    A[gpprefcl.dll traite un item GPP] --> B{Section filters\nprésente ?}
    B -->|Non| APPLY[Appliquer l'item\nau système]
    B -->|Oui| C[Lire condition suivante]
    C --> D{bool = AND ?}
    D -->|Oui| E[Évaluer la condition]
    E --> F{Résultat ?\nnot appliqué}
    F -->|Vrai| G{Dernière condition\ndu bloc ?}
    F -->|Faux| SKIP[Ignorer l'item\nsilencieusement]
    G -->|Non| C
    G -->|Oui| H{Dernier bloc ?}
    H -->|Non| I{bool = OR ?\nnext block}
    I -->|Oui| APPLY
    H -->|Oui| APPLY
    D -->|Non — OR| J[Évaluer la condition]
    J --> K{Résultat ?\nnot appliqué}
    K -->|Vrai| APPLY
    K -->|Faux| C
    APPLY --> L[Écrire registre / mapper\nlecteur / créer raccourci...]

Condition avancée : LDAP Query¶

Principe¶

La condition LDAP Query est la plus puissante de toutes. Elle peut interroger n'importe quel attribut de n'importe quel objet AD en utilisant la syntaxe de filtre LDAP standard.

Exemples d'utilisation :

• Cibler les ordinateurs dont l'attribut extensionAttribute1 vaut "Poste-DevOps"
• Cibler les utilisateurs dont le département est "Ingénierie" (department)
• Cibler les objets dont la description contient un code spécifique

Namespace : LDAP:                    (vide = contrôleur de domaine courant)
Filter     : (&(objectClass=computer)(extensionAttribute1=Poste-DevOps))
Binding    : Computer                (Computer ou User selon le contexte)

Dans le XML GPP¶

<filterLdap bool="AND" not="0"
            binding="computer"
            ldapQuery="(&amp;(objectClass=computer)(extensionAttribute1=Poste-DevOps))"
            searchRoot=""
            dnsDomain="contoso.local"/>

Impact sur les performances¶

Chaque condition LDAP Query génère un appel LDAP au contrôleur de domaine lors de l'évaluation. Cet appel est synchrone pendant le traitement GPP.

Estimation de l'impact :

Sur un lien WAN ou un accès via VPN avec de la latence, l'impact peut devenir significatif à l'ouverture de session.

:material-registry: Condition avancée : Registry Match¶

Principe¶

Registry Match vérifie l'existence ou la valeur d'une clé de registre sur le client local. C'est l'alternative recommandée à WMI Query pour détecter des logiciels installés.

Opérateurs disponibles :

Détecter un logiciel sans Win32_Product¶

L'exemple classique : appliquer un paramètre uniquement si Google Chrome est installé.

<!-- Check default value of the App Paths registry key -->
<filterRegistry bool="AND" not="0"
                hive="HKEY_LOCAL_MACHINE"
                key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe"
                value=""
                type="REG_SZ"
                operator="EXISTS"/>

Ou via la version installée dans Uninstall :

<filterRegistry bool="AND" not="0"
                hive="HKEY_LOCAL_MACHINE"
                key="SOFTWARE\Google\Chrome\BLBeacon"
                value="version"
                type="REG_SZ"
                operator="EXISTS"/>

Vérifier manuellement depuis PowerShell¶

# Simulate what Registry Match checks for Chrome detection
$chromeKey = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe"
$chromeInstalled = Test-Path $chromeKey
Write-Output "Chrome detected: $chromeInstalled"

# Check specific value
$chromeBLBeacon = "HKLM:\SOFTWARE\Google\Chrome\BLBeacon"
if (Test-Path $chromeBLBeacon) {
    $version = (Get-ItemProperty $chromeBLBeacon -ErrorAction SilentlyContinue).version
    Write-Output "Chrome version from BLBeacon: $version"
}

Condition avancée : WMI Query¶

Principe¶

WMI Query dans l'ILT fonctionne de la même façon qu'un filtre WMI au niveau GPO — une requête WQL est exécutée et si elle retourne au moins un objet, la condition est vraie.

La différence : un filtre WMI bloque toute la GPO. Une condition WMI Query ILT ne bloque que l'item concerné.

<filterWmi bool="AND" not="0"
           namespace="root\CIMv2"
           query="SELECT * FROM Win32_ComputerSystem WHERE Manufacturer LIKE '%Dell%'"/>

Exemples de requêtes WMI utiles pour l'ILT¶

SELECT * FROM Win32_ComputerSystem WHERE Manufacturer LIKE '%Dell%'

SELECT * FROM Win32_ComputerSystem WHERE Model = 'Latitude 5540'

SELECT * FROM Win32_ComputerSystem WHERE HypervisorPresent = FALSE

SELECT * FROM Win32_NetworkAdapter 
WHERE NetConnectionStatus = 2 
AND PhysicalAdapter = TRUE 
AND Name LIKE '%Wireless%'

SELECT * FROM Win32_DiskDrive WHERE MediaType = 'Fixed hard disk media'

Pièges de performance WMI¶

Les classes WMI lentes à ne jamais utiliser dans l'ILT :

Classes WMI rapides et sûres pour l'ILT :

Impact sur les performances¶

Coût cumulatif des évaluations ILT¶

L'ILT a un coût d'évaluation cumulatif. Chaque item GPP avec des conditions ILT ajoute un temps d'évaluation au traitement GPP total.

Lors d'un traitement foreground (démarrage / ouverture de session), ce surcoût s'additionne directement au temps de logon perçu par l'utilisateur.

Estimation par type de condition :

Scénario concret : 50 items GPP avec LDAP Query¶

50 items × 50 ms/LDAP Query = 2,5 secondes de surcoût
50 items × 80 ms/LDAP Query (WAN) = 4 secondes de surcoût

Ces 4 secondes s'ajoutent à chaque traitement GPP foreground — démarrage machine et logon utilisateur.

Stratégies d'optimisation¶

1. Remplacer LDAP Query par Security Group quand possible

Créez un groupe AD qui matérialise le critère. Remplissez-le via un script ou un provisionnement automatique. La vérification de groupe coûte 0 ms.

2. Exploiter le court-circuit OR

Placez les conditions les moins coûteuses et les plus souvent vraies en premier dans un bloc OR. Dès qu'une est vraie, les suivantes ne sont pas évaluées.

Bloc 1 : Security Group = GRP-Machines-DevOps   [OR — très rapide, souvent vrai]
Bloc 2 : LDAP Query = extensionAttribute1=DevOps [OR — lent, fallback]

3. Consolider les items avec la même condition WMI

Si 20 items partagent la même requête Win32_ComputerSystem WHERE Manufacturer LIKE '%Dell%', placez-les dans une GPO dédiée et remplacez la condition WMI par un WMI Filter au niveau GPO — exécuté une seule fois.

4. Utiliser Registry Match plutôt que WMI Query pour la détection de logiciels

Registry Match est 10 à 100 fois plus rapide que n'importe quelle requête WMI pour détecter un logiciel installé.

5. Auditer les items ILT avec le journal Operational Group Policy

# Read GPP processing events from the Operational log
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
    Where-Object { $_.Id -in @(4016, 5016, 5017, 5018) } |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize -Wrap

ILT vs WMI Filter vs Security Filtering¶

Comparaison rigoureuse¶

:material-decision: Quand utiliser quoi ?¶

Security Filtering — quand toute la GPO doit être restreinte à un groupe AD. C'est le mécanisme le plus rapide et le plus simple. Le choix par défaut pour la grande majorité des GPO.

WMI Filter — quand une GPO entière doit s'appliquer uniquement dans un contexte matériel ou OS précis et que ce critère n'est pas exprimable par un groupe AD. Acceptable sur LAN avec des classes WMI rapides.

ILT — quand différents items GPP dans la même GPO doivent s'appliquer à des cibles différentes, ou quand la granularité par item est nécessaire. Inévitable dès que vous avez des préférences polymorphes dans une même GPO.

Règle de décision¶

Si vous voulez restreindre toute la GPO à un groupe AD → Security Filtering
Si vous voulez restreindre toute la GPO à une condition hardware/OS → WMI Filter
Si vous voulez des items différents selon des critères différents → ILT
Si les critères ILT sont tous identiques pour tous les items → reconsidérez WMI Filter

Diagnostiquer un ILT silencieux¶

Le problème de la transparence¶

Quand un item GPP est ignoré par ILT, Windows n'écrit aucune entrée dans le journal des événements par défaut. Du point de vue de l'administrateur, l'item "ne s'applique pas" sans explication visible.

Il existe plusieurs techniques pour comprendre pourquoi.

Vérifier le résultat RSoP pour les GPP¶

Le RSoP classique (Resultant Set of Policy) ne montre pas les détails ILT. Utilisez gpresult avec le flag HTML pour une vue plus détaillée :

# Run as the targeted user or with /USER parameter
gpresult /H C:\Temp\rsop-report.html /F

Ouvrez le fichier HTML et cherchez la section "Group Policy Preferences" — les items ignorés par ILT apparaissent avec le statut "Item filtered due to targeting".

Activer la journalisation détaillée GPP¶

La journalisation détaillée des GPP peut être activée par registre :

# Enable verbose GPP logging — creates log files under C:\ProgramData\GroupPolicy\Preference
$gppTracingKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics"
New-Item -Path $gppTracingKey -Force | Out-Null
Set-ItemProperty -Path $gppTracingKey -Name "GPSvcDebugLevel" -Value 0x30002 -Type DWord

# Force a GP refresh to generate logs
gpupdate /force

# Read the generated log
$logPath = "C:\ProgramData\GroupPolicy\Preference\Trace"
Get-ChildItem $logPath | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Event IDs pertinents¶

# Find GPP items that were skipped (filtered or errored)
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
    Where-Object { $_.Id -eq 4098 } |
    Select-Object TimeCreated, Message |
    Sort-Object TimeCreated -Descending |
    Format-List

Simuler les conditions ILT manuellement¶

Avant de déployer, testez les conditions ILT directement sur une machine cible avec PowerShell pour vous assurer qu'elles retournent le résultat attendu.

# --- Battery Present ---
$battery = Get-CimInstance -ClassName Win32_Battery -ErrorAction SilentlyContinue
Write-Output "Battery Present: $($null -ne $battery)"

# --- OS Version ---
$osVersion = [System.Environment]::OSVersion.Version.ToString()
Write-Output "OS Version: $osVersion"

# --- Security Group membership (computer context) ---
$computerGroups = ([Security.Principal.WindowsIdentity]::GetCurrent()).Groups |
    ForEach-Object { $_.Translate([Security.Principal.NTAccount]).Value }
Write-Output "Computer group memberships:"
$computerGroups | Sort-Object

# --- IP Address ---
$ipAddresses = Get-NetIPAddress -AddressFamily IPv4 |
    Where-Object { $_.IPAddress -notmatch '^(127\.|169\.254\.)' } |
    Select-Object -ExpandProperty IPAddress
Write-Output "Routable IPv4 addresses: $($ipAddresses -join ', ')"

# --- Registry Match simulation ---
$regPath = "HKLM:\SOFTWARE\Google\Chrome\BLBeacon"
$regExists = Test-Path $regPath
Write-Output "Chrome registry key exists: $regExists"

# --- WMI Query simulation ---
$dellQuery = Get-CimInstance -Query "SELECT * FROM Win32_ComputerSystem WHERE Manufacturer LIKE '%Dell%'"
Write-Output "Dell manufacturer WMI match: $($null -ne $dellQuery)"

Interaction ILT avec l'action GPP (C/U/R/D)¶

Ce que l'action fait quand ILT est faux¶

Chaque item GPP possède une action : Create (C), Update (U), Replace (R), ou Delete (D).

Quand les conditions ILT d'un item échouent, l'action n'est jamais exécutée, quelle que soit l'action configurée. Il n'y a pas d'effet de bord — pas de suppression, pas de remplacement, pas de rollback.

C'est un comportement important à comprendre pour les items avec l'action Delete (D) : si la condition ILT est fausse, l'item ne sera pas supprimé, même si l'intention était de supprimer une configuration pour les machines hors scope.

Combinaison ILT + Action Delete : pattern de nettoyage ciblé¶

Un pattern avancé consiste à créer deux items pour le même objet :

1. Item A — Action U avec ILT = "membre du groupe GRP-Développeurs" → applique la configuration
2. Item B — Action D avec ILT = "NON membre du groupe GRP-Développeurs" → supprime la configuration sur les machines qui n'y appartiennent plus

Ce pattern garantit qu'une configuration est proprement retirée quand une machine quitte le groupe cible, sans avoir à créer une GPO de nettoyage séparée.

Références croisées¶