Delegar los permisos en la cuenta que inicia Kontivo

1. Por qué una cuenta delegada

Kontivo actúa en el directorio con la cuenta de Windows que lo inicia. Una cuenta «Admins. del dominio» funciona, pero un error de manipulación tendría entonces permisos sobre todo el dominio. Una cuenta delegada solo tiene permisos sobre las tres carpetas (OU) elegidas en la configuración: la carpeta de los usuarios, la carpeta de las cuentas dadas de baja y la carpeta de los grupos del directorio. Incluso en caso de error, no puede tocar nada más.

La herramienta no necesita ningún permiso de administrador en el equipo: solo escucha en el propio equipo (dirección 127.0.0.1) y guarda sus datos en C:\ProgramData\ComptesAD, que un usuario puede crear.

2. Crear la cuenta y su grupo

Conceda los permisos a un grupo y, después, ponga la cuenta en ese grupo: podrá cambiar de cuenta sin rehacer la delegación. En los ejemplos, el dominio se llama DEMO (demo.local):

• un grupo de seguridad global, por ejemplo GG-ComptesAD;
• una cuenta de usuario, por ejemplo adm-comptes, miembro de ese grupo, con una contraseña larga, guardada fuera de las carpetas de los usuarios gestionados;
• esta cuenta no debe ser miembro de ningún grupo de administración.

En los comandos siguientes, sustituya los nombres de las OU por los de su directorio (los ejemplos usan los nombres propuestos por la herramienta, Personas, Bajas y Grupos, dentro de una OU primaria Organizacion):

OU de los usuarios               OU=Personas,OU=Organizacion,DC=demo,DC=local
OU de las cuentas dadas de baja  OU=Bajas,OU=Organizacion,DC=demo,DC=local
OU de los grupos                 OU=Grupos,OU=Organizacion,DC=demo,DC=local

Cree primero estas tres OU (con «Usuarios y equipos de Active Directory», o en la configuración de la herramienta con una cuenta que tenga permiso para ello): la cuenta delegada no puede crear una OU fuera de la carpeta de los usuarios.

3. Los permisos, carpeta por carpeta

Mover una cuenta (cambio de grupo, baja, regreso) requiere «eliminar» sobre la propia cuenta y «crear objetos secundarios» sobre la OU de destino. El permiso «eliminar» sobre los usuarios de la OU de los usuarios es necesario: cuando las OU de grupo creadas por la herramienta están protegidas contra la eliminación accidental, esta protección aplica a su OU primaria una denegación de «eliminar objetos secundarios», que impediría mover una cuenta guardada directamente en la OU de los usuarios (usuario pendiente de grupo).

Las OU de grupo creadas por la cuenta delegada

La herramienta crea cada OU de grupo en dos tiempos: primero la OU, sin protección, y después, en un paso separado, la protección contra la eliminación accidental. Aplicar esta protección modifica los permisos de la OU de los usuarios (la denegación descrita más arriba), algo que la delegación de este documento no permite. Si falta el permiso, la OU se crea de todos modos y la operación es correcta, con esta nota en el registro: «OU creada, sin protección contra la eliminación accidental (falta el permiso «cambiar permisos» en la OU primaria): un administrador puede aplicarla en Usuarios y equipos de Active Directory (pestaña Objeto de la OU).» Después hay dos formas de proceder:

• dejar las OU de grupo sin protección (solo contienen cuentas de usuarios gestionadas, y la herramienta las vuelve a crear si es necesario), o protegerlas manualmente con una cuenta de administrador;
• o conceder al grupo delegado «Modificar permisos» solo sobre la OU de los usuarios (no sobre sus sub-OU), lo que es un permiso amplio que conviene valorar con el administrador del dominio:

  dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /G "DEMO\GG-ComptesAD:WD"

La primera pasada en una OU de prueba (manual, § 6) muestra cuál de los dos casos se produce en su directorio.

Para todo lo demás, la herramienta se limita a leer, con los permisos de lectura que cualquier cuenta del dominio tiene de forma predeterminada: la lista de los nombres de usuario del dominio (para evitar duplicados), las directivas de contraseñas, los controladores.

4. Conceder los permisos con dsacls

dsacls se instala con las herramientas de Active Directory (RSAT) y en los controladores de dominio. Escriba estos comandos en un símbolo del sistema abierto con una cuenta «Admins. del dominio». /I:T aplica el permiso a la OU y a todo lo que contiene; /I:S, solo a los objetos que contiene.

OU de los usuarios

dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;user"
dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CC;organizationalUnit"
dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;user"
dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:SD;;user"
dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:CA;Reset Password;user"

OU de las cuentas dadas de baja

dsacls "OU=Bajas,OU=Organizacion,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;user"
dsacls "OU=Bajas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;user"
dsacls "OU=Bajas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:SD;;user"

Solo si una eliminación falla con el error 8213 («La cuenta contiene objetos»):

dsacls "OU=Bajas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:DT;;user"

OU de los grupos

dsacls "OU=Grupos,OU=Organizacion,DC=demo,DC=local" /I:T /G "DEMO\GG-ComptesAD:CCDC;group"
dsacls "OU=Grupos,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:RPWP;;group"

