Aparentemente, mi karma es este: implementar tareas estándar en todo tipo de formas no triviales. Si alguien tiene una visión diferente del problema, pido una discusión para resolver el problema.
Una buena mañana, apareció una tarea interesante: distribuir derechos a grupos de usuarios en diferentes bolas que contienen subcarpetas de proyectos con carpetas de documentos. Todo estaba bien y se le asignó un script para asignar derechos a las carpetas. Y luego resultó que los grupos deberían contener usuarios de diferentes dominios, de diferentes bosques (
para aquellos que olvidaron lo que es ). Supongamos que el balón en sí está alojado en los medios de Synology registrados en el dominio FB del bosque PSI. Objetivo: permitir a los usuarios de dominios en otro bosque tener acceso a los contenidos de esta bola, y de manera muy selectiva.
TK después de un tiempo apareció en 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 globos y las carpetas / subcarpetas deben tener cuentas de administrador de dominio FB con derechos de FullControl
- Los nombres de las carpetas de globos deben sistematizarse. La administración estaba negociando las ID del proyecto. Decidí asignar el nombre de los grupos de seguridad a las ID del proyecto.
- Las carpetas de proyecto en las bolas del sistema deben contener una estructura preparada de antemano en el archivo .xlsx, con los privilegios de acceso apropiados (R / RW / NA, donde NA - sin acceso)
- Debería ser posible restringir los derechos de los usuarios / miembros del grupo de un proyecto a solo ciertos directorios de este proyecto. El usuario puede no tener acceso a otros directorios / proyectos, de acuerdo con la membresía del grupo.
- Al crear una carpeta de proyecto, los grupos en los dominios correspondientes con los nombres de los ID de proyecto correspondientes deben crearse de la forma más automática posible.
Notas a los TdR
- Las relaciones de fomento de la confianza no son parte de los conocimientos tradicionales
- La ID del proyecto contiene números y letras latinas
- Los roles de usuario del proyecto para todos los dominios tienen nombres genéricos
- Se prepara un archivo .xlsx con carpetas y permisos (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 TK
Después de formalizar estos requisitos, se tomó una pausa táctica para probar los métodos de crear directorios y asignarles derechos. Se suponía que debía usar solo PowerShell, para no complicar el proyecto. Como escribí anteriormente, el algoritmo de script parecía bastante simple:
- registrar grupos con el nombre derivado de la ID del proyecto (por ejemplo, KC40587) y los roles correspondientes indicados en la matriz de acceso: KC40587-EN- para el ingeniero; KC40587-PM - para gerente de producto, etc.
- obtener los SID de los grupos creados
- registre la carpeta del proyecto y el conjunto de directorios correspondiente (la lista de subcarpetas depende de las bolas en las que se crea y define en la matriz de acceso)
- asignar derechos a grupos de acuerdo con la matriz de acceso a nuevos subdirectorios del proyecto.
Dificultades encontradas en la etapa 1:
- falta de comprensión de la forma de establecer la matriz de acceso en el script (ahora se implementa una matriz multidimensional, pero se busca una forma de llenarla en función del contenido del archivo .xlsx / matriz de acceso)
- La imposibilidad de establecer derechos de acceso en bolas SMB en unidades de sincronización utilizando 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 tuve que adaptar todo a los scripts utilizando la utilidad de edición de permisos icacls, que requería la creación de un almacén intermedio de archivos de texto y cmd.
En el modo actual, la ejecución de archivos cmd se controla manualmente, debido a la necesidad de registrar una carpeta para el proyecto.
También resultó que el script debería ejecutarse, incluso para registrar grupos en otros bosques (usaron el término Dominios cruzados), y la proporción puede ser no solo de 1 a uno, sino de 1 a muchos.
Esto significa que los grupos de otros dominios cruzados, incluido el bosque vecino, ahora pueden reclamar el acceso a los recursos de un dominio. Para lograr la uniformidad, se decidió crear una estructura simétrica en la unidad organizativa de todos los dominios servidos de todos los bosques (óvalos verticales negros). Como dicen, en el ejército todo debería ser feo, pero uniforme:
Por lo tanto, al registrar el proyecto 80XXX en el dominio TG, el script ejecuta:
1. Creación de la OU correspondiente (óvalos horizontales rojos) en un dominio dado y dominios cruzados, es decir, aquellos dominios cuyos empleados deben tener acceso a este recurso.
2. Rellenar la unidad organizativa con grupos con nombres del formulario <SRC_ domain> <DST_domain> <ID_project> -, donde:
- SRC_ domain: un dominio cruzado cuyos empleados tendrán acceso a los recursos del dominio DST
- DST_domain - dominio, a cuyos recursos, de hecho, se debe otorgar acceso, es decir, en aras de que todo se inició
- <ID_project> - número de proyecto
- ROLES: los nombres de los roles enumerados en la matriz de acceso.
3. leer la matriz SID de todos los grupos de todos los dominios involucrados y guardarla para la posterior transferencia de datos a un archivo que determina los derechos de una subcarpeta de proyecto específica
4. generación de archivos fuente (parámetro / restauración) con un conjunto de permisos para usar la utilidad icacKC en el modo de archivo ejecutable “icacKC" \\ as-nasNN \ KC \ Projects "/ restore C: \ Temp \ KC \ KC40XX \ KC40XX.txt"
5. crear un archivo CMD que combine todos los icacls iniciados para todas las carpetas de proyectos
Como se escribió anteriormente, el archivo ejecutable se inicia manualmente y la evaluación de los resultados de la ejecución también se realiza manualmente.
Dificultades encontradas al final:
- si la carpeta del proyecto ya está llena con una gran cantidad de archivos, entonces desarrollar el comando icacls en los volúmenes disponibles puede llevar un tiempo considerable y, en algunos casos, provocar un error (por ejemplo, si hay rutas de archivo largas);
- Además de la opción / restaurar, tuve que agregar líneas con la opción / restablecer en caso de que las carpetas no se crearan, sino que se transfirieran de carpetas existentes anteriormente, con los derechos de herencia desactivados desde la raíz;
- parte del script para crear grupos tuvo que ejecutarse en una CC arbitraria de cada bosque, el problema concierne a las cuentas administrativas de cada árbol.
Conclusión general: es muy extraño que todavía no haya utilidades con una funcionalidad similar en el mercado. Parece posible implementar dicha funcionalidad sobre la base del portal Sharepoint.
También proporciona un hecho incomprensible de que no es posible utilizar las utilidades PoSH para configurar permisos en una carpeta en dispositivos de sinología.
A voluntad, estoy listo para compartir el guión creando algún tipo de proyecto en github, si es interesante para alguien.