Aparentemente mi karma es este: implementar tareas estándar de todo tipo de formas no triviales. Si alguien tiene una visión diferente del problema, discútalo para que se pueda solucionar el problema.
Una buena mañana surgió una interesante tarea: distribuir derechos a grupos de usuarios sobre diferentes recursos compartidos que contienen subcarpetas de proyectos con carpetas de documentos. Todo estuvo bien y se escribió un script para asignar derechos a las carpetas. Y luego resultó que los grupos deberían contener usuarios de diferentes dominios, de diferentes bosques (). Digamos que el recurso compartido en sí está ubicado en los medios Synology, registrado en el dominio FB del bosque PSI. Tarea: permitir que los usuarios de dominios en otro bosque tengan acceso al contenido de este recurso compartido, y de forma muy selectiva.
Después de algún tiempo, las especificaciones técnicas tomaron la siguiente forma:
- 2 bosques: bosque PSI, bosque TG.
- Cada bosque tiene 3 dominios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Existe una relación de confianza entre los bosques; Synology ve todos los grupos de seguridad en todos los bosques.
- Los recursos compartidos y las carpetas/subcarpetas deben tener cuentas de administrador de dominio FB con derechos FullControl
- Se deben sistematizar los nombres de las carpetas. La administración coordinó los ID del proyecto; decidí vincular el nombre de los grupos de seguridad a los ID del proyecto.
- Las carpetas de proyectos en recursos compartidos del sistema deben contener una estructura preparada de antemano en un archivo .xlsx, con los privilegios de acceso adecuados (R/RW/NA, donde NA – sin acceso)
- Debería ser posible restringir los derechos de los usuarios/miembros del grupo de un proyecto solo a ciertos directorios de ese proyecto. Es posible que el usuario no tenga acceso a otros directorios/proyectos, dependiendo de la membresía del grupo.
- Al crear una carpeta de proyecto, los grupos deben crearse de la manera más automática posible en los dominios apropiados con nombres correspondientes a los ID del proyecto.
Notas a las especificaciones técnicas.
- El establecimiento de relaciones de confianza no está incluido en el alcance de las especificaciones técnicas.
- El ID del proyecto contiene números y caracteres latinos.
- Los roles de usuario del proyecto para todos los dominios tienen nombres estándar
- Se prepara un archivo .xlsx con carpetas y derechos de acceso (matriz de acceso) antes del inicio de todo el proyecto.
- Al implementar 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 especificaciones técnicas.
Después de formalizar estos requisitos, se tomó una pausa táctica para probar métodos para crear directorios y asignarles derechos. Se pretendía utilizar únicamente PowerShell, para no complicar el proyecto. Como escribí anteriormente, el algoritmo del script parecía bastante simple:
- registramos grupos con un nombre derivado del ID del proyecto (por ejemplo KC40587) y los roles correspondientes especificados en la matriz de acceso: KC40587-EN- para ingeniero; KC40587-PM – para gerente de producto, etc.
- obtenemos los SID de los grupos creados
- registrar la carpeta del proyecto y el conjunto de directorios correspondiente (la lista de subcarpetas depende del recurso compartido en el que se crea y se define en la matriz de acceso)
- asignar derechos a grupos para nuevos subdirectorios del proyecto según la matriz de acceso.
Dificultades encontradas en la etapa 1:
- malentendido del método para especificar la matriz de acceso en el script (ahora se implementa una matriz multidimensional, pero se busca la ruta para completarla en función del contenido del archivo .xlsx/matriz de acceso)
- imposibilidad de configurar derechos de acceso en recursos compartidos SMB en unidades Synology usando PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), por lo que se perdió mucho tiempo y todo tuvo que adaptarse a los scripts utilizando la utilidad de edición de derechos de acceso icacls, lo que requirió la creación de un repositorio intermedio de archivos de texto y cmd.
En el modo actual, la ejecución de archivos cmd se controla manualmente, dependiendo de la necesidad de registrar una carpeta para el proyecto.
También resultó que el script también debería ejecutarse para registrar grupos en otros bosques (se utilizó el término dominios cruzados), y la proporción puede ser no sólo de 1 a uno, sino también de 1 a muchos.
Esto significa que los grupos de otros dominios cruzados, incluido un bosque vecino, ahora pueden reclamar acceso a los recursos de cualquier dominio. Para lograr uniformidad, se decidió crear una estructura simétrica en la unidad organizativa de todos los dominios con servicios de todos los bosques (óvalos verticales negros). Como dicen, en el ejército todo debería ser feo, pero uniforme:
Así, al registrar el proyecto 80XXX en el dominio TG, el script ejecuta:
1. creación de las OU correspondientes (óvalos horizontales rojos) en este dominio y dominios cruzados, es decir, aquellos dominios cuyos empleados deben tener acceso a este recurso.
2. llenar OU con grupos con nombres como -, Dónde:
- Dominio SRC_: dominio cruzado cuyos empleados tendrán acceso a los recursos del dominio DST
- DST_domain – el dominio a cuyos recursos, de hecho, se debe proporcionar acceso, es decir, por el cual se inició todo
- - número de proyecto
- ROLES: nombres de los roles enumerados en la matriz de acceso.
3. leer la matriz de SID de todos los grupos de todos los dominios involucrados y guardarla para la transferencia de datos posterior a un archivo que define los derechos de una subcarpeta de proyecto específica
4. generación de archivos fuente (parámetro /restore) con un conjunto de derechos para uso de la utilidad icacKC en modo de archivo ejecutable “icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. crear un archivo CMD que combine todos los icacls iniciados para todas las carpetas del proyecto
Como se escribió anteriormente, el lanzamiento del archivo ejecutable se realiza manualmente y la evaluación de los resultados de la ejecución también se realiza manualmente.
Dificultades que tuvimos que afrontar al final:
- si la carpeta del proyecto ya está llena con una gran cantidad de archivos, ejecutar el comando icacls en los volúmenes existentes puede llevar un tiempo considerable y, en algunos casos, provocar fallas (por ejemplo, cuando hay rutas de archivo largas);
- además del parámetro /restore, tuvimos que agregar líneas con el parámetro /reset en caso de que las carpetas no se crearan, sino que se transfirieran desde carpetas previamente existentes, con los derechos de herencia desde la raíz deshabilitados;
- Parte del script para crear grupos tuvo que ejecutarse en un dc arbitrario de cada bosque; el problema tiene que ver con las cuentas administrativas de cada árbol.
Conclusión general: es muy extraño que todavía no existan en el mercado utilidades con una funcionalidad similar. Parece posible implementar una funcionalidad similar basada en el portal Sharepoint.
También es incomprensible que no sea posible utilizar las utilidades PoSH para configurar derechos de carpeta en dispositivos Sinology.
Si lo desea, estoy listo para compartir el script creando algún proyecto en github si alguien está interesado.
Fuente: habr.com