Windows Server 2016: schermo nero dopo AppLocker in Enforced – cause, fix e best practice

Schermo (quasi) nero su Windows Server 2016 (o client collegati) subito dopo aver portato AppLocker da “Audit” a “Enforced”? Questa guida pratica spiega perché accade, come ripristinare rapidamente le macchine bloccate e come riattivare l’enforcement in modo sicuro, evitando nuovi falsi positivi su DLL di sistema.

Indice

Panoramica del problema

Dopo settimane di monitoraggio in Audit Mode, la GPO di AppLocker viene impostata su Enforced. Al primo riavvio, alcuni endpoint (server o client) mostrano una schermata nera con il solo cursore del mouse. I log di AppLocker evidenziano il blocco di numerose DLL sotto %WINDIR% e %SYSTEM32%, pur in presenza di regole che dovrebbero consentirne l’esecuzione. Il risultato: sessioni che non caricano la shell (es. explorer.exe) o processi critici che falliscono a causa di librerie dinamiche negate.

Perché succede

Regole DLL troppo restrittive o mal configurate – Le DLL non ereditano automaticamente le eccezioni delle regole EXE. Se la collezione “DLL” viene messa in Enforced senza regole di base sufficienti (o con una regola per %WINDIR% che non include correttamente le sottocartelle), molte librerie legittime risultano bloccate.
Assenza o rimozione delle “Default Rules” – Le regole predefinite fornite da Microsoft coprono i binari di sistema e gli amministratori locali. Senza di esse, è facile impedire il caricamento di componenti vitali.
Regole basate solo su hash – Gli aggiornamenti Windows (e side-by-side in WinSxS) cambiano hash molto frequentemente. Senza regole Publisher o Path, gli aggiornamenti rompono l’allineamento.
Interazioni con UAC – In alcuni ambienti la combinazione di UAC abilitato e regole DLL aggressive peggiora il percorso di elevazione/avvio di processi di sistema, amplificando i blocchi.

Sintomi tipici

Schermata nera post-logon con solo cursore.
Impossibilità di aprire Task Manager o prompt elevati.
Eventi di AppLocker che riportano “file negato” sotto %WINDIR%, %SYSTEM32%, %SYSWOW64%, %ProgramFiles% e %WINDIR%\WinSxS.

Soluzioni e contromisure rapide

Le azioni seguenti consentono di recuperare subito le macchine bloccate e di prevenire futuri incidenti. La tabella riassume il piano, seguito dalla procedura passo‑passo.

Azione	Scopo	Note operative	Comandi rapidi
Disattivare temporaneamente UAC `EnableLUA = 0`	Esclude l’interazione UAC↔AppLocker e consente il boot per correggere la policy.	Richiede riavvio; re‑impostare a 1 appena sistemate le regole. Impatto sulla sicurezza e su app UWP.	`reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^ /v EnableLUA /t REG_DWORD /d 0 /f shutdown /r /t 0`
Fermare/Disabilitare il servizio Application Identity (`AppIDSvc`)	Arresta l’enforcement di AppLocker e sblocca subito la macchina.	Eseguibile da remoto (es. strumenti RMM) o via PS Remoting; poi correggere la GPO.	`sc \<PC> stop AppIDSvc sc \<PC> config AppIDSvc start= disabled` `# PowerShell Invoke-Command -ComputerName <PC> -ScriptBlock { Stop-Service AppIDSvc -Force Set-Service AppIDSvc -StartupType Disabled }`
Ampliare le regole sulle DLL	Evita blocchi futuri, coprendo binari di sistema e aggiornamenti.	Aggiungere/ripristinare le Default Rules. Verificare che la regola `%WINDIR%\` includa sottocartelle (`System32`, `SysWOW64`, `WinSxS`). Preferire Publisher* o Path agli hash.	`# Console GPMC/Local SecPol: tasto destro su ogni "Rule Collection" → Create Default Rules (EXE, DLL, MSI, Script, Packaged apps)`
Analisi automatica dei log	Individuare DLL/EXE legittimi mancanti dalle regole.	Generare eccezioni mirate partendo dagli eventi di blocco, poi consolidare.	`# PowerShell (locale) $ev = Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" $blocked = $ev \| Where-Object { $_.Message -match "blocked\|denied" } $paths = $blocked \| ForEach-Object { if ($_.Message -match "Path:\s+(.*)") { $Matches[1].Trim() } } \| Sort-Object -Unique $fi = Get-AppLockerFileInformation -Path $paths -ErrorAction SilentlyContinue New-AppLockerPolicy -FileInformation $fi -RuleType DLL -User 'Everyone' -RuleNamePrefix 'Recovered' -Optimize -Merge`
Ri‑abilitare l’enforcement a step	Riduce il rischio di nuovi blocchi critici.	Prima EXE/MSI, poi SCRIPT, infine DLL, sempre validando i log fra un passaggio e l’altro.	`# Strategia GPO: 1) EXE/MSI: Enforced 2) Script: Audit → Enforced dopo verifica 3) DLL: Audit → Enforced solo quando i log sono “puliti”`

