Ilmselt on mul selline karma: teostada tavalisi ülesandeid igasuguste ebatavaliste viisidega. Kui kellelgi on probleemist teine arusaam — ootan arutelu, et küsimust arendada.
Ühel kaunil hommikul tuli ette huvitav ülesanne anda õigusi kasutajagruppidele erinevatesse jagadesse, mis sisaldavad projektide alamkaustu dokumentide kaustadega. Kõik oli hästi ja kirjutati skript, mis määras kaustade õigused. Seejärel selgus, et grupid peavad sisaldama erinevate domeenide kasutajaid, erinevatest metsadest (). Oletame, et jagamine ise asub Synology seadmel, mis on registreeritud domeenis FB, metsades PSI. Ülesanne: lubada teise metsa kasutajatel sellele jagamise sisule juurde pääseda, kuid väga valikuliselt. of domains Tehniline ülesanne hakkas mingi aja pärast välja nägema sellisena:
2 metsa: Metsa PSI, metsa TG.
- Igas metsas on 3 domeeni: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Metsade vahel on usalduslikud suhted, Synology näeb kõiki Security gruppe kõigis metsades.
- Jagades ja kaustades/alamkaustades peavad olema domeeni FB administraatorite kontod täisõigustega.
- На шарах и папках/подпапках обязательно должны быть учетные записи админов домена FB с правами FullControl
- Kaustade nimed peavad olema süsteemselt korrastatud. Projektide ID-de kooskõlastamisega tegeles juhtkond, otsustasin grupi Security nimed siduda projektide ID-dega.
- Projektikaustad süsteemsetes jagades peavad sisaldama ettevalmistatud struktuuri .xlsx failis koos vastava juurdepääsu õigustega (R/RW/NA, kus NA – juurdepääs puudub).
- Peab olema võimalik piirata kasutajate/grupi liikmete õigusi ühe projekti määratud kaustadega. Kasutajal ei pruugi olla juurdepääsu teistele kaustadele/projektidele vastavalt gruppidesse kuulumisele.
- Projektikausta loomisel peavad automaatselt looma vastavates domeenides grupid, mille nimed vastavad projektide ID-dele.
Märgid tehnilisse ülesandesse.
- Usalduslike suhete seadmine ei kuulu tehnilise ülesande raamesse.
- Projektide ID sisaldab numbreid ja ladina tähestiku tähti.
- Projektide kasutajate rolle kõigis domeenides nimetatakse tüüpiliste nimedega.
- .xlsx fail kaustade ja juurdepääsu õigustega (juurdepääsumaatriks) valmistatakse ette enne kogu projekti elluviimist.
- Projektide rakendamisel on võimalik luua kasutajagruppe vastavates domeenides.
- Automatiseerimine saavutatakse MS Windowsi haldamise tavaliste vahendite abil
Tehnilise ülesande täitmine
Pärast nende nõuete formaliseerimist tehti taktikaline paus kataloogide loomise meetodite katsetamiseks ja õiguste määramiseks. Kasutusele pidi minema ainult PowerShell, et projekti ei keerukaks. Nagu olen varem maininud, nägi skripti algoritm välja piisavalt lihtne:
- registreerime rühmad nimega, mis tuleneb projekti ID-st (näiteks KC40587) ja sobivate rollidega, nagu on näidatud juurdepääsumaatriksis: KC40587-EN - insenerile; KC40587-PM - tootemanagerile jne.
- saame loodud rühmade SID'id
- registreerime projekti kausta ja vastava kogumi katalooge (alamkaustade loetelu sõltub jagamisest, milles see luuakse ja on määratletud juurdepääsumaatriksis)
- määrame uutele projekti alamkaustadele õigused rühmadele vastavalt juurdepääsumaatriksile.
Raskused, millega tuli silmitsi seista esimesel etapil:
- juurde pääsemise maatriksi määramise viisi arusaamatus skripti joonisel (praegu on realiseeritud mitmemõõtmeline massiiv, kuid otsitakse teed selle täitmiseks .xlsx faili/sisule tuginedes juurdepääsumaatriksist)
- Synology veebide SMB õiguste määramine PoSH abil osutus võimatuks (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), mille tõttu kulus palju aega ning tuli kohandada kõik skriptide jaoks, kasutades õiguste redigeerimise utiliiti icacls, mis nõudis vahepealse tekstifailide ja cmd-failide hoidla loomist.
Praeguses režiimis kontrollitakse cmd-faile käsitsi, vastavalt vajadusele registreeritakse projekti kaust.
Samuti selgus, et skript peab toimima ka rühmade registreerimiseks teistes metsades (kasutati mõistet Cross-domains), kusjuures suhe võib olla mitte ainult 1:1, vaid ka 1: palju.
See tähendab, et mingisse domeeni ressursside juurde pääsemiseks võivad nüüd pretendeerida rühmad teistest ristdomeenidest, sealhulgas naabermetsast. Ühtsuse saavutamiseks otsustati luua sümmeetriline struktuur kõigi teenindatavate domeenide OU-de vahel kõikides metsades (mustad vertikaalsed ovaalid). Nagu öeldakse, peab armees olema kõik kaootiline, kuid ühtlane:
Seega, registreerides projekti 80XXX domeenis TG, täidab skript järgmisi toiminguid:
1. vastava OU (punased horisontaalsed ovaalid) loomine antud domeenis ja ristdomeenides, s.t. nendes domeenides, mille töötajatel peaks olema juurdepääs sellele ressursile.
2. OU täitmine gruppidega, mille nimed on kujul -, kus:
- SRC_domeen – ristdomeen, mille töötajad saavad juurdepääsu DST domeeni ressurssidele.
- DST_domeen – domeen, millele tuleb tegelikult juurdepääs anda, ehk mille pärast see kõik korraldatud on.
- — projekti number.
- ROLES – rollide nimed, mis on loetletud juurdepääsumatriisis.
3. kõikide osalevate domeenide gruppide kõigi SID-de massiivi lugemine ja selle salvestamine edasise andmefaili jaoks, mis määratleb õigused konkreetsele projekti alakaustale.
4. lähtefailide genereerimine (parameeter /restore) õiguste kogumiga, et kasutada utiliiti icacKC käivitatava faili režiimis «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt».
5. CMD-faili loomine, mis ühendab kõik käivitatavad icacls failid kõigi projekti kaustade jaoks.
Nagu varem mainitud, käivitatakse täidetav fail käsitsi ja tulemuste hindamine toimub samuti käsitsi.
Kohtunud raskused:
- kui projekti kaust on juba täidetud suure hulga failidega, võib käsk icacls tundide vältel töötlemine võtta palju aega ning mõnel juhul põhjustada tõrke (näiteks kui failide teed on pikad);
- kõrval parameetrile /restore tuli lisada read parameetriga /reset, juhuks kui kaustade loomine ei toimunud, vaid need viidi üle juba olemasolevatest kaustadest, millel on välja lülitatud pärandi õigused juurelt;
- osa skriptist, mis tegeleb rühmade loomisega, tuli käitada igas metsas suvalisel dc-l, probleem puudutab haldustäiendavaid kontosid iga puu jaoks.
Üldine järeldus: on väga kummaline, et turul ei ole sellise funktsionaalsusega utiliite. Tundub, et sellise funktsionaalsuse rakendamine on võimalik SharePointi portaali baasil.
Samuti on arusaamatu fakt, et PoSH utiliite ei saa kasutada kaustade õiguste seadmiseks seadmetel sinology.
Soovi korral olen valmis jagama skripti, luues mingi projekti githubis, kui kellelgi peaks huvi olema.
Allikas: habr.com
