Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

Ilmselt on minu karma selline: standardülesannete elluviimine kõikvõimalikel mittetriviaalsetel viisidel. Kui kellelgi on probleemist erinev nägemus, siis palun arutage seda, et probleem saaks lahendada.

Ühel ilusal hommikul tekkis huvitav ülesanne jagada kasutajarühmadele õigusi erinevatele aktsiatele, mis sisaldavad projektide alamkaustu koos dokumendikaustadega. Kõik oli korras ja kaustadele õiguste määramiseks kirjutati skript. Ja siis selgus, et rühmad peaksid sisaldama kasutajaid erinevatest domeenidest, erinevatest metsadest (neile, kes unustasid, mis see on). Oletame, et aktsia ise asub Synology meedias, mis on registreeritud PSI metsa FB domeenis. Ülesanne: võimaldada teises metsas asuvate domeenide kasutajatele juurdepääs selle aktsia sisule ja seda väga valikuliselt.

Mõne aja pärast võeti tehnilised kirjeldused järgmisel kujul:

  • 2 metsa: PSI mets, TG mets.

    Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

  • Igal metsal on 3 domeeni: PSI (ZG, PSI, FB); TG (TG, HU, KC).
  • Metsade vahel on usaldussuhe; Synology näeb kõigis metsades kõiki turvagruppe.
  • Jagamistel ja kaustadel/alamkaustadel peavad olema FullControli õigustega FB domeeni administraatori kontod
  • Kaustade nimed tuleks süstematiseerida. Juhtkond koordineeris projekti ID-d, otsustasin siduda turvagruppide nimed projekti ID-dega.
  • Süsteemi ühiskasutuses olevad projektikaustad peavad sisaldama eelnevalt .xlsx-failis ettevalmistatud struktuuri koos vastavate juurdepääsuõigustega (R/RW/NA, kus NA – puudub juurdepääs)

    Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

  • Ühe projekti kasutajate/rühmaliikmete õigusi peaks olema võimalik piirata ainult selle projekti teatud kataloogidega. Sõltuvalt grupi liikmelisusest ei pruugi kasutajal olla juurdepääsu teistele kataloogidele/projektidele.
  • Projekti kausta loomisel tuleks võimalikult automaatselt luua rühmad vastavatesse domeenidesse projekti ID-dele vastavate nimedega.

Märkused tehniliste kirjelduste kohta

  • Usaldussuhete loomine ei kuulu tehniliste kirjelduste alla
  • Projekti ID sisaldab numbreid ja ladina tähti
  • Kõigi domeenide projekti kasutajarollidel on standardsed nimed
  • Enne kogu projekti algust koostatakse .xlsx fail kaustade ja juurdepääsuõigustega (juurdepääsu maatriks)
  • Projektide elluviimisel on võimalik luua vastavates domeenides kasutajagruppe
  • Automatiseerimine saavutatakse standardsete MS Windowsi haldustööriistade abil

Tehniliste kirjelduste rakendamine

Pärast nende nõuete vormistamist tehti taktikaline paus kataloogide loomise ja neile õiguste määramise meetodite testimiseks. Projekti mitte keerulisemaks muutmiseks kavatseti kasutada ainult PowerShelli. Nagu ma varem kirjutasin, tundus skripti algoritm üsna lihtne:

  • registreerime grupid projekti ID-st tuletatud nimega (näiteks KC40587) ja vastavate juurdepääsumaatriksis määratud rollidega: KC40587-EN- for engineer; KC40587-PM – tootejuhile jne.
  • saame loodud rühmade SID-d
  • registreerige projekti kaust ja vastav kataloogide komplekt (alamkaustade loend sõltub jagamisest, milles see on loodud ja juurdepääsumaatriksis määratletud)
  • määrata projekti uute alamkataloogide rühmadele õigused vastavalt juurdepääsumaatriksile.

