Grootschalige toewijzing van rechten aan gebruikers van domeinen uit verschillende bossen

Blijkbaar is mijn karma zo: standaard taken op allerlei niet-triviale manieren uitvoeren. Als iemand een andere kijk op het probleem heeft, nodig ik uit tot discussie om de zaak verder te onderzoeken.

Op een mooie ochtend verscheen er een interessante taak om rechten toe te wijzen aan gebruikersgroepen voor verschillende shares, die submappen bevatten van projecten met documenten. Alles ging goed en er werd een script geschreven om de rechten op de mappen toe te wijzen. Toen bleek echter dat de groepen gebruikers van verschillende domeinen, uit verschillende forests moesten bevatten (voor wie vergeten is wat dit inhoudt.). Stel dat de share zelf wordt gehost op een Synology-opslag, geregistreerd in het domein FB, forest PSI. Taak: gebruikers van domeinen een ander forest toegang geven tot de inhoud van deze share, en dat op een zeer selectieve manier.

De technische specificaties ontvouwden zich na verloop van tijd in de volgende vorm:

• 2 forests: Forest PSI, forest TG.

  

• In elk forest zijn er 3 domeinen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Tussen de forests zijn er vertrouwensrelaties, Synology ziet alle Security groepen in alle forests.
• Bij shares en mappen/submappen moeten accounts voor de admins van domein FB met FullControl-rechten aanwezig zijn.
• De namen van de shares moeten geordend zijn. De goedkeuring van de project-ID's gebeurde door het management, ik besloot de namen van de Security groepen te koppelen aan de project-ID's.
• De projectmappen in de systeem shares moeten een vooraf voorbereide structuur in een .xlsx-bestand bevatten, met de bijbehorende toegangsprivileges (R/RW/NA, waar NA – geen toegang betekent).

  

• Er moet de mogelijkheid zijn om de rechten van gebruikers/groepsleden van één project alleen tot bepaalde mappen van dat project te beperken. Voor andere mappen/projecten mag de gebruiker geen toegang hebben, afhankelijk van hun lidmaatschap in de groepen.
• Bij het aanmaken van een projectmap moeten automatisch groepen in de bijbehorende domeinen worden aangemaakt met namen die overeenkomen met de project-ID's.

Opmerkingen bij de technische specificaties.

• Het instellen van vertrouwensrelaties valt niet binnen de reikwijdte van de specificatie.
• De project-ID bevat cijfers en letters.
• Projectrollen voor alle domeinen hebben standaard benamingen.
• Het .xlsx-bestand met mappen en toegangsrechten (toegangsmatrix) wordt voorbereid voordat de uitvoering van het project begint.
• Bij de uitvoering van projecten kan het nodig zijn om gebruikersgroepen in de bijbehorende domeinen aan te maken.
• Automatisering wordt bereikt door gebruik te maken van de standaard beheertools van MS Windows

Implementatie van de specificaties

Na de formalisering van deze eisen werd er een tactische pauze genomen om de methoden voor het creëren van mappen en het toekennen van rechten daarop uit te proberen. Alleen PowerShell zou worden gebruikt om het project niet te compliceren. Zoals ik eerder al schreef, leek het algoritme van het script vrij eenvoudig:

• We registreren groepen met een naam afgeleid van het project-ID (bijvoorbeeld KC40587) en de bijbehorende rollen zoals aangegeven in de toegangsmatrix: KC40587-EN- voor de ingenieur; KC40587-PM – voor de productmanager, enzovoorts.
• We verkrijgen de SID's van de aangemaakte groepen
• We registreren de projectmap en de bijbehorende set mappen (de lijst met submappen hangt af van de share waarin deze wordt aangemaakt en is gedefinieerd in de toegangsmatrix)
• We wijzen rechten op de nieuwe submappen van het project toe aan de groepen overeenkomstig de toegangsmatrix.

Moeilijkheden waarmee we geconfronteerd werden in de eerste fase:

