Filtrado de seguridad GPO MS16-072: restaurar Read y preservar el ámbito

¿Qué es el filtrado de seguridad GPO MS16-072?

El diagnóstico del filtrado de seguridad GPO MS16-072 empieza con dos preguntas distintas: ¿puede el equipo recuperar la directiva de usuario y tiene el usuario que ha iniciado sesión permiso para aplicarla? Una directiva destinada a un grupo reducido de usuarios puede dejar de funcionar cuando el equipo pierde el permiso Read. Restaurar un permiso Apply amplio puede hacer que la directiva funcione y, al mismo tiempo, cambiar sus destinatarios previstos.

El artículo de soporte MS16-072 de Microsoft documenta el cambio introducido el 14 de junio de 2016: Windows recupera las GPO de usuario mediante el contexto de seguridad del equipo, en lugar del contexto del usuario. La solución es conceder Read a Authenticated Users, o a Domain Computers cuando se utiliza el filtrado de seguridad. El boletín MS16-072 vincula la actualización al artículo 3163622 de Microsoft Knowledge Base; los paquetes de actualización instalables dependen de la versión de Windows. Es un cambio de procesamiento establecido, no un problema recién descubierto.

El objetivo práctico es restaurar la recuperación preservando los destinatarios previstos. La misma revisión debe distinguir las directivas que deben estar en producción de los pares AD/SYSVOL incompletos, las directivas deshabilitadas con vínculos activos, los objetos sin uso y las delegaciones cuestionables. Estos estados requieren decisiones diferentes; hacer que todas las directivas se apliquen no es un objetivo de remediación útil.

Funcionamiento: Read, Apply y ámbito de los vínculos

Las instrucciones actuales de diagnóstico de Microsoft explican por qué quitar Authenticated Users de Security Filtering puede romper las directivas de usuario: esa acción elimina tanto Read como Apply Group Policy. Un grupo de usuarios específico puede conservar sus permisos mientras la cuenta del equipo ya no puede recuperar la GPO.

Read añadido mediante la pestaña Delegation de GPMC es diferente de la entrada denominada Read (from Security Filtering). Esta última incluye Apply; Read por sí solo restaura la recuperación sin conceder ese derecho de aplicación. Mantenga el grupo de usuarios previsto en Security Filtering y conceda Read a la población de equipos adecuada mediante Delegation.

El filtrado de seguridad opera dentro de las ubicaciones alcanzadas por los vínculos de la GPO. La referencia sobre filtrado de seguridad de Microsoft explica que pertenecer a un grupo no introduce por sí solo a un usuario fuera de ámbito en un sitio, dominio u OU vinculados. Añadir Apply amplio puede ampliar los destinatarios dentro del ámbito de los vínculos aplicables; no aplica automáticamente la GPO a todo el dominio. Esta página histórica explica los mecanismos del filtrado y debe leerse junto con las instrucciones actuales sobre Read para los equipos.

La documentación sobre procesamiento de directivas de grupo de Microsoft describe otras condiciones: secciones deshabilitadas, filtros WMI y procesamiento de bucle invertido. Merge añade la lista de directivas de usuario basada en el equipo después de la lista del usuario; Replace utiliza en su lugar la lista basada en el equipo. Registre el modo real antes de interpretar un resultado. Para el bucle invertido Merge, el artículo de soporte MS16-072 indica específicamente que se añadan los usuarios y equipos previstos en Scope > Security Filtering. Valide por separado esa configuración específica; la corrección general de Read para equipos descrita arriba no es una receta completa de bucle invertido.

Cadena de fallo y directivas que requieren revisión

Una secuencia habitual de fallo es sencilla: un administrador restringe una GPO de usuario a un grupo de negocio, elimina Authenticated Users y después descubre que faltan los ajustes de usuario en los equipos pertinentes. El grupo objetivo sigue pareciendo correcto. La dependencia que falta es Read para los equipos. Volver a añadir Authenticated Users a Security Filtering puede ocultar esa dependencia al restaurar tanto Read como Apply.

Microsoft documenta como síntoma el fallo de aplicación de la directiva de usuario; su ejemplo de diagnóstico incluye un error en el informe de resultados. No suponga que este fallo siempre es silencioso ni considere cada ajuste ausente como prueba de un problema de permisos MS16-072.

Otros estados de GPO merecen una decisión independiente antes de vincularlos o reactivarlos:

