Parece que tengo esa karma: implementar tareas estándar de maneras no triviales. Si alguien tiene una visión diferente del problema, les invito a participar en la discusión para abordar la cuestión.
Una hermosa mañana apareció una tarea interesante: asignar permisos a grupos de usuarios en diferentes comparticiones que contienen subcarpetas de proyectos con carpetas de documentos. Todo iba bien y se escribió un script que asignaba derechos a las carpetas. Luego se descubrió que los grupos debían contener usuarios de diferentes dominios, de diferentes bosques (). Supongamos que la compartición en sí está alojada en un dispositivo Synology registrado en el dominio FB, bosque PSI. La tarea: permitir a los usuarios dominios de otro bosque acceder al contenido de esta compartición, de manera muy selectiva.
El TDR se fue delineando de la siguiente manera:
- 2 bosques: Bosque PSI, bosque TG.
- En cada bosque hay 3 dominios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Entre los bosques hay relaciones de confianza, Synology ve todos los grupos de seguridad en todos los bosques.
- Las comparticiones y las carpetas/subcarpetas deben tener cuentas de administradores del dominio FB con derechos de FullControl.
- Los nombres de las carpetas compartidas deben estar sistematizados. La coordinación de los ID de los proyectos fue realizada por la dirección, decidí vincular los nombres de los grupos de seguridad a los ID de los proyectos.
- Las carpetas de proyectos en las comparticiones del sistema deben contener una estructura predefinida en un archivo .xlsx, con los privilegios de acceso correspondientes (R/RW/NA, donde NA significa que no hay acceso).
- Debería ser posible limitar los derechos de los usuarios/miembros de un proyecto a solo ciertos directorios de dicho proyecto. El usuario puede no tener acceso a otros directorios/proyectos, según la membresía en los grupos.
- Al crear la carpeta del proyecto, deberían crearse automáticamente grupos en los dominios correspondientes con nombres vinculados a los ID de los proyectos.
Notas sobre el TDR
- La configuración de relaciones de confianza no está incluida en el marco del TDR.
- El ID del proyecto contiene números y letras latinas.
- Los roles de los usuarios de los proyectos para todos los dominios tienen nombres estándar.
- El archivo .xlsx con las carpetas y los derechos de acceso (matriz de acceso) se prepara antes de iniciar la implementación de todo el proyecto.
- Durante la implementación de proyectos es posible crear grupos de usuarios en los dominios correspondientes.
- La automatización se logra mediante el uso de herramientas de administración estándar de MS Windows
Implementación de requisitos técnicos
Después de formalizar estos requisitos, se tomó una pausa táctica para probar métodos de creación de directorios y asignación de permisos. Se planeaba utilizar únicamente PowerShell para no complicar el proyecto. Como mencioné anteriormente, el algoritmo del script se consideraba bastante simple:
- registramos grupos con nombres derivados del ID del proyecto (por ejemplo, KC40587) y los roles correspondientes indicados en la matriz de acceso: KC40587-EN- para ingenieros; KC40587-PM – para el gerente de producto, etc.
- obtenemos los SID de los grupos creados
- registramos la carpeta del proyecto y el conjunto correspondiente de directorios (la lista de subcarpetas depende del recurso compartido en el que se crea y está definido en la matriz de acceso)
- asignamos permisos en los nuevos subdirectorios del proyecto a los grupos de acuerdo con la matriz de acceso.
Las dificultades que enfrentamos en la primera etapa:
- falta de comprensión sobre cómo establecer la matriz de acceso en el script (actualmente se implementa un array multidimensional, pero se busca la manera de llenarlo con el contenido de un archivo .xlsx/matriz de acceso)
- imposibilidad de establecer permisos de acceso en recursos compartidos SMB en dispositivos Synology mediante PowerShell (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), lo que provocó una gran pérdida de tiempo y la necesidad de adaptar todo a scripts utilizando la utilidad icacls para editar permisos, lo que requirió crear un almacenamiento intermedio de archivos de texto y cmd.
En el modo actual, la ejecución de archivos .cmd se controla manualmente, a raíz de la necesidad de registrar la carpeta para el proyecto.
También resultó que el script debe ejecutarse, entre otras cosas, para registrar grupos en otros bosques (utilizamos el término 'Cross-domains'), y la relación puede no ser solo 1 a 1, sino también 1 a muchos.
Esto significa que grupos de otros dominios cruzados, incluyendo el bosque vecino, ahora pueden reclamar acceso a los recursos de un dominio. Para implementar uniformidad, se tomó la decisión de crear una estructura simétrica en la OU de todos los dominios atendidos de todos los bosques (óvalos verticales negros). Como se dice, en el ejército todo debe ser desordenado, pero uniforme:
Así, al registrar el proyecto 80XXX en el dominio TG, el script ejecuta:
1. la creación de la OU correspondiente (óvalos rojos horizontales) en este dominio y en dominios cruzados, es decir, aquellos dominios cuyos empleados deben tener acceso a este recurso.
2. el llenado de la OU con grupos nombrados como -, donde:
- SRC_domain – dominio cruzado, cuyos empleados tendrán acceso a los recursos del dominio DST
- DST_domain – dominio al que, en realidad, se debe proporcionar acceso, es decir, para qué se comenzó todo esto
- — número del proyecto
- ROLES – nombres de los roles enumerados en la matriz de acceso.
3. lectura de la matriz SID de todos los grupos de todos los dominios involucrados y su conservación para la posterior transmisión de datos a un archivo que determina los derechos sobre una subcarpeta específica del proyecto
4. generación de archivos de origen (parámetro /restore) con un conjunto de derechos para usar con la utilidad icacKC en modo de archivo ejecutable «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»
5. creación de un archivo CMD que combine todos los icacls ejecutables para todas las carpetas del proyecto
Como se mencionó anteriormente, la ejecución del archivo ejecutable se realiza manualmente y la evaluación de los resultados de la ejecución también se lleva a cabo de forma manual.
Dificultades con las que se enfrentó al final:
- si la carpeta del proyecto ya está llena de un gran número de archivos, la ejecución del comando icacls sobre los volúmenes existentes puede tardar un tiempo considerable y, en algunos casos, puede llevar a un fallo (por ejemplo, en caso de rutas de archivos largas);
- además del parámetro /restore, se tuvo que añadir líneas con el parámetro /reset en caso de que las carpetas no se crearan, sino que se trasladaran desde carpetas ya existentes, con los derechos de herencia desactivados desde la raíz;
- tuve que ejecutar parte del script para crear grupos en un DC aleatorio de cada bosque; el problema se refiere a las cuentas administrativas de cada árbol.
Conclusión general: es muy extraño que en el mercado no existan utilidades con esta funcionalidad. Se ve que es posible implementar esta funcionalidad en la base del portal Sharepoint.
También resulta incomprensible la falta de posibilidad de utilizar utilidades de PoSH para asignar derechos a carpetas en dispositivos sinology.
Si lo desean, estoy dispuesto a compartir el script, creando algún proyecto en github, si a alguien le interesa.
Fuente: habr.com
