Atribuição de direitos em larga escala a usuários de domínio de diferentes florestas

Aparentemente, meu carma é este: implementar tarefas padrão de todas as maneiras não triviais. Se alguém tiver uma visão diferente do problema, discuta-a para que a questão possa ser resolvida.

Certa manhã, surgiu uma tarefa interessante de distribuir direitos a grupos de usuários para diferentes compartilhamentos contendo subpastas de projetos com pastas de documentos. Tudo correu bem e um script foi escrito para atribuir direitos às pastas. E então descobriu-se que os grupos deveriam conter usuários de domínios diferentes, de florestas diferentes (para quem esqueceu o que é). Digamos que o compartilhamento em si esteja localizado na mídia Synology, registrada no domínio FB da floresta PSI. Tarefa: permitir que usuários de domínios de outra floresta tenham acesso ao conteúdo deste compartilhamento, e de forma muito seletiva.

Depois de algum tempo, as especificações técnicas assumiram a seguinte forma:

• 2 florestas: floresta PSI, floresta TG.

  

• Cada floresta possui 3 domínios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Existe uma relação de confiança entre florestas; a Synology vê todos os grupos de segurança em todas as florestas.
• Compartilhamentos e pastas/subpastas devem ter contas de administrador de domínio FB com direitos FullControl
• Os nomes das pastas devem ser sistematizados. A gerência coordenou os IDs do projeto; decidi vincular o nome dos grupos de segurança aos IDs do projeto.
• As pastas do projeto em compartilhamentos do sistema devem conter uma estrutura preparada previamente em um arquivo .xlsx, com privilégios de acesso apropriados (R/RW/NA, onde NA – sem acesso)

  

• Deveria ser possível restringir os direitos dos usuários/membros do grupo de um projeto apenas a determinados diretórios desse projeto. O usuário pode não ter acesso a outros diretórios/projetos, dependendo da participação no grupo.
• Ao criar uma pasta de projeto, os grupos devem ser criados tão automaticamente quanto possível nos domínios apropriados com nomes correspondentes aos IDs do projeto.

Notas às especificações técnicas

• O estabelecimento de relações de confiança não está incluído no âmbito das especificações técnicas
• O ID do projeto contém números e caracteres latinos
• As funções de usuário do projeto para todos os domínios têm nomes padrão
• Um arquivo .xlsx com pastas e direitos de acesso (matriz de acesso) é preparado antes do início de todo o projeto
• Na implementação de projetos é possível criar grupos de usuários nos domínios correspondentes
• A automação é obtida usando ferramentas de administração padrão do MS Windows

Implementação de especificações técnicas

Após a formalização desses requisitos, foi feita uma pausa tática para testar métodos de criação de diretórios e atribuição de direitos a eles. Pretendia-se usar apenas PowerShell, para não complicar o projeto. Como escrevi anteriormente, o algoritmo do script parecia bastante simples:

• registramos grupos com um nome derivado do ID do projeto (por exemplo KC40587) e as funções correspondentes especificadas na matriz de acesso: KC40587-EN- para engenheiro; KC40587-PM – para gerente de produto, etc.
• obtemos os SIDs dos grupos criados
• cadastre a pasta do projeto e o conjunto de diretórios correspondente (a lista de subpastas depende do compartilhamento em que é criado e definido na matriz de acesso)
• atribuir direitos a grupos para novos subdiretórios do projeto de acordo com a matriz de acesso.

Dificuldades encontradas na fase 1:

• mal-entendido do método de especificação da matriz de acesso no script (um array multidimensional agora está implementado, mas o caminho para preenchê-lo está sendo procurado com base no conteúdo do arquivo .xlsx/matriz de acesso)

  

• impossibilidade de definir direitos de acesso em compartilhamentos SMB em unidades de sinologia usando PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), por isso muito tempo foi perdido e tudo teve que ser adaptado para scripts usando o utilitário de edição de direitos de acesso icacls, o que exigiu a criação de um repositório intermediário de arquivos de texto e cmd.

No modo atual, a execução dos arquivos cmd é controlada manualmente, dependendo da necessidade de cadastrar uma pasta para o projeto.

Descobriu-se também que o script também deveria ser executado para registrar grupos em outras florestas (foi usado o termo Domínios Cruzados), e a proporção pode ser não apenas de 1 para um, mas também de 1 para muitos.

Isto significa que grupos de outros domínios cruzados, incluindo uma floresta vizinha, podem agora reivindicar acesso aos recursos de qualquer domínio. Para alcançar a uniformidade, decidiu-se criar uma estrutura simétrica na UO de todos os domínios atendidos de todas as florestas (ovais verticais pretas). Como se costuma dizer, no exército tudo deveria ser feio, mas uniforme:

Assim, ao registrar o projeto 80XXX no domínio TG, o script executa:

1. criação da UO correspondente (ovais horizontais vermelhas) neste domínio e entre domínios, ou seja, aqueles domínios cujos funcionários devem ter acesso a este recurso.

2. preencher a UO com grupos com nomes como -, onde:

• Domínio SRC_ – domínio cruzado cujos funcionários terão acesso aos recursos do domínio DST
• DST_domain – o domínio a cujos recursos, de fato, deve ser fornecido acesso, ou seja, para o qual tudo foi iniciado
• — número do projeto
• FUNÇÕES – nomes das funções listadas na matriz de acesso.

3. ler a matriz de SIDs de todos os grupos de todos os domínios envolvidos e salvá-la para posterior transferência de dados em um arquivo que define os direitos para uma subpasta específica do projeto

4. geração de arquivos fonte (parâmetro /restore) com um conjunto de direitos para uso pelo utilitário icacKC no modo de arquivo executável “icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

5. Criando um arquivo CMD que combina todos os icacls lançados para todas as pastas do projeto

Conforme escrito anteriormente, o lançamento do arquivo executável é feito manualmente e a avaliação dos resultados da execução também é feita manualmente.

Dificuldades que tivemos que enfrentar no final:

• se a pasta do projeto já estiver preenchida com um grande número de arquivos, a execução do comando icacls nos volumes existentes pode levar um tempo considerável e, em alguns casos, pode levar à falha (por exemplo, quando há caminhos de arquivo longos);
• além do parâmetro /restore, tivemos que adicionar linhas com o parâmetro /reset caso as pastas não fossem criadas, mas fossem transferidas de pastas previamente existentes, com direitos de herança da raiz desabilitados;
• Parte do script de criação de grupos teve que ser executado em um dc arbitrário de cada floresta, o problema diz respeito às contas administrativas de cada árvore.

Conclusão geral: é muito estranho que ainda não existam utilitários com funcionalidades semelhantes no mercado. Parece possível implementar funcionalidades semelhantes com base no portal Sharepoint.
Também é incompreensível que não seja possível usar utilitários PoSH para definir direitos de pasta em dispositivos sinologia.

Se desejar, estou pronto para compartilhar o script criando algum projeto no github se alguém estiver interessado.

Fonte: habr.com