• Incoherencia AD/SYSVOL: compruebe el objeto de directorio y los archivos correspondientes, la replicación y las copias de seguridad recuperables. Un hallazgo de objeto huérfano no justifica por sí solo restaurar la directiva para su uso ni eliminarla.
• Ambas secciones deshabilitadas, pero un vínculo habilitado: determine si se trata de mantenimiento deliberado o de un vínculo obsoleto. El hallazgo no significa que los ajustes deshabilitados se estén aplicando.
• Ningún vínculo inventariado: identifique un borrador, una directiva de reserva o un despliegue olvidado. La ausencia de vínculo es una señal de inventario, no una prueba de compromiso.
• Delegación cuestionable sobre directivas y vínculos: inspeccione los beneficiarios y objetos pertinentes. Un hallazgo de permisos no prueba que alguien haya insertado un vínculo malicioso.

Para la cuestión independiente de quién puede reescribir los ajustes, las malas configuraciones GPO como vector de ataque explican la exposición por derechos de edición de directivas y configuración débil. Para una OU privilegiada, las ACL débiles de GPO en Tier 0 explican por qué bloquear la herencia no protege los propios permisos de edición de la GPO vinculada. El acceso de lectura, el acceso de edición de directivas y el acceso de escritura de vínculos necesitan pruebas propias.

Detección: medir permisos y resultados reales

Empiece por una GPO afectada, identificada sin ambigüedad. El ejemplo 3 de la referencia Get-GPPermission de Microsoft proporciona este comando:

Get-GPPermission -Name "TestGPO" -All

Sustituya el nombre del ejemplo por la directiva real. El cmdlet informa de las entidades de seguridad que tienen permisos en esa GPO; no simula por completo el procesamiento de directivas. Si los nombres son ambiguos, utilice el GUID de la GPO. Las siguientes consultas individuales adaptan parámetros documentados:

Get-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group

Get-GPPermission -Name "TestGPO" -TargetName "GPO-Users-Cible" -TargetType Group

Utilice los nombres resueltos de su dominio. Compare Read para los equipos, el permiso Apply del grupo previsto y cualquier Apply amplio inesperado. Un resultado ausente o un error no es una comprobación de permisos satisfactoria. Inspeccione los permisos personalizados y las entradas Deny explícitas en lugar de inferir el acceso efectivo a partir de un nivel resumido.

Para el resultado del procesamiento, el ejemplo de diagnóstico de Microsoft utiliza:

gpresult /h gpresult.html

Ejecute una prueba de usuario positiva y otra negativa e inspeccione los informes generados. Conserve el equipo, el usuario, la identidad de la GPO, los vínculos pertinentes y cualquier error junto a cada resultado. La siguiente matriz de diagnóstico ayuda a mantener visibles las explicaciones alternativas:

Estos son comandos documentados y un procedimiento de validación propuesto. Aquí no se afirma disponer de resultados de pruebas AD ni de capturas de registros de eventos.

Remediación: restaurar Read sin ampliar Apply (Remediation)

1. Registrar los destinatarios previstos y el estado actual

Antes de cambiar permisos, conserve el estado de la directiva y establezca su propietario, usuarios objetivo, equipos de inicio de sesión, ámbito de los vínculos y modo de procesamiento. Determine qué población de equipos necesita Read. Authenticated Users, Domain Computers o un grupo de equipos adecuado son opciones que evaluar frente a esa población; compruebe Deny explícito por separado.

2. Conceder Read a los equipos mediante Delegation

En GPMC, abra la pestaña Delegation de la GPO afectada, seleccione Add, elija el grupo u objeto de equipo, seleccione Read y confirme. Mantenga Apply en el grupo de usuarios previsto. La página de diagnóstico de Microsoft documenta esta vía y la distinción resultante entre Read por sí solo y Read procedente de Security Filtering.

Para una vista previa de PowerShell, este ejemplo utiliza parámetros de la documentación Set-GPPermission de Microsoft:

Set-GPPermission -Name "TestGPO" -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead -WhatIf

-WhatIf muestra una vista previa de la operación; no aplica el cambio. Utilice la GPO y el beneficiario reales, revise la vista previa y realice el cambio aprobado sobre una sola directiva mediante el procedimiento elegido.

3. Corregir una concesión accidental de Apply amplio

Si Authenticated Users solo debe leer esta GPO específica, previsualice la sustitución de su nivel de permisos actual:

Set-GPPermission -Name "TestGPO" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel GpoRead -Replace -WhatIf

La documentación indica que un nivel de permisos existente superior permanece sin cambios salvo que se utilice -Replace. Por tanto, solicitar únicamente GpoRead puede dejar vigente una concesión Apply existente. La sustitución solo es adecuada tras confirmar que la entidad de seguridad debe perder su permiso superior en esta GPO. Preserve el permiso Apply del grupo objetivo y el estado registrado para revertir el cambio.

4. Validar la aplicación y resolver los hallazgos de inventario

