Laialdane õiguste määramine domeenide kasutajatele erinevates metsades

Ilmselt on mul selline karma: ellu viia tavapäraseid ülesandeid erinevate mittetavaliste meetoditega. Kui kellelgi on probleemile teine nägemus, palun liitu aruteluga, et probleemi arutada.

Ühel kaunil hommikul tekkis huvitav ülesanne jagada õigusi kasutajagruppidele erinevatele jagamisele, mis sisaldavad projektikaustade alakaustu koos dokumentidega. Kõik läks hästi ja kirjutati skript kaustade õiguste seadmiseks. Siis selgus, et grupid peavad sisaldama erinevate domeenide kasutajaid, erinevatest metsadest (kellele, kes unustas, mis see on). Oletame, et jagamine end ise asub Synology seadmel, mis on registreeritud domeenis FB, metsas PSI. Ülesanne: lubada teiste metsade kasutajatel pääseda sellele jagamisele, ja seda väga valikuliselt. domeenide Tehniline ülesanne (TÜ) hakkas paistma järgmises vormis:

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õikides metsades.
• Jagamistel ja kaustadel/alakaustadel peavad olema domeeni FB administraatorite kontod, kellel on täiskontrolli õigused.
• Jagamise kaustade nimed peavad olema sistematiseeritud. Projektide ID-de kooskõlastamist tegi juhtkond, otsustasin seondada Security gruppide nimed projektide ID-dega.
• Projektikaustad süsteemsetes jagamistes peavad sisaldama eelnevalt ettevalmistatud struktuuri .xlsx failis, koos vastavate juurdepääsu privileegidega (R/RW/NA, kus NA – juurdepääs puudub).
• Peab olema võimalik piirata ühe projekti kasutajate/rühma liikmete õigusi ainult konkreetsete kataloogidega antud projektis. Teiste kataloogide/projektide osas ei pruugi kasutajal olla juurdepääsu, vastavalt rühmade liikmelisusele.

  

• Projektikausta loomisel peavad maksimaalselt automaatselt looma vastavates domeenides grupid, mille nimed vastavad projektide ID-dele.
• Märkused TÜ-le

Usalduslike suhete seadmine ei kuulu TÜ raamidesse.

• Projektide ID sisaldab numbreid ja ladina tähti.
• Projektide kasutajate rollidel kõigis domeenides on tüüpilised nimed.
• .xlsx fail kaustade ja juurdepääsu õiguste (juurdepääsumatriis) osas valmistatakse enne kogu projekti elluviimist.
• Projektide rakendamisel on võimalik luua kasutajagruppide vastavates domeenides.
• Projektide elluviimisel võib luua kasutajagruppe vastavates domeenides.
• Automatiseerimine saavutatakse MS Windowsi haldamise natiivsete tööriistade kasutamise teel.

Tehnilise spetsifikatsiooni täitmine.

Pärast nende nõuete formaliseerimist tehti taktikaline paus, et katsetada kataloogide loomise meetodeid ja õiguste määramist. Eesmärgiks oli kasutada ainult PowerShelli, et projekti keerukust mitte suurendada. Nagu ma varem mainisin, tundus skripti algoritm piisavalt lihtne:

• registreerime rühmad, mille nimed on tuletatud projekti ID-st (näiteks KC40587) ja vastavad õigused, mis on toodud juurdepääsu matris: KC40587-EN - insenerile; KC40587-PM - tootemanajerile jne.
• saame loodud rühmade SID-id.
• registreerime projekti kausta ja vastava kataloogide komplekti (alampdst sõltub jagamisest, milles see luuakse ja on määratud juurdepääsu matris).
• määrame uutele projekti alakaustadele õigused rühmadele vastavalt juurdepääsu matris.

Esimese etapi raskused, millega tuli silmitsi seista:

• juurdepääsu matriisi määratlemise viisi arusaamatus skripti sees (praegu on rakendatud mitmemõõtmeline massiiv, kuid otsitakse teed selle täitmiseks .xlsx faili/juurdepääsu matriisi sisu põhjal).

  

• Rikkalike of SMB jagatud õiguste seadmine Synology salvestites PowerShelli vahenditega ei ole võimalik (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), mistõttu kulus palju aega ja tuli kohandada kõike skriptide kasutamiseks õiguste redigeerimise utiliidi icacls abil, mis nõudis vahepealse tekstifailide ja cmd-failide loomist.

Praeguses režiimis kontrollitakse cmd-faile käsitsi vastavalt vajadusele registreerida projekti kausta.

Samuti selgus, et skripti peab käivitama 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 juurdepääsutele, mis kuuluvad mõnda domeeni, võivad nüüd pretendeeida ka rühmad teistest ristdomeenidest, sealhulgas naabermetsast. Ühtsuse saavutamiseks otsustati luua sümmeetriline struktuur kõigis hallatavate domeenide OU-des (mustad vertikaalsed ovoid). Nagu öeldakse, peab armees olema kõik kohutav, aga ühtne:

Seega, registreerides projekti 80XXX domeenis TG, täidab skript:

1. vastava OU (punased horisontaalset ovaalid) loomine antud domeenis ja ristdomeenides, st nendes domeenides, mille töötajatel peab olema ligipääs sellele ressursile.

2. OU täitmine gruppidega, mille nimed on kujul -, kus:

• SRC_domain – ristdomeen, mille töötajatel on juurdepääs DST domeeni ressurssidele
• DST_domain – domeen, mille ressurssidele tuleb juurdepääs anda, st mille jaoks see kõik algatati
• — projekti number
• ROLES – rollide nimed, mis on loetletud ligipääsumatriisis.

3. kõigi seotud domeenide rühmade SID-massiivi lugemine ja selle salvestamine edasiseks andmete edastamiseks failile, mis määratleb õigused konkreetsele projekti alamkaustale

4. allikafailide genereerimine (parameeter /restore) koos õiguste komplektiga, et kasutada utiliiti icacKC käitatava faili režiimis «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»

5. CMD-faili loomine, mis ühendab kõik käivitatavad icacls kõikide projekti kaustade jaoks

Nagu varasemas mainitud, käivitatakse käitav fail käsitsi ja tulemuste hindamine toimub samuti käsitsi.

Koonduvad raskused, millega tuli kokku puutuda:

• kui projekti kaust on juba suurte failide kogumiga täidetud, võib icacls-i käsu töötlemine olemasolevate mahtude puhul võtta märkimisväärselt aega, ning mõnel juhul viia keeldumiseni (näiteks pikade failiteede olemasolul);
• lisaks parameetrile /restore tuli lisada read parameetriga /reset juhuks, kui kaustad ei olnud loodud, vaid viidud varasemate olemasolevate kaustadest, millel oli juurdepääsu pärimise õigus välja lülitatud;
• osaliselt tuli skripti gruppide loomise osa käivitada iga metsakontori juhuslikul dc-l, probleem puudutab halduskontode olemasolu iga puu jaoks.

Üldine järeldus: on väga kummaline, et turul pole veel utiliite sellise funktsionaalsusega. Tundub, et sellise funktsionaalsuse rakendamine portaalil Sharepoint on võimalik.
Samuti on arusaamatu, et sinology seadmetes ei ole võimalik kasutada PoSH utiliite kausta õiguste määramiseks.

Soovi korral olen valmis jagama skripti, luues mingi projekti githubis, kui see kellelegi huvi pakub.

Allikas: habr.com