1. etapis ilmnenud raskused:

  • arusaamatus skriptis juurdepääsumaatriksi määramise meetodist (nüüd on rakendatud mitmemõõtmeline massiiv, kuid selle täitmise teed otsitakse .xlsx faili/pääsumaatriksi sisu põhjal)

    Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

  • PoSH abil sünoloogiadraividel SMB aktsiate juurdepääsuõigusi pole võimalik seadistada (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), mille tõttu läks palju aega kaotsi ja kõik tuli icaclsi juurdepääsuõiguste redigeerimisutiliiti kasutades skriptidele kohandada, mis nõudis teksti- ja cmd-failide vahepealse hoidla loomist.

Praeguses režiimis juhitakse cmd-failide täitmist käsitsi, olenevalt vajadusest projekti jaoks kaust registreerida.

Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

Samuti selgus, et skripti tuleks käivitada ka teiste metsade rühmade registreerimiseks (kasutati mõistet Cross-domains) ja suhe võib olla mitte ainult 1 ühele, vaid ka 1 paljudele.

Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

See tähendab, et rühmad teistest domeenidevahelistest, sealhulgas naabermetsast, saavad nüüd taotleda juurdepääsu mis tahes domeeni ressurssidele. Ühtsuse saavutamiseks otsustati kõigi metsade kõigi teenindatavate domeenide OU-s luua sümmeetriline struktuur (mustad vertikaalsed ovaalid). Nagu öeldakse, peaks sõjaväes kõik olema kole, kuid ühtlane:

Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

Seega käivitab skript projekti 80XXX registreerimisel TG domeenis:

1. vastavate OU (punased horisontaalsed ovaalid) loomine selles domeenis ja ristdomeenides, st nendes domeenides, mille töötajatel peab olema juurdepääs sellele ressursile.

2. OU täitmine rühmadega, mille nimed on nagu -, Kus:

  • SRC_ domeen – domeen, mille töötajatel on juurdepääs DST domeeni ressurssidele
  • DST_domeen – domeen, mille ressurssidele tegelikult peaks juurdepääsu võimaldama ehk mille nimel kõike alustati
  • — projekti number
  • ROLLID – juurdepääsumaatriksis loetletud rollide nimed.

3. kõigi kaasatud domeenide kõigi rühmade SID-ide massiivi lugemine ja selle salvestamine hilisemaks andmeedastuseks faili, mis määratleb õigused konkreetse projekti alamkaustale

4. õiguste kogumiga lähtefailide genereerimine (parameeter /restore), mida icacKC utiliit kasutab käivitatava failirežiimis "icacKC "as-nasNNKCCrojects" /restore C:TempKCKC40XXKC40XX.txt

5. CMD-faili loomine, mis ühendab kõik käivitatud icacl-id kõigi projekti kaustade jaoks

Laiaulatuslik õiguste määramine erinevatest metsadest pärit domeeni kasutajatele

Nagu varem kirjutatud, käib täitmisfaili käivitamine käsitsi ja täitmistulemuste hindamine samuti käsitsi.

Raskused, millega pidime lõpuks silmitsi seisma:

  • kui projekti kaust on juba täidetud suure hulga failidega, võib käsu icacls käivitamine olemasolevatel köidetel võtta palju aega ja mõnel juhul põhjustada tõrkeid (näiteks kui failiteed on pikad);
  • lisaks parameetrile /restore pidime lisama ridu parameetriga /reset juhuks, kui kaustu ei loodud, vaid kanti üle varem olemasolevatest kaustadest, kusjuures juure pärimisõigused on keelatud;
  • Osa rühmade loomise skriptist tuli käivitada iga metsa suvalisel alalisvoolul, probleem puudutab iga puu halduskontosid.

Üldine järeldus: on väga kummaline, et turul pole veel sarnase funktsionaalsusega kommunaalteenuseid. Sarnase funktsionaalsuse juurutamine Sharepointi portaali põhjal näib olevat võimalik.
Arusaamatu on ka see, et sinoloogiaseadmetes pole võimalik PoSH utiliite kaustaõiguste seadistamiseks kasutada.

Soovi korral olen valmis skripti jagama, luues mõne projekti githubis, kui kellelgi on huvi.

Allikas: www.habr.com

Lisa kommentaar