Tilsyneladende er min karma dette: at implementere standardopgaver på alle mulige ikke-trivielle måder. Hvis nogen har en anden vision af problemet, bedes du diskutere det, så problemet kan løses.
En god morgen opstod der en interessant opgave med at distribuere rettigheder til grupper af brugere til forskellige delinger indeholdende undermapper til projekter med dokumentmapper. Alt var fint, og der blev skrevet et script for at tildele rettigheder til mapperne. Og så viste det sig, at grupperne skulle indeholde brugere fra forskellige domæner, fra forskellige skove (). Lad os sige, at selve delingen er placeret på Synology-medier, der er registreret i FB-domænet i PSI-skoven. Opgave: at give brugere af domæner i en anden skov adgang til indholdet af denne share, og det meget selektivt.
Efter nogen tid tog de tekniske specifikationer følgende form:
- 2 skove: PSI skov, TG skov.
- Hver skov har 3 domæner: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Der er et tillidsforhold mellem skove; Synology ser alle sikkerhedsgrupper i alle skove.
- Delinger og mapper/undermapper skal have FB-domæneadministratorkonti med FullControl-rettigheder
- Navnene på mapperne bør systematiseres. Ledelsen koordinerede projekt-id'erne; jeg besluttede at knytte navnet på sikkerhedsgrupperne til projekt-id'erne.
- Projektmapper i systemshares skal indeholde en struktur, der er forberedt på forhånd i en .xlsx-fil, med passende adgangsrettigheder (R/RW/NA, hvor NA – ingen adgang)
- Det bør være muligt at begrænse rettighederne for brugere/gruppemedlemmer af et projekt til kun at omfatte bestemte mapper i det pågældende projekt. Brugeren har muligvis ikke adgang til andre mapper/projekter, afhængigt af gruppemedlemskab.
- Ved oprettelse af en projektmappe bør grupper oprettes så automatisk som muligt i de relevante domæner med navne svarende til projekt-id'er.
Bemærkninger til de tekniske specifikationer
- Etablering af tillidsforhold er ikke omfattet af de tekniske specifikationer
- Projekt-id indeholder tal og latinske tegn
- Projektbrugerroller for alle domæner har standardnavne
- En .xlsx-fil med mapper og adgangsrettigheder (adgangsmatrix) udarbejdes før hele projektets start
- Ved implementering af projekter er det muligt at oprette brugergrupper i de tilsvarende domæner
- Automatisering opnås ved at bruge standard MS Windows administrationsværktøjer
Implementering af tekniske specifikationer
Efter at have formaliseret disse krav, blev der taget en taktisk pause for at teste metoder til at oprette mapper og tildele rettigheder til dem. Det var beregnet til kun at bruge PowerShell, for ikke at komplicere projektet. Som jeg skrev tidligere, virkede script-algoritmen ret simpel:
- vi registrerer grupper med et navn, der er afledt af projekt-id'et (for eksempel KC40587) og de tilsvarende roller specificeret i adgangsmatrixen: KC40587-EN- for ingeniør; KC40587-PM – til produktchef mv.
- vi får SID'erne for de oprettede grupper
- registrer projektmappen og det tilsvarende sæt af mapper (listen over undermapper afhænger af den share, hvori den er oprettet og defineret i adgangsmatrixen)
- tildele rettigheder til grupper for nye undermapper til projektet i henhold til adgangsmatrixen.
Vanskeligheder på trin 1:
- misforståelse af metoden til at specificere adgangsmatrixen i scriptet (et multidimensionelt array er nu implementeret, men stien til at udfylde det søges baseret på indholdet af .xlsx-filen/adgangsmatrixen)
- umuligt at indstille adgangsrettigheder i SMB-shares på synology-drev ved hjælp af PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), på grund af hvilket en masse tid gik tabt, og alt skulle tilpasses til scripts ved hjælp af icacls adgangsrettighedsredigeringsværktøj, som krævede oprettelsen af et mellemliggende lager af tekst- og cmd-filer.
I den aktuelle tilstand styres udførelsen af cmd-filer manuelt, afhængigt af behovet for at registrere en mappe til projektet.
Det viste sig også, at scriptet også skulle udføres for at registrere grupper i andre skove (begrebet Cross-domains blev brugt), og forholdet kan ikke kun være 1 til en, men også 1 til mange.
Det betyder, at grupper fra andre tværdomæner, inklusive en naboskov, nu kan kræve adgang til ressourcerne på ethvert domæne. For at opnå ensartethed blev det besluttet at skabe en symmetrisk struktur i OU af alle betjente domæner i alle skove (sorte lodrette ovaler). Som de siger, i hæren skal alt være grimt, men ensartet:
Når projekt 80XXX registreres i TG-domænet, udfører scriptet således:
1. oprettelse af den tilsvarende OU (røde horisontale ovaler) i dette domæne og på tværs af domæner, det vil sige de domæner, hvis medarbejdere skal have adgang til denne ressource.
2. udfylde OU med grupper med navne som -, hvor:
- SRC_ domæne – på tværs af domæner, hvis medarbejdere vil have adgang til DST domæneressourcer
- DST_domain – det domæne, hvis ressourcer i virkeligheden skal gives adgang til, det vil sige for hvilket alting blev startet
- — projektnummer
- ROLLER – navne på rollerne, der er angivet i adgangsmatrixen.
3. læse arrayet af SID'er for alle grupper af alle involverede domæner og gemme det til efterfølgende dataoverførsel til en fil, der definerer rettighederne til en specifik projektundermappe
4. generering af kildefiler (parameter /gendan) med et sæt rettigheder til brug af icacKC-værktøjet i eksekverbar filtilstand "icacKC "as-nasNNKCProjects" /gendan C:TempKCKC40XXKC40XX.txt"
5. oprette en CMD-fil, der kombinerer alle lancerede icacls for alle projektmapper
Som det blev skrevet tidligere, udføres lanceringen af den eksekverbare fil manuelt, og evaluering af udførelsesresultaterne udføres også manuelt.
Vanskeligheder, som vi måtte stå over for i sidste ende:
- hvis projektmappen allerede er fyldt med et stort antal filer, kan det tage lang tid at køre icacls-kommandoen på de eksisterende volumener og i nogle tilfælde føre til fejl (for eksempel når der er lange filstier);
- ud over parameteren /restore, var vi nødt til at tilføje linjer med parameteren /reset i tilfælde af, at mapperne ikke blev oprettet, men blev overført fra tidligere eksisterende mapper, med arverettigheder fra roden deaktiveret;
- En del af scriptet til oprettelse af grupper skulle udføres på en vilkårlig jævnstrøm i hver skov, problemet vedrører administrative konti for hvert træ.
Generel konklusion: det er meget mærkeligt, at der endnu ikke er nogen hjælpeprogrammer med lignende funktionalitet på markedet. Det synes muligt at implementere lignende funktionalitet baseret på Sharepoint-portalen.
Det er også uforståeligt, at det ikke er muligt at bruge PoSH-værktøjer til at indstille mapperettigheder på sinology-enheder.
Hvis det ønskes, er jeg klar til at dele scriptet ved at oprette et eller andet projekt på github, hvis nogen er interesseret.
Kilde: www.habr.com