¿Tu Software Restriction Policy (SRP) dejó de bloquear aplicaciones de un día para otro aunque el GPO sigue apareciendo como correcto en gpresult? A continuación encontrarás un caso real, la causa raíz y un procedimiento exhaustivo para restablecer la restricción de software sin reinstalar ni formatear el equipo.
Resumen del problema
Un administrador tenía una SRP que prohibía la ejecución de software no autorizado. El GPO continuaba figurando como “Winning Policy” en las herramientas de diagnóstico de directivas, sin embargo los usuarios podían ejecutar cualquier archivo EXE o MSI. La duda era doble: ¿por qué SRP se había desactivado “en silencio” y qué directivas pueden provocar este comportamiento?
Entendiendo la interacción entre SRP y AppLocker
Desde Windows 7/Server 2008 R2, AppLocker se introduce como evolución de SRP y, por diseño, goza de una prioridad más alta. El motor de control de aplicaciones aplica la siguiente lógica:
- Si el servicio Application Identity está iniciado y existen reglas válidas de AppLocker en el mismo contexto de seguridad, se detiene la evaluación de SRP.
- El sistema no avisa al usuario ni al administrador; simplemente ignora las reglas SRP.
En el caso analizado, el departamento de seguridad había añadido un GPO con reglas AppLocker para bloquear “bloatware” preinstalado (Xbox, Camera, 3D Viewer, etc.). Esa pequeña modificación fue suficiente para invalidar la SRP corporativa.
Diagnóstico paso a paso
Para llegar a la causa se siguió la secuencia siguiente:
- Confirmar la vigencia de la SRP: con
gpresult /H srp.htmlse comprobó que la SRP seguía apareciendo como la política ganadora. - Revisar AppLocker via Event Viewer: en Event Viewer → Applications and Services Logs → Microsoft → Windows → AppLocker aparecían eventos 8002, 8003 y 8004 indicando bloqueos recientes.
- Comprobar el estado del servicio Application Identity: el servicio estaba en modo Automático e iniciado, requisito imprescindible para que AppLocker se active.
- Filtrar las GPO por palabra clave “AppLocker”: se encontró un nuevo GPO vinculado al mismo OU que contenía reglas de tipo Packaged app.
- Revisar registros SRP: en Event Viewer → Security no se hallaron eventos 865, 866 ni 868 en el periodo de fallo, corroborando que el motor SRP no se estaba ejecutando.
Tabla comparativa SRP vs AppLocker
| Característica | Software Restriction Policies | AppLocker |
|---|---|---|
| Introducido en | Windows XP / Server 2003 | Windows 7 / Server 2008 R2 |
| Tipos de reglas | Hash, Ruta, Certificado, Zona de Internet | Editor, Ruta, Hash, Paquete (“Modern apps”) |
| Servicio requerido | No | Application Identity |
| Auditoría granular | Básica (eventos 865‑868) | Avanzada (eventos 8001‑8007) |
| Prioridad de evaluación | Anulada si AppLocker activo | Se evalúa antes que SRP |
Solución aplicada
- Deshabilitar o mover las reglas AppLocker conflictivas.
- Se editó el GPO “Bloqueo bloatware” y se eliminó la acción Deny para las aplicaciones afectadas.
- Alternativamente, la organización puede mover las reglas AppLocker a un GPO diferente vinculado a equipos piloto o a otro OU.
- Forzar la actualización de directivas con
gpupdate /force. - Reiniciar el equipo para asegurar que el servicio Application Identity reinicia y SRP se vuelva a evaluar.
- Verificar la solución:
- Intentar ejecutar un EXE previamente bloqueado por SRP; debe rechazarse con el clásico mensaje “Esta publicación está bloqueada…”.
- Comprobar en
gpresult /Rque la SRP continúa como política ganadora y que no hay reglas AppLocker activas. - Observar eventos 865, 866 o 868 recién generados en el visor de eventos de Seguridad.
Buenas prácticas para evitar conflictos futuros
- Usar un solo mecanismo por cada segmento de la organización: implementar SRP en estaciones heredadas y AppLocker en equipos modernos, pero no ambos a la vez sobre los mismos objetos de usuario o equipo.
- Documentar cada cambio de GPO indicando qué servicio de control de aplicaciones se activa, fecha, responsable y justificación.
- Activar auditoría antes de aplicar bloqueos: tanto SRP como AppLocker permiten registrar acciones en modo Audit Only, ideal para detectar falsos positivos.
- Automatizar el reinicio del servicio Application Identity cuando se modifiquen reglas AppLocker, evitando estados incoherentes.
- Supervisar eventos críticos con una herramienta SIEM filtrando:
- SRP → Id. 865 (MPMP policypath is being evaluated), 866 (apply policy), 868 (rule applied).
- AppLocker → Id. 8002 (executable denied), 8003 (dll denied), 8004 (appx denied).
- Revisar plantillas administrativas tras cada Patch Tuesday: algunas builds renuevan el contenido de Windows Components → AppLocker y pueden habilitar reglas por defecto.
Preguntas frecuentes
¿Puedo forzar a que SRP tenga prioridad sobre AppLocker?
No. El orden de precedencia está codificado en el sistema operativo. Si existen reglas AppLocker válidas para el usuario o equipo y el servicio Application Identity está iniciado, SRP se ignora.
¿Qué ocurre si simplemente detengo el servicio Application Identity?
Detener el servicio devuelve el control a SRP pero también deja al equipo sin la protección avanzada de AppLocker. Además, Windows Update o un reinicio pueden reactivarlo; no es una solución permanente.
¿SRP y AppLocker comparten los mismos logs?
No. SRP escribe en el registro Security, mientras que AppLocker utiliza un registro dedicado bajo Applications and Services Logs → AppLocker.
¿Las reglas de AppLocker de tipo Auditoría también deshabilitan SRP?
Sí. Cualquier regla válida —sea “Allow”, “Deny” o solo auditoría— provoca que Windows utilice el motor AppLocker y deje de evaluar SRP.
Conclusión
La coexistencia de SRP y AppLocker puede causar confusión si no se conoce su jerarquía interna. En entornos donde SRP se utiliza para bloquear software no autorizado, la introducción inadvertida de una sola regla AppLocker basta para desactivar todo el sistema de restricciones heredado. Mantén un único motor de control de aplicaciones por cada grupo de usuarios y audita cualquier nuevo GPO que pueda alterar esa estabilidad. Siguiendo los pasos de diagnóstico y las buenas prácticas descritas, podrás restaurar rápidamente la seguridad y evitar interrupciones inesperadas en el futuro.