Un administrador descubre que un técnico junior puede crear y modificar objetos en Active Directory Users and Computers (ADUC) inmediatamente después de instalar RSAT. El siguiente artículo explica por qué ocurre, dónde buscar los permisos heredados y cómo restaurar un modelo de delegación seguro.

Contexto del problema

RSAT no otorga privilegios por sí mismo; solo instala las consolas de administración. El comportamiento inesperado de edición siempre se debe a permisos ya existentes en las listas de control de acceso (ACL) de Active Directory. La clave es identificar de dónde provienen esos permisos —grupo directo, grupo anidado, delegación previa o herencia— y neutralizarlos sin interrumpir el servicio.

Diagnóstico rápido: la ruta más corta a la respuesta

Antes de perderse en miles de objetos, siga esta secuencia:

1. Abra ADUC, elija el dominio u OU sospechosa y navegue a Propiedades → Seguridad → Avanzado → Acceso efectivo.
2. Seleccione la cuenta junior y tome nota de los permisos que muestra como Concedido.
3. En la misma ventana revise la columna De dónde (Inherited From) para ver si la autorización proviene de la propia OU, de un contenedor superior o de un grupo.
4. Use PowerShell o dsacls para confirmar membresías y delegaciones.
5. Aplique correcciones mínimas pero efectivas: retirar al usuario del grupo, ajustar la ACL o desactivar la herencia.

Tabla de pasos y acciones recomendadas

Paso	Qué verificar	Acción recomendada
Revisar “Acceso efectivo”	En la pestaña Acceso efectivo seleccione la cuenta problemática para ver las ACL reales sobre el dominio u OU.	Anote los permisos de “Crear, eliminar o administrar objetos” que aparezcan.
Comprobar pertenencia a grupos	Compruebe pertenencias directas e indirectas a grupos con privilegios elevados (Domain Admins, Account Operators, “Help Desk”, etc.).	Quite la membresía innecesaria o cree un grupo específico con permisos restringidos.
Analizar herencia de permisos	Una ACL permisiva en una OU superior se hereda por defecto.	Use la vista Permisos avanzados para localizar la OU origen y desmarque “Heredar” o ajuste la ACL del contenedor padre.
Delegaciones existentes	Revise el asistente Delegar control… que pudo haberse usado sobre el dominio u OU.	Elimine la delegación o modifique la tarea delegada para el grupo afectado.
Activar auditoría	Habilite las GPO “Audit Directory Service Changes” y “Audit Directory Service Access”.	Supervise los eventos 4662 y 4670 para saber quién modifica objetos o permisos.

Verificar el acceso efectivo en ADUC

La pestaña Acceso efectivo es el punto de inicio más directo. AD consultará todas las ACL aplicables —incluidas las heredadas— y mostrará el resultado consolidado. Detalles clave:

• Si un permiso aparece marcado en negrita, significa que se concede de forma implícita por un grupo o herencia, no por una entrada explícita.
• Revise la columna De dónde. Si indica “None”, es una ACE directa sobre el objeto; si muestra una OU, busque la ACL en ese contenedor.
• Exportar el resultado con Get-ADPermission -Identity <DN> | Format-List facilita comparaciones.

Confirmar pertenencia a grupos privilegiados

Hasta un dominio aparentemente bien controlado suele albergar grupos anidados que heredan privilegios de manera casi invisible. Para descartarlo:

Import-Module ActiveDirectory
Get-ADPrincipalGroupMembership <SamAccountName> |
  Select-Object -ExpandProperty Name

Si emerge una pertenencia sospechosa (p. ej. a Account Operators):

1. Compruebe con el propietario del proceso si esa pertenencia es realmente necesaria.
2. Sustituya el grupo privilegiado por otro sin permisos inherentes y delegue allí los derechos mínimos.
3. Documente la excepción y dé seguimiento en un registro de cambios.

Analizar herencia de permisos en OU y contenedores

En AD cada contenedor puede propagar sus ACL a todos los objetos hijos. Aunque resulte tentador “cortar” la herencia, hágalo con precaución porque:

• Los objetos existentes retendrán las ACE heredadas, a menos que limpie la lista durante la ruptura.
• Los cambios masivos pueden impedir la aplicación homogénea de GPO.
• Una estructura demasiado granular complica el mantenimiento diario.

