Umfangreiche Berechtigungsvergabe an Benutzer von Domänen aus verschiedenen Wäldern

Offensichtlich habe ich so etwas wie Karma: Standardaufgaben auf verschiedene, unkonventionelle Weisen zu lösen. Wenn jemand eine andere Sichtweise auf das Problem hat, bitte ich um Diskussion, um die Angelegenheit zu klären.

Eines schönen Morgens tauchte eine interessante Aufgabe auf: Benutzergruppen die Berechtigungen für verschiedene Shares zuzuweisen, die Unterordner von Projekten mit Dokumentenordnern enthalten. Alles war gut und es wurde ein Skript geschrieben, das Berechtigungen für die Ordner zuwies. Dann stellte sich heraus, dass die Gruppen Benutzer aus verschiedenen Domänen, aus verschiedenen Foresten enthalten müssen (für diejenigen, die vergessen haben, was das ist). Angenommen, das Share selbst befindet sich auf einem Synology-Gerät, das in der Domäne FB, im Forest PSI registriert ist. Aufgabe: Benutzer des Domains anderen Forests den Zugriff auf den Inhalt dieses Shares zu gewähren, und zwar sehr selektiv.

Das Lastenheft kristallisierte sich nach einiger Zeit wie folgt heraus:

• 2 Forests: Forest PSI, Forest TG.

  

• In jedem Forest gibt es 3 Domänen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Zwischen den Forests bestehen Vertrauensverhältnisse, Synology sieht alle Security-Gruppen in allen Forests.
• Auf den Shares und Ordnern/Unterordnern müssen unbedingt Konten von Domain-Admins aus der Domäne FB mit FullControl-Rechten vorhanden sein.
• Die Namen der Ordner im Share müssen systematisch organisiert sein. Die Genehmigung der Projekt-IDs erfolgte durch die Leitung, ich entschied, die Namen der Security-Gruppen an die Projekt-IDs zu koppeln.
• Die Projektordner in den systemisierten Shares müssen eine im .xlsx-Dokument vorbereitete Struktur mit den entsprechenden Zugriffsprivilegien (R/RW/NA, wobei NA – kein Zugriff) enthalten.

  

• Es muss möglich sein, die Rechte der Benutzer/Gruppenmitglieder eines Projekts nur auf bestimmte Verzeichnisse dieses Projekts zu beschränken. Auf andere Verzeichnisse/Projekte kann der Benutzer keinen Zugriff haben, abhängig von der Mitgliedschaft in den Gruppen.
• Beim Erstellen eines Projektordners sollten in den entsprechenden Domänen automatisch Gruppen mit Namen, die den Projekt-IDs entsprechen, erstellt werden.

Anmerkungen zum Lastenheft

• Die Einrichtung von Vertrauensverhältnissen ist nicht Teil des Lastenhefts.
• Die Projekt-ID enthält Ziffern und lateinische Buchstaben.
• Die Rollen der Projektbenutzer für alle Domänen haben standardisierte Namen.
• Die .xlsx-Datei mit Ordnern und Zugriffsrechten (Zugriffs-Matrix) wird vor Beginn der gesamten Projektumsetzung vorbereitet.
• Bei der Umsetzung von Projekten kann die Erstellung von Benutzergruppen in den entsprechenden Domänen erfolgen.
• Automatisierung erfolgt durch die Nutzung der Standardverwaltungsmittel von MS Windows

Umsetzung der Anforderungen

Nach der Formalisierung dieser Anforderungen gab es eine taktische Pause zur Erprobung der Methoden zur Erstellung von Verzeichnissen und der Vergabe von Rechten auf diese. Es sollte nur PowerShell verwendet werden, um das Projekt nicht zu komplizieren. Wie bereits erwähnt, stellte sich der Algorithmus des Skripts als recht einfach dar:

• Wir registrieren Gruppen mit einem Namen, der sich von der Projekt-ID ableitet (zum Beispiel KC40587) und den entsprechenden Rollen, die in der Zugriffsmatrix angegeben sind: KC40587-EN- für Ingenieure; KC40587-PM – für Produktmanager usw.
• wir erhalten die SID der erstellten Gruppen
• wir registrieren den Projektordner und das entsprechende Set von Verzeichnissen (die Liste der Unterordner hängt vom Share ab, in dem er erstellt wird, und ist in der Zugriffsmatrix definiert)
• wir vergeben Rechte an den neuen Unterverzeichnissen des Projekts an Gruppen gemäß der Zugriffsmatrix.

Schwierigkeiten, mit denen wir in der ersten Phase konfrontiert waren:

