Ilmeisesti karmani on tämä: toteuttaa standarditehtäviä kaikenlaisilla ei-triviaalisilla tavoilla. Jos jollakulla on erilainen näkemys ongelmasta, keskustele siitä, jotta ongelma voidaan ratkaista.
Eräänä kauniina aamuna syntyi mielenkiintoinen tehtävä jakaa käyttäjäryhmille oikeuksia erilaisiin osuuksiin, jotka sisältävät projektien alikansioita dokumenttikansioineen. Kaikki oli hyvin ja skripti kirjoitettiin kansioiden oikeuksien määrittämiseksi. Ja sitten kävi ilmi, että ryhmissä pitäisi olla käyttäjiä eri toimialueilta, eri metsistä (). Oletetaan, että itse osake sijaitsee Synology-mediassa, joka on rekisteröity PSI-metsän FB-verkkotunnukseen. Tehtävä: sallia toisen metsän verkkotunnusten käyttäjien pääsy tämän osuuden sisältöön, ja hyvin valikoivasti.
Jonkin ajan kuluttua tekniset tiedot otettiin seuraavassa muodossa:
- 2 metsää: PSI-metsä, TG-metsä.
- Jokaisessa metsässä on 3 verkkotunnusta: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Metsien välillä on luottamussuhde; Synology näkee kaikki turvallisuusryhmät kaikissa metsissä.
- Osuuksilla ja kansioilla/alikansioilla on oltava FB-verkkotunnuksen järjestelmänvalvojatilit FullControl-oikeuksilla
- Kansioiden nimet tulee systematisoida. Johto koordinoi projektitunnukset, päätin linkittää suojausryhmien nimet projektitunnuksiin.
- Järjestelmäosuuksissa olevien projektikansioiden on sisällettävä .xlsx-tiedostossa etukäteen valmistettu rakenne, jossa on asianmukaiset käyttöoikeudet (R/RW/NA, missä NA – ei pääsyä)
- Yhden projektin käyttäjien/ryhmän jäsenten oikeudet pitäisi olla mahdollista rajoittaa vain tiettyihin kyseisen projektin hakemistoihin. Käyttäjällä ei välttämättä ole pääsyä muihin hakemistoihin/projekteihin, riippuen ryhmän jäsenyydestä.
- Projektikansiota luotaessa ryhmät tulee luoda mahdollisimman automaattisesti asianmukaisiin verkkotunnuksiin projektitunnuksia vastaavilla nimillä.
Huomautuksia teknisistä tiedoista
- Luottamussuhteiden luominen ei sisälly teknisten eritelmien piiriin
- Projektin tunnus sisältää numeroita ja latinalaisia merkkejä
- Kaikkien verkkotunnusten projektin käyttäjärooleilla on vakionimet
- .xlsx-tiedosto kansioista ja käyttöoikeuksista (pääsymatriisi) valmistetaan ennen koko projektin aloittamista
- Projekteja toteutettaessa on mahdollista luoda käyttäjäryhmiä vastaaville toimialueille
- Automaatio saavutetaan MS Windows -hallintatyökaluilla
Teknisten eritelmien toteuttaminen
Näiden vaatimusten virallistamisen jälkeen pidettiin taktinen tauko, jossa testattiin menetelmiä hakemistojen luomiseksi ja oikeuksien myöntämiseksi niille. Tarkoituksena oli käyttää vain PowerShellia, jotta projektia ei monimutkaistaisi. Kuten aiemmin kirjoitin, käsikirjoitusalgoritmi vaikutti melko yksinkertaiselta:
- rekisteröimme ryhmiä projektitunnuksesta johdetuilla nimillä (esim. KC40587) ja vastaavilla pääsymatriisissa määritellyillä rooleilla: KC40587-FI- for engineer; KC40587-PM – tuotepäällikölle jne.
- saamme luotujen ryhmien SID:t
- rekisteröi projektikansio ja vastaava joukko hakemistoja (alikansioiden luettelo riippuu jaosta, johon se on luotu ja määritelty pääsymatriisissa)
- antaa oikeudet ryhmille projektin uusille alihakemistoille pääsymatriisin mukaan.
Vaiheessa 1 havaitut vaikeudet:
- väärinkäsitys menetelmästä, jolla skriptissä määritetään pääsymatriisi (moniulotteinen matriisi on nyt toteutettu, mutta polkua sen täyttöön etsitään .xlsx-tiedoston/pääsymatriisin sisällön perusteella)
- mahdotonta asettaa käyttöoikeuksia SMB-osuuksiin synology-asemilla PoSH:n avulla (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), jonka vuoksi paljon aikaa meni hukkaan ja kaikki oli sovitettava skripteihin icacls-käyttöoikeuksien muokkaustyökalulla, mikä vaati teksti- ja cmd-tiedostojen välivaraston luomista.
Nykyisessä tilassa cmd-tiedostojen suorittamista ohjataan manuaalisesti riippuen tarpeesta rekisteröidä kansio projektille.
Kävi myös ilmi, että komentosarja tulisi suorittaa myös muiden metsien ryhmien rekisteröimiseksi (käytettiin termiä Cross-domains), ja suhde voi olla 1:n lisäksi 1:n ja monien välillä.
Tämä tarkoittaa, että ryhmät muista verkkotunnuksista, mukaan lukien naapurimetsästä, voivat nyt vaatia pääsyn minkä tahansa toimialueen resursseihin. Yhdenmukaisuuden saavuttamiseksi päätettiin luoda symmetrinen rakenne kaikkien metsien kaikkien palvelualueiden OU:iin (mustat pystysuorat soikeat). Kuten sanotaan, armeijassa kaiken pitäisi olla rumaa, mutta yhtenäistä:
Siten, kun projekti 80XXX rekisteröidään TG-verkkotunnukseen, komentosarja suorittaa:
1. vastaavan OU:n (punaiset vaakasuorat soikeat) luominen tälle verkkotunnukselle ja verkkotunnuksille, eli niille verkkotunnuksille, joiden työntekijöillä on oltava pääsy tähän resurssiin.
2. OU:n täyttäminen ryhmillä sellaisilla nimillä kuin -, Missä:
- SRC_ domain – verkkotunnusten välinen verkkotunnus, jonka työntekijöillä on pääsy DST-verkkoalueen resursseihin
- DST_domain – verkkotunnus, jonka resursseihin itse asiassa pitäisi tarjota pääsy, eli jonka vuoksi kaikki aloitettiin
- - hankkeen numero
- ROOLIT – pääsymatriisissa lueteltujen roolien nimet.
3. luetaan kaikkien mukana olevien verkkotunnusten kaikkien ryhmien SID-taulukko ja tallennetaan se myöhempää tiedonsiirtoa varten tiedostoon, joka määrittää oikeudet tiettyyn projektin alikansioon
4. lähdetiedostojen (parametri /restore) luominen oikeuksilla icacKC-apuohjelman käyttöön suoritettavassa tiedostotilassa "icacKC "as-nasNNKCCrojects" /restore C:TempKCKC40XXKC40XX.txt
5. luodaan CMD-tiedosto, joka yhdistää kaikki käynnistetyt icacl:t kaikille projektikansioille
Kuten aiemmin kirjoitettiin, suoritettavan tiedoston käynnistäminen tapahtuu manuaalisesti ja suoritustulosten arviointi tapahtuu myös manuaalisesti.
Vaikeudet, jotka meidän oli lopulta kohdattava:
- jos projektikansio on jo täynnä suurella määrällä tiedostoja, icacls-komennon suorittaminen olemassa olevilla taltioilla voi viedä huomattavasti aikaa ja joissakin tapauksissa johtaa epäonnistumiseen (esimerkiksi kun tiedostopolut ovat pitkiä);
- /restore-parametrin lisäksi meidän piti lisätä rivejä /reset-parametrilla siltä varalta, että kansioita ei luotu, vaan ne siirrettiin aiemmin olemassa olevista kansioista, jolloin juuren periytymisoikeudet estettiin;
- Osa ryhmien luomisskriptistä oli suoritettava jokaisen metsän mielivaltaiselle tasavirralle, ongelma koskee kunkin puun hallinnollisia tilejä.
Yleinen johtopäätös: on hyvin outoa, että markkinoilla ei ole vielä saman toiminnallisia apuohjelmia. Vaikuttaa mahdolliselta toteuttaa vastaava toiminnallisuus Sharepoint-portaalin pohjalta.
On myös käsittämätöntä, että PoSH-apuohjelmia ei voi käyttää kansiooikeuksien asettamiseen sinology-laitteissa.
Haluttaessa olen valmis jakamaan käsikirjoituksen luomalla projektin githubiin, jos joku on kiinnostunut.
Lähde: will.com