Cesión a gran escala de dereitos a usuarios de dominios de diferentes bosques

Ao parecer, o meu karma é este: implementar tarefas estándar de todo tipo de formas non triviais. Se alguén ten unha visión diferente do problema, coméntao para que se poida resolver o problema.

Unha boa mañá xurdiu unha interesante tarefa de repartir dereitos a grupos de usuarios para diferentes comparticións que conteñan subcarpetas de proxectos con cartafoles de documentos. Todo estaba ben e escribiuse un script para asignar dereitos aos cartafoles. E entón resultou que os grupos deberían conter usuarios de diferentes dominios, de diferentes bosques (para os que esqueceron o que é). Digamos que a participación en si está situada nos medios Synology, rexistrados no dominio FB do bosque PSI. Tarefa: permitir que os usuarios de dominios doutro bosque teñan acceso aos contidos deste recurso compartido, e de forma moi selectiva.

Despois dun tempo, as especificacións técnicas tomaron a seguinte forma:

• 2 bosques: bosque PSI, bosque TG.

  

• Cada bosque ten 3 dominios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Existe unha relación de confianza entre os bosques; Synology ve todos os grupos de seguridade en todos os bosques.
• Os recursos compartidos e os cartafoles/subcartafoles deben ter contas de administrador de dominio FB con dereitos FullControl
• Deben sistematizarse os nomes dos cartafoles. A dirección coordinou os ID do proxecto; decidín vincular o nome dos grupos de Seguridade aos ID do proxecto.
• Os cartafoles do proxecto dos recursos compartidos do sistema deben conter unha estrutura preparada previamente nun ficheiro .xlsx, cos privilexios de acceso adecuados (R/RW/NA, onde NA – sen acceso)

  

• Debería ser posible restrinxir os dereitos dos usuarios/membros do grupo dun proxecto só a certos directorios dese proxecto. É posible que o usuario non teña acceso a outros directorios/proxectos, dependendo da pertenza ao grupo.
• Ao crear un cartafol de proxecto, os grupos deben crearse o máis automaticamente posible nos dominios apropiados cos nomes correspondentes aos ID do proxecto.

Notas ás especificacións técnicas

• O establecemento de relacións de confianza non está incluído no ámbito das especificacións técnicas
• O ID do proxecto contén números e caracteres latinos
• Os roles de usuario do proxecto para todos os dominios teñen nomes estándar
• Prepárase un ficheiro .xlsx con cartafoles e dereitos de acceso (matriz de acceso) antes do inicio de todo o proxecto
• Á hora de implementar proxectos, é posible crear grupos de usuarios nos dominios correspondentes
• A automatización conséguese mediante o uso de ferramentas de administración estándar de MS Windows

Implantación de especificacións técnicas

Despois de formalizar estes requisitos, realizouse unha pausa táctica para probar métodos para crear directorios e asignarlles dereitos. Pretendíase utilizar só PowerShell, para non complicar o proxecto. Como escribín anteriormente, o algoritmo de guión parecía bastante sinxelo:

• rexistramos grupos cun nome derivado do ID do proxecto (por exemplo, KC40587) e os roles correspondentes especificados na matriz de acceso: KC40587-EN- para enxeñeiro; KC40587-PM: para xestor de produtos, etc.
• obtemos os SID dos grupos creados
• rexistrar o cartafol do proxecto e o conxunto de directorios correspondente (a lista de subcartafoles depende do recurso compartido no que se crea e se define na matriz de acceso)
• Asignamos dereitos aos grupos en novos subdirectorios do proxecto segundo a matriz de acceso.

Dificultades atopadas na fase 1:

• malentendido do método de especificación da matriz de acceso no script (agora está implementada unha matriz multidimensional, pero búscase o camiño para enchela en función do contido do ficheiro .xlsx/matriz de acceso)

  

• imposibilidade de establecer dereitos de acceso en recursos compartidos SMB en unidades synology mediante PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), polo que se perdeu moito tempo e houbo que adaptar todo aos scripts mediante a utilidade de edición de dereitos de acceso icacls, que requiriu a creación dun repositorio intermedio de ficheiros de texto e cmd.

No modo actual, a execución dos ficheiros cmd contrólase manualmente, dependendo da necesidade de rexistrar un cartafol para o proxecto.

Tamén resultou que o script tamén debería executarse para rexistrar grupos noutros bosques (usouse o termo Cross-domains) e a proporción pode ser non só de 1 a un, senón tamén de 1 a moitos.

Isto significa que os grupos doutros dominios cruzados, incluído un bosque veciño, agora poden reclamar o acceso aos recursos de calquera dominio. Para lograr a uniformidade, decidiuse crear unha estrutura simétrica na OU de todos os dominios atendidos de todos os bosques (óvalos verticais negros). Como din, no exército todo debe ser feo, pero uniforme:

Así, ao rexistrar o proxecto 80XXX no dominio TG, o script executa:

1. creación da correspondente OU (óvalos horizontais vermellos) neste dominio e entre dominios, é dicir, aqueles dominios cuxos empregados deben ter acceso a este recurso.

2. enchendo OU con grupos con nomes como -, onde:

• SRC_ domain: dominio cruzado cuxos empregados terán acceso aos recursos do dominio DST
• DST_domain - o dominio a cuxos recursos, de feito, debe proporcionarse acceso, é dicir, polo que se iniciou todo
• — número do proxecto
• ROLES – nomes dos roles listados na matriz de acceso.

3. ler a matriz de SID de todos os grupos de todos os dominios implicados e gardala para a posterior transferencia de datos a un ficheiro que defina os dereitos dun subcartafol do proxecto específico

4. xeración de ficheiros fonte (parámetro /restore) cun conxunto de dereitos para o seu uso pola utilidade icacKC no modo de ficheiro executable "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

5. creando un ficheiro CMD que combine todos os icacls iniciados para todos os cartafoles do proxecto

Como se escribiu anteriormente, o lanzamento do ficheiro executable faise manualmente e a avaliación dos resultados da execución tamén se realiza manualmente.

Dificultades que tivemos que enfrontar ao final:

• se o cartafol do proxecto xa está cheo cunha gran cantidade de ficheiros, a execución do comando icacls nos volumes existentes pode levar un tempo considerable e, nalgúns casos, provocar un fallo (por exemplo, cando hai camiños de ficheiro longos);
• ademais do parámetro /restore, tivemos que engadir liñas co parámetro /reset no caso de que os cartafoles non fosen creados, senón que fosen transferidos de cartafoles xa existentes, con dereitos de herdanza da raíz desactivados;
• Parte do script para crear grupos tivo que ser executado nun dc arbitrario de cada bosque, o problema refírese ás contas administrativas de cada árbore.

Conclusión xeral: é moi estraño que aínda non haxa utilidades con funcionalidades similares no mercado. Parece posible implementar tal funcionalidade baseándose no portal de Sharepoint.
Tamén é incomprensible que non sexa posible utilizar as utilidades PoSH para establecer dereitos de cartafol en dispositivos sinoloxía.

Se o desexa, estou preparado para compartir o script creando algún proxecto en github se alguén está interesado.

Fonte: www.habr.com