SRP s’affiche comme « Winning Policy » dans vos rapports gpresult/RSOP mais les restrictions ne s’appliquent plus ? Voici un guide pas‑à‑pas pour diagnostiquer et corriger un cas réel où des règles AppLocker actives rendaient SRP inopérant sur Windows 10/11.
Problème rencontré
Les Software Restriction Policy (SRP) sont visibles dans gpresult et dans la Resultant Set of Policy comme « Winning Policy » ; pourtant, la plupart des utilisateurs ne sont plus bloqués comme prévu (lancement d’applications non autorisées, absence de fenêtres d’alerte, comportements incohérents entre postes).
- Environnement : domaines Active Directory, GPO SRP historiquement déployées.
- Symptômes : lancement possible d’apps Microsoft (Xbox, Camera, 3D Viewer, OfficeHub, etc.), comportements variables selon l’utilisateur ou la machine.
- Contexte : présence d’un autre GPO contenant des règles AppLocker.
Fait clé : dès qu’AppLocker (ou WDAC) est actif, Windows ignore silencieusement SRP. Le moteur le plus moderne prend la main.
Pistes de diagnostic explorées
Voici les vérifications réalisées pour reproduire et comprendre le dysfonctionnement.
| Étape | Objectif |
|---|---|
| Vérification des règles SRP | S’assurer qu’aucune règle n’a été supprimée ou modifiée. |
| Contrôle du lien GPO / filtrage de sécurité | Confirmer que le GPO est bien lié à l’OU cible et que les ACL de sécurité laissent passer l’objet. |
| Utilisation de gpresult / RSOP | Vérifier que le GPO SRP est effectivement appliqué au poste et à l’utilisateur. |
| Examen des journaux Événements Système & Application | Rechercher erreurs/avertissements liés à SRP ou AppLocker. |
| Commande gpupdate /force et redémarrage | Forcer la réapplication des stratégies. |
| Vérification des mises à jour récentes | Détecter un correctif Windows susceptible d’avoir changé le comportement. |
| Validation des privilèges utilisateur et de l’UAC | S’assurer qu’aucune élévation ou paramètre local ne court‑circuitent SRP. |
Checklist rapide
- gpresult confirme la présence de Software Restriction Policies ?
- Des journaux AppLocker existent‑ils (Applications and Services Logs → Microsoft → Windows → AppLocker) ?
- Le service Application Identity (AppIDSvc) est‑il démarré ?
- Une stratégie WDAC (Code Integrity) est‑elle présente sur le poste ?
- L’étendue des GPO (LIENS/ACL/WMI Filter) permet‑elle à AppLocker de toucher « Tout le monde » ?
Commandes utiles
gpresult /h C:\Temp\rsop.html
gpresult /scope user /v
gpresult /scope computer /v
# PowerShell - politique AppLocker effective
Get-AppLockerPolicy -Effective -Xml | Out-File C:\Temp\Applocker-Effective.xml
# PowerShell - état du service Application Identity
Get-Service AppIDSvc | Format-List Name,Status,StartType Cause identifiée
Un GPO AppLocker (distinct du GPO SRP) contenait des règles bloquant de nombreuses applications Microsoft pour le groupe Tout le monde. Or, AppLocker et SRP ne cohabitent pas : dès que des règles AppLocker sont actives, Windows désactive de fait SRP sans avertissement explicite. Résultat : gpresult affiche SRP comme « Winning Policy », mais l’exécution est arbitrée par AppLocker, pas par SRP.
- AppLocker s’appuie sur le service Application Identity pour l’évaluation.
- Si AppLocker est en mode Audit ou Enforcement, ses décisions prévalent sur SRP.
- Le phénomène est identique si une politique WDAC (Windows Defender Application Control) est active : SRP devient inopérant.
Solution mise en œuvre
- Localiser le ou les GPO AppLocker appliqués aux machines/utilisateurs concernés (via gpresult, Group Policy Management).
- Désactiver ou ajuster le GPO fautif :
- Retirer le filtrage « Tout le monde » si la stratégie devait viser un sous‑ensemble restreint.
- Basculer temporairement en Audit only pour mesurer l’impact sans bloquer.
- Créer les règles par défaut autorisantes (éditeurs Microsoft, répertoires Program Files, Windows) avant d’ajouter des blocages ciblés.
- Forcer l’application :
gpupdate /forcepuis redémarrage (requis si AppIDSvc change d’état). - Vérifier que SRP reprend effet (tests d’exécution, journaux). Voir la section « Vérifications post‑correctif ».
Après suppression du conflit, les restrictions SRP sont de nouveau appliquées comme prévu.
Vérifications post‑correctif
Test simple côté utilisateur
- Choisir une application historiquement bloquée par SRP.
- Vider le cache des stratégies ou redémarrer la session.
- Lancer l’application :
- Si SRP est actif : message de blocage SRP (ou absence de lancement selon configuration).
- Si AppLocker est actif : événements AppLocker (800x) apparaissent dans ses journaux.
Scripts rapides d’audit
# 1) Détecter la présence effective de règles AppLocker
$applocker = Get-AppLockerPolicy -Effective -Xml
if ([string]::IsNullOrWhiteSpace($applocker)) {
"Aucune règle AppLocker effective."
} else {
"Règles AppLocker détectées (Effective)."
}
# 2) Vérifier l’état du service Application Identity
(Get-Service AppIDSvc).Status
# 3) Indice de WDAC : présence d’une politique Code Integrity
$ciPaths = @(
"$env:windir\System32\CodeIntegrity\SIPolicy.p7b",
"$env:windir\System32\CodeIntegrity\CiPolicies\Active"
)
$ciPaths | ForEach-Object { if (Test-Path $*) { "WDAC : artefact présent -> $*" } }
# 4) Export SRP (machine)
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" C:\Temp\SRP_Machine.reg /y
# 5) Rapport gpresult
gpresult /h C:\Temp\rsop.html Priorité des mécanismes de contrôle d’exécution
Sur Windows, plusieurs moteurs peuvent contrôler ce qui s’exécute :
- WDAC (Windows Defender Application Control) – le plus récent, niveau noyau.
- AppLocker – règles par éditeur, chemin, hash, y compris Packaged apps (UWP).
- SRP – mécanisme hérité basé sur des règles simples (chemin/hash/zone).
Ordre d’autorité simplifié : WDAC ⟶ AppLocker ⟶ SRP. Si WDAC ou AppLocker est actif, SRP est ignoré.
Bonnes pratiques
- Ne pas mélanger SRP et AppLocker sur un même périmètre ; choisir un seul moteur.
- Sur Windows 10/11, privilégier AppLocker ou WDAC ; considérer SRP comme hérité.
- Documenter les dépendances : AppLocker requiert le service Application Identity démarré.
- Si vous migrez :
- Commencer par un mode Audit exhaustif, analyser les événements, bâtir une liste d’autorisations de base (éditeurs Microsoft, répertoires système, outils IT).
- Passer ensuite en Enforcement progressivement, par groupes pilotes.
- Éviter les filtres trop larges (« Tout le monde ») sans tests ; préférer des groupes dédiés.
- Garder des règles par défaut autorisantes pour les chemins %WINDIR% et %ProgramFiles% avant d’ajouter des blocages fins.
Outils et journaux à connaître
| Outil | But | Commande/Accès |
|---|---|---|
| gpresult / RSOP | Voir les GPO appliquées et la « Winning Policy » | gpresult /h C:\Temp\rsop.html |
| Event Viewer – AppLocker | Tracer autorisations/refus (événements 800x) | Applications and Services Logs → Microsoft → Windows → AppLocker |
| AppIDSvc | Service requis pour l’évaluation AppLocker | Get-Service AppIDSvc |
| PowerShell AppLocker | Exporter la politique effective | Get-AppLockerPolicy -Effective -Xml |
| SRP (Registre) | Vérifier les règles machine/utilisateur | HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers |
| WDAC (artefacts) | Détecter une politique Code Integrity | %windir%\System32\CodeIntegrity\SIPolicy.p7b |
Comparatif SRP, AppLocker, WDAC
| Critère | SRP | AppLocker | WDAC |
|---|---|---|---|
| Objectif | Contrôler l’exécution via règles simples (hérité) | Contrôle applicatif avancé (éditeurs, chemins, hash, UWP) | Contrôle en profondeur (noyau), sécurité maximale |
| Précédence | Ignoré si AppLocker/WDAC actif | Prend la main sur SRP | Prend la main sur AppLocker et SRP |
| Dépendances | Aucune service dédiée | Application Identity requis | Politique Code Integrity (p7b/CI) |
| Cas d’usage | Environnements anciens, besoins simples | Windows 10/11, granularité, UWP | Hardening strict, postes à haute sensibilité |
Procédure pas‑à‑pas de correction
Identifier le GPO conflictuel
- Sur une machine affectée :
gpresult /scope computer /vpour lister les GPO appliqués. - Dans la console Group Policy Management : inspecter chaque GPO contenant un nœud AppLocker (Exe, Script, MSI, Packaged apps, DLL).
- Noter le filtrage de sécurité et les WMI filters : la présence de « Tout le monde » est un indicateur fort.
Neutraliser l’impact AppLocker
- Désactiver temporairement le GPO AppLocker, ou définir Enforcement sur Audit only.
- Redémarrer le service Application Identity (ou redémarrer le poste) pour réévaluer les politiques.
- Vérifier que SRP reprend la main (test d’exécution et absence de nouveaux événements AppLocker).
Corriger durablement
- Si AppLocker est la cible stratégique : retirer SRP et consolider AppLocker (règles par défaut, listes d’autorisation, exceptions par groupes AD).
- Si SRP doit rester en production : retirer le GPO AppLocker ou en limiter l’étendue à des groupes pilotes non soumis à SRP.
- Éviter Tout le monde : créer un groupe AD Scope‑AppLocker‑Pilote et y affecter des machines/tests.
Exemples de règles et de scripts
Créer des règles AppLocker par défaut
# Console AppLocker > Exécutable > Créer des règles par défaut
# (Autorise %WINDIR% et %ProgramFiles%, plus les fichiers signés par Microsoft)
Détecter en PowerShell la co‑présence SRP/AppLocker/WDAC
$report = [ordered]@{}
$report['AppLockerEffective'] = -not [string]::IsNullOrWhiteSpace((Get-AppLockerPolicy -Effective -Xml 2>$null))
$report['AppIDSvc'] = (Get-Service AppIDSvc -ErrorAction SilentlyContinue).Status
$report['SRP_Machine_Key'] = Test-Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers'
$report['WDAC_SIPolicy'] = Test-Path "$env:windir\System32\CodeIntegrity\SIPolicy.p7b"
$report['WDAC_CI_Active'] = Test-Path "$env:windir\System32\CodeIntegrity\CiPolicies\Active"
$report | Format-List
Points d’appui pour SRP
- Règles par chemin, hash, zone Internet.
- Utiliser les règles supplémentaires pour désigner des éditeurs de confiance via certificats si applicable.
- Protéger l’accès d’écriture aux répertoires d’exécution (ex. %ProgramFiles%, %WINDIR%).
Scénarios fréquents et résolution
Les apps Microsoft Store s’exécutent malgré SRP
Les Packaged apps (UWP) sont gérées nativement par AppLocker/WDAC, pas par SRP. Si un GPO AppLocker existe, il s’applique ; sinon, SRP ne voit pas ces apps. D’où une impression de « SRP cassé ».
SRP fonctionne pour certains utilisateurs mais pas d’autres
Vérifier : héritage GPO, sécurité de filtrage, groupes AD, OU, priorité de liens. Un GPO AppLocker ciblant un sous‑groupe peut « doubler » SRP localement.
gpresult affiche SRP « Winning », mais rien n’est bloqué
Comportement attendu si AppLocker/WDAC est actif : l’interface Resultant Set of Policy ne signale pas toujours la préemption. Les journaux AppLocker sont l’indicateur le plus fiable.
Méthode d’audit express
- Exporter
gpresult /h. - Ouvrir l’Observateur d’événements sur les canaux AppLocker (chercher les 800x).
- Vérifier
Get-AppLockerPolicy -Effective. - Confirmer l’absence/présence de
SIPolicy.p7b(WDAC). - Décider : conserver AppLocker/WDAC OU conserver SRP (pas les deux).
Plan de migration SRP → AppLocker/WDAC
- Inventorier les exécutables réellement utilisés (journaux SRP/AppLocker, télémétrie).
- Basculer en Audit AppLocker/WDAC sur un périmètre pilote.
- Construire une politique « autoriser par défaut » (éditeurs Microsoft, chemins système), puis affiner.
- Élargir par vagues, documentation, communication utilisateurs.
- Décommissionner SRP une fois l’équivalence atteinte.
Résumé exécutable
- Symptôme : SRP visible comme « Winning Policy » mais non appliquée pour la majorité des utilisateurs.
- Cause : un GPO AppLocker actif (souvent filtré « Tout le monde ») préempte SRP.
- Fix : désactiver/ajuster AppLocker (réduire l’étendue, activer les règles par défaut, ou migrer totalement vers AppLocker/WDAC). Après retrait du conflit, SRP refonctionne immédiatement.
Annexes : commandes et extraits prêts à l’emploi
Forcer l’application des GPO
gpupdate /force
shutdown /r /t 0 # si nécessaire après modification AppIDSvc
Exporter les clés SRP pour audit
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" C:\Temp\SRP_Machine.reg /y
reg export "HKCU\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers" C:\Temp\SRP_User.reg /y
Vérifier la politique AppLocker par catégories
(Get-AppLockerPolicy -Effective).RuleCollections | Select-Object Name, EnforcementMode
Points de contrôle GPO
- Ordre de liens (LSDOU) et paramètres de liaisons.
- Filtres WMI : s’appliquent‑ils réellement aux machines ciblées ?
- Groupes de sécurité : éviter « Tout le monde », préférer des groupes d’affectation explicites.
Conclusion
Ce cas illustre un piège classique : AppLocker actif = SRP neutralisé. La bonne approche consiste à choisir un seul moteur de contrôle d’exécution sur un périmètre donné, à documenter ses dépendances (service Application Identity pour AppLocker, politique Code Integrity pour WDAC) et à valider l’effet via les journaux. En supprimant ou corrigeant le GPO AppLocker fautif, les restrictions SRP ont été rétablies immédiatement, sans autre changement. Si votre cible est Windows 10/11, anticipez une migration vers AppLocker ou WDAC pour bénéficier d’un contrôle plus fin et d’une meilleure compatibilité avec les applications modernes, tout en conservant une trajectoire claire et auditée.
FAQ
Pourquoi gpresult montre SRP « Winning » si AppLocker gagne réellement ?
Parce que gpresult/RSOP reflète l’état des paramètres GPO, pas le moteur d’exécution qui tranche in fine. Quand AppLocker est actif, ses décisions prévalent sans que SRP soit explicitement marqué comme « désactivé ».
Faut‑il désinstaller SRP si l’on adopte AppLocker ?
Pas nécessairement, mais il faut retirer les GPO SRP de l’étendue où AppLocker/WDAC s’applique, pour éviter les ambiguïtés et simplifier la maintenance.
Comment tester sans impacter la production ?
Créer un groupe pilote, lier le GPO AppLocker en Audit only, surveiller les événements, ajuster, puis élargir graduellement.