• Onbegrip over hoe de toegangsmatrix in het script moet worden ingesteld (momenteel is er een multidimensionale array geïmplementeerd, maar er wordt naar een manier gezocht om deze in te vullen op basis van de inhoud van het .xlsx-bestand/de toegangsmatrix)

  

• Onmogelijk om toegangrechten op SMB-shares op Synology-opslag toe te wijzen met behulp van PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), waardoor er veel tijd verloren is gegaan en alles moest worden aangepast voor scripts met behulp van de icacls-toegangrechten-editor, wat de creatie van een tussenopslag van tekst- en cmd-bestanden vereiste.

In de huidige modus wordt de uitvoering van cmd-bestanden handmatig gecontroleerd, afhankelijk van de noodzaak om een map voor het project te registreren.

Het bleek ook dat het script moet worden uitgevoerd om groepen in andere forests te registreren (we gebruikten de term Cross-domains), waarbij de verhouding niet alleen 1 op 1 kan zijn, maar ook 1 op veel.

Dit betekent dat groepen uit andere cross-domains, inclusief de aangrenzende forest, nu ook aanspraak kunnen maken op toegang tot de bronnen van een bepaald domein. Om uniformiteit te realiseren, werd besloten om een symmetrische structuur in de OU van alle bediende domeinen in alle forests te creëren (zwarte verticale ovalen). Zoals men zegt, moet alles in het leger ongeordend maar uniform zijn:

Bij de registratie van project 80XXX in het domein TG wordt het volgende gedaan met het script:

1. aanmaken van de bijbehorende OU (rode horizontale ovalen) in dit domein en cross-domeinen, dat zijn de domeinen waarvan medewerkers toegang moeten hebben tot deze bron.

2. vullen van de OU met groepen met namen zoals <SRC_domein><DST_domein><ID_project>-, waarbij:

• SRC_domein – cross-domein waarvan de medewerkers toegang hebben tot de bronnen van het DST-domein
• DST_domein – het domein waarvan toegang moet worden verleend tot de bronnen, met andere woorden, waar alles voor bedoeld is
• <ID_project> — het nummer van het project
• ROLES – namen van de rollen vermeld in de toegangs matrix.

3. uitlezen van de array SID van alle groepen van alle betrokken domeinen en deze opslaan voor een latere gegevensoverdracht naar een bestand dat de rechten op een specifieke submap van het project definieert

4. genereren van bronbestanden (parameter /restore) met een set rechten voor gebruik in de icacKC-tool in de uitvoerbare modus "icacKC \"as-nasNNKCProjects\" /restore C:TempKCKC40XXKC40XX.txt"

5. aanmaken van een CMD-bestand dat alle icacls-opdrachten voor alle mappen van het project samenvoegt

Zoals eerder vermeld, wordt het uitvoerbare bestand handmatig gestart en de beoordeling van de resultaten van de uitvoering wordt ook handmatig uitgevoerd.

De moeilijkheden waarmee uiteindelijk werd geconfronteerd:

• als de projectmap al is gevuld met een groot aantal bestanden, kan de verwerking van de icacls-opdracht op de bestaande bestanden aanzienlijke tijd in beslag nemen en in sommige gevallen leiden tot een weigering (bijvoorbeeld bij lange bestandsnamen);
• naast de parameter /restore moest ik regels toevoegen met de parameter /reset voor het geval mappen niet werden aangemaakt, maar werden verplaatst vanuit reeds bestaande mappen, met uitgeschakelde erfelijkheid van rechten vanaf de root;
• een deel van het script voor het aanmaken van groepen moest worden uitgevoerd op willekeurige dc's van elke forest, het probleem betreft administratieve accounts voor elke tree.

Algemene conclusie: het is vreemd dat er momenteel geen tools op de markt zijn met dergelijke functionaliteit. Een implementatie van vergelijkbare functionaliteit lijkt mogelijk op basis van het SharePoint-portaal.
Het is ook onduidelijk waarom er geen mogelijkheid is om PoSH-tools te gebruiken voor het instellen van rechten op mappen op Sinology-apparaten.

Op verzoek ben ik bereid het script te delen door een project op GitHub aan te maken, als dit iemand interesseert.

Bron: habr.com