Un changement d’AppLocker du mode Audit au mode Application sur Windows Server 2016 peut se solder par un redémarrage bloqué sur un écran noir avec simple curseur. Découvrez comment analyser la cause, rétablir l’accès et déployer des règles sécurisées sans paralyser vos serveurs.
Problème rencontré
- Passage d’AppLocker en mode Application.
- Redémarrage ⇒ écran noir avec curseur, aucune session utilisable.
- Retour en mode Audit, exécution de
gpupdate /forceet redémarrage ⇒ la machine redevient opérationnelle. - Journaux « AppLocker » : plusieurs DLL bloquées dans %WINDIR% et %SYSTEM32% alors qu’une règle “Système” était supposée les autoriser.
Pourquoi l’écran noir apparaît‑il ?
Au démarrage, le service AppIDSvc applique instantanément les règles de restriction logicielle ; si l’une d’elles empêche le chargement d’une DLL critique (par exemple LogonUI.dll ou Winlogon.exe), la séquence d’ouverture de session s’interrompt. Les symptômes :
- Écran noir : l’interface graphique échoue avant l’apparition de la boîte de connexion.
- Aucun message d’erreur visible, car la couche graphique elle‑même n’est pas encore démarrée.
- Événements 800X / 802X dans le journal « Microsoft‑Windows‑AppLocker/EXE & DLL » listant les fichiers bloqués.
Causes fréquentes recensées
| Cause | Détail |
|---|---|
| Règles DLL incomplètes | Des fichiers essentiels n’entrent dans aucune règle Publisher, Path ou Hash ; AppLocker les bloque par défaut. |
| Interopérabilité UAC | Sur Server 2016, AppLocker dépend toujours de la clé EnableLUA. Un conflit UAC + AppLocker peut empêcher le lancement de Winlogon. |
Évaluation anticipée de AppIDSvc | Le service démarre très tôt ; une erreur avant l’init de la session graphique provoque un black‑screen silencieux. |
Analyse des événements AppLocker
- Démarrez en mode sans échec + Invite de commandes ou via WinPE.
- Ouvrez
eventvwr.mscou exportez le journal :wevtutil epl Microsoft-Windows-AppLocker/EXE\_and\_DLL C:\Logs\AppLocker.evtx - Repérez les ID : 8004 (exécutions bloquées) et 8007 (DLL bloquées).
- Filtrez par Path commençant par
%SystemRoot%ou%WinDir%. - Listez les signatures numériques absentes :
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" |
Where-Object {$_.Id -eq 8007} |
Select TimeCreated, @{n='DLL';e={$_.Properties[6].Value}}, @{n='Rule';e={$_.Properties[9].Value}} |
Export-Csv C:\Logs\DLL_bloquees.csv -NoTypeInformation
Plan de remédiation pas à pas
Désactiver temporairement AppLocker
Depuis une session distante (ou WinPE), stoppez et désactivez le service :
sc \\<Serveur> stop AppIDSvc
sc \\<Serveur> config AppIDSvc start= disabledRedémarrez. La GUI réapparaît ; réactivez l’accès administrateur.
Neutraliser UAC pour le test
Dans regedit :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLUA = 0
Redémarrez ; si l’écran noir persiste, le souci vient essentiellement des règles AppLocker.
Réinitialiser (ou créer) les règles par défaut
Depuis l’Éditeur de stratégie locale (gpedit.msc) :
- Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Contrôle des applications AppLocker.
- Pour chaque nœud (Executable, Windows Installer, Script, DLL) clic droit : Create Default Rules.
- Une règle par Publisher autorise tous les fichiers signés Microsoft dans
%WINDIR%. - Une règle par Path autorise
%ProgramFiles%et%System32%.
Étendre la règle Publisher Microsoft
Les correctifs de sécurité mensuels peuvent introduire de nouvelles familles de certificats Microsoft. Créez une règle Publisher couvrant l’éditeur « Microsoft Windows » sans restreindre la version :
New-AppLockerPolicy -Publisher "*Microsoft Windows*" -RuleType Publisher -Category EXE,DLL -User "Everyone"Valider en mode Audit pendant 48 h
Passez l’ensemble des règles en mode Audit Only :
Set-AppLockerPolicy -PolicyObject (Get-AppLockerPolicy -Local) -RuleStatus NotConfiguredLaissez la stratégie vivre deux cycles de redémarrage et surveillez l’absence d’événements 8004/8007 avant de revenir en mode Application.
Script de pré‑contrôle avant activation
Automatisez une vérification des binaires système :
$critical = @("winlogon.exe","logonui.exe","explorer.exe","lsass.exe")
foreach ($file in $critical) {
if (-not (Test-AppLockerPolicy -Path "$env:windir\system32\$file" -User "NT AUTHORITY\SYSTEM").Allowed) {
Write-Warning "$file bloqué ! Règle manquante."
}
}Bonnes pratiques pour éviter un nouvel écran noir
- Priorisez les règles Publisher sur les règles Path ; elles suivent les mises à jour et réclament moins de maintenance.
- Maintenez UAC activé (valeur 1) ; AppLocker est officiellement supporté uniquement avec UAC en place.
- Documentez les changements : exportez toujours la stratégie courante avant modification :
Get-AppLockerPolicy -Effective | Export-AppLockerPolicy C:\Backup\Applocker.xml - Surveillez les journaux : configurez une alerte Event ID 8004/8007 dans votre solution SIEM.
- Dépannez sur un clone ou un « sandbox » Hyper‑V avant de déployer en production.
Comparatif rapide : AppLocker vs WDAC
| Critère | AppLocker (Server 2016) | WDAC (Server 2022+) |
|---|---|---|
| Dépendance UAC | Oui | Non |
| Niveau de sécurité | Contrôle applicatif utilisateur/processus | Contrôle du kernel ; blocage pré‑boot |
| Facilité de configuration | Élevée (console MMC) | Moyenne (PowerShell + politiques CSP) |
| Flexibilité des règles | Publisher, Path, Hash | Catalogues de fichiers, Signatures ; plus granulaire |
| Scénario recommandé | Serveurs existants jusqu’à 2019 | Nouveaux environnements Zero Trust |
Conclusion
Le basculement d’AppLocker en mode Application sans couverture exhaustive des DLL système entraîne souvent l’infâme écran noir. Suivez une méthodologie structurée : désactivation temporaire, collecte des journaux, création des règles par défaut, extension des règles Publisher Microsoft puis validation longue en Audit. Vous pourrez réactiver AppLocker sereinement et renforcer la posture de sécurité de vos serveurs Windows Server 2016 sans compromettre leur disponibilité.