Procedure passo‑passo di ripristino

Recupero rapido via servizio AppIDSvc (consigliato)

Da una macchina di amministrazione con connettività verso il PC bloccato, eseguire: sc \\NOMEPC stop AppIDSvc sc \\NOMEPC config AppIDSvc start= disabled
Forzare l’aggiornamento GPO o riavviare. La macchina tornerà operativa senza l’enforcement di AppLocker.
Correggere le regole (vedi capitolo successivo) e, quando pronto, riattivare: sc \\NOMEPC config AppIDSvc start= auto sc \\NOMEPC start AppIDSvc

Recupero via UAC (workaround d’emergenza)

Applicare temporaneamente: reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableLUA /t REG_DWORD /d 0 /f shutdown /r /t 0
Rientrare nel sistema, correggere la policy AppLocker, quindi ripristinare: reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableLUA /t REG_DWORD /d 1 /f shutdown /r /t 0

Nota: disabilitare UAC riduce la sicurezza ed impatta app UWP/Modern. Usare solo per sbloccare, poi ripristinare.

Se l’host è completamente irraggiungibile

Modalità provvisoria con Prompt: disabilitare AppIDSvc, riavviare, correggere GPO.
Offline registry: da WinRE, usare regedit, montare l’hive di sistema e impostare EnableLUA=0 o forzare il tipo di avvio di AppIDSvc su Disabled.

Correzione delle regole AppLocker (senza più sorprese)

Ripristinare le Default Rules

Aprire la console GPO o la Local Security Policy e, per ciascuna collezione (Executable, Windows Installer, Script, Packaged app & installer, DLL), fare clic destro → Create Default Rules. Queste regole:

Consentono l’esecuzione ai membri di Administrators.
Consentono i file firmati da Microsoft nelle cartelle di sistema.
Stabiliscono un baseline sicuro per EXE/MSI/Script/APPX e DLL.

Regola per `%WINDIR%` e sottocartelle

Assicurarsi che esista una regola Path del tipo %WINDIR%\* con Include subfolders selezionato. Verificare copertura di %WINDIR%\System32, %WINDIR%\SysWOW64 e %WINDIR%\WinSxS. In ambienti particolarmente rigidi, si possono creare regole dedicate:

%WINDIR%\System32\*
%WINDIR%\SysWOW64\*
%WINDIR%\WinSxS\*

Valutare eccezioni (cartelle temporanee, percorsi non di sistema) come deny espliciti, se necessario, ma solo dopo avere validato i log.

Preferire Publisher o Path agli hash

Le regole basate su hash sono fragili: ogni aggiornamento di sistema genera nuovi hash e quindi nuovi falsi positivi. Quando possibile:

Usare Publisher per file firmati (Microsoft, vendors affidabili).
Usare Path per directory controllate e di sola scrittura amministrativa.
Riservare gli hash a binari isolati, raramente aggiornati.

Generare regole partendo dai log

Esempio di pipeline PowerShell per estrarre i file bloccati e produrre regole provvisorie per poi consolidarle:

# Eseguire sul PC affetto (o via remoting)
$from = (Get-Date).AddDays(-7)   # finestra temporale
$filter = @{ LogName='Microsoft-Windows-AppLocker/EXE and DLL'; StartTime=$from }
$events = Get-WinEvent -FilterHashtable $filter | Where-Object { $_.Message -match 'block|deny' }

$paths = foreach ($e in $events) {
if ($e.Message -match 'Path:\s+(.*)') { $Matches[1].Trim() }
}
$paths = $paths | Where-Object { Test-Path $_ } | Sort-Object -Unique

Creare informazioni file e regole (DLL/EXE) per Everyone (provvisorie!)

$fi = Get-AppLockerFileInformation -Path $paths -ErrorAction SilentlyContinue
New-AppLockerPolicy -FileInformation $fi -RuleType DLL,Exe -User 'Everyone' `
-RuleNamePrefix 'RecoveredFromLogs' -Optimize -Merge

Esportare la policy per revisione

(Get-AppLockerPolicy -Local).ToXml() | Out-File C:\Temp\AppLocker-AfterMerge.xml

Consiglio: usare queste regole come base di revisione, poi convertire dove possibile in regole Publisher o Path più generali e manutenibili.

Reintrodurre l’enforcement senza rischi

Fase 1 – EXE/MSI: Enforced
Monitorare 24–72 ore. I log devono essere “puliti” (pochi o zero blocchi inattesi).
Fase 2 – Script: Audit → Enforced
Analizzare i blocchi di .ps1, .vbs, .cmd. Autorizzare solo ciò che serve.
Fase 3 – DLL: Audit → Enforced
Attendere di aver coperto %WINDIR%, System32, SysWOW64, WinSxS e i percorsi applicativi aziendali. Passare a Enforced quando i blocchi residui sono noti e giustificati.

Verifiche e diagnostica mirata

Controllo servizio – Get-Service AppIDSvc: lo stato deve essere Running quando l’enforcement è attivo.
Forzare GPO – gpupdate /force (Computer & User). Verificare l’applicazione con gpresult /r /scope computer.
Esportare/ordinare i log – Usare wevtutil epl o PowerShell per centralizzare e analizzare offline.
Test “a freddo” – Prima di mettere Enforced su DLL, simulare l’avvio con RDP su macchine di test e utenti non admin.

Buone pratiche supplementari

Ambiente di test separato – Validare su un gruppo pilota (diversi profili utente, software eterogeneo).
GPO di “rollback” – Mantenere una GPO in Audit con link/priorità pronta all’uso per disinnescare rapidamente problemi in produzione.
Monitoraggio continuo – Attivare la raccolta centralizzata dei log AppLocker (Event Forwarding/SIEM) con alert su “denied”.
Change management – Allineare AppLocker a patching e rilasci: ogni change può introdurre nuove DLL.
Documentazione – Conservare l’export XML delle policy approvate e versionarlo (Git, repository IT).

Checklist operativa

Ho le Default Rules attive per tutte le collezioni (EXE, DLL, MSI, Script, Packaged)?
La regola %WINDIR%\* include tutte le sottocartelle critiche (System32, SysWOW64, WinSxS)?
Ho convertito gli hash in regole Publisher/Path dove possibile?
Ho esaminato i log di blocco degli ultimi 7–14 giorni e generato le eccezioni necessarie?
Sto reintroducendo l’enforcement a step (EXE/MSI → Script → DLL)?
Ho pronta una GPO di rollback e uno script di emergenza per AppIDSvc?

Playbook di emergenza (riuso rapido)

:: 1) Fermare enforcement AppLocker su PC bloccato
sc \\%PC% stop AppIDSvc
sc \\%PC% config AppIDSvc start= disabled

:: 2) (Opzionale) Disattivare UAC (solo sblocco)
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
/v EnableLUA /t REG_DWORD /d 0 /f
shutdown /r /t 0

:: 3) Ripristinare Default Rules e regole Path/Pubblicatore per %WINDIR%*, System32, SysWOW64, WinSxS

:: 4) Analizzare eventi di blocco e generare eccezioni mirate (PowerShell)

:: 5) Riattivare AppIDSvc, reimpostare UAC a 1 e riavviare
sc \%PC% config AppIDSvc start= auto
sc \%PC% start AppIDSvc
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
/v EnableLUA /t REG_DWORD /d 1 /f
shutdown /r /t 0

FAQ rapide

Serve davvero usare le regole DLL?
Sì, ma solo quando si ha piena visibilità. Le DLL estendono il controllo oltre gli eseguibili e intercettano tecniche di DLL search order hijacking. Tuttavia sono la parte più delicata della policy: vanno introdotte per ultime, dopo un audit accurato.

Perché con %WINDIR%\* continuano i blocchi?
Nella pratica possono mancare sotto‑percorsi (es. WinSxS) o la regola non è realmente applicata alla collezione DLL. Verificare Include subfolders e l’effettiva presenza della regola nella raccolta giusta.

Posso lasciare AppIDSvc disabilitato?
No: AppLocker richiede AppIDSvc in esecuzione per applicare le regole. Disabilitarlo è solo un mezzo di sblocco; poi va riattivato.

È meglio usare “Allow by default, block per eccezione” o il contrario?
AppLocker è pensato per un modello deny by default ben disegnato, ma in molti ambienti si inizia con un approccio ibrido: baseline permissiva (Default Rules + cartelle di sistema) e restrizioni mirate per ridurre i rischi di blocchi critici.

Esempi di policy minimali “sicure” per iniziare

Obiettivo: impostare un baseline robusto ma non bloccante, da irrigidire progressivamente.

Executable: Default Rules + Publisher per software standardizzato + Path in %ProgramFiles% e %ProgramFiles(x86)%.
Windows Installer: Default Rules + solo pacchetti firmati o provenienti da share approvati (regole Path).
Script: Audit per 1–2 cicli di patch; poi Enforced consentendo solo script firmati o in share controllati.
Packaged apps: Default Rules (se usate app UWP).
DLL: Audit con copertura completa %WINDIR%, System32, SysWOW64, WinSxS e cartelle applicative; Enforced solo dopo report “verde”.

Monitoraggio continuo: cosa guardare nei log

Picchi di “denied” dopo patch o nuove release.
Blocchi ricorrenti su percorsi di sistema: segno che le regole Path non coprono tutte le directory.
Utenti/host specifici che collezionano più errori: indizio di software non standard.

# Esempio export CSV per dashboard
$from=(Get-Date).AddDays(-14)
$evt=Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppLocker/EXE and DLL'; StartTime=$from}
$evt | Select-Object TimeCreated, ProviderName, Id, MachineName, Message |
 Export-Csv C:\Temp\AppLocker-EXE-DLL.csv -NoTypeInformation

Errori comuni da evitare

Saltare l’Audit sulle DLL: è la causa principale di schermate nere.
Rimuovere le Default Rules pensando di “irrobustire” la sicurezza.
Affidarsi solo a hash per pacchetti soggetti ad aggiornamenti.
Non testare con utenti non amministratori durante il pilota.

Conclusioni

La combinazione “AppLocker in Enforced + regole DLL inadeguate” può produrre l’effetto collaterale del black screen post‑logon. Con un playbook di emergenza (stop AppIDSvc o UAC temporaneo), la reintroduzione controllata dell’enforcement e la copertura sistematica di %WINDIR%, System32, SysWOW64 e WinSxS, si riportano rapidamente online i dispositivi e si costruisce una policy sostenibile, riducendo falsi positivi e mantenendo alto il livello di sicurezza.

Appendice A – Script PowerShell “tutto in uno” (raccolta e regole provvisorie)

# Eseguire come amministratore sul PC target (o via Invoke-Command)
1) Raccogli eventi di blocco EXE/DLL degli ultimi 7 giorni
$from=(Get-Date).AddDays(-7)
$flt=@{LogName='Microsoft-Windows-AppLocker/EXE and DLL'; StartTime=$from}
$denied=Get-WinEvent -FilterHashtable $flt | Where-Object { $_.Message -match 'block|deny' }

2) Estrarre percorsi file dai messaggi

$paths = foreach($e in $denied){
if($e.Message -match 'Path:\s+(.*)'){ $Matches[1].Trim() }
}
$paths = $paths | Where-Object { $ -and (Test-Path $) } | Sort-Object -Unique

3) Creare informazioni file e generare regole provvisorie per Everyone

$fi = Get-AppLockerFileInformation -Path $paths -ErrorAction SilentlyContinue
New-AppLockerPolicy -FileInformation $fi -RuleType Exe,Dll -User 'Everyone' `
-RuleNamePrefix 'FromDeniedLogs' -Optimize -Merge

4) Suggerimento: Convertire poi queste regole in Path/Publisher e rimuovere gli hash

Write-Host "Regole provvisorie generate. Rivedere e consolidare."

Appendice B – Riattivazione controllata del servizio AppIDSvc via GPO

In GPMC → GPO di ripristino → Computer Configuration > Preferences > Control Panel Settings > Services.
Aggiungere Application Identity (AppIDSvc) con Startup type: Automatic e Service action: Start service.
Collegare la GPO all’OU interessata, forzare gpupdate e verificare.

Con queste misure è possibile riportare rapidamente online i computer bloccati, eliminare i falsi positivi su DLL di sistema e riattivare in sicurezza l’enforcement di AppLocker.