Opcional: quitar la protección contra la eliminación accidental

Solo si desea utilizar la opción «Quitar la protección» (configuración, recuadro «Opciones avanzadas», o botón de la vista previa):

dsacls "OU=Personas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"
dsacls "OU=Bajas,OU=Organizacion,DC=demo,DC=local" /I:S /G "DEMO\GG-ComptesAD:WD;;user"

5. Conceder los permisos con el Asistente para delegación de control

En «Usuarios y equipos de Active Directory», clic con el botón derecho en la OU, Delegar control..., agregue el grupo GG-ComptesAD y, después, elija Crear una tarea personalizada para delegar. Las etiquetas siguientes pueden variar ligeramente según la versión de Windows.

OU de los usuarios (dos pasadas del asistente)

1. Primera pasada: Sólo los siguientes objetos en la carpeta, marque Objetos Usuario y, después, Crear los objetos seleccionados en esta carpeta y Eliminar los objetos seleccionados en esta carpeta. En la página siguiente, en General: Leer todas las propiedades, Escribir todas las propiedades, Eliminar, Restablecer contraseña.
2. Segunda pasada: Sólo los siguientes objetos en la carpeta, marque Objetos Unidad organizativa y Crear los objetos seleccionados en esta carpeta; en la página siguiente no se necesita ningún permiso más (marque Leer si es necesario).

OU de las cuentas dadas de baja

Una pasada, como la primera pasada de la OU de los usuarios, sin «Restablecer contraseña».

OU de los grupos

Una pasada: Objetos Grupo, crear y eliminar; permisos Leer todas las propiedades y Escribir todas las propiedades.

Después del asistente, compruebe el resultado: clic con el botón derecho en la OU, Propiedades, pestaña Seguridad, Opciones avanzadas (la pestaña Seguridad solo aparece con Ver > Características avanzadas). Los permisos sobre los usuarios deben aplicarse a «Objetos Usuario descendientes», y los de creación también a las sub-OU.

6. El recurso compartido de las carpetas particulares

Si se rellena un modelo de ruta en la configuración (por ejemplo, \\srv-fichiers\personas$\{sam}), la casilla «Crear la carpeta en el recurso compartido y conceder los permisos al usuario» queda marcada de oficio. Para cada usuario nuevo, la herramienta:

1. crea la carpeta \\srv-fichiers\personas$\lea.martin, si no existe (una carpeta existente nunca se modifica);
2. concede al usuario, por su SID, el permiso elegido sobre esa carpeta y su contenido: «Modificar» (de forma predeterminada) o «Control total»;
3. al eliminar definitivamente la cuenta, si se ha elegido el archivado, crea si es necesario \\srv-fichiers\personas$\_archives y cambia en ella el nombre de la carpeta (_archives\lea.martin_2027-10-05). No se borra nada, y los permisos de la carpeta no cambian.

Preparar el recurso compartido de una vez: ComptesAD.exe -PreparerPartage

El recurso compartido se prepara en el servidor de archivos (preferiblemente no en el controlador de dominio), una sola vez, por un administrador de ese servidor. Copie en él ComptesAD.exe (por ejemplo, en C:\ComptesAD) y, después, escriba, en un símbolo del sistema o una ventana de PowerShell abiertos como administrador:

C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\Personas -Partage personas$ -GroupeDelegue DEMO\GG-ComptesAD

Sin parámetros, una pequeña ventana pide la carpeta, el nombre del recurso compartido, el grupo delegado y, opcionalmente, el grupo de los usuarios, con un botón Comprobar (no se cambia nada) y un botón Preparar. La preparación hace, por este orden:

1. crea la carpeta D:\Personas si falta;
2. aplica los permisos NTFS de la raíz, deshabilitando la herencia del disco:
   • SYSTEM y Administradores: «Control total»;
   • el grupo delegado (GG-ComptesAD): «Modificar», en esta carpeta, subcarpetas y archivos;
   • los usuarios: «Atravesar carpeta» y «Mostrar carpeta», en solo esta carpeta, para llegar a su propia carpeta sin ver las de los demás. De forma predeterminada, «Usuarios autentificados»; agregue -GroupeEleves DEMO\Personas-Todas si los usuarios tienen su grupo;
   • CREATOR OWNER: nada.
   Cualquier otro permiso aplicado manualmente en la raíz se retira, y el informe lo menciona (la ventana pide confirmación antes);
3. crea el recurso compartido personas$ (el «$» lo oculta en el entorno de red) con estos permisos de recurso compartido: Administradores «Control total», Usuarios autentificados «Cambiar»; los permisos detallados siguen siendo los de NTFS. Si ya existe en esta carpeta, solo se corrigen sus permisos; si existe en otra carpeta, no se hace nada: elija otro nombre;
4. habilita la enumeración basada en el acceso: al abrir \\srv-fichiers\personas$, cada usuario solo ve su carpeta;
5. muestra el modelo que se debe pegar en la configuración de Kontivo, bloque «Carpeta particular», campo «Modelo de ruta de la carpeta»: \\srv-fichiers.demo.local\personas$\{sam} (nombre DNS completo del servidor).

