Anscheinend lautet mein Karma: Standardaufgaben auf alle möglichen nicht-trivialen Arten umsetzen. Wenn jemand eine andere Sicht des Problems hat - bitte ich um Diskussion, um das Problem zu lösen.
Eines schönen Morgens tauchte eine interessante Aufgabe auf: Rechte an Benutzergruppen auf verschiedenen Bällen zu verteilen, die Projektunterordner mit Dokumentenordnern enthalten. Alles war in Ordnung und ein Skript wurde zugewiesen, das den Ordnern Rechte zuweist. Und dann stellte sich heraus, dass die Gruppen Benutzer verschiedener Domänen aus verschiedenen Gesamtstrukturen enthalten sollten (
für diejenigen, die vergessen haben, was es ist ). Angenommen, der Ball selbst wird auf Synology-Medien gehostet, die in der FB-Domäne der PSI-Gesamtstruktur registriert sind. Ziel: Benutzern von Domänen in einer anderen Gesamtstruktur den Zugriff auf den Inhalt dieses Balls zu ermöglichen, und zwar sehr selektiv.
TK zeichnete sich nach einiger Zeit in folgender Form ab:
- 2 Wälder: PSI Forest, TG Forest.
- Jede Gesamtstruktur hat 3 Domänen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Es besteht eine vertrauensvolle Beziehung zwischen Gesamtstrukturen. Synology sieht alle Sicherheitsgruppen in allen Gesamtstrukturen.
- Sprechblasen und Ordner / Unterordner müssen über FB-Domänenadministratorkonten mit FullControl-Rechten verfügen
- Die Namen der Sprechblasenordner sollten systematisiert werden. Das Management handelte die Projekt-IDs aus und ich beschloss, den Projekt-IDs den Namen der Sicherheitsgruppen zuzuweisen.
- Projektordner in den Systembällen sollten eine im Voraus in der XLSX-Datei vorbereitete Struktur mit entsprechenden Zugriffsberechtigungen enthalten (R / RW / NA, wobei NA - kein Zugriff).
- Es sollte möglich sein, die Rechte von Benutzern / Gruppenmitgliedern eines Projekts nur auf bestimmte Verzeichnisse dieses Projekts zu beschränken. Der Benutzer hat möglicherweise keinen Zugriff auf andere Verzeichnisse / Projekte, je nach Gruppenzugehörigkeit.
- Beim Anlegen eines Projektordners sollten möglichst automatisch Gruppen in den entsprechenden Domänen mit den Namen der entsprechenden Projekt-IDs angelegt werden.
Anmerkungen zum ToR
- Vertrauensbildende Beziehungen gehören nicht zur TK
- Die Projekt-ID enthält Zahlen und lateinische Buchstaben
- Projektbenutzerrollen für alle Domänen haben generische Namen
- Vor dem Start des gesamten Projekts wird eine XLSX-Datei mit Ordnern und Berechtigungen (Zugriffsmatrix) erstellt
- Bei der Implementierung von Projekten ist es möglich, Benutzergruppen in den entsprechenden Domänen anzulegen
- Die Automatisierung erfolgt mit Standard-MS-Windows-Administrationstools
TK-Implementierung
Nach der Formalisierung dieser Anforderungen wurde eine taktische Pause eingelegt, um die Methoden zum Erstellen von Verzeichnissen und zum Zuweisen von Rechten zu testen. Es sollte nur PowerShell verwendet werden, um das Projekt nicht zu komplizieren. Wie ich bereits schrieb, schien der Skriptalgorithmus recht einfach zu sein:
- Registrieren Sie Gruppen mit dem aus der Projekt-ID abgeleiteten Namen (z. B. KC40587) und den entsprechenden in der Zugriffsmatrix angegebenen Rollen: KC40587-DE- für den Bearbeiter; KC40587-PM - für Produktmanager usw.
- Rufen Sie die SIDs der erstellten Gruppen ab
- Registrieren Sie den Projektordner und die entsprechenden Verzeichnisse (die Liste der Unterordner hängt von den Bällen ab, in denen er erstellt und in der Zugriffsmatrix definiert wurde).
- Zuweisen von Rechten zu Gruppen gemäß der Zugriffsmatrix zu neuen Unterverzeichnissen des Projekts.
Schwierigkeiten in Stufe 1:
- Mangelndes Verständnis für die Art und Weise, wie die Zugriffsmatrix im Skript festgelegt wird (ein mehrdimensionales Array ist jetzt implementiert, es wird jedoch nach einer Möglichkeit gesucht, es basierend auf dem Inhalt der XLSX-Datei / Zugriffsmatrix zu füllen.)
- die Unmöglichkeit, Zugriffsrechte in SMB-Bällen 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 ich alles mit dem Dienstprogramm icacls permissions editing an Skripte anpassen musste, das die Erstellung eines Zwischenspeichers mit Text- und Cmd-Dateien erforderte.
Im aktuellen Modus wird die Ausführung von Cmd-Dateien manuell gesteuert, wenn ein Ordner für das Projekt registriert werden muss.
Es stellte sich auch heraus, dass das Skript ausgeführt werden sollte, auch zum Registrieren von Gruppen in anderen Gesamtstrukturen (unter Verwendung des Begriffs Domänenübergreifend), und das Verhältnis kann nicht nur 1 zu 1, sondern auch 1 zu vielen betragen.
Dies bedeutet, dass Gruppen aus anderen Domänen, einschließlich der benachbarten Gesamtstruktur, nun Zugriff auf die Ressourcen einer Domäne beanspruchen können. Um eine Einheitlichkeit zu erreichen, wurde beschlossen, eine symmetrische Struktur in der Organisationseinheit aller bedienten Domänen aller Wälder (schwarze vertikale Ovale) zu erstellen. In der Armee soll alles hässlich, aber einheitlich sein:
Wenn Sie also das 80XXX-Projekt in der TG-Domäne registrieren, führt das Skript Folgendes aus:
1. Erstellen der entsprechenden Organisationseinheit (rote horizontale Ovale) in dieser Domäne und domänenübergreifend, dh in den Domänen, deren Mitarbeiter Zugriff auf diese Ressource haben müssen.
2. Füllen Sie die Organisationseinheit mit Gruppen mit Namen der Form <SRC_Domain> <DST_Domain> <ID_Projekt> -, wobei:
- SRC_-Domäne - Eine domänenübergreifende Domäne, deren Mitarbeiter Zugriff auf DST-Domänenressourcen haben
- DST_domain - Domäne, zu deren Ressourcen tatsächlich Zugriff gewährt werden soll, dh zu deren Gunsten alles gestartet wurde
- <ID_Projekt> - Projektnummer
- ROLES - die Namen der in der Zugriffsmatrix aufgelisteten Rollen.
3. Lesen Sie das SID-Array aller Gruppen aller beteiligten Domänen und speichern Sie es für die anschließende Datenübertragung in einer Datei, die die Rechte für einen bestimmten Projekt-Unterordner festlegt
4. Generieren von Quelldateien (Parameter / Restore) mit einer Reihe von Berechtigungen für die Verwendung des Dienstprogramms icacKC im ausführbaren Dateimodus "icacKC" \\ as-nasNN \ KC \ Projects "/ restore C: \ Temp \ KC \ KC40XX \ KC40XX.txt"
5. Erstellen einer CMD-Datei, die alle gestarteten icacls für alle Projektordner kombiniert
Wie bereits geschrieben, wird die ausführbare Datei manuell gestartet und die Auswertung der Ergebnisse der Ausführung erfolgt ebenfalls manuell.
Am Ende aufgetretene Schwierigkeiten:
- Wenn der Projektordner bereits mit einer großen Anzahl von Dateien gefüllt ist, kann das Ausarbeiten des Befehls icacls auf den verfügbaren Volumes viel Zeit in Anspruch nehmen und in einigen Fällen zu einem Fehler führen (z. B. wenn lange Dateipfade vorhanden sind).
- Zusätzlich zur Option / restore musste ich Zeilen mit der Option / reset hinzufügen, falls Ordner nicht erstellt, sondern aus zuvor vorhandenen Ordnern mit deaktivierten Vererbungsrechten aus dem Stammverzeichnis übertragen wurden.
- Ein Teil des Skripts zum Erstellen von Gruppen musste auf einem beliebigen DC jeder Gesamtstruktur ausgeführt werden. Das Problem betrifft administrative Konten für jeden Baum.
Allgemeines Fazit: Es ist sehr merkwürdig, dass es auf dem Markt noch keine Versorgungsunternehmen mit ähnlichen Funktionen gibt. Eine solche Funktionalität scheint auf Basis des Sharepoint-Portals realisierbar zu sein.
Es ist auch unverständlich, dass PoSH-Dienstprogramme nicht zum Festlegen von Berechtigungen für einen Ordner auf Sinologiegeräten verwendet werden können.
Nach Belieben bin ich bereit, das Skript mit anderen zu teilen, indem ich ein Projekt auf Github erstelle, wenn es für jemanden interessant ist.