• Unverständnis über die Art und Weise, wie die Zugriffsmatrix im Skript angegeben wird (momentan wird ein mehrdimensionales Array implementiert, aber es wird nach einem Weg gesucht, um es basierend auf dem Inhalt einer .xlsx-Datei/Zugriffsmatrix zu füllen)

  

• Unfähigkeit, Zugriffsrechte in SMB-Shares auf Synology-Speichern mit Hilfe von PowerShell 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 an Skripte unter Verwendung des Tools zur Bearbeitung von Zugriffsrechten icacls angepasst werden musste, was die Erstellung eines temporären Speichers für Text- und CMD-Dateien erforderte.

Im aktuellen Modus wird die Ausführung von CMD-Dateien manuell kontrolliert, falls es notwendig ist, den Ordner für das Projekt zu registrieren.

Es stellte sich auch heraus, dass das Skript auch zur Registrierung von Gruppen in anderen Wäldern (wir verwendeten den Begriff Cross-Domains) ausgeführt werden muss, wobei das Verhältnis nicht nur 1 zu 1, sondern auch 1 zu vielen betragen kann.

Das bedeutet, dass auf den Zugriff auf Ressourcen eines bestimmten Dominis nun Gruppen aus anderen Cross-Domains, einschließlich des benachbarten Waldes, Anspruch erheben können. Um Einheitlichkeit zu gewährleisten, wurde beschlossen, eine symmetrische Struktur in den OU aller verwalteten Domains aller Wälder zu schaffen (schwarze vertikale Ovale). Wie man sagt, sollte in der Armee alles unordentlich, aber einheitlich sein:

Daher wird bei der Registrierung des Projekts 80XXX in der Domäne TG durch das Skript folgendes durchgeführt:

1. Erstellung der entsprechenden OU (rote horizontale Ovale) in dieser Domäne und in Cross-Domänen, das heißt in denen, deren Mitarbeiter Zugang zu dieser Ressource haben sollen.

2. Befüllung der OU mit Gruppen mit Bezeichnungen wie -, wobei:

• SRC_domain – Cross-Domäne, deren Mitarbeiter Zugriff auf die Ressourcen der DST-Domäne haben werden.
• DST_domain – Domäne, auf deren Ressourcen tatsächlich Zugriff gewährt werden soll, sprich der Grund, warum alles umgesetzt wird.
• — Projektnummer.
• ROLES – Bezeichnungen der in der Zugangsmatrix aufgeführten Rollen.

3. Auslesen des Arrays SID aller Gruppen aller beteiligten Domänen und Speicherung dessen zur späteren Übertragung der Daten in eine Datei, die die Berechtigungen für einen bestimmten Unterordner des Projekts definiert.

4. Generierung von Quelldateien (Parameter /restore) mit einem Berechtigungsset zur Verwendung des Dienstprogramms icacKC im Modus der ausführbaren Datei "icacKC \"as-nasNNKCProjects\" /restore C:TempKCKC40XXKC40XX.txt".

5. Erstellung einer CMD-Datei, die alle ausführbaren icacls für alle Ordner des Projekts kombiniert.

Wie bereits erwähnt, erfolgt die Ausführung der ausführbaren Datei manuell, und die Auswertung der Ergebnisse erfolgt ebenfalls manuell.

Die Schwierigkeiten, mit denen wir letztendlich konfrontiert waren:

• Wenn der Projektordner bereits mit einer großen Anzahl von Dateien gefüllt ist, kann die Bearbeitung des icacls-Befehls auf dem vorhandenen Volumen erheblich Zeit in Anspruch nehmen und in einigen Fällen zu einem Fehler führen (z.B. bei langen Dateipfaden);
• Neben dem Parameter /restore mussten Zeilen mit dem Parameter /reset hinzugefügt werden, falls Ordner nicht erstellt, sondern aus bereits existierenden Ordnern mit deaktivierten Vererbungseinstellungen vom Stamm verschoben wurden;
• Einen Teil des Skripts zur Erstellung von Gruppen musste ich auf willkürlichen DCs jeder Baumstruktur ausführen, das Problem betrifft die administrativen Konten für jeden Baum.

Insgesamt ist es sehr seltsam, dass es auf dem Markt bisher keine Dienstprogramme mit einer ähnlichen Funktionalität gibt. Eine Umsetzung einer solchen Funktionalität auf der Basis des SharePoint-Portals erscheint möglich.
Es ist ebenfalls unverständlich, warum es keine Möglichkeit gibt, PoSH-Dienstprogramme zur Festlegung von Berechtigungen für Ordner auf Synology-Geräten zu verwenden.

Auf Wunsch bin ich bereit, das Skript zu teilen, indem ich ein Projekt auf GitHub erstelle, falls es jemanden interessiert.

Quelle: habr.com