AppLocker provoca pantalla negra tras reiniciar en Windows Server 2016: causas, recuperación y GPO correcta

Tras activar AppLocker en modo Enforced en Windows Server 2016, algunos equipos pueden quedarse en pantalla negra con cursor tras reiniciar. Aquí tienes un plan probado para recuperar el servidor, encontrar la causa y desplegar una directiva estable sin bloquear DLL críticas del sistema.

Índice

Síntomas y contexto

Escenario habitual reportado en laboratorio y pilotos:

  • Semanas en modo Audit only sin incidencias aparentes.
  • Se cambia la GPO de AppLocker a Enforced y se reinicia.
  • El inicio de sesión no llega a mostrarse: pantalla negra con cursor.
  • En el Visor de eventos aparecen cargas de DLL bloqueadas en rutas del sistema como %WINDIR% y %SYSTEM32%, pese a existir reglas de Allow “aparentemente” suficientes.
  • Para recuperar, se regresa a Audit only, se fuerza gpupdate y tras reiniciar el equipo inicia con normalidad.

Por qué ocurre

La causa más frecuente es una colección de DLL con reglas restrictivas, incompletas o con Deny que eclipsan Allow. Factores que suelen confluir:

  • Falta de cobertura de rutas del SO: no se incluyen carpetas como %WINDIR%\SysWOW64\ en sistemas x64, %WINDIR%\WinSxS\ (ensamblados side-by-side), %WINDIR%\SystemApps\* u otras subrutas necesarias.
  • Redirección WOW64: procesos de 32 bits cargan DLL desde SysWOW64. Si solo permites %WINDIR%\System32\*, no cubres las DLL de 32 bits.
  • Deny tiene prioridad: una regla Deny más específica invalida un Allow más general, aunque el Allow esté “arriba” visualmente.
  • Auditoría incompleta: la colección DLL quizá no estuvo realmente en Audit, o se revisaron solo EXE/MSI/Script. Resultado: no se registró lo que se habría bloqueado al forzar.
  • Ausencia de default rules o editor: sin reglas base y sin reglas por editor (Publisher) para Microsoft, aumenta el riesgo de bloquear componentes firmados del sistema.

Recuperación inmediata del servidor bloqueado

Objetivo: desactivar temporalmente AppLocker para poder iniciar sesión y corregir la GPO.

Desde otro equipo (remoto)

Si el equipo responde por red y puedes llegar al servicio de Control de Servicios (RPC):

sc \\NOMBRE_EQUIPO stop AppIDSvc
sc \\NOMBRE_EQUIPO config AppIDSvc start= disabled

Vuelve la GPO a Audit only, ejecuta:

gpupdate /target:computer /force
shutdown /r /t 0

Desde consola local o Modo Seguro

Inicia en Modo Seguro con funciones de red, abre una consola elevada y ejecuta:

sc stop AppIDSvc
sc config AppIDSvc start= disabled
gpupdate /target:computer /force
shutdown /r /t 0

Último recurso

Nota: Cambiar EnableLUA a 0 (desactivar UAC) puede ayudar a recuperar, pero no es una solución permanente. Reduce la seguridad y rompe componentes modernos. Evítalo salvo emergencia y revierte después.

Comando de emergencia (requiere reinicio):

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
/v EnableLUA /t REG_DWORD /d 0 /f

Ajustes de GPO para estabilizar AppLocker

Trabaja siempre en una OU de pruebas y sobre un conjunto controlado de servidores.

  • Ruta: Computer Configuration → Policies → Windows Settings → Security Settings → Application Control Policies → AppLocker.
  • En Configure rule enforcement:
    • Pon la colección DLL en Audit only mientras estabilizas la lista blanca.
    • Mantén EXE/MSI/Script según tu estrategia (idealmente con default rules y reglas por editor).
  • En cada colección (EXE, DLL, MSI, Script y Packaged apps si aplica), crea las reglas predeterminadas con Create Default Rules como base.
  • Configura el servicio Application Identity para arranque automático: sc config AppIDSvc start= auto sc start AppIDSvc

Reglas de permitir recomendadas para DLL

Usa primero reglas por ruta amplias que cubran el sistema, y completa con reglas por editor para Microsoft. Colócalas por encima de cualquier Deny y evita Deny salvo casos muy concretos.

