Anscheinend besteht mein Karma darin, Standardaufgaben auf alle möglichen, nicht trivialen Arten umzusetzen. Wenn jemand eine andere Sicht auf das Problem hat, besprechen Sie es bitte, damit das Problem gelöst werden kann.
Eines schönen Morgens ergab sich eine interessante Aufgabe, Rechte an Benutzergruppen für verschiedene Freigaben zu verteilen, die Unterordner von Projekten mit Dokumentordnern enthielten. Alles war in Ordnung und es wurde ein Skript geschrieben, um den Ordnern Rechte zuzuweisen. Und dann stellte sich heraus, dass die Gruppen Benutzer aus verschiedenen Domänen und aus verschiedenen Wäldern enthalten sollten (). Nehmen wir an, die Freigabe selbst befindet sich auf Synology-Medien und ist in der FB-Domäne der PSI-Gesamtstruktur registriert. Aufgabe: Benutzern von Domänen in einer anderen Gesamtstruktur den Zugriff auf die Inhalte dieser Freigabe zu ermöglichen, und zwar sehr selektiv.
Nach einiger Zeit nahmen die technischen Spezifikationen folgende Form an:
- 2 Wälder: PSI-Wald, TG-Wald.
- Jede Gesamtstruktur hat drei Domänen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Zwischen den Wäldern besteht eine Vertrauensbeziehung; Synology sieht alle Sicherheitsgruppen in allen Wäldern.
- Freigaben und Ordner/Unterordner müssen über FB-Domänenadministratorkonten mit FullControl-Rechten verfügen
- Die Namen der Ordner sollten systematisiert werden. Das Management koordinierte die Projekt-IDs; ich beschloss, den Namen der Sicherheitsgruppen mit den Projekt-IDs zu verknüpfen.
- Projektordner in Systemfreigaben müssen eine vorab in einer XLSX-Datei vorbereitete Struktur mit entsprechenden Zugriffsrechten (R/RW/NA, wobei NA – kein Zugriff) enthalten.
- Es sollte möglich sein, die Rechte von Benutzern/Gruppenmitgliedern eines Projekts nur auf bestimmte Verzeichnisse dieses Projekts zu beschränken. Abhängig von der Gruppenzugehörigkeit hat der Benutzer möglicherweise keinen Zugriff auf andere Verzeichnisse/Projekte.
- Beim Anlegen eines Projektordners sollten möglichst automatisch Gruppen in den entsprechenden Domänen angelegt werden, deren Namen den Projekt-IDs entsprechen.
Hinweise zu den technischen Spezifikationen
- Der Aufbau von Vertrauensverhältnissen ist nicht Gegenstand der technischen Spezifikationen
- Die Projekt-ID enthält Zahlen und lateinische Zeichen
- Projektbenutzerrollen für alle Domänen haben Standardnamen
- Vor dem Start des gesamten Projekts wird eine .xlsx-Datei mit Ordnern und Zugriffsrechten (Zugriffsmatrix) erstellt
- Bei der Umsetzung von Projekten besteht die Möglichkeit, Benutzergruppen in den entsprechenden Domänen anzulegen
- Die Automatisierung wird durch die Verwendung von Standard-MS-Windows-Verwaltungstools erreicht
Umsetzung technischer Spezifikationen
Nach der Formalisierung dieser Anforderungen wurde eine taktische Pause eingelegt, um Methoden zum Erstellen von Verzeichnissen und zum Zuweisen von Rechten zu testen. Es war beabsichtigt, nur PowerShell zu verwenden, um das Projekt nicht zu verkomplizieren. Wie ich bereits geschrieben habe, schien der Skriptalgorithmus recht einfach zu sein:
- Wir registrieren Gruppen mit einem Namen, der von der Projekt-ID abgeleitet ist (z. B. KC40587) und den entsprechenden Rollen, die in der Zugriffsmatrix angegeben sind: KC40587-EN- für Ingenieur; KC40587-PM – für Produktmanager usw.
- Wir erhalten die SIDs der erstellten Gruppen
- Registrieren Sie den Projektordner und die entsprechenden Verzeichnisse (die Liste der Unterordner hängt von der Freigabe ab, in der sie erstellt und in der Zugriffsmatrix definiert werden).
- Vergeben Sie Rechte an Gruppen für neue Unterverzeichnisse des Projekts gemäß der Zugriffsmatrix.
Auf Stufe 1 aufgetretene Schwierigkeiten:
- Missverständnis der Methode zur Angabe der Zugriffsmatrix im Skript (ein mehrdimensionales Array ist jetzt implementiert, aber der Pfad zum Füllen wird basierend auf dem Inhalt der .xlsx-Datei/Zugriffsmatrix gesucht)
- Unmöglichkeit, Zugriffsrechte in SMB-Freigaben auf Synology-Laufwerken mithilfe von PoSH festzulegen (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), wodurch viel Zeit verloren ging und alles mit dem Dienstprogramm zur Bearbeitung der Zugriffsrechte icacls an Skripte angepasst werden musste, was die Erstellung eines Zwischenspeichers für Text- und cmd-Dateien erforderte.
Im aktuellen Modus wird die Ausführung von cmd-Dateien manuell gesteuert, abhängig von der Notwendigkeit, einen Ordner für das Projekt zu registrieren.
Es stellte sich auch heraus, dass das Skript auch ausgeführt werden sollte, um Gruppen in anderen Wäldern zu registrieren (es wurde der Begriff domänenübergreifend verwendet), und das Verhältnis kann nicht nur 1 zu eins, sondern auch 1 zu viele sein.
Dies bedeutet, dass Gruppen aus anderen domänenübergreifenden, einschließlich einer benachbarten Gesamtstruktur, nun Zugriff auf die Ressourcen einer beliebigen Domäne beanspruchen können. Um Einheitlichkeit zu erreichen, wurde beschlossen, in der OU aller bedienten Domänen aller Wälder eine symmetrische Struktur zu schaffen (schwarze vertikale Ovale). Wie man so schön sagt, soll in der Armee alles hässlich, aber einheitlich sein:
Wenn Sie also das Projekt 80XXX in der TG-Domäne registrieren, führt das Skript Folgendes aus:
1. Erstellung der entsprechenden OU (rote horizontale Ovale) in dieser Domäne und domänenübergreifend, also denjenigen Domänen, deren Mitarbeiter Zugriff auf diese Ressource haben müssen.
2. OU mit Gruppen mit Namen wie füllen -, Wo:
- SRC_-Domäne – domänenübergreifend, deren Mitarbeiter Zugriff auf DST-Domänenressourcen haben
- DST_domain – die Domäne, auf deren Ressourcen eigentlich Zugriff gewährt werden soll, d. h. für die alles gestartet wurde
- - Projektnummer
- ROLLEN – Namen der in der Zugriffsmatrix aufgeführten Rollen.
3. Lesen des SID-Arrays aller Gruppen aller beteiligten Domänen und Speichern für die spätere Datenübertragung in einer Datei, die die Rechte für einen bestimmten Projektunterordner definiert
4. Generierung von Quelldateien (Parameter /restore) mit einer Reihe von Rechten zur Verwendung durch das icacKC-Dienstprogramm im ausführbaren Dateimodus „icacKC „as-nasNNKCProjects“ /restore C:TempKCKC40XXKC40XX.txt“
5. Erstellen einer CMD-Datei, die alle gestarteten ICACLs für alle Projektordner vereint
Wie bereits erwähnt, erfolgt der Start der ausführbaren Datei manuell und die Auswertung der Ausführungsergebnisse erfolgt ebenfalls manuell.
Schwierigkeiten, mit denen wir uns am Ende auseinandersetzen mussten:
- Wenn der Projektordner bereits mit einer großen Anzahl von Dateien gefüllt ist, kann die Ausführung des Befehls icacls auf den vorhandenen Volumes viel Zeit in Anspruch nehmen und in einigen Fällen zu Fehlern führen (z. B. bei langen Dateipfaden).
- Zusätzlich zum Parameter /restore mussten wir Zeilen mit dem Parameter /reset hinzufügen, falls die Ordner nicht erstellt, sondern aus zuvor vorhandenen Ordnern übertragen wurden, wobei die Vererbungsrechte vom Stammverzeichnis deaktiviert waren;
- Ein Teil des Skripts zum Erstellen von Gruppen musste auf einem beliebigen DC jedes Waldes ausgeführt werden. Das Problem betrifft die Administratorkonten für jeden Baum.
Allgemeine Schlussfolgerung: Es ist sehr seltsam, dass es noch keine Dienstprogramme mit ähnlicher Funktionalität auf dem Markt gibt. Es scheint möglich, eine ähnliche Funktionalität auf Basis des Sharepoint-Portals zu implementieren.
Es ist auch unverständlich, dass es nicht möglich ist, PoSH-Utilities zum Festlegen von Ordnerrechten auf Sinology-Geräten zu verwenden.
Falls gewünscht, bin ich bereit, das Skript zu teilen, indem ich ein Projekt auf Github erstelle, falls jemand Interesse hat.
Source: habr.com