Blijkbaar is mijn karma dit: standaardtaken op allerlei niet-triviale manieren implementeren. Als iemand een andere visie op het probleem heeft, bespreek dit dan zodat het probleem kan worden opgelost.
Op een mooie ochtend deed zich een interessante taak voor om rechten te verdelen onder groepen gebruikers voor verschillende shares die submappen van projecten met documentmappen bevatten. Alles was in orde en er is een script geschreven om rechten aan de mappen toe te kennen. En toen bleek dat de groepen gebruikers uit verschillende domeinen moesten bevatten, uit verschillende forests (). Laten we zeggen dat de share zelf zich op Synology-media bevindt, geregistreerd in het FB-domein van het PSI-forest. Taak: gebruikers van domeinen in een ander forest toegang geven tot de inhoud van deze share, en wel zeer selectief.
Na enige tijd namen de technische specificaties de volgende vorm aan:
- 2 bossen: PSI-bos, TG-bos.
- Elk bos heeft 3 domeinen: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Er bestaat een vertrouwensrelatie tussen forests; Synology ziet alle beveiligingsgroepen in alle forests.
- Shares en mappen/submappen moeten FB-domeinbeheerdersaccounts hebben met FullControl-rechten
- De namen van de mappen moeten worden gesystematiseerd. Het management coördineerde de project-ID's; ik besloot de naam van de Security-groepen aan de project-ID's te koppelen.
- Projectmappen in systeemshares moeten een structuur bevatten die vooraf is voorbereid in een .xlsx-bestand, met de juiste toegangsrechten (R/RW/NA, waarbij NA – geen toegang)
- Het zou mogelijk moeten zijn om de rechten van gebruikers/groepsleden van één project te beperken tot slechts bepaalde mappen van dat project. Afhankelijk van het groepslidmaatschap heeft de gebruiker mogelijk geen toegang tot andere mappen/projecten.
- Bij het aanmaken van een projectmap moeten groepen zo automatisch mogelijk worden aangemaakt in de juiste domeinen met namen die overeenkomen met project-ID's.
Toelichting bij de technische specificaties
- Het opzetten van vertrouwensrelaties valt niet onder de reikwijdte van de technische specificaties
- Project-ID bevat cijfers en Latijnse tekens
- Projectgebruikersrollen voor alle domeinen hebben standaardnamen
- Vóór de start van het gehele project wordt een .xlsx-bestand met mappen en toegangsrechten (toegangsmatrix) opgesteld
- Bij het implementeren van projecten is het mogelijk om gebruikersgroepen in de betreffende domeinen aan te maken
- Automatisering wordt bereikt door gebruik te maken van standaard MS Windows-beheertools
Implementatie van technische specificaties
Na het formaliseren van deze vereisten werd een tactische pauze genomen om methoden te testen voor het maken van mappen en het toewijzen van rechten daaraan. Het was de bedoeling om alleen PowerShell te gebruiken, om het project niet ingewikkelder te maken. Zoals ik eerder schreef, leek het scriptalgoritme vrij eenvoudig:
- we registreren groepen met een naam afgeleid van het project-ID (bijvoorbeeld KC40587) en de bijbehorende rollen gespecificeerd in de toegangsmatrix: KC40587-EN- voor engineer; KC40587-PM – voor productmanager, enz.
- we krijgen de SID's van de gemaakte groepen
- registreer de projectmap en de bijbehorende set mappen (de lijst met submappen is afhankelijk van de share waarin deze is gemaakt en gedefinieerd in de toegangsmatrix)
- wijs rechten toe aan groepen voor nieuwe submappen van het project volgens de toegangsmatrix.
Moeilijkheden in fase 1:
- misverstand over de methode voor het specificeren van de toegangsmatrix in het script (er is nu een multidimensionale array geïmplementeerd, maar het pad om deze te vullen wordt gezocht op basis van de inhoud van het .xlsx-bestand/toegangsmatrix)
- onmogelijkheid om toegangsrechten in SMB-shares op synology-schijven in te stellen 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 ging en alles moest worden aangepast aan scripts met behulp van het icacls bewerkingshulpprogramma voor toegangsrechten, waarvoor een tussenopslag van tekst- en cmd-bestanden moest worden aangemaakt.
In de huidige modus wordt de uitvoering van cmd-bestanden handmatig beheerd, afhankelijk van de noodzaak om een map voor het project te registreren.
Ook bleek dat het script ook uitgevoerd zou moeten worden om groepen in andere forests te registreren (de term Cross-domains werd gebruikt), en de verhouding kan niet alleen 1 op één zijn, maar ook 1 op veel.
Dit betekent dat groepen uit andere domeinoverschrijdende domeinen, inclusief een aangrenzend bos, nu toegang kunnen claimen tot de bronnen van elk domein. Om uniformiteit te bereiken werd besloten om een symmetrische structuur te creëren in de OU van alle onderhouden domeinen van alle bossen (zwarte verticale ovalen). Zoals ze zeggen, in het leger moet alles lelijk zijn, maar uniform:
Wanneer project 80XXX in het TG-domein wordt geregistreerd, wordt het script dus uitgevoerd:
1. creatie van de overeenkomstige OU (rode horizontale ovalen) in dit domein en tussen domeinen, dat wil zeggen de domeinen waarvan de werknemers toegang moeten hebben tot deze bron.
2. OU vullen met groepen met namen als -, Waar:
- SRC_ domein – domeinoverschrijdend waarvan de werknemers toegang hebben tot DST-domeinbronnen
- DST_domain – het domein waartoe de bronnen in feite toegang moeten worden verleend, dat wil zeggen waarvoor alles is gestart
- - projectnummer
- ROLLEN – namen van de rollen vermeld in de toegangsmatrix.
3. het lezen van de reeks SID's van alle groepen van alle betrokken domeinen en deze opslaan voor daaropvolgende gegevensoverdracht naar een bestand dat de rechten op een specifieke projectsubmap definieert
4. genereren van bronbestanden (parameter /restore) met een set rechten voor gebruik door het icacKC-hulpprogramma in uitvoerbare bestandsmodus “icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. een CMD-bestand maken dat alle gelanceerde icacls voor alle projectmappen combineert
Zoals eerder geschreven, gebeurt het starten van het uitvoerbare bestand handmatig en wordt de evaluatie van de uitvoeringsresultaten ook handmatig gedaan.
Moeilijkheden waar we uiteindelijk mee te maken kregen:
- als de projectmap al gevuld is met een groot aantal bestanden, kan het uitvoeren van de opdracht icacls op de bestaande volumes veel tijd in beslag nemen, en in sommige gevallen tot mislukkingen leiden (bijvoorbeeld als er lange bestandspaden zijn);
- naast de parameter /restore moesten we regels toevoegen met de parameter /reset voor het geval de mappen niet waren aangemaakt, maar waren overgebracht vanuit eerder bestaande mappen, waarbij de overervingsrechten van de root waren uitgeschakeld;
- Een deel van het script voor het maken van groepen moest worden uitgevoerd op een willekeurige dc van elk bos; het probleem betreft administratieve accounts voor elke boom.
Algemene conclusie: het is heel vreemd dat er nog geen hulpprogramma's met vergelijkbare functionaliteit op de markt zijn. Het lijkt mogelijk om vergelijkbare functionaliteit te implementeren op basis van de Sharepoint-portal.
Het is ook onbegrijpelijk dat het niet mogelijk is om PoSH-hulpprogramma's te gebruiken voor het instellen van maprechten op sinologie-apparaten.
Indien gewenst ben ik bereid om het script te delen door een project op github te maken als iemand geïnteresseerd is.
Bron: www.habr.com