Utilice dsacls "OU=Soporte,DC=contoso,DC=local" para obtener una vista recursiva y -h para incluir las ACE heredadas. Compare con un entorno de referencia o un backup reciente.

Inspeccionar delegaciones de control ya existentes

El asistente Delegar control… graba ACE explícitas que muchas veces pasan desapercibidas. Pasos para auditar:

1. Abra el asistente en modo lectura (DelegationWizard.exe /v) y recorra las tareas asignadas.
2. Busque ACE que contengan SELF o “This object and all descendant objects”, pues son las más permisivas.
3. Reduzca el ámbito de All descendant objects a las clases estrictamente necesarias, por ejemplo user o computer.
4. Para deshacer delegaciones masivas, capture primero las ACE con dsacls y revise el impacto en un entorno de pruebas.

Auditar cambios y acceso a objetos de directorio

Aunque encuentre el origen de los permisos, conviene activar auditoría para prevenir futuros incidentes. Configure una GPO con:

• Audit Directory Service Changes = Éxito y error.
• Audit Directory Service Access = Éxito y error.

Los ID de evento relevantes son:

ID	Descripción	Uso práctico
4662	Una operación intentó modificar un objeto.	Detectar quién creó, borró o cambió propiedades.
4670	Se modificó la ACL de un objeto.	Alertar ante asignaciones de permisos inesperadas.

Centralice los logs en un SIEM o, al menos, en un servidor de registros dedicado para correlar eventos entre controladores de dominio.

Herramientas y comandos recomendados

• DSACLS: exporta e importa ACL de forma masiva. Ideal para baseline.
• PowerShell AD Module: Get-Acl, Set-Acl, Get-ADPermission, Remove-ADPermission.
• Active Directory Administrative Center (ADAC): interfaz moderna con una pestaña Effective Access más intuitiva que ADUC.
• Microsoft Security Compliance Toolkit: plantillas y scripts para comparar la configuración real con la deseada.
• Gráficos de BloodHound: identificación visual de rutas de privilegios y memberships anidadas.
• PowerShell JEA (Just Enough Administration): expone cmdlets restringidos para tareas de help desk sin necesidad de acceso total a ADUC.

Diseño de un modelo de delegación robusto

Para entornos con cientos de OUs y miles de usuarios, improvisar delegaciones conduce a una “ensalada” de permisos imposible de mantener. Se recomienda:

1. Clasificación por funciones ⇢ OU por función: separe help desks de campus, administradores de servidores y equipos de desarrollo.
2. Modelo RACI o equivalente: identifique Responsable, Aprobador, Consultado e Informado para cada clase de objeto.
3. Grupos anidados: asigne privilegios a un grupo de rol y haga que los usuarios sean miembros de ese rol, nunca de Domain Admins directamente.
4. Documentación viva: registre cada delegación con fecha, motivo y aprobación.
5. Revisión semestral: audite membresías y ACE para detectar “creep” de privilegios.

Buenas prácticas preventivas

• Apoye cualquier cambio de ACL con un change ticket aprobado.
• Sustituya el acceso GUI por cmdlets cuando sea posible; los scripts se documentan solos y son versionables.
• Use controladores de dominio dedicados para tareas de administración masiva y limite el inicio de sesión interactivo.
• Aplique el principio de privilegio mínimo: menos es más, incluso para administradores sénior.
• Adopte LAPS o Windows LAPS para contraseñas locales de equipos; así evita escalar privilegios desde cuentas locales.
• Considere implementar un PAM (Privileged Access Management) de Microsoft o de terceros para aislación completa de cuentas AD administrativas.
• Eduque al personal: un curso rápido sobre herencia de ACL y delegación evita errores costosos.

Conclusión

Un usuario con permisos inesperados en ADUC es la “luz roja” de una delegación mal gestionada. Siguiendo los pasos descritos —verificar Acceso efectivo, revisar grupos, inspeccionar herencia, auditar delegaciones y habilitar registros— es posible identificar la causa raíz y restablecer la seguridad sin afectar la productividad. Con un modelo de delegación bien documentado y auditorías periódicas, podrá prevenir que incidentes así vuelvan a repetirse, manteniendo la administración de Active Directory bajo control y con el mínimo acceso necesario.