Repita las mediciones de permisos y ambas pruebas de usuario. Compruebe la aplicación esperada, la exclusión de usuarios ajenos al grupo objetivo y las condiciones de procesamiento pertinentes. Para los objetos huérfanos, valide ambos componentes de almacenamiento antes de restaurarlos o retirarlos. Para las directivas deshabilitadas pero vinculadas, confirme la intención y elimine vínculos obsoletos cuando corresponda; no reactive los ajustes automáticamente. Revise las concesiones cuestionables con su propietario, incluidos los derechos de escritura de vínculos independientemente de los permisos del contenedor de directivas.

Cómo detecta EtcSec estos problemas

Las siguientes descripciones reflejan siete implementaciones Detect() revisadas en etc-collector, commit c38a5bb9d0d847a56980c8ba02c7b0169abbc69f. Describen señales de configuración, no siete ataques demostrados ni una prueba ejecutada sobre este entorno.

Comprobaciones de filtrado

GPO_AUTHENTICATED_USERS_APPLY selecciona GPO con un vínculo habilitado y una entrada ACL de Authenticated Users que contiene el bit Apply. El adaptador LDAP asocia ese bit con el derecho extendido pertinente; Microsoft documenta Apply Group Policy como el derecho utilizado para determinar la aplicación. El propio Detect() no rechaza entradas Deny ni calcula el acceso efectivo, evalúa WMI o comprueba secciones deshabilitadas. Una configuración base intencionadamente amplia puede generar legítimamente una señal de revisión.

GPO_NO_SECURITY_FILTERING busca GPO vinculadas y habilitadas con Apply para Everyone o Authenticated Users y ningún otro beneficiario específico de Apply, excluyendo Domain Computers de esa prueba de beneficiario específico. Un grupo específico no anula una concesión Apply amplia, por lo que el detector puede pasar por alto una ampliación cuando ambas coexisten. Tampoco calcula el acceso efectivo ni el estado de las secciones. Estas dos comprobaciones se solapan y deben revisarse como una sola cuestión de filtrado, en lugar de contarse como pruebas independientes de exposición.

Ninguno de los dos predicados establece que falte Read para los equipos. Utilice las mediciones de permisos y las pruebas de procesamiento anteriores para diagnosticar MS16-072.

Comprobaciones de inventario

GPO_ORPHANED consume los hallazgos SYSVOL suministrados de tipo orphaned_ldap u orphaned_sysvol. Si no se devuelve un hallazgo de objeto huérfano coincidente, su mecanismo alternativo LDAP señala una ruta de archivo vacía o un objeto con DisplayName y CN vacíos. Ese mecanismo puede ejecutarse incluso cuando se han suministrado otros hallazgos SYSVOL. Un objeto LDAP completo cuya carpeta SYSVOL haya desaparecido puede eludir ese mecanismo. Registre si se suministraron pruebas SYSVOL; no es un detector de un gPLink que haga referencia a una GPO inexistente.

GPO_DISABLED_BUT_LINKED exige Flags = 3, que significa que ambas secciones están deshabilitadas, y un vínculo habilitado. Identifica un estado del inventario que explicar, no ajustes deshabilitados que se estén aplicando.

GPO_UNLINKED encuentra GPO sin ningún vínculo inventariado, incluye los vínculos deshabilitados en el conjunto de GPO vinculadas y excluye los dos GUID de GPO predeterminados. No significa lo mismo que un vínculo deshabilitado, secciones deshabilitadas o un objeto huérfano AD/SYSVOL. Revise el ciclo de vida y la intención antes de vincular o retirar el objeto.

Comprobaciones de delegación

GPO_MODIFY_RIGHTS comprueba la pertenencia directa o resuelta mediante el grupo primario a Group Policy Creator Owners, identificado por RID 520. No sigue la pertenencia anidada. La referencia sobre identificadores de seguridad de Microsoft describe la capacidad del grupo para crear GPO y la propiedad de los nuevos objetos por su creador. La pertenencia por sí sola no demuestra derechos de edición en todas las GPO existentes ni permiso para vincularlas. Revise los miembros y las directivas y delegaciones que poseen.

GPO_LINK_POISONING selecciona ACE de concesión cuyo DN de objeto contiene CN=Policies,CN=System y cuya máscara incluye GenericAll, GenericWrite o WriteDACL. El propio Detect() no excluye administradores, inspecciona la ACL de cada GPO, establece acceso de escritura al gPLink de una OU ni identifica un vínculo malicioso existente. Su Count representa objetos distintos; TotalInstances puede incluir varias ACE. Valide el beneficiario y la delegación y después inspeccione por separado los permisos de vínculos del sitio, dominio u OU pertinentes. La documentación sobre ámbito de Microsoft sitúa gPLink en esos objetos y su procedimiento de delegación gestiona allí los permisos Link GPOs.