Umfangreiche Rechtevergabe an Domänenbenutzer aus unterschiedlichen Forests

Das ist offenbar mein Karma: Standardaufgaben auf alle möglichen nicht trivialen Arten umzusetzen. Wenn jemand eine andere Sicht auf das Problem hat, beteiligen Sie sich bitte an der Diskussion, um das Problem zu lösen.

Eines schönen Morgens ergab sich eine interessante Aufgabe: Rechte an Benutzergruppen auf verschiedenen Freigaben zu verteilen, die Projektunterordner mit Dokumentordnern enthielten. Alles war in Ordnung und es wurde ein Skript geschrieben, das den Ordnern Rechte zuweist. Und dann stellte sich heraus, dass die Gruppen Benutzer aus verschiedenen Domänen, aus verschiedenen Wäldern enthalten sollten (für diejenigen, die vergessen haben, was es istAngenommen, die Freigabe selbst befindet sich auf einem Synology-Laufwerk, das in der FB-Domäne der PSI-Gesamtstruktur registriert ist. Die Aufgabe besteht darin, Benutzern den Zugriff zu ermöglichen. domenov ein anderer Wald, um Zugang zum Inhalt dieser Kugel zu erhalten, und zwar sehr selektiv.

Nach einiger Zeit nahmen die technischen Spezifikationen folgende Form an:

• 2 Wälder: PSI-Wald, TG-Wald.

  

• Jeder Wald hat 3 Domänen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Zwischen den Gesamtstrukturen besteht eine Vertrauensbeziehung. Synology sieht alle Sicherheitsgruppen in allen Gesamtstrukturen.
• Freigaben und Ordner/Unterordner müssen über FB-Domänenadministratorkonten mit Vollzugriffsrechten verfügen
• Die Namen der Ordner im Ball sollten systematisiert werden. Das Management war für die Koordinierung der Projekt-IDs verantwortlich und ich beschloss, die Namen der Sicherheitsgruppen mit den Projekt-IDs zu verknüpfen.
• Projektordner in Systemfreigaben müssen eine vorab in einer XLSX-Datei vorbereitete Struktur mit den entsprechenden Zugriffsrechten (R/RW/NA, wobei NA keinen Zugriff bedeutet) enthalten.

  

• Es sollte möglich sein, die Rechte von Benutzern/Gruppenmitgliedern eines Projekts auf bestimmte Verzeichnisse dieses Projekts zu beschränken. Aufgrund der Gruppenmitgliedschaft hat der Benutzer möglicherweise keinen Zugriff auf andere Verzeichnisse/Projekte.
• Beim Anlegen eines Projektordners sollen möglichst automatisch Gruppen in den entsprechenden Domänen angelegt werden, deren Namen den Projekt-IDs entsprechen.

Hinweise zu den technischen Daten

• Der Aufbau von Vertrauensbeziehungen ist nicht im Leistungsumfang enthalten.
• Die Projekt-ID enthält Zahlen und lateinische Buchstaben
• Projektbenutzerrollen für alle Domänen haben Standardnamen
• Die .xlsx-Datei mit Ordnern und Zugriffsrechten (Zugriffsmatrix) wird vor Beginn des gesamten Projekts erstellt.
• Bei der Umsetzung von Projekten besteht die Möglichkeit, Benutzergruppen in den entsprechenden Domänen zu erstellen.
• Die Automatisierung wird durch den Einsatz von Standard-MS-Verwaltungstools erreicht. Windows

Umsetzung der technischen Spezifikationen

Nach der Formalisierung dieser Anforderungen wurde eine taktische Pause eingelegt, um Methoden zum Erstellen von Verzeichnissen und zum Zuweisen von Rechten an diese zu testen. Um das Projekt einfach zu halten, sollte nur PowerShell verwendet werden. Wie ich bereits schrieb, schien der Skriptalgorithmus recht einfach zu sein:

• Wir registrieren Gruppen mit einem Namen, der aus der Projekt-ID abgeleitet ist (z. B. KC40587) und den entsprechenden Rollen, die in der Zugriffsmatrix angegeben sind: KC40587-EN – für einen Ingenieur; KC40587-PM – für Produktmanager usw.
• wir erhalten 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 wird).
• Für neue Projektunterverzeichnisse vergeben wir Rechte an Gruppen entsprechend der Zugriffsmatrix.

