Masívne prideľovanie práv používateľom domén z rôznych lesov

Zjavne mám takú karmu: realizovať štandardné úlohy rôznymi netriviálnymi spôsobmi. Ak má niekto iný pohľad na problém — prosím o diskusiu, na prepracovanie otázky.

Jedného krásneho rána sa objavila zaujímavá úloha rozdať práva skupinám používateľov na rôzne zdieľania, obsahujúce podpriečinky projektov s priečinkami dokumentov. Všetko bolo v poriadku a bol napísaný skript prideľujúci práva na priečinky. A potom sa zistilo, že skupiny musia obsahovať používateľov rôznych domén, z rôznych lesov (pre tých, ktorí zabudli, čo to je). Predpokladajme, že samotné zdieľanie sa nachádza na zariadení Synology, registrovanom v doméne FB, lesa PSI. Úloha: povoliť používateľom domén iného lesa mať prístup k obsahu tohto zdieľania, a to veľmi selektívne.

Technická úloha sa po čase vyjavila v nasledujúcej podobe:

• 2 lesy: Les PSI, les TG.

  

• V každom lese sú 3 domény: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Medzi lesmi existujú dôverné vzťahy, Synology vidí všetky skupiny Security vo všetkých lesoch.
• Na zdieľaniach a priečinkoch/podpriečinkoch musia byť nevyhnutne účty adminov domény FB s právami FullControl.
• Názvy priečinkov zdieľania by mali byť systematizované. S dohodou ID projektov sa zaoberalo vedenie, rozhodol som sa názvy skupín Security priradiť k ID projektov.
• Priečinky projektov v systémových zdieľaniach by mali obsahovať vopred pripravenú štruktúru v .xlsx súbore, s príslušnými prístupovými privilégiami (R/RW/NA, kde NA – prístup neexistuje).

  

• Mala by existovať možnosť obmedziť práva používateľov/členov skupiny jedného projektu len na určité adresáre tohto projektu. K iným adresárom/projektom nemusí mať používateľ prístup, podľa členstva v skupinách.
• Pri zakladaní priečinka projektu by sa maximálne automaticky mali vytvárať skupiny v príslušných doménach s názvami zodpovedajúcimi ID projektov.

Poznámky k technickej úlohe

• Nastavenie dôverných vzťahov nie je zahrnuté v rozsahu technickej úlohy.
• ID projektu obsahuje číslice a latinku.
• Roly používateľov projektov pre všetky domény majú typové názvy.
• Súbor .xlsx s priečinkami a prístupovými právami (matrica prístupov) sa pripravuje pred začiatkom realizácie celého projektu.
• Pri realizácii projektov je možné vytvoriť skupiny používateľov v príslušných doménach.
• Automatizácia sa dosahuje použitím štandardných administratívnych nástrojov MS Windows.

Realizácia technického zadania.

Po formalizácii týchto požiadaviek bola oznámená taktická prestávka na vyskúšanie metód tvorby adresárov a prideľovania práv na ne. Predpokladalo sa používanie iba PowerShell, aby sa projekt nezložil. Ako som už spomínal, algoritmus skriptu sa zdal byť dosť jednoduchý:

• Registrujeme skupiny s názvom odvodeným od ID projektu (napríklad KC40587) a príslušnými rolami uvedenými v matrixe prístupov: KC40587-EN - pre inžiniera; KC40587-PM - pre produktového manažéra a pod.
• Získavame SID-y vytvorených skupín.
• Registrujeme priečinok projektu a príslušný súbor adresárov (zoznam podpriečinkov závisí od zdieľania, v ktorom sa vytvára a je definovaný v matici prístupov).
• Prideľujeme na nové podadresáre projektu práva skupinám podľa matrixu prístupov.

Ťažkosti, s ktorými sme sa stretli v 1. etape:

• nepochopenie spôsobu definovania prístupovej matice v skripte (aktuálne bol realizovaný viacdimenzionálny pole, ale hľadá sa cesta k jeho naplneniu na základe obsahu súboru .xlsx/matice prístupov).

  

• nemožnosť definovania prístupových práv v SMB zdieľania na úložiskách synology pomocou PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), čo spôsobilo veľa strateného času a museli sme prispôsobiť všetko pre skripty pomocou nástroja na úpravu prístupových práv icacls, čo si vyžiadalo vytvorenie medzitýmneho úložiska textových a cmd súborov.

V aktuálnom režime sa vykonávanie cmd súborov kontroluje manuálne, v prípade potreby registrácie priečinka pre projekt.

Taktiež sa ukázalo, že skript musí byť vykonaný aj na registráciu skupín v iných lesoch (používali sme termín Cross-domains), pričom pomer môže byť nielen 1 k 1, ale aj 1 k mnohým.

To znamená, že na prístup k zdrojom nejakého domény môžu mať nárok rôzne skupiny z iných medzi-domén, vrátane susedného lesa. Na realizáciu jednotnosti bolo rozhodnuté o vytvorení symetrickej štruktúry v OU všetkých spravovaných domén všetkých lesov (čierne vertikálne ovály). Ako sa hovorí, v armáde musí byť všetko bezchybné, ale jednotné:

Týmto spôsobom, pri registrácii projektu 80XXX v doméne TG, sa skript vykonáva:

1. vytvorenie zodpovedajúcej OU (červené horizontálne ovály) v tejto doméne a cez-domény, to znamená v tých doménach, ktorých zamestnanci by mali mať prístup k tomuto zdroju.

2. naplnenie OU skupinami s názvami typu <SRC_domain><DST_domain><ID_project>-, kde:

• SRC_domain – cez-doména, zamestnanci ktorej budú mať prístup k zdrojom DST domény
• DST_domain – doména, k zdrojom ktorej by mal byť vlastne poskytnutý prístup, to znamená, kvôli čomu to všetko začalo
• <ID_project> — číslo projektu
• ROLES – názvy rolí, uvedených v matici prístupu.

3. načítanie poľa SID všetkých skupín všetkých zapojených domén a jeho uloženie na neskoršie odoslanie údajov do súboru, ktorý určuje práva na konkrétnu podsložku projektu

4. generovanie súborov-zdrojov (parametr /restore) s množinou práv pre použitie utilitkou icacKC v režime spúšťateľného súboru „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt“

5. vytvorenie súboru CMD, ktorý spája všetky spúšťané icacls pre všetky priečinky projektu

Ako bolo napísané skôr, spustenie spúšťateľného súboru sa vykonáva ručne a hodnotenie výsledkov vykonania – taktiež sa vykonáva ručne.

Ťažkosti, s ktorými sa bolo treba nakoniec vysporiadať:

• ak je priečinok projektu už naplnený veľkým množstvom súborov, spracovanie príkazu icacls na existujúcom objeme môže trvať dlhý čas, a v niektorých prípadoch to viedlo k zlyhaniu (napríklad pri dlhých cestách súborov);
• okrem parametra /restore bolo potrebné pridať riadky s parametrom /reset pre prípad, že priečinky neboli vytvorené, ale presúvali sa z už existujúcich priečinkov, s vypnutými právami dedičnosti z koreňa;
• vykonávať časť skriptu na vytvorenie skupín bolo potrebné na ľubovoľnom dc každého lesa, problém sa týka administratívnych účtov pre každé strom.

Záverečné zhodnotenie: je veľmi zvláštne, že na trhu zatiaľ neexistujú nástroje s podobnou funkčnosťou. Zdá sa, že je možné implementovať podobnú funkcionalitu na báze portálu SharePoint.
Taktiež je nejasné, prečo nie je možné používať PoSH nástroje na priraďovanie práv na priečinky na zariadeniach Synology.

Na požiadanie sa rád podelím o skript, vytvorím nejaký projekt na GitHub, ak by to niekoho zaujímalo.

Zdroj: habr.com