Atribuição em massa de direitos a usuários de domínios de diferentes florestas

Parece que minha karma é assim: realizar tarefas padrão de maneiras não triviais. Se alguém tiver uma visão diferente do problema, por favor, participe da discussão para trabalharmos na questão.

Certa manhã, surgiu uma tarefa interessante: conceder direitos a grupos de usuários em diferentes shares, contendo subpastas de projetos com pastas de documentos. Tudo estava indo bem e um script foi escrito para atribuir permissões nas pastas. Então, descobrimos que os grupos deveriam conter usuários de diferentes domínios, de diferentes florestas (para aqueles que se esqueceram do que é). Suponha que o share em si esteja localizado em um dispositivo Synology, registrado no domínio FB, floresta PSI. Tarefa: permitir que usuários domínios de outra floresta tenham acesso ao conteúdo desse share, de maneira bastante seletiva.

O escopo foi se delineando da seguinte forma:

• 2 florestas: Floresta PSI, floresta TG.

  

• Em cada floresta, há 3 domínios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Entre as florestas – relações de confiança, o Synology vê todos os grupos de Segurança em todas as florestas.
• Nos shares e pastas/subpastas, devem obrigatoriamente existir contas de administradores do domínio FB com direitos de FullControl.
• Os nomes das pastas do share devem ser sistematizados. A coordenação dos IDs dos projetos foi feita pela gerência, e eu decidi vincular o nome dos grupos de Segurança aos IDs dos projetos.
• As pastas dos projetos nos shares do sistema devem conter uma estrutura previamente preparada em um arquivo .xlsx, com as correspondentes permissões de acesso (R/RW/NA, onde NA – acesso não disponível)

  

• Deve haver a possibilidade de restringir os direitos de usuários/membros de um projeto apenas a certos diretórios desse projeto. Para outros diretórios/projetos, o usuário pode não ter acesso, conforme sua condição nos grupos.
• Ao criar uma pasta do projeto, grupos nos domínios correspondentes devem ser criados de forma automática, com nomes correspondentes aos IDs dos projetos.

Notas sobre o escopo

• A configuração de relações de confiança não faz parte do escopo
• O ID do projeto contém números e letras
• Os papéis dos usuários dos projetos para todos os domínios têm nomes padrão
• O arquivo .xlsx com pastas e direitos de acesso (matriz de acesso) deve ser preparado antes do início da implementação de todo o projeto
• Na implementação de projetos, a criação de grupos de usuários nos domínios correspondentes pode ser realizada
• A automatização é alcançada através do uso de ferramentas padrão de administração do MS Windows

Implementação do Termo de Referência

Após a formalização desses requisitos, houve uma pausa tática para testar métodos de criação de diretórios e atribuição de permissões. A intenção era usar apenas o PowerShell, para não complicar o projeto. Como já mencionei antes, o algoritmo do script parecia bastante simples:

• registramos grupos com nomes derivados do ID do projeto (por exemplo, KC40587) e as respectivas funções, conforme indicado na matriz de acesso: KC40587-EN- para engenheiro; KC40587-PM – para gerente de produto, etc.
• obtemos os SID dos grupos criados
• registramos a pasta do projeto e o conjunto correspondente de diretórios (a lista de subpastas depende da unidade compartilhada em que é criada e está definida na matriz de acesso)
• atribuímos permissões nos novos subdiretórios do projeto aos grupos, conforme a matriz de acesso.

Dificuldades que enfrentamos na 1ª etapa:

• incompreensão sobre como definir a matriz de acesso no script (atualmente, um array multidimensional está implementado, mas estamos buscando uma forma de preenchê-lo com base no conteúdo do arquivo .xlsx/matriz de acesso)

  

• impossibilidade de definir permissões de acesso nas unidades SMB em dispositivos Synology usando recursos do PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), o que resultou em uma perda enorme de tempo e precisou adaptar tudo para scripts utilizando a ferramenta de edição de permissões icacls, exigindo a criação de um repositório intermediário de arquivos de texto e cmd.

No modo atual, a execução de arquivos cmd é controlada manualmente, conforme se torna necessário registrar a pasta para o projeto.

Também se revelou que o script precisa ser executado para registrar grupos em outras florestas (utilizamos o termo Cross-domains), sendo que a relação pode não ser apenas 1 para 1, mas também 1 para muitos.

Isso significa que o acesso aos recursos de um determinado domínio agora pode ser reivindicado por grupos de outros cross-domains, incluindo a floresta vizinha. Para garantir uniformidade, foi tomada a decisão de criar uma estrutura simétrica nas OU de todos os domínios atendidos em todas as florestas (ovais verticais pretos). Como se costuma dizer, no exército tudo deve ser desordenado, mas uniforme:

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

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

2. O preenchimento da OU com grupos com nomes do tipo <SRC_domain><DST_domain><ID_project>-, onde:

• SRC_domain – domínio cruzado, cujos funcionários terão acesso aos recursos do domínio DST
• DST_domain – domínio cujos recursos, propriamente dito, devem ser acessados, ou seja, a razão pela qual tudo foi iniciado
• <ID_project> — número do projeto
• ROLES – nomes dos papéis listados na matriz de acesso.

3. A leitura da matriz SID de todos os grupos de todos os domínios envolvidos e sua preservação para a eventual transmissão de dados em um arquivo que define os direitos em uma subpasta específica do projeto

4. Geração de arquivos de origem (parâmetro /restore) com um conjunto de permissões para uso com a ferramenta icacKC no modo de arquivo executável "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

5. Criação de um arquivo CMD, que integra todos os icacls executáveis para todas as pastas do projeto

Como foi mencionado anteriormente, a execução do arquivo executável é feita manualmente e a avaliação dos resultados da execução também é realizada manualmente.

Dificuldades que surgiram no final:

• se a pasta do projeto já estiver cheia de muitos arquivos, a execução do comando icacls nos volumes existentes pode levar um tempo considerável e, em alguns casos, levar à falha (por exemplo, na presença de caminhos longos para os arquivos);
• além do parâmetro /restore, foi necessário adicionar linhas com o parâmetro /reset caso as pastas não fossem criadas, mas sim transferidas de pastas já existentes, com a herança de direitos desativada a partir da raiz;
• executar parte do script para criar grupos teve que ser feito em um DC aleatório de cada floresta, o que diz respeito a contas administrativas de usuários para cada árvore.

Conclusão geral: é muito estranho que no mercado ainda não existam utilitários com uma funcionalidade semelhante. A implementação dessa funcionalidade na plataforma Sharepoint parece possível.
Além disso, permanece incompreensível o fato da ausência de utilitários PoSH para definir direitos em pastas em dispositivos Sinology.

Estou disposto a compartilhar o script, criando algum projeto no github, se isso for de interesse de alguém.

Fonte: habr.com