In Phase 1 aufgetretene Schwierigkeiten:

• Missverständnis der Methode zur Angabe der Zugriffsmatrix im Skript (derzeit ist ein mehrdimensionales Array implementiert, es wird jedoch nach einer Möglichkeit gesucht, es basierend auf dem Inhalt der XLSX-Datei/Zugriffsmatrix zu füllen)

  

• Unmöglichkeit, Zugriffsrechte in SMB-Freigaben auf Synology-Laufwerken mit 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 für Skripte mit dem Dienstprogramm zur Bearbeitung von Zugriffsrechten icacls angepasst werden musste, was die Erstellung eines Zwischenrepositorys mit Text- und Befehlsdateien erforderte.

Im aktuellen Modus wird die Ausführung von cmd-Dateien manuell gesteuert, basierend auf der Notwendigkeit, einen Ordner für das Projekt zu registrieren.

Es stellte sich auch heraus, dass das Skript ausgeführt werden muss, auch um Gruppen in anderen Gesamtstrukturen zu registrieren (der Begriff „Cross-Domains“ wurde verwendet) und das Verhältnis nicht nur 1 zu eins, sondern auch 1 zu viele betragen kann.

Dies bedeutet, dass Gruppen aus anderen domänenübergreifenden Bereichen, einschließlich benachbarter Gesamtstrukturen, nun Zugriff auf Ressourcen jeder beliebigen Domäne beanspruchen können. Um Einheitlichkeit zu erreichen, wurde beschlossen, in der OU eine symmetrische Struktur aller bedienten Domänen aller Wälder zu erstellen (schwarze vertikale Ovale). Wie man sagt, sollte in der Armee alles hässlich, aber einheitlich sein:

Daher führt das Skript beim Registrieren des 80XXX-Projekts in der TG-Domäne Folgendes aus:

1. Erstellen der entsprechenden OU (rote horizontale Ovale) in der angegebenen Domäne und domänenübergreifend, d. h. in den Domänen, deren Mitarbeiter Zugriff auf die angegebene Ressource haben sollen.

2. Füllen der OU mit Gruppen mit Namen wie -, Wo:

• SRC_-Domäne – domänenübergreifend, deren Mitarbeiter Zugriff auf die DST-Domänenressourcen haben
• DST_domain – die Domäne, auf deren Ressourcen eigentlich Zugriff gewährt werden sollte, 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. Generieren von Quelldateien (Parameter /restore) mit einer Reihe von Rechten zur Verwendung durch das Dienstprogramm icacKC im ausführbaren Dateimodus "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

5. Erstellen einer CMD-Datei, die alle für alle Projektordner gestarteten icacls kombiniert

Wie bereits erwähnt, wird die ausführbare Datei manuell gestartet und die Auswertung der Ausführungsergebnisse erfolgt ebenfalls manuell.

Schwierigkeiten, die am Ende bewältigt werden mussten:

• Wenn der Projektordner bereits mit einer großen Anzahl von Dateien gefüllt ist, kann die Verarbeitung des icacls-Befehls auf den verfügbaren Datenträgern sehr viel Zeit in Anspruch nehmen und in einigen Fällen zu einem Fehler führen (z. B. bei langen Dateipfaden).
• zusätzlich zum Parameter /restore mussten Zeilen mit dem Parameter /reset hinzugefügt werden, falls die Ordner nicht erstellt, sondern aus bereits vorhandenen Ordnern übertragen wurden, wobei die Vererbungsrechte vom Stammverzeichnis deaktiviert waren;
• Ein Teil des Skripts zum Erstellen von Gruppen musste auf einem zufälligen DC jedes Forests ausgeführt werden. Das Problem betrifft Administratorkonten für jeden Baum.

Allgemeines Fazit: Es ist sehr merkwürdig, dass es noch keine Dienstprogramme mit ähnlicher Funktionalität auf dem Markt gibt. Es scheint möglich, ähnliche Funktionen auf Basis des Sharepoint-Portals zu implementieren.
Unklar ist auch, dass es keine Möglichkeit gibt, mithilfe von PoSH-Dienstprogrammen Rechte für einen Ordner auf Sinology-Geräten festzulegen.

Falls gewünscht, bin ich bereit, das Skript zu teilen, indem ich ein Projekt auf GitHub erstelle, falls jemand Interesse hat.

Source: habr.com