Apparemment, mon karma est le suivant: implémentez des tâches standard de toutes sortes de façons non triviales. Si quelqu'un a une vision différente du problème - je demande une discussion pour résoudre le problème.
Un beau matin, une tâche intéressante est apparue: distribuer les droits aux groupes d'utilisateurs sur différentes billes contenant des sous-dossiers de projet avec des dossiers de documents. Tout allait bien et un script a été attribué en attribuant des droits aux dossiers. Et puis il s'est avéré que les groupes devraient contenir des utilisateurs de différents domaines, de différentes forêts (
pour ceux qui ont oublié ce que c'est ). Supposons que la balle elle-même soit hébergée sur un support Synology enregistré dans le domaine FB de la forêt PSI. Objectif: permettre aux utilisateurs de domaines d'une autre forêt d'avoir accès au contenu de cette boule, et de manière très sélective.
Les savoirs traditionnels se profilaient sous la forme suivante:
- 2 forêts: forêt PSI, forêt TG.
- Chaque forêt a 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 bulles et les dossiers / sous-dossiers doivent avoir des comptes d'administrateur de domaine FB avec des droits FullControl
- Les noms des dossiers de bulles doivent être systématisés. La direction était en train de négocier les ID du projet. J'ai décidé d'attribuer le nom des groupes de sécurité aux ID du projet.
- Les dossiers de projet dans les boules système doivent contenir une structure préparée à l'avance dans le 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 du groupe d'un projet à certains répertoires de ce projet uniquement. L'utilisateur peut ne pas avoir accès à d'autres répertoires / projets, selon l'appartenance au groupe.
- Lors de la création d'un dossier de projet, les groupes dans les domaines correspondants avec les noms des ID de projet correspondants doivent être créés aussi automatiquement que possible.
Notes aux TdR
- Les relations de confiance ne font pas partie des savoirs traditionnels
- L'ID du projet contient des chiffres et des lettres latines
- Les rôles d'utilisateur de projet pour tous les domaines ont des noms génériques
- Un fichier .xlsx avec dossiers et autorisations (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 obtenue en utilisant des outils d'administration MS Windows standard
Mise en œuvre des savoirs traditionnels
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 leur attribuer des droits. Il était censé utiliser uniquement PowerShell, afin de ne pas compliquer le projet. Comme je l'ai écrit plus tôt, l'algorithme de script semblait assez simple:
- enregistrer les groupes avec le nom dérivé de l'ID de projet (par exemple, KC40587) et les rôles correspondants spécifiés dans la matrice d'accès: KC40587-EN- pour l'ingénieur; KC40587-PM - pour chef de produit, etc.
- obtenir 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 des boules dans lesquelles il est créé et défini dans la matrice d'accès)
- attribuer des droits aux groupes selon la matrice d'accès aux nouveaux sous-répertoires du projet.
Difficultés rencontrées à l'étape 1:
- manque de compréhension de la façon de définir la matrice d'accès dans le script (un tableau multidimensionnel est maintenant implémenté, mais un moyen de le remplir est recherché en fonction du contenu du fichier .xlsx / de la matrice d'accès)
- l'impossibilité de définir les droits d'accès dans les boules SMB sur les lecteurs de synchronisation à 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 duquel beaucoup de temps a été perdu et j'ai dû tout adapter aux scripts à l'aide de l'utilitaire de modification des autorisations icacls, qui a nécessité la création d'un entrepôt intermédiaire de fichiers texte et cmd.
Dans le mode actuel, l'exécution des fichiers cmd est contrôlée manuellement, du fait de la nécessité d'enregistrer un dossier pour le projet.
Il s'est également avéré que le script devait être exécuté, y compris pour l'enregistrement de groupes dans d'autres forêts (en utilisant le terme inter-domaines), 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 croisés, y compris la forêt voisine, peuvent désormais revendiquer l'accès aux ressources d'un domaine. Pour atteindre 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 moche, mais uniforme:
Ainsi, lors de l'enregistrement du projet 80XXX dans le domaine TG, le script exécute:
1. Création de l'unité d'organisation 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'unité d'organisation avec des groupes avec des noms de la forme <domaine SRC_> <domaine DST> <projet_ID> -, où:
- Domaine SRC_ - un domaine croisé dont les employés auront accès aux ressources du domaine DST
- DST_domain - domaine, aux ressources desquelles, en fait, l'accès doit être accordé, c'est-à-dire pour le bien duquel tout a été démarré
- <ID_project> - numéro de projet
- RÔLES - les noms des rôles répertoriés dans la matrice d'accès.
3. lire le tableau SID de tous les groupes de tous les domaines impliqués et l'enregistrer pour le transfert de données ultérieur dans un fichier qui détermine les droits sur un sous-dossier de projet spécifique
4. génération de fichiers source (paramètre / restauration) avec un ensemble d'autorisations pour utiliser l'utilitaire icacKC dans le mode de fichier exécutable "icacKC" \\ as-nasNN \ KC \ Projects "/ restaurer C: \ Temp \ KC \ KC40XX \ KC40XX.txt"
5. créer un fichier CMD qui combine tous les icacls lancés pour tous les dossiers de projet
Comme il a été écrit précédemment, le fichier exécutable est lancé manuellement et l'évaluation des résultats de l'exécution est également effectuée manuellement.
Difficultés rencontrées au final:
- si le dossier du projet est déjà rempli d'un grand nombre de fichiers, l'élaboration de la commande icacls sur les volumes disponibles peut prendre un temps considérable et, dans certains cas, conduire à un échec (par exemple, si les chemins d'accès aux fichiers sont longs);
- en plus de l'option / restore, j'ai dû ajouter des lignes avec l'option / reset au cas où des dossiers n'auraient pas été créés, mais auraient été transférés à partir de dossiers existants, avec des droits d'héritage désactivés depuis la racine;
- une partie du script pour créer des groupes devait être exécutée sur un dc arbitraire 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'utilitaires avec des fonctionnalités similaires sur le marché. Il semble possible de mettre en œuvre une telle fonctionnalité sur la base du portail Sharepoint.
Il fournit également un fait incompréhensible qu'il n'est pas possible d'utiliser les utilitaires PoSH pour définir des autorisations sur un dossier sur des appareils de sinologie.
À volonté, je suis prêt à partager le script en créant une sorte de projet sur github, si cela intéresse quelqu'un.