Une attribution massive de droits aux utilisateurs de domaines provenant de différentes forêts

Il semble que j'aie ce karma : réaliser des tâches standards de manière non triviale. Si quelqu'un a une vision différente du problème, je vous invite à en discuter pour traiter la question.

Un beau matin, une tâche intéressante est apparue : attribuer des droits à des groupes d'utilisateurs sur différents partages, contenant des sous-dossiers de projets avec des dossiers de documents. Tout se passait bien et un script a été écrit pour attribuer des droits sur les dossiers. Puis, il s'est avéré que les groupes devaient contenir des utilisateurs de différents domaines, de différentes forêts (pour ceux qui ont oublié ce que c'est). Supposons que le partage lui-même est hébergé sur un dispositif Synology, enregistré dans le domaine FB, forêt PSI. Tâche : autoriser les utilisateurs domaines d'une autre forêt à accéder au contenu de ce partage, de manière très sélective.

Le cahier des charges prenait forme peu à peu comme suit :

• 2 forêts : forêt PSI, forêt TG.

  

• Dans chaque forêt, il y a 3 domaines : PSI (ZG, PSI, FB) ; TG (TG, HU, KC).
• Entre les forêts, des relations de confiance existent, Synology voit tous les groupes de sécurité dans toutes les forêts.
• Des comptes d'administration du domaine FB avec des droits FullControl doivent obligatoirement être présents sur les partages et les dossiers/sous-dossiers.
• Les noms des dossiers partagés doivent être systématisés. La direction s'est occupée de l'accord sur les ID de projets, j'ai décidé de lier les noms des groupes de sécurité aux ID des projets.
• Les dossiers de projets dans les partages système doivent contenir une structure préparée à l'avance dans un fichier .xlsx, avec les privilèges d'accès correspondants (R/RW/NA, où NA signifie aucun accès)

  

• Il doit être possible de restreindre les droits des utilisateurs/membres d'un projet à certains répertoires de ce projet. Pour d'autres répertoires/projets, l'utilisateur peut ne pas avoir d'accès, selon son appartenance aux groupes.
• Lors de la création d'un dossier de projet, des groupes dans les domaines correspondants avec des noms correspondant aux ID des projets doivent être créés de manière aussi automatique que possible.

Remarques sur le cahier des charges

• La configuration des relations de confiance ne fait pas partie du cahier des charges
• L'ID du projet contient des chiffres et des lettres latines
• Les rôles des utilisateurs des projets pour tous les domaines ont des noms types
• Un fichier .xlsx avec les dossiers et les droits d'accès (matrice d'accès) doit être préparé avant le début de la mise en œuvre de l'ensemble du projet
• Lors de la mise en œuvre de projets, il est possible de créer des groupes d'utilisateurs dans les domaines correspondants
• L'automatisation est réalisée par l'utilisation des outils d'administration standard de MS Windows.

Mise en œuvre du cahier des charges.

Après la formalisation de ces exigences, une pause tactique a été prise pour tester les méthodes de création de répertoires et d'attribution des droits. Il était prévu d'utiliser uniquement PowerShell afin de ne pas compliquer le projet. Comme je l'ai déjà mentionné, l'algorithme du script devait être relativement simple :

• Nous enregistrons des groupes avec un nom dérivé de l'ID du projet (par exemple KC40587) et les rôles correspondants indiqués dans la matrice d'accès : KC40587-EN- pour l'ingénieur ; KC40587-PM – pour le chef de produit, etc.
• Nous obtenons les SID des groupes créés.
• Nous enregistrons le dossier du projet et l'ensemble correspondant de répertoires (la liste des sous-dossiers dépend du partage dans lequel il est créé et est définie dans la matrice d'accès).
• Nous attribuons les droits d'accès aux nouveaux sous-répertoires du projet aux groupes selon la matrice d'accès.

Les difficultés rencontrées lors de la première étape :

• Incompréhension de la manière de définir la matrice d'accès dans le script (actuellement, un tableau multidimensionnel est mis en œuvre, mais un moyen de le remplir en fonction du contenu d'un fichier .xlsx / matrice d'accès est recherché).

  

• Incapacité à définir les droits d'accès sur les partages SMB sur les stockages Synology à l'aide de PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), ce qui a entraîné une perte considérable de temps et la nécessité d'adapter tout cela pour des scripts utilisant l'outil d'édition des droits icacls, ce qui a exigé la création d'un dépôt intermédiaire pour des fichiers texte et cmd.

Dans le mode actuel, l'exécution des fichiers cmd est contrôlée manuellement, lorsque cela est nécessaire pour enregistrer un dossier pour le projet.

Il est également apparu que le script doit être exécuté, y compris pour l'enregistrement de groupes dans d'autres forêts (nous avons utilisé le terme Cross-domains), et qu'il peut y avoir une relation non seulement de 1 à 1, mais aussi de 1 à plusieurs.

Cela signifie que l'accès aux ressources d'un domaine quelconque peut maintenant être revendiqué par des groupes d'autres cross-domaines, y compris d'une forêt voisine. Pour garantir l'uniformité, il a été décidé de créer une structure symétrique dans l'OU de tous les domaines desservis de toutes les forêts (ovales verticaux noirs). Comme on dit, dans l'armée, tout doit être dans le désordre, mais uniformément :

Ainsi, lors de l'enregistrement du projet 80XXX dans le domaine TG, le script exécute :

1. la création de l'OU (ovales rouges horizontaux) correspondante dans ce domaine et dans les cross-domaines, c'est-à-dire dans les domaines dont les employés doivent avoir accès à cette ressourc.

2. le remplissage de l'OU avec des groupes nommés comme <SRC_domain><DST_domain><ID_project>-, où :

• SRC_domain – cross-domaine, dont les employés auront accès aux ressources du domaine DST
• DST_domain – domaine, dont les ressources doivent en fait être accessibles, c'est-à-dire la raison pour laquelle tout cela a été mis en place
• <ID_project> — numéro de projet
• ROLES – noms des rôles énumérés dans la matrice d'accès.

3. la lecture du tableau SID de tous les groupes de tous les domaines concernés et sa sauvegarde pour la transmission ultérieure des données dans un fichier définissant les droits sur un sous-dossier spécifique du projet

4. génération de fichiers sources (paramètre /restore) avec un ensemble de droits pour une utilisation par l'utilitaire icacKC en mode exécutable « icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt »

5. création d'un fichier CMD, combinant toutes les commandes icacls exécutables pour tous les dossiers du projet

Comme mentionné précédemment, l'exécution du fichier exécutable se fait manuellement et l'évaluation des résultats d'exécution se fait également manuellement.

Difficultés rencontrées au final :

• si le dossier du projet contient déjà un grand nombre de fichiers, l'exécution de la commande icacls sur les volumes existants peut prendre un temps considérable et, dans certains cas, entraîner un échec (par exemple en cas de chemins de fichiers longs) ;
• en plus du paramètre /restore, il a fallu ajouter des lignes avec le paramètre /reset au cas où les dossiers n'étaient pas créés, mais transférés depuis des dossiers déjà existants, sans droits d'héritage depuis la racine ;
• une partie du script pour créer des groupes a dû être exécutée sur un dc aléatoire de chaque forêt, le problème concerne les comptes administratifs pour chaque arbre.

Conclusion générale : il est très étrange qu'il n'y ait pas encore d'outils sur le marché avec une telle fonctionnalité. Il semble possible de réaliser une telle fonctionnalité sur la base du portail Sharepoint.
Le fait qu'il n'existe pas la possibilité d'utiliser des utilitaires PoSH pour assigner des droits sur des dossiers sur des appareils sinology reste également incompréhensible.

Je suis prêt à partager le script, en créant un projet sur github, si cela intéresse quelqu'un.

Source : habr.com