Matyt, mano karma tokia: standartines užduotis įgyvendinti visokiais nebanaliais būdais. Jei kas nors turi kitokią problemos viziją, aptarkite tai, kad būtų galima išspręsti problemą.
Vieną gražų rytą iškilo įdomi užduotis paskirstyti teises vartotojų grupėms į skirtingas dalis, kuriose yra projektų su dokumentų aplankais poaplankiai. Viskas buvo gerai ir buvo parašytas scenarijus, kaip priskirti teises į aplankus. Ir tada paaiškėjo, kad grupėse turėtų būti vartotojai iš skirtingų domenų, iš skirtingų miškų (). Tarkime, kad pati dalis yra „Synology“ laikmenoje, registruotoje PSI miško FB domene. Užduotis: leisti kitame miške esančių domenų vartotojams pasiekti šios dalies turinį ir labai pasirinktinai.
Po kurio laiko techninės specifikacijos buvo tokios formos:
- 2 miškai: PSI miškas, TG miškas.
- Kiekvienas miškas turi 3 domenus: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Tarp miškų yra pasitikėjimo ryšys; „Synology“ mato visas saugumo grupes visuose miškuose.
- Bendrinami objektai ir aplankai/poaplankiai turi turėti FB domeno administratoriaus paskyras su FullControl teisėmis
- Aplankų pavadinimai turėtų būti susisteminti. Vadovybė derino projektų ID, nusprendžiau saugos grupių pavadinimus susieti su projektų ID.
- Sistemos bendrinamų projektų aplankuose turi būti iš anksto .xlsx faile parengta struktūra su atitinkamomis prieigos teisėmis (R/RW/NA, kur NA – jokios prieigos)
- Turėtų būti įmanoma apriboti vieno projekto vartotojų / grupės narių teises tik tam tikriems to projekto katalogams. Atsižvelgiant į grupės narystę, vartotojas gali neturėti prieigos prie kitų katalogų / projektų.
- Kuriant projekto aplanką, grupės turi būti sukurtos kuo automatiškai atitinkamuose domenuose, kurių pavadinimai atitinka projekto ID.
Pastabos dėl techninių specifikacijų
- Pasitikėjimo santykių nustatymas neįtrauktas į techninių specifikacijų taikymo sritį
- Projekto ID sudaro skaičiai ir lotyniški simboliai
- Visų domenų projekto naudotojų vaidmenys turi standartinius pavadinimus
- .xlsx failas su aplankais ir prieigos teisėmis (prieigos matrica) paruošiamas prieš viso projekto pradžią
- Įgyvendinant projektus galima sukurti vartotojų grupes atitinkamuose domenuose
- Automatizavimas pasiekiamas naudojant standartinius MS Windows administravimo įrankius
Techninių specifikacijų įgyvendinimas
Įforminus šiuos reikalavimus, buvo padaryta taktinė pauzė, bandant katalogų kūrimo ir teisių į juos priskyrimo metodus. Buvo numatyta naudoti tik „PowerShell“, kad nebūtų apsunkintas projektas. Kaip rašiau anksčiau, scenarijaus algoritmas atrodė gana paprastas:
- registruojame grupes pavadinimu, gautu iš projekto ID (pavyzdžiui, KC40587) ir atitinkamomis prieigos matricoje nurodytais vaidmenimis: KC40587-LT- inžinieriui; KC40587-PM – produktų vadybininkui ir kt.
- gauname sukurtų grupių SID
- užregistruokite projekto aplanką ir atitinkamą katalogų rinkinį (poaplankių sąrašas priklauso nuo bendrinimo, kuriame jis sukurtas ir apibrėžtas prieigos matricoje)
- priskirti teises grupėms naujiems projekto pakatalogiams pagal prieigos matricą.
Sunkumai, su kuriais susidurta 1 etape:
- neteisingas prieigos matricos nurodymo scenarijuje metodo supratimas (dabar yra įdiegtas daugiamatis masyvas, tačiau jo užpildymo kelias ieškomas pagal .xlsx failo/prieigos matricos turinį)
- neįmanoma nustatyti prieigos teisių SMB bendrinimui sinologijos diskuose naudojant PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), dėl ko buvo prarasta daug laiko ir reikėjo viską pritaikyti prie scenarijų naudojant icacls prieigos teisių redagavimo priemonę, dėl kurios reikėjo sukurti tarpinę teksto ir cmd failų saugyklą.
Dabartiniu režimu cmd failų vykdymas valdomas rankiniu būdu, atsižvelgiant į poreikį registruoti projekto aplanką.
Taip pat paaiškėjo, kad scenarijus turėtų būti vykdomas ir registruojant grupes kituose miškuose (vartotas terminas Cross-domains), o santykis gali būti ne tik 1 su vienu, bet ir 1 su daug.
Tai reiškia, kad grupės iš kitų kryžminių domenų, įskaitant gretimą mišką, dabar gali reikalauti prieigos prie bet kurio domeno išteklių. Siekiant vienodumo, buvo nuspręsta visų miškų visų aptarnaujamų sričių OU sukurti simetrišką struktūrą (juodus vertikalius ovalus). Kaip sakoma, armijoje viskas turi būti negražu, bet vienoda:
Taigi, registruojant projektą 80XXX TG domene, scenarijus vykdo:
1. atitinkamų OU (raudonų horizontalių ovalų) sukūrimas šioje srityje ir kryžminiuose domenuose, tai yra tuose domenuose, kurių darbuotojai turi turėti prieigą prie šio šaltinio.
2. OU užpildymas grupėmis tokiais pavadinimais kaip -, kur:
- SRC_ domenas – kryžminis domenas, kurio darbuotojai turės prieigą prie DST domeno išteklių
- DST_domenas – domenas, prie kurio išteklių iš tikrųjų turėtų būti suteikta prieiga, tai yra, dėl kurio viskas buvo pradėta
- – projekto numeris
- ROLES – prieigos matricoje išvardytų vaidmenų pavadinimai.
3. nuskaityti visų susijusių domenų grupių SID masyvą ir išsaugoti jį vėlesniam duomenų perkėlimui į failą, kuris apibrėžia teises į konkretų projekto poaplankį
4. šaltinio failų generavimas (parametras /restore) su teisių rinkiniu, skirtu naudoti icacKC programai vykdomojo failo režimu „icacKC "as-nasNNKCCrojects" /restore C:TempKCKC40XXKC40XX.txt
5. sukurti CMD failą, kuris sujungia visus paleistus visų projekto aplankų icacls
Kaip buvo rašyta anksčiau, vykdomasis failas paleidžiamas rankiniu būdu, o vykdymo rezultatų įvertinimas taip pat atliekamas rankiniu būdu.
Sunkumai, su kuriais galiausiai teko susidurti:
- jei projekto aplankas jau užpildytas daugybe failų, komandos icacls vykdymas esamuose tomuose gali užtrukti daug laiko ir kai kuriais atvejais sukelti gedimą (pavyzdžiui, kai yra ilgi failų keliai);
- be parametro /restore, turėjome pridėti eilutes su parametru /reset tuo atveju, jei aplankai nebuvo sukurti, o perkelti iš anksčiau buvusių aplankų, išjungus paveldėjimo teises iš šakninio;
- Dalis grupių kūrimo scenarijaus turėjo būti vykdoma savavališkai kiekvieno miško nuolatinėje srovėje, problema susijusi su kiekvieno medžio administracinėmis sąskaitomis.
Bendra išvada: labai keista, kad rinkoje dar nėra panašaus funkcionalumo komunalinių paslaugų. Panašu, kad panašias funkcijas galima įdiegti remiantis Sharepoint portalu.
Taip pat nesuprantama, kad sinologijos įrenginiuose negalima naudoti PoSH paslaugų aplankų teisėms nustatyti.
Jei noriu, esu pasirengęs pasidalinti scenarijumi, sukurdamas kokį nors projektą github, jei kam įdomu.
Šaltinis: www.habr.com