Partager via

Los permisos delegados sobre cuentas de usuarios en Directorio Activo se resetean para algunos usuarios automáticamente

  • Article

Hoy vamos a hablar de un viejo conocido de Directorio Activo pero que todavía está provocando muchos quebraderos de cabeza. Seguramente muchos de vosotros os habréis encontrado ya con este problema, pero para los que no, ahí va el post del día.

Imaginemos que se han establecido determinadas ACLs de seguridad sobre ciertos usuarios/grupos en Directorio Activo. Hasta ahí vamos bien y cabría esperar que dichas ACLs permanecieran tal y como las hemos establecido, ¿no? Pues imaginémonos ahora que, pasado cierto tiempo, las ACLs son restablecidas a su configuración original automáticamente para algunos usuarios/grupos. Y tantas veces como las volvamos a establecer, tantas veces que se resetean.

Bien, pues la causa de que se restablezcan los permisos sobre los usuarios o grupos de usuarios protegidos se debe a un mecanismo de protección de Directorio Activo que asegura que las ACLs se establecen correctamente a miembros de grupos sensibles. Este mecanismo se ejecuta cada hora en el PDC Emulator. Se compara la ACL sobre las cuentas de usuario que son miembros de grupos protegidos contra la ACL del siguiente objeto:  CN=AdminSDHolder,CN=System,DC=<MiDominio>,DC=<Com> . Si la ACL es diferente, la ACL sobre el objeto de usuario (o grupo) se sobrescribe para reflejar la configuración de seguridad del objeto AdminSDHolder y se deshabilita la herencia. Este proceso protege estas cuentas especiales para que no sean modificadas por usuarios no autorizados si las cuentas se mueven a un contenedor o Unidad Organizativa  donde se hayan delegado a un usuario malicioso credenciales administrativas para modificar cuentas de usuario.

Las cuentas que se consideran “especiales” o protegidas son las que pertenecen a los siguientes grupos:

  • Enterprise Admins
  • Schema Admins
  • Domain Admins
  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Cert Publishers

Adicionalmente, también se consideran protegidas las siguientes cuentas:

  • Administrator
  • Krbtgt

Este comportamiento se describe en el siguiente artículo:

817433 Delegated permissions are not available and inheritance is automatically disabled

Bien, y ahora ¿qué hacemos para resolver el problema?

En el propio artículo se explican las diferentes alternativas posibles para establecer los permisos deseados sobre usuarios/grupos que pertenezcan a grupos protegidos:

1. Sacar al usuario/grupo sobre el que se resetean los permisos de los grupos protegidos a los que pertenezca. Esta opción es la más recomendable, ya que entonces se establecerían los permisos deseados sobre una cuenta de usuario común y no sobre un usuario que pertenece a un grupo protegido (y sobre el que teóricamente y por razones de seguridad no deberíamos modificar los permisos).

2. Evitar que el proceso monitorice alguno de los grupos protegidos (únicamente se pueden excluir Account Operators, Server Operators, Print Operators y Backup Operators) dejándolos de esa manera “desprotegidos” del chequeo de las ACLs. Esta opción sería probablemente la más adecuada si fuera necesario asignar permisos para un usuario sobre otros usuarios que deben pertenecer a alguno de estos grupos protegidos, pero deben considerarse los riesgos que se van a tomar.

3. Modificar la ACL del contenedor AdminSDHolder para adecuarla a la configuración deseada sobre los usuarios miembros de grupos protegidos (se establecería esta configuración de seguridad para todos los usuarios/grupos pertenecientes a cualquiera de los grupos protegidos). En este caso, habría que tener en cuenta que el usuario al que estáis otorgando los permisos tendría esos permisos sobre todos los grupos/usuarios protegidos, con los riesgos que ello implica.

4. Habilitar la herencia en las propiedades del contenedor AdminSDHolder de tal manera que los usuarios que pertenezcan a cualquiera de estos grupos protegidos hereden la configuración de seguridad de los contenedores en los que estén ubicados (con todo lo que ello conlleva, ya que podrían establecerse permisos sobre estos objetos de usuario para otros usuarios a los que no se les quiere o no se les debería dar esta capacidad == un usuario del HelpDesk podría tener permiso para resetear la contraseña de un Domain Admin, por ejemplo).

Más información sobre AdminSDHolder:

“AdminSDHolder
The Administrator security descriptor holder protects administrative groups through a background task that computes the set of memberships and checks whether their security descriptors are well-known protected security descriptors. If the security descriptor of any administrative account does not match that of AdminSDHolder, the security descriptor is overwritten with the security descriptor of AdminSDHolder. This task is executed only on the domain controller that holds the primary domain controller (PDC) emulator operations master role.”

Espero que esta información os sirva de ayuda y os ahorre unas cuantas horas :)

- Paula Tomás Galed