Det ser ud til, at jeg har en sådan karma: at løse standardopgaver på forskellige utraditionelle måder. Hvis nogen har en anden opfattelse af problemet, er de velkomne til at deltage i diskussionen for at finde en løsning.
En smuk morgen opstod en interessant opgave: at tildele rettigheder til brugergrupper på forskellige delinger, der indeholder undermapper til projekter med dokumentmapper. Alt gik glat, og der blev skrevet et script til at tildele rettigheder til mapperne. Men så viste det sig, at grupperne skulle indeholde brugere fra forskellige domæner, fra forskellige skove (). Antag, at selve delingen er placeret på en Synology-enhed, registreret i domænet FB, skoven PSI. Opgaven: at give brugere domæner fra den anden skov adgang til indholdet af denne deling, og dette meget selektivt.
Specifikationen udviklede sig efter noget tid til følgende:
- 2 skove: Skov PSI, skov TG.
- I hver skov er der 3 domæner: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Mellem skovene er der tillidsforhold, og Synology ser alle sikkerhedsgrupper i alle skove.
- Der skal være domæneadministratorerkonti fra domænet FB med fuld kontrol på delingerne og mapperne/undermapperne.
- Navnene på mapperne i delingerne skal være systematiserede. Ledelsen stod for godkendelsen af projekt-ID'erne, og jeg besluttede at knytte navnene på sikkerhedsgrupperne til projekt-ID'erne.
- Projektmapperne i systemdelingerne skal indeholde en på forhånd forberedt struktur i en .xlsx-fil med de relevante adgangsrettigheder (R/RW/NA, hvor NA betyder, at der ikke er adgang).
- Der skal være mulighed for at begrænse rettighederne for brugere/gruppemedlemmer af et projekt til kun bestemte kataloger fra dette projekt. Til andre kataloger/projekter kan brugeren muligvis ikke have adgang, afhængig af medlemskabet i grupperne.
- Når en projektmappe oprettes, skal der automatisk oprettes grupper i de relevante domæner med navne svarende til projekt-ID'erne.
Bemærkninger til specifikationen
- Opsætning af tillidsforhold er ikke en del af specifikationen.
- Projekt-ID'et indeholder tal og latinske bogstaver.
- Brugernes roller i projekterne har standardnavne for alle domæner.
- En .xlsx-fil med mapper og adgangsrettigheder (adgangsmatrix) forberedes før implementeringen af hele projektet.
- Ved implementeringen af projekter kan der oprettes brugergrupper i de relevante domæner.
- Automatisering opnås ved hjælp af de indbyggede administrationsværktøjer i MS Windows
Implementering af kravspecifikation
Efter formaliseringen af disse krav blev der taget en taktisk pause for at teste metoderne til oprettelse af mapper og tildeling af rettigheder til dem. Det var meningen, at der kun skulle anvendes PowerShell for at undgå at komplicere projektet. Som jeg tidligere har nævnt, forekom algoritmen til scriptet ret enkel:
- vi registrerer grupper med navne afledt fra projekt-ID'et (f.eks. KC40587) og tilsvarende roller angivet i adgangsmatrixen: KC40587-EN- for ingeniøren; KC40587-PM – for produktlederen osv.
- vi får SID'erne for de oprettede grupper
- vi registrerer projektmappen og den tilsvarende samling af kataloger (listen over undermapper afhænger af den deling, hvori den oprettes, og er defineret i adgangsmatrixen)
- vi tildeler de nye undermapper i projektet rettigheder i henhold til adgangsmatrixen.
Udfordringer, som vi stødte på i første fase:
- manglende forståelse af måden at definere adgangsmatrixen i scriptet (der er nu implementeret en multidimensionel matrix, men der søges efter en måde at udfylde den baseret på indholdet af .xlsx-filen/adgangsmatrixen)
- umuligheden af at tildele adgangsrettigheder i SMB-deling på synology-lagringsenheder 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), hvilket resulterede i et betydeligt tidstab, og vi måtte tilpasse alt til scripts, der bruger værktøjet til at redigere adgangsrettigheder icacls, hvilket krævede oprettelse af et mellemlager af tekst- og cmd-filer.
I den nuværende tilstand kontrolleres udførelsen af cmd-filer manuelt, når der er behov for at registrere en mappe til projektet.
Det viste sig også, at scriptet skal udføres for at registrere grupper i andre domæner (vi brugte termen Cross-domæner), og forholdet kan ikke kun være 1 til 1, men også 1 til mange.
Dette betyder, at grupper fra andre tvær-domaener, herunder den nærliggende skov, nu kan have krav på adgang til ressourcerne i et givent domæne. For at sikre ensartethed blev det besluttet at oprette en symmetrisk struktur i OU for alle betjente domæner i alle skove (de sorte lodrette ovaler). Som man siger, i hæren skal alt være grotesk, men ensartet:
Når der registreres et projekt 80XXX i domænet TG, udføres følgende af scriptet:
1. Oprettelse af den relevante OU (røde horisontale ovaler) i dette domæne og tværdomæner, det vil sige de domæner, hvis medarbejdere skal have adgang til denne ressource.
2. Udfyldning af OU med grupper med navne af typen -, hvor:
- SRC_domain – tværdomæne, hvis medarbejdere vil have adgang til ressourcerne i DST-domænet
- DST_domain – domænet, til ressourcerne i hvilket adgang faktisk skal gives, altså det, som hele dette drejer sig om
- — projektets nummer
- ROLES – navne på de roller, der er angivet i adgangsmatrixen.
3. Indlæsning af arrayet af SID for alle grupper i alle involverede domæner og gemme det til senere overførsel af data til en fil, der definerer rettighederne for en specifik undermappe af projektet
4. Generering af kildefiler (parameter /restore) med et sæt rettigheder til brug i værktøjet icacKC i den eksekverbare fil «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»
5. Oprettelse af en CMD-fil, der kombinerer alle kørende icacls for alle mapper i projektet
Som tidligere nævnt udføres eksekveringen af den eksekverbare fil manuelt, ligesom evalueringen af resultatet også udføres manuelt.
Udfordringer, der opstod i sidste ende:
- hvis projektmappen allerede er fyldt med mange filer, kan eksekvering af icacls-kommandoen på de eksisterende mængder tage betydelig tid og i nogle tilfælde føre til fiasko (f.eks. ved lange filstier);
- udover parameteren /restore måtte jeg tilføje linjer med parameteren /reset i tilfælde af, at mapperne ikke blev oprettet, men overflyttet fra allerede eksisterende mapper med rettighederne arvet fra roden deaktiveret;
- det blev nødvendigt at udføre en del af scriptet til at oprette grupper på en vilkårlig dc i hver skov, problemet vedrører administrative konti for hvert træ.
Generel konklusion: det er meget mærkeligt, at der endnu ikke findes værktøjer på markedet med en sådan funktionalitet. Det synes muligt at implementere en sådan funktionalitet baseret på Sharepoint-portalen.
Det er også en uklar kendsgerning, at PoSH-værktøjer til tildeling af rettigheder til mapper ikke kan bruges på sinology-enheder.
Jeg er også klar til at dele scriptet og oprette et eller andet projekt på github, hvis nogen er interesseret.
Kilde: habr.com
