DSACLS: cómo delegar correctamente Resultant Set of Policy (Logging) a grupos en Active Directory

Otorgar permisos “Generate Resultant Set of Policy (Logging)” mediante DSACLS es rápido, pero cuando se aplica a grupos puede resultar engañoso: la ACE parece correcta, sin embargo el menú RSoP continúa gris. En esta guía aprenderás por qué sucede y cómo solucionarlo de forma definitiva.

Contexto: DSACLS y la delegación granular en Active Directory

DSACLS es la navaja suiza en la línea de comandos para modificar listas de control de acceso (ACL) dentro de Active Directory. Con él podemos delegar tareas finas—por ejemplo, permitir que un rol de soporte ejecute Resultant Set of Policy (RSoP) en modo Logging sobre una Unidad Organizativa (OU)—sin conceder privilegios excesivos.

Para delegar el derecho se usa el Control de Acceso Extendido (Extended Right) identificado por el GUID 4c164200-20c0-11d0-a768-00aa006e0529. El comando habitual es:

dsacls.exe "ou=Disabled Computers,dc=domain,dc=local" /I:T ^
  /G "DOMAIN\RBAC‑Workstations‑Admin":CA;"Generate Resultant Set of Policy (Logging)"

Cuando el sujeto es un usuario individual, el cambio se refleja de inmediato. Sin embargo, al concederlo a un grupo, los invitados descubren que la opción sigue bloqueada.

El síntoma observable

• La ACE creada por DSACLS aparece en la pestaña Security » Advanced y coincide en todo con la que crea el asistente gráfico de delegación.
• Al abrir la consola de Usuarios y Equipos de Active Directory (ADUC) en un controlador de dominio diferente, el menú continua mostrando la opción “Resultant Set of Policy (Logging)” deshabilitada para los miembros del grupo.
• Si se asigna el mismo permiso al usuario directamente—o si se utiliza el asistente gráfico—funciona de inmediato.

Dónde está el problema

La causa está en la interacción de tres piezas básicas de la arquitectura de seguridad de Windows Server:

1. Replicación de Active Directory: la ACE se escribe en el DC que ejecuta DSACLS, pero tarda un intervalo de replicación en propagarse a los demás.
2. Token de seguridad del usuario: los derechos delegados a través de grupos solo se tienen en cuenta cuando el usuario obtiene un token nuevo (inicio de sesión o adquisición de nuevo TGT).
3. Herencia y precedencia de ACE: si existe una ACE de denegación, si la herencia está bloqueada o si se ha elegido un ámbito de grupo incorrecto, el derecho no llegará al objeto destino.

No hay un bug en DSACLS: la herramienta escribe la ACE exactamente igual que el asistente; el desafío es sincronizar los demás elementos.

Paso a paso para restaurar el acceso

Verificar replicación entre controladores de dominio

Primero confirma que la nueva ACE haya llegado a todos tus DC. Desde un símbolo de PowerShell con privilegios:

repadmin /replsummary

Si hay fallos, fuerza la operación:

repadmin /syncall /AdeP

Comando	¿Para qué sirve?
repadmin /replsummary	Detecta retrasos de replicación.
repadmin /syncall /AdeP	Sincroniza todo inmediatamente.

Actualizar el token de los miembros del grupo

Una vez que estés seguro de la replicación, cada afectado debe obtener un token limpio. La forma más fiable es cerrar sesión y volver a entrar. Si esto no es posible (servidores críticos, turnos 24 × 7), basta con purgar los tickets Kerberos:

klist purge
gpupdate /force

El primer comando obliga a descartar el TGT y, por tanto, reconstruir el token; el segundo actualiza directivas.

Comprobar herencia y ámbito de aplicación

Para que la ACE funcione, la herencia debe estar habilitada en la OU y la ACE debe aplicarse a “Este objeto y todos los objetos descendientes”. Revisa con:

dsacls "ou=Disabled Computers,dc=domain,dc=local"

Busca una línea similar a:

Allow DOMAIN\RBAC‑Workstations‑Admin
     GENERATE RSOP LOGGING

Asegúrate de que no haya una ACE de Deny con prioridad superior ni bloqueos de herencia en sub‑OUs.

Validar tipo y ámbito del grupo

Solo los grupos de tipo Security se incluyen en el token. Si se trata de un grupo Distribution, cambia el tipo:

Set-ADGroup "RBAC‑Workstations‑Admin" -GroupCategory Security

Respecto al ámbito: en un único dominio casi cualquier ámbito sirve. En entornos multidominio es más seguro delegar con grupos Domain Local (si la OU está en el mismo dominio) o Universal.

Recordar la limitación de la consola ADUC

ADUC solo refresca su vista cuando la vuelves a abrir contra el DC que contiene la copia actual de la base de datos. Cerrar y reabrir la consola o elegir un DC distinto con Change Domain Controller evita interpretaciones erróneas.

Comparar la ACE con herramientas de bajo nivel

Para tranquilidad absoluta usa ADSI Edit:

1. Conéctate a la ruta de la OU.
2. Abre Security » Advanced y localiza la ACE.
3. Confirma que el ObjectType sea {4c164200-20c0-11d0-a768-00aa006e0529} y que la casilla Apply to esté marcada para el objeto y sus descendientes.

Puedes exportar la ACL antes y después para comparar:

dsacls "ou=Disabled Computers,dc=domain,dc=local" > antes.txt
:: Aplica el permiso con el asistente
dsacls "ou=Disabled Computers,dc=domain,dc=local" > despues.txt
fc antes.txt despues.txt

Buenas prácticas para delegar RSoP de forma robusta

• Centraliza la delegación en grupos RBAC: evita asignar permisos a usuarios directos, lo que dificulta auditoría.
• Documenta los GUID de Extended Rights: mantén una hoja de referencia para cada derecho delegado.
• Incluye la revisión de replicación en tu checklist después de cualquier delegación masiva.
• Programa una tarea de auditoría que liste ACEs críticas semanalmente mediante PowerShell.
• No mezcles asistentes y línea de comandos cuando automatices, así mantienes un historial uniforme.

Preguntas frecuentes

¿Es mejor usar el asistente gráfico que DSACLS? Para operaciones puntuales sí, pero DSACLS o PowerShell son indispensables en automatizaciones.

¿Cuánto puede tardar la replicación? Depende del site link; en la misma sede suele bastar un par de minutos. Entre sitios con enlaces lentos puede retrasarse horas.

¿Por qué la ACE funciona al delegarla a usuarios pero no a grupos? Porque el token de un usuario incluye los SIDs de sus grupos en el momento del inicio de sesión. Si el grupo adquiere nuevos permisos después, es necesario renovarlo.

¿Puedo usar un grupo anidado? Sí, siempre que sea de tipo Security y la anidación no incrementa la complejidad de replicación.

¿Qué version de Windows Server necesito? DSACLS existe desde Windows 2000. El GUID del derecho RSoP es el mismo en todas las versiones.

Conclusión

Cuando DSACLS parece “fallar” al delegar “Generate Resultant Set of Policy (Logging)” a un grupo, en realidad está haciendo su trabajo. La clave para que los miembros del grupo vean el cambio radica en tres pasos: replica la ACE a todos los controladores de dominio, consigue que los usuarios obtengan un token actualizado y verifica herencia, tipo y ámbito del grupo. Siguiendo el procedimiento descrito, podrás delegar el derecho de RSoP con la confianza de que estará disponible a tiempo y sin concesiones indebidas de privilegios.