Duket se kjo është karma ime: të realizoj detyra standarde në mënyra të pazakonta. Nëse dikush ka një tjetër vizion për problemin, ju lutem diskutoni për të, për të punuar mbi këtë çështje.
Një mëngjes të bukur, u shfaq një detyrë interesante për të dhënë të drejta grupeve të përdoruesve në ndarjet e ndryshme, që përmbajnë nëndokumenet e projekteve me objekte dokumentesh. Gjërat shkuan mirë dhe u shkrua një skript që caktonte të drejtat në dosje. Por më pas doli se grupet duhet të përmbajnë përdorues nga fusha të ndryshme, nga pyje të ndryshme (). Le të supozojmë se vetë ndarja ndodhet në një pajisje Synology, e regjistruar në domenin FB, pylli PSI. Detyra: të lejojmë përdoruesit të domenëve të një pylli tjetër të kenë qasje në përmbajtjen e kësaj ndarjeje, dhe kjo duhet të jetë shumë selektive.
Specifikimi i detyrës pas një kohe po përfundonte në këtë formë:
- 2 pyje: Pylli PSI, pylli TG.
- Në çdo pyll ka 3 domenë: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Mes pyjeve ka marrëdhënie besimi, Synology sheh të gjitha grupet e Sigurisë, në të gjitha pyjet.
- Në ndarjet dhe dosjet/nëndosjet duhet të ketë patjetër llogari të adminëve të domenit FB me të drejta FullControl.
- Emrat e dosjeve të ndarjeve duhet të jenë të sistematizuar. Kordinimi i ID e projekteve është bërë nga drejtoria, unë vendosa të lidh emrat e grupeve të Sigurisë me ID e projekteve.
- Dosjet e projekteve në ndarjet sistemike duhet të përmbajnë një strukturë të përgatitur paraprakisht në skedarin .xlsx, me privilegjet përkatëse të aksesit (R/RW/NA, ku NA – akses nuk ekziston)
- Duhet të ketë mundësinë për të kufizuar të drejtat e përdoruesve/anëtarëve të grupit të një projekti vetëm në disa katalogë të këtij projekti. Për katalogë/të tjerë projekte, përdoruesi mund të mos ketë akses, sipas anëtarësisë në grupe.
- Kur krijohet një dosje projekti, grupe në domenet përkatëse duhet të krijohen automatikisht me emrat përkatës ID e projekteve.
Shënime për specifikimin e detyrës
- Konfigurimi i marrëdhënieve të besimit nuk është në kuadër të specifikimit të detyrës
- ID e projektit përmban numra dhe letra latine
- Rollet e përdoruesve të projekteve për të gjitha domenet kanë emra standard
- Skedari .xlsx me dosjet dhe të drejtat e aksesit (matrica e aksesit) përgatitet para fillimit të implementimit të të gjithë projektit
- Gjatë realizimit të projekteve, është e mundur të krijohen grupe përdoruesish në domenet përkatëse
- Automatizimi arrihet përmes përdorimit të mjeteve standarde të administrimit të MS Windows
Zbatimi i kërkesave
Pas formalizimit të këtyre kërkesave, u mor një pauzë taktike për të provuar metodat e krijimit të katalogëve dhe ndarjen e të drejtave mbi ta. Shtë e parashikuar që të përdoret vetëm PowerShell, për të mos e komplikua projektin. Siç e kam shkruar më parë, algoritmi i skriptit duket mjaft i thjeshtë:
- regjistrojmë grupe me emra të përftuar nga ID e projektit (për shembull KC40587) dhe me rolet përkatëse të caktuara në matricën e qasjes: KC40587-EN - për inxhinierin; KC40587-PM - për menaxherin e produktit etj.
- marrim SID-të e grupeve të krijuara
- regjistrojmë dosjen e projektit dhe setin përkatës të katalogëve (lista e nënkatalogëve varet nga ndarja, në të cilën krijohet dhe përcaktohet në matricën e qasjes)
- i caktojmë grupet të drejtat mbi nënkatalogët e rinj të projektit sipas matricës së qasjes.
Vështirësitë me të cilat u përballëm në fazën e parë:
- përplasja në mënyrën e caktimit të matricës së qasjes në skript (aktualisht është realizuar një masiv shumë-dimensionale, por po kërkohet një mënyrë për ta mbushur atë mbi bazën e përmbajtjes së skedarit .xlsx/ matricës së qasjes)
- pamundësia për të caktuar të drejtat e qasjes në ndarjet SMB në ruajtësit e synology përmes mjeteve PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), për shkak të së cilës u humb shumë kohë dhe u desh të adaptohet gjithçka me skriptet që përdorin utilitarin e redaktimit të të drejtave të qasjes icacls, që kërkoi krijimin e një depoje ndërmjetëse për skedarët tekst dhe cmd.
Në mënyrën aktuale, ekzekutimi i skedarëve cmd kontrollohet manualisht, në rastin e nevojës për regjistrimin e dosjes për projektin.
Gjithashtu doli se skripti duhet të ekzekutohet gjithashtu për regjistrimin e grupeve në pyje të tjera (përdorëm termin Cross-domains), përveçse marrëdhënia mund të jetë jo vetëm 1 për 1, por edhe 1 për shumë.
Kjo do të thotë që grupet nga kros-domen të tjera, përfshirë pyllin fqinj, tani mund të pretendonin për qasje në burimet e një domeni. Për të realizuar njësi, u mor vendimi për të krijuar një strukturë simetrike në OU të të gjithë domaineve që shërbehen nga të gjitha pyjet (ovale vertikale të zeza). Siç thotë, në ushtri gjithcka duhet të jetë mëkaresh, por njësi:
Në këtë mënyrë, kur regjistrohet projekti 80XXX në domenin TG, skripti ekzekuton:
1. krijimin e OU përkatëse (eline horizontale të kuqe) në këtë domain dhe cross-domena, do të thotë që në ato domaine, punonjësit e të cilëve duhet të kenë qasje në këtë burim.
2. mbushjen e OU me grupe me emra si -, ku:
- SRC_domain – cross-domen, punonjësit e të cilit do të kenë qasje në burimet e domenit DST
- DST_domain – domeni, në burimet e të cilit duhet të jepet qasje, do të thotë për çfarë është në realizim e gjithë kjo
- — numri i projektit
- ROLES – emrat e roleve të listuara në matricën e aksesit.
3. leximi i masës SID të të gjitha grupeve të të gjithë domainve të angazhuar dhe ruajtja e saj për transferimin e të dhënave në një skedar, që përcakton të drejtat për një nënfolder të veçantë të projektit
4. генерация файлов-источников (параметр /restore) с набором прав для использования утилитой icacKC в режиме исполняемого файла «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»
5. krijimi i skedarit CMD, që bashkon të gjitha icacls e nisura për të gjitha folderat e projektit
Siç u shkrua më parë, ekzekutimi i skedarit bëhet manualisht dhe vlerësimi i rezultateve të ekzekutimit – po ashtu bëhet manualisht.
Vështirësitë me të cilat u përballëm në fund:
- nëse folderi i projektit është mbushur tashmë me një numër të madh skedash, ekzekutimi i komandës icacls mbi volume ekzistuese mund të marrë kohë të konsiderueshme, dhe në disa raste ka sjellë refuzimin (për shembull, në rast se ekzistojnë rrugë të gjata skedash);
- përveç parametrave /restore, duhej të shtojmë rreshta me parametrin /reset në rast se folderat nuk janë krijuar, por janë transferuar nga folderat që ekzistonin më parë, me të drejtat e trashëgimit të fikura nga rrënjët;
- duhej të ekzekutohej një pjesë e skriptit për krijimin e grupeve në një dc të rastësishëm të çdo pylli, problemi ka të bëjë me llogaritë administrative për çdo pemë.
Përfundimi i përgjithshëm: është shumë e çuditshme që në treg nuk ka ende utilita me funksionalitet të tillë. Realizimi i këtij funksionaliteti duket i mundur mbi bazën e portalit Sharepoint.
Gjithashtu ofrohet një fakt i paqartë rreth mungesës së mundësisë për të përdorur utilitat PoSH për caktimin e të drejtave në një folder në pajisjet sinology.
Nëse dëshirohet, jam i gatshëm të ndaj skriptin, duke krijuar ndonjë projekt në github, nëse dikujt do t'i interesojë.
Burimi: habr.com