Cada línea del informe empieza por [OK] (ya implantado), [FAIT], [A FAIRE] (solo en comprobación), [ATTENTION] o [REFUS]: la preparación puede volver a ejecutarse sin riesgo, y lo que ya está implantado nunca se rehace. Para solo comprobar, agregue -LectureSeule. En un script, el informe se escribe en la salida de errores (UTF-8) y el código de salida es 0 (listo), 1 (rechazo o error), 2 (parámetros) o 3 (comprobación: puntos que corregir).

Rechaza, sin cambiar nada: una cuenta sin privilegios de administrador activos en el servidor (abra el símbolo del sistema «como administrador»); una carpeta en una unidad de red o en un recurso compartido (ejecute la preparación en el servidor que aloja el disco, con su ruta local); la raíz de un disco o una carpeta de Windows; un nombre de recurso compartido no válido o reservado (C$, ADMIN$…); un grupo que no se encuentra (compruebe DOMINIO\nombre, y que el servidor es miembro del dominio); un grupo delegado demasiado amplio («Usuarios del dominio», «Usuarios autentificados»…): recibiría el permiso de modificar todas las carpetas de los usuarios.

Manualmente, si lo prefiere

Permisos que se deben conceder al grupo GG-ComptesAD:

• Permisos del recurso compartido: al menos «Cambiar» (o «Control total» para Todos, si gestiona los permisos únicamente con NTFS, lo que es habitual);
• Permisos NTFS sobre la carpeta raíz del recurso compartido: «Modificar», aplicado a «Esta carpeta, subcarpetas y archivos». En el servidor de archivos, por ejemplo:

icacls "D:\Personas" /grant "DEMO\GG-ComptesAD:(OI)(CI)M"

Si la herramienta indica «Carpeta creada, pero no se ha podido conceder el permiso al usuario», conceda además al grupo el permiso «Cambiar permisos» sobre la raíz y, después, conceda manualmente el permiso que falta al usuario afectado (la herramienta nunca modifica una carpeta que ya existe). Los permisos de los usuarios sobre la raíz siguen siendo los que usted haya fijado (en general: atravesar la carpeta, sin ver las de los demás); compruebe que no pueden entrar en _archives.

Si una directiva de grupo (redirección de carpetas) ya crea las carpetas de los usuarios, desmarque la casilla en la configuración: la herramienta solo rellenará entonces los atributos de la cuenta (ruta y letra de unidad), y no se necesita ningún permiso sobre el recurso compartido.

7. En el equipo

• La cuenta delegada debe poder iniciar sesión en el puesto de administración (es el caso de forma predeterminada para un usuario del dominio en una estación de trabajo; no lo es de forma predeterminada en un controlador de dominio).
• Debe poder leer la carpeta de la herramienta: inicie la herramienta una primera vez con esa cuenta, y haga que un administrador del equipo escriba el comando icacls que muestra, en un símbolo del sistema o una ventana de PowerShell abiertos como administrador (consulte el manual, § 3.3). La carpeta de datos que la herramienta crea entonces (C:\ProgramData\ComptesAD) pertenece a esa cuenta: una sola cuenta por carpeta de datos.
• No se necesita ningún permiso de administrador local para utilizar la herramienta, y no hay nada que instalar: RSAT ya no es necesario desde la versión 2. ComptesAD.exe se comunica con el directorio por LDAP firmado y cifrado (Kerberos o, en su defecto, NTLM), en el puerto 389 del controlador de dominio.

8. Comprobar

1. Inicie la herramienta con la cuenta delegada, en solo lectura: runas /user:DEMO\adm-comptes "C:\ComptesAD\ComptesAD.exe -LectureSeule".
2. En la configuración, paso 1, la comprobación debe mostrar «✓ Su cuenta puede crear cuentas en «Organizacion › Personas».», lo mismo para «Organizacion › Bajas», y «✓ Su cuenta puede crear grupos en «Organizacion › Grupos».» (se muestra la ruta completa de cada OU: compruebe que son realmente las OU delegadas, ya que la herramienta las ha rellenado previamente según su nombre).
3. La vista previa no debe mostrar «Su cuenta no puede crear cuentas en…».
4. En el servidor de archivos, C:\ComptesAD\ComptesAD.exe -PreparerPartage -Dossier D:\Personas -Partage personas$ -GroupeDelegue DEMO\GG-ComptesAD -LectureSeule debe terminar con «todo está ya implantado».
5. La primera aplicación real se hace en una OU de prueba, con algunas cuentas ficticias. El error «Permisos insuficientes» durante una aplicación indica el permiso que le falta a la operación afectada.

La herramienta no controla las sub-OU una por una: un permiso retirado manualmente en una OU de grupo solo se detecta en la aplicación («Permisos insuficientes»).

Kontivo 3, para Active Directory · permisos tomados del § 10.9 del diseño de la herramienta; preparación del recurso compartido: § 15.2 del diseño de la V2 · Active Directory es una marca de Microsoft.