ColecciónTipo de reglaÁmbito propuestoNotas de seguridad
DLLPath Allow%WINDIR%\*Cubre System32, WinSxS, SystemApps, WBEM, etc.
DLLPath Allow%WINDIR%\SysWOW64\*Obligatoria en x64 por WOW64. Evita bloquear DLL de 32 bits.
DLLPath Allow%PROGRAMFILES%\, %PROGRAMFILES(X86)%\Permite DLL de aplicaciones instaladas correctamente en Program Files.
DLLPublisher AllowFirma: Microsoft, todas las versionesReduce el riesgo de bloquear componentes del sistema firmados.
EXE/MSI/ScriptDefault rules + PublisherWindows y Program FilesComplementa con reglas por editor para tus ISV críticos.
Packaged appsPublisher AllowMicrosoft y apps permitidasSolo si usas aplicaciones modernas/Edge en el servidor.

Evitar conflictos con Deny

  • Usa Deny solo para excepciones puntuales. Recuerda que Deny más específico se impone sobre cualquier Allow.
  • Revisa que no existan Deny que afecten a %WINDIR%, System32, SysWOW64 o Program Files.
  • Prefiere Publisher sobre hash para binarios que se actualizan a menudo.

Cubrir variaciones 32/64 bits

En x64, un proceso de 32 bits verá %SYSTEM32% redirigido a SysWOW64. Si la regla solo cubre %WINDIR%\System32\, una DLL de 32 bits que se cargue desde SysWOW64 puede quedar bloqueada. Incluye explícitamente %WINDIR%\SysWOW64\ en Allow para la colección DLL.

Recolectar y resolver auditoría

Con DLL en Audit, reinicia y usa el Visor de eventos:

  • Applications and Services Logs → Microsoft → Windows → AppLocker → EXE and DLL y DLL.
  • Filtra eventos de “sería bloqueado” y toma nota de ruta, editor y proceso llamante.

Para consolidar en PowerShell:

# Eventos recientes de AppLocker (EXE y DLL)
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 2000 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Sort-Object TimeCreated -Descending |
  Out-File C:\Temp\AppLocker-EXE-DLL.log

Solo entradas con "would be blocked" (texto puede variar según idioma del SO)

Get-Content C:\Temp\AppLocker-EXE-DLL.log | Select-String -Pattern "would be blocked","sería bloqueado" |
Out-File C:\Temp\AppLocker-EXE-DLL-Resumen.log 

Validación previa a forzar

Antes de volver a Enforced, prueba la directiva contra rutas representativas:

# Exportar la directiva efectiva de la máquina de pruebas
$xml = "C:\Temp\AppLocker.xml"
Get-AppLockerPolicy -Effective | Out-File -FilePath $xml

Probar rutas críticas con la política exportada

Test-AppLockerPolicy -XmlPolicy \$xml -Path "C:\Windows\System32\svchost.exe" -User "DOMINIO\CuentaDeServicio"
Test-AppLockerPolicy -XmlPolicy \$xml -Path "C:\Windows\SysWOW64\msiexec.exe" -User "DOMINIO\Administrador" 

Si alguna prueba sale Denied, ajusta la regla de Allow correspondiente antes de forzar.

Procedimiento de despliegue recomendado

  1. Baselining: crea directivas con default rules en todas las colecciones.
  2. Modo auditoría: deja DLL en Audit y EXE/MSI/Script según tu política. Monitorea eventos al menos una semana con cargas típicas y reinicios.
  3. Cierre de brechas: añade Allow por ruta para %WINDIR%\, %WINDIR%\SysWOW64\, %PROGRAMFILES%\, %PROGRAMFILES(X86)%\, y Publisher para Microsoft/ISV clave.
  4. Piloto: aplica en una OU de pruebas con servidores representativos. Verifica inicio de sesión, servicios y tareas programadas.
  5. Enforced gradual: activa Enforced primero en EXE/MSI/Script; cuando la auditoría de DLL quede limpia, aplica Enforced en DLL.
  6. Operación: mantén un ciclo continuo de auditoría → ajuste → despliegue. Documenta cambios y versiones de reglas.

Comprobaciones rápidas

  • Aplicación de GPO: gpresult /r /scope computer para confirmar que la GPO correcta llega al servidor.
  • Servicio en automático: sc qc AppIDSvc y sc query AppIDSvc.
  • Subcarpetas: valida que las reglas por ruta incluyan subdirectorios, no solo archivos en la raíz.
  • Reglas por editor: prioriza Microsoft y fabricantes clave; evita reglas por hash salvo necesidad puntual.
  • Sin Deny conflictivos: elimina o reubica Deny que afecten a rutas del sistema.
  • Arquitectura: incluye SysWOW64 en x64.
  • Eventos de AppLocker: revisa y deja en cero los “would be blocked” antes de Enforced.

Tabla de diagnóstico

SíntomaProbable causaAcción
Pantalla negra tras forzarDLL del sistema bloqueadasRegresar DLL a Audit; añadir Allow para %WINDIR%\* y SysWOW64; revisar Deny.
Servicios que no inicianDLL o EXE del servicio sin coberturaPublisher para Microsoft/ISV; Allow en Program Files.
App de 32 bits falla en x64Falta %WINDIR%\SysWOW64\*Añadir Allow explícito a SysWOW64.
Eventos de auditoría vacíosAuditoría no habilitada en DLLPoner DLL en Audit y reiniciar; volver a verificar.

Ejemplo de política mínima funcional para DLL

Aplica en una OU de pruebas. Ajusta según tu entorno:

  • Allow por ruta:
    • %WINDIR%\*
    • %WINDIR%\SysWOW64\* (solo x64)
    • %PROGRAMFILES%\*
    • %PROGRAMFILES(X86)%\*
  • Allow por editor:
    • Firmante: Microsoft Corporation (todas las versiones)
    • ISV de agentes de seguridad/monitorización y backup instalados en tus servidores
  • Evitar Deny globales sobre %WINDIR% y Program Files.
  • Audit activo hasta vaciar eventos de “sería bloqueado”.

Buenas prácticas operativas

  • Versiona la GPO: etiquétala con fecha y cambios. Documenta reglas nuevas y motivos.
  • Prueba tras actualizaciones: parches de Windows y actualizaciones de agentes pueden introducir DLL nuevas.
  • Usa colecciones separadas por tipo (EXE, DLL, MSI, Script, Packaged) y mueve cada una a Enforced cuando su auditoría esté limpia.
  • Minimiza reglas por hash: se invalidan en cada actualización del archivo.
  • Automatiza la recolección de eventos y la generación de informes periódicos.

Errores comunes que debes evitar

  • Forzar la colección DLL sin haberla auditado de verdad.
  • Confiar en que %SYSTEM32% cubre DLL de 32 bits (no cubre SysWOW64).
  • Colocar Deny amplios sobre rutas del sistema.
  • Olvidar crear las default rules en cada colección.
  • Falta de pruebas con cuentas de servicio y tareas programadas.

Checklist antes de pasar a Enforced en DLL

  • La auditoría de DLL lleva al menos una semana sin “would be blocked”.
  • Existen Allow por ruta para %WINDIR%\, SysWOW64\ (x64), %PROGRAMFILES%\ y %PROGRAMFILES(X86)%\.
  • Existen reglas por editor para Microsoft y tus ISV clave.
  • No hay Deny conflictivos activos.
  • El servicio AppIDSvc está en Automatic y en ejecución.
  • Se ha validado con Test-AppLockerPolicy rutas críticas y cuentas de servicio.
  • Se ha probado en OU de piloto y documentado el resultado.

Resultado esperado

Con la colección DLL correctamente cubierta (incluida SysWOW64) y sin Deny conflictivos, el inicio de sesión no debe quedarse en negro al volver a Enforced. Mantén un ciclo auditoría → ajuste → piloto → despliegue para evitar bloquear componentes críticos del sistema operativo.

Recap express

  • Si ya estás en negro: deshabilita temporalmente AppLocker deteniendo AppIDSvc, vuelve la GPO a Audit only, fuerza gpupdate y reinicia.
  • Corrige la GPO: añade Allow amplios por ruta para Windows y Program Files (incluida SysWOW64), y Publisher para Microsoft; elimina Deny problemáticos.
  • Audita de nuevo y valida con PowerShell antes de forzar.

Comandos clave de referencia

:: Recuperación (remoto)
sc \\NOMBRE_EQUIPO stop AppIDSvc
sc \\NOMBRE_EQUIPO config AppIDSvc start= disabled

\:: Recuperación (local)
sc stop AppIDSvc
sc config AppIDSvc start= disabled
gpupdate /target\:computer /force
shutdown /r /t 0

\:: Servicio en automático
sc config AppIDSvc start= auto
sc start AppIDSvc

\:: Confirmar aplicación de GPO
gpresult /r /scope computer 
Índice