Attribution de droits à grande échelle aux utilisateurs de domaine de différentes forêts

Apparemment, mon karma est le suivant : mettre en œuvre des tâches standard de toutes sortes de manières non triviales. Si quelqu'un a une vision différente du problème, veuillez en discuter afin que le problème puisse être résolu.

Un beau matin, une tâche intéressante s'est présentée : distribuer les droits à des groupes d'utilisateurs pour différents partages contenant des sous-dossiers de projets avec des dossiers de documents. Tout allait bien et un script a été écrit pour attribuer des droits aux dossiers. Et 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). Disons que le partage lui-même se trouve sur un support Synology, enregistré dans le domaine FB de la forêt PSI. Tâche : permettre aux utilisateurs de domaines d'une autre forêt d'avoir accès au contenu de ce partage, et de manière très sélective.

Après un certain temps, les spécifications techniques ont pris la forme suivante :

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

  

• Chaque forêt possède 3 domaines : PSI (ZG, PSI, FB) ; TG (TG, HU, KC).
• Il existe une relation de confiance entre les forêts ; Synology voit tous les groupes de sécurité dans toutes les forêts.
• Les partages et dossiers/sous-dossiers doivent avoir des comptes d'administrateur de domaine FB avec des droits FullControl
• Les noms des dossiers doivent être systématisés. La direction a coordonné les identifiants du projet ; j'ai décidé de lier le nom des groupes de sécurité aux identifiants du projet.
• Les dossiers de projet 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 appropriés (R/RW/NA, où NA – pas d'accès)

  

• Il devrait être possible de restreindre les droits des utilisateurs/membres d'un groupe d'un projet à seulement certains répertoires de ce projet. L'utilisateur peut ne pas avoir accès à d'autres répertoires/projets, en fonction de son appartenance au groupe.
• Lors de la création d'un dossier de projet, les groupes doivent être créés aussi automatiquement que possible dans les domaines appropriés avec des noms correspondant aux ID de projet.

Notes sur les spécifications techniques

• La mise en place de relations de confiance n'entre pas dans le cadre des spécifications techniques
• L'ID du projet contient des chiffres et des caractères latins
• Les rôles d'utilisateur du projet pour tous les domaines ont des noms standard
• Un fichier .xlsx avec les dossiers et les droits d'accès (matrice d'accès) est préparé avant le démarrage 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 à l'aide des outils d'administration standard MS Windows

Mise en place des spécifications techniques

Après avoir formalisé ces exigences, une pause tactique a été prise pour tester les méthodes de création d'annuaires et d'attribution de droits. Il était prévu d'utiliser uniquement PowerShell, afin de ne pas compliquer le projet. Comme je l'ai écrit plus tôt, l'algorithme du script semblait assez simple :

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

Difficultés rencontrées à l'étape 1 :

• incompréhension de la méthode de spécification de la matrice d'accès dans le script (un tableau multidimensionnel est désormais implémenté, mais le chemin pour le remplir est recherché en fonction du contenu du fichier .xlsx/matrice d'accès)

  

• impossibilité de définir les droits d'accès aux partages SMB sur les disques 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), à cause de quoi beaucoup de temps a été perdu et tout a dû être adapté aux scripts à l'aide de l'utilitaire d'édition des droits d'accès icacls, ce qui a nécessité la création d'un référentiel intermédiaire de fichiers texte et cmd.

Dans le mode actuel, l'exécution des fichiers cmd est contrôlée manuellement, en fonction de la nécessité d'enregistrer un dossier pour le projet.

Il s'est également avéré que le script devait également être exécuté pour enregistrer des groupes dans d'autres forêts (le terme Cross-domains a été utilisé), et le rapport peut être non seulement de 1 pour un, mais également de 1 pour plusieurs.

Cela signifie que les groupes d'autres domaines inter-domaines, y compris une forêt voisine, peuvent désormais revendiquer l'accès aux ressources de n'importe quel domaine. Pour parvenir à l'uniformité, il a été décidé de créer une structure symétrique dans l'UO de tous les domaines desservis de toutes les forêts (ovales verticaux noirs). Comme on dit, dans l'armée, tout doit être laid, mais uniforme :

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

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

2. remplir l'UO avec des groupes avec des noms comme -, Où:

• Domaine SRC_ – inter-domaine dont les employés auront accès aux ressources du domaine DST
• DST_domain – le domaine aux ressources duquel, en fait, l'accès doit être fourni, c'est-à-dire pour lequel tout a été commencé
• - numéro de projet
• ROLES – noms des rôles répertoriés dans la matrice d'accès.

3. lire le tableau des SID de tous les groupes de tous les domaines impliqués et l'enregistrer pour un transfert de données ultérieur dans un fichier qui définit les droits sur un sous-dossier de projet spécifique

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

5. création d'un fichier CMD qui combine tous les icacls lancés pour tous les dossiers du projet

Comme cela a été écrit précédemment, le lancement du fichier exécutable se fait manuellement et l'évaluation des résultats de l'exécution se fait également manuellement.

Difficultés auxquelles nous avons dû faire face au final :

• si le dossier du projet est déjà rempli d'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, conduire à un échec (par exemple, lorsqu'il existe de longs chemins de fichiers) ;
• en plus du paramètre /restore, nous avons dû ajouter des lignes avec le paramètre /reset au cas où les dossiers n'auraient pas été créés, mais auraient été transférés à partir de dossiers existants, avec les droits d'héritage de la racine désactivés ;
• Une partie du script de création de groupes a dû être exécutée sur un DC arbitraire de chaque forêt, le problème concerne les comptes administratifs de chaque arbre.

Conclusion générale : il est très étrange qu'il n'existe pas encore d'utilitaires dotés de fonctionnalités similaires sur le marché. Il semble possible de mettre en œuvre des fonctionnalités similaires basées sur le portail Sharepoint.
Il est également incompréhensible qu'il ne soit pas possible d'utiliser les utilitaires PoSH pour définir les droits de dossier sur les appareils sinologie.

Si vous le souhaitez, je suis prêt à partager le script en créant un projet sur github si quelqu'un est intéressé.

Source: habr.com