Aparentemente, meu karma é o seguinte: implemente tarefas padrão de todo tipo de maneiras não triviais. Se alguém tem uma visão diferente do problema - peço uma discussão para resolver o problema.
Em uma bela manhã, apareceu uma tarefa interessante: distribuir direitos a grupos de usuários em diferentes esferas contendo subpastas de projeto com pastas de documentos. Tudo estava bem e foi atribuído um script atribuindo direitos às pastas. E então os grupos devem conter usuários de domínios diferentes, de florestas diferentes (
para quem esqueceu o que é ). Suponha que a bola em si esteja hospedada na mídia Synology registrada no domínio FB da floresta PSI. Objetivo: permitir que usuários de domínios em outra floresta tenham acesso ao conteúdo desta bola e de maneira muito seletiva.
Depois de algum tempo, o TK apareceu na seguinte forma:
- 2 florestas: Floresta PSI, Floresta TG.
- Cada floresta possui 3 domínios: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Há uma relação de confiança entre florestas, o Synology vê todos os grupos de segurança em todas as florestas.
- Balões e pastas / subpastas devem ter contas de administrador de domínio do FB com direitos FullControl
- Os nomes das pastas dos balões devem ser sistematizados. A gerência estava negociando os IDs do projeto.Eu decidi atribuir o nome dos grupos de Segurança aos IDs do projeto.
- As pastas do projeto nas esferas do sistema devem conter uma estrutura previamente preparada no 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 a apenas determinados diretórios desse projeto. O usuário pode não ter acesso a outros diretórios / projetos, de acordo com a associação ao grupo.
- Ao criar uma pasta de projeto, grupos nos domínios correspondentes com os nomes dos IDs de projeto correspondentes devem ser criados o mais automaticamente possível.
Notas ao ToR
- Relações de construção de confiança não fazem parte da CT
- O ID do projeto contém números e letras latinas
- As funções de usuário do projeto para todos os domínios têm nomes genéricos
- Um arquivo .xlsx com pastas e permissões (matriz de acesso) é preparado antes do início de todo o projeto
- Ao implementar projetos, é possível criar grupos de usuários nos domínios correspondentes
- A automação é alcançada usando ferramentas de administração padrão do MS Windows
Implementação TK
Após formalizar esses requisitos, foi feita uma pausa tática para testar os métodos de criação de diretórios e atribuição de direitos a eles. Era para usar apenas o PowerShell, para não complicar o projeto. Como escrevi anteriormente, o algoritmo de script parecia bastante simples:
- registrar grupos com o nome derivado do ID do projeto (por exemplo, KC40587) e as funções correspondentes especificadas na matriz de acesso: KC40587-EN- para o engenheiro; KC40587-PM - para gerente de produtos etc.
- obtenha os SIDs dos grupos criados
- registrar a pasta do projeto e o conjunto de diretórios correspondente (a lista de subpastas depende das esferas em que é criada e definida na matriz de acesso)
- atribua direitos a grupos de acordo com a matriz de acesso a novos subdiretórios do projeto.
Dificuldades encontradas no estágio 1:
- falta de entendimento da maneira de definir a matriz de acesso no script (uma matriz multidimensional agora está implementada, mas uma maneira de preenchê-la é procurada com base no conteúdo da matriz de arquivos / acesso .xlsx)
- a impossibilidade de definir direitos de acesso em esferas 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 causa do qual muito tempo foi perdido e eu tive que adaptar tudo aos scripts usando o utilitário de edição de permissões do icacls, que exigiu a criação de um depósito intermediário de arquivos de texto e cmd.
No modo atual, a execução dos arquivos cmd é controlada manualmente, devido à necessidade de registrar uma pasta para o projeto.
Também ocorreu que o script deve ser executado, inclusive para registrar grupos em outras florestas (eles usaram o termo domínios cruzados), e a proporção pode ser não apenas de 1 para um, mas de 1 para muitos.
Isso significa que grupos de outros domínios cruzados, incluindo a floresta vizinha, agora podem reivindicar acesso aos recursos de um domínio. Para obter uniformidade, decidiu-se criar uma estrutura simétrica na UO de todos os domínios atendidos de todas as florestas (ovais verticais pretos). Como se costuma dizer, no exército tudo deve ser feio, mas uniforme:
Portanto, ao registrar o projeto 80XXX no domínio TG, o script executa:
1. Criação da OU correspondente (ovais horizontais vermelhas) neste domínio e domínios cruzados, ou seja, os domínios cujos funcionários devem ter acesso a esse recurso.
2. preenchendo a UO com grupos com nomes no formulário <SRC_ domain> <DST_domain> <ID_project> -, em que:
- SRC_ domain - um domínio cruzado cujos funcionários terão acesso aos recursos do domínio DST
- DST_domain - domain, para cujos recursos, de fato, o acesso deve ser concedido, ou seja, para o qual tudo foi iniciado
- <ID_project> - número do projeto
- ROLES - os nomes das funções listadas na matriz de acesso.
3. lendo a matriz SID de todos os grupos de todos os domínios envolvidos e salvando-a para posterior transferência de dados em um arquivo que determina os direitos de uma subpasta de projeto específica
4. geração de arquivos de origem (parâmetro / restauração) com um conjunto de permissões para usar o utilitário icacKC no modo de arquivo executável "icacKC" \\ as-nasNN \ KC \ Projects "/ restaura C: \ Temp \ KC \ KC40XX \ KC40XX.txt"
5. criando um arquivo CMD que combina todos os icacls lançados para todas as pastas do projeto
Como foi escrito anteriormente, o arquivo executável é iniciado manualmente e a avaliação dos resultados da execução também é realizada manualmente.
Dificuldades encontradas 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 disponíveis poderá levar um tempo considerável e, em alguns casos, levar à falha (por exemplo, se houver longos caminhos de arquivo);
- além da opção / restore, tive que adicionar linhas com a opção / reset caso as pastas não fossem criadas, mas transferidas de pastas existentes anteriormente, com os direitos de herança desativados da raiz;
- Como parte do script para criar grupos teve que ser executada em um CC 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 funcionalidade semelhante no mercado. Parece possível implementar essa funcionalidade com base no portal do Sharepoint.
Ele também fornece um fato incompreensível de que não é possível usar os utilitários PoSH para definir permissões em uma pasta em dispositivos de sinologia.
À vontade, estou pronto para compartilhar o script criando algum tipo de projeto no github, se for interessante para alguém.