Moja karma je zrejme takáto: implementovať štandardné úlohy najrôznejšími netriviálnymi spôsobmi. Ak má niekto iný pohľad na problém, prosím, prediskutujte ho, aby sa problém mohol vyriešiť.
V jedno pekné ráno vznikla zaujímavá úloha rozdeliť 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 na pridelenie práv priečinkom. A potom sa ukázalo, že skupiny by mali obsahovať používateľov z rôznych domén, z rôznych lesov (). Povedzme, že samotné zdieľanie sa nachádza na médiu Synology, registrovanom vo FB doméne lesa PSI. Úloha: umožniť používateľom domén v inom lese prístup k obsahu tohto zdieľania a to veľmi selektívne.
Po určitom čase nadobudli technické špecifikácie nasledujúcu podobu:
- 2 lesy: PSI les, TG les.
- Každý les má 3 domény: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Medzi lesmi existuje dôveryhodný vzťah; Synology vidí všetky skupiny zabezpečenia vo všetkých lesoch.
- Zdieľané položky a priečinky/podpriečinky musia mať účty správcu domény FB s právami FullControl
- Názvy priečinkov by mali byť systematizované. Vedenie koordinovalo ID projektu, rozhodol som sa prepojiť názov skupín zabezpečenia s ID projektu.
- Priečinky projektu v systémových zdieľaniach musia obsahovať vopred pripravenú štruktúru v súbore .xlsx s príslušnými prístupovými oprávneniami (R/RW/NA, kde NA – bez prístupu)
- Malo by byť možné obmedziť práva používateľov/členov skupiny jedného projektu len na určité adresáre tohto projektu. Používateľ nemusí mať prístup k iným adresárom/projektom v závislosti od členstva v skupine.
- Pri vytváraní priečinka projektu by sa skupiny mali vytvárať čo najviac automaticky v príslušných doménach s názvami zodpovedajúcimi ID projektu.
Poznámky k technickým špecifikáciám
- Nastavenie dôveryhodných vzťahov nie je zahrnuté v rozsahu technických špecifikácií
- ID projektu obsahuje čísla a latinské znaky
- Roly používateľov projektu pre všetky domény majú štandardné názvy
- Pred spustením celého projektu je pripravený súbor .xlsx s priečinkami a prístupovými právami (matica prístupu).
- Pri implementácii projektov je možné vytvárať skupiny užívateľov v príslušných doménach
- Automatizácia je dosiahnutá použitím štandardných administračných nástrojov MS Windows
Implementácia technických špecifikácií
Po formalizácii týchto požiadaviek sa urobila taktická pauza na testovanie metód vytvárania adresárov a prideľovania práv k nim. Zámerom bolo používať iba PowerShell, aby sa projekt nekomplikoval. Ako som už napísal, algoritmus skriptu sa zdal celkom jednoduchý:
- registrujeme skupiny s názvom odvodeným od ID projektu (napríklad KC40587) a zodpovedajúcimi rolami špecifikovanými v prístupovej matici: KC40587-EN- pre inžiniera; KC40587-PM – pre produktového manažéra atď.
- získame SID vytvorených skupín
- zaregistrovať priečinok projektu a zodpovedajúcu sadu adresárov (zoznam podpriečinkov závisí od zdieľania, v ktorom je vytvorený a definovaný v prístupovej matici)
- prideľovať práva skupinám pre nové podadresáre projektu podľa prístupovej matice.
Ťažkosti, ktoré sa vyskytli v prvej fáze:
- nepochopenie spôsobu špecifikovania prístupovej matice v skripte (teraz je implementované viacrozmerné pole, ale cesta k jeho naplneniu sa hľadá na základe obsahu .xlsx súboru/prístupovej matice)
- nemožnosť nastavenia prístupových práv v zdieľaniach SMB na jednotká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), kvôli čomu sa stratilo veľa času a všetko sa muselo prispôsobiť skriptom pomocou utility na úpravu prístupových práv icacls, čo si vyžiadalo vytvorenie medziúložiska textových a cmd súborov.
V aktuálnom režime je spúšťanie cmd súborov riadené manuálne v závislosti od potreby registrácie priečinka pre projekt.
Ukázalo sa tiež, že skript by sa mal spustiť aj na registráciu skupín v iných lesoch (používal sa výraz Cross-domains) a pomer môže byť nielen 1 ku jednej, ale aj 1 ku mnohým.
To znamená, že skupiny z iných viacerých domén, vrátane susedného lesa, si teraz môžu nárokovať prístup k zdrojom ľubovoľnej domény. Na dosiahnutie jednotnosti bolo rozhodnuté o vytvorení symetrickej štruktúry v OU všetkých obsluhovaných domén všetkých lesov (čierne vertikálne ovály). Ako sa hovorí, v armáde by malo byť všetko škaredé, ale jednotné:
Pri registrácii projektu 80XXX v doméne TG teda skript vykoná:
1. vytvorenie zodpovedajúcich OU (červené horizontálne ovály) v tejto doméne a medzi doménami, to znamená tých domén, ktorých zamestnanci musia mať prístup k tomuto zdroju.
2. naplnenie OU skupinami s názvami ako -, kde:
- Doména SRC_ – medzi doménami, ktorých zamestnanci budú mať prístup k zdrojom domény DST
- DST_domain – doména, ku ktorej zdrojom by sa mal v skutočnosti poskytnúť prístup, to znamená, kvôli ktorej sa všetko začalo
- — číslo projektu
- ROLES – názvy rolí uvedených v prístupovej matici.
3. načítanie poľa SID všetkých skupín všetkých zapojených domén a jeho uloženie pre následný prenos dát do súboru, ktorý definuje práva na konkrétny podpriečinok projektu
4. generovanie zdrojových súborov (parameter /restore) so sadou práv na použitie obslužným programom icacKC v režime spustiteľného súboru „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. vytvorenie súboru CMD, ktorý kombinuje všetky spustené súbory icacl pre všetky priečinky projektu
Ako už bolo napísané vyššie, spúšťanie spustiteľného súboru sa vykonáva manuálne a vyhodnotenie výsledkov vykonávania sa tiež vykonáva manuálne.
Ťažkosti, ktorým sme museli nakoniec čeliť:
- ak je priečinok projektu už naplnený veľkým počtom súborov, spustenie príkazu icacls na existujúcich zväzkoch môže trvať značne dlho av niektorých prípadoch viedlo k zlyhaniu (napríklad ak existujú dlhé cesty k súborom);
- okrem parametra /restore sme museli pridať riadky s parametrom /reset v prípade, že priečinky neboli vytvorené, ale boli prenesené z predtým existujúcich priečinkov, pričom práva dedenia od roota sú vypnuté;
- Časť skriptu na vytváranie skupín bolo potrebné spustiť na ľubovoľnom dc každého lesa, problém sa týka administratívnych účtov pre každý strom.
Všeobecný záver: je veľmi zvláštne, že na trhu zatiaľ nie sú žiadne nástroje s podobnou funkcionalitou. Zdá sa, že je možné implementovať podobnú funkcionalitu založenú na portáli Sharepoint.
Nepochopiteľné je aj to, že na sinologických zariadeniach nie je možné použiť pomôcky PoSH na nastavenie priečinkových práv.
Ak chcete, som pripravený zdieľať skript vytvorením nejakého projektu na github, ak by mal niekto záujem.
Zdroj: hab.com