Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

Acīmredzot mana karma ir šāda: īstenot standarta uzdevumus visdažādākajos ne-triviālos veidos. Ja kādam ir citāds redzējums par problēmu, lūdzu diskusiju, lai jautājumu varētu atrisināt.

Kādā jaukā rītā radās interesants uzdevums sadalīt tiesības lietotāju grupām uz dažādiem koplietojumiem, kas satur projektu apakšmapes ar dokumentu mapēm. Viss bija kārtībā un tika uzrakstīts skripts, lai piešķirtu tiesības mapēm. Un tad izrādījās, ka grupās ir jābūt lietotājiem no dažādiem domēniem, no dažādiem mežiem (tiem, kas aizmirsa, kas tas ir). Pieņemsim, ka pati daļa atrodas Synology medijā, kas reģistrēta PSI meža FB domēnā. Uzdevums: ļaut cita meža domēnu lietotājiem piekļūt šī koplietojuma saturam, turklāt ļoti selektīvi.

Pēc kāda laika tehniskās specifikācijas ieguva šādu formu:

  • 2 meži: PSI mežs, TG mežs.

    Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

  • Katram mežam ir 3 domēni: PSI (ZG, PSI, FB); TG (TG, HU, KC).
  • Starp mežiem pastāv uzticības attiecības; Synology redz visas drošības grupas visos mežos.
  • Koplietojamiem failiem un mapēm/apakšmapēm ir jābūt FB domēna administratora kontiem ar FullControl tiesībām
  • Mapju nosaukumi ir jāsistematizē. Vadība koordinēja projektu ID, es nolēmu saistīt drošības grupu nosaukumus ar projektu ID.
  • Sistēmas koplietošanas projektu mapēs ir jāietver struktūra, kas iepriekš sagatavota .xlsx failā ar atbilstošām piekļuves privilēģijām (R/RW/NA, kur NA — nav piekļuves)

    Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

  • Jābūt iespējai ierobežot viena projekta lietotāju/grupas dalībnieku tiesības tikai uz noteiktiem šī projekta direktorijiem. Lietotājam var nebūt piekļuves citiem direktorijiem/projektiem atkarībā no dalības grupā.
  • Veidojot projekta mapi, pēc iespējas automātiski ir jāveido grupas atbilstošajos domēnos ar nosaukumiem, kas atbilst projekta ID.

Piezīmes par tehniskajām specifikācijām

  • Uzticības attiecību izveide nav iekļauta tehnisko specifikāciju darbības jomā
  • Projekta ID satur ciparus un latīņu rakstzīmes
  • Projekta lietotāju lomām visiem domēniem ir standarta nosaukumi
  • Pirms visa projekta sākuma tiek sagatavots .xlsx fails ar mapēm un piekļuves tiesībām (piekļuves matrica).
  • Īstenojot projektus, ir iespējams izveidot lietotāju grupas atbilstošajos domēnos
  • Automatizācija tiek panākta, izmantojot standarta MS Windows administrēšanas rīkus

Tehnisko specifikāciju ieviešana

Pēc šo prasību formalizēšanas tika ieturēta taktiskā pauze, lai pārbaudītu direktoriju izveides un tiem tiesību piešķiršanas metodes. Bija paredzēts izmantot tikai PowerShell, lai nesarežģītu projektu. Kā jau rakstīju iepriekš, skripta algoritms šķita diezgan vienkāršs:

  • mēs reģistrējam grupas ar nosaukumu, kas iegūts no projekta ID (piemēram, KC40587) un atbilstošajām lomām, kas norādītas piekļuves matricā: KC40587-EN- inženierim; KC40587-PM – produktu vadītājam u.c.
  • mēs iegūstam izveidoto grupu SID
  • reģistrēt projekta mapi un atbilstošo direktoriju kopu (apakšmapju saraksts ir atkarīgs no koplietojuma, kurā tas ir izveidots un definēts piekļuves matricā)
  • piešķirt tiesības grupām jauniem projekta apakšdirektorijiem atbilstoši piekļuves matricai.

1. posmā radušās grūtības:

  • pārpratums par pieejas matricas norādīšanas metodi skriptā (tagad ir ieviests daudzdimensiju masīvs, bet ceļš uz tā aizpildīšanu tiek meklēts, pamatojoties uz .xlsx faila/piekļuves matricas saturu)

    Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

  • nav iespējams iestatīt piekļuves tiesības SMB kopīgošanai sinoloģijas diskdziņos, izmantojot PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), kā dēļ tika zaudēts daudz laika un viss bija jāpielāgo skriptiem, izmantojot icacls piekļuves tiesību rediģēšanas utilītu, kas prasīja teksta un cmd failu starprepozitoriju izveidi.

Pašreizējā režīmā cmd failu izpilde tiek kontrolēta manuāli, atkarībā no nepieciešamības reģistrēt mapi projektam.

Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

Izrādījās arī, ka skripts jāizpilda arī grupu reģistrēšanai citos mežos (izmantots termins Cross-domains), un attiecība var būt ne tikai 1 pret vienu, bet arī 1 pret daudziem.

Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

Tas nozīmē, ka grupas no citiem starpdomēniem, tostarp blakus esoša meža, tagad var pieprasīt piekļuvi jebkura domēna resursiem. Lai panāktu vienveidību, tika nolemts visu mežu visu apkalpoto domēnu OU izveidot simetrisku struktūru (melni vertikāli ovāli). Kā saka, armijā visam jābūt neglītam, bet vienveidīgam:

Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

Tādējādi, reģistrējot projektu 80XXX TG domēnā, skripts izpilda:

1. atbilstošo OU (sarkani horizontāli ovāli) izveide šajā domēnā un starpdomēnos, tas ir, tiem domēniem, kuru darbiniekiem ir jābūt piekļuvei šim resursam.

2. OU aizpildīšana ar grupām ar tādiem nosaukumiem kā -, Kur:

  • SRC_ domēns – starpdomēns, kura darbiniekiem būs piekļuve DST domēna resursiem
  • DST_domēns – domēns, kura resursiem faktiski ir jānodrošina piekļuve, tas ir, kura dēļ viss tika sākts
  • — projekta numurs
  • ROLES – piekļuves matricā uzskaitīto lomu nosaukumi.

3. nolasot visu iesaistīto domēnu visu grupu SID masīvu un saglabājot to turpmākai datu pārsūtīšanai failā, kas nosaka tiesības uz konkrētu projekta apakšmapi.

4. avota failu ģenerēšana (parametrs /restore) ar tiesību kopu, ko izmantot icacKC utilīta izpildāmā faila režīmā “icacKC "as-nasNNKCCrojects" /restore C:TempKCKC40XXKC40XX.txt

5. CMD faila izveide, kas apvieno visus palaistos icacls visām projekta mapēm

Liela mēroga tiesību piešķiršana domēna lietotājiem no dažādiem mežiem

Kā jau tika rakstīts iepriekš, izpildāmā faila palaišana tiek veikta manuāli, un arī izpildes rezultātu novērtēšana tiek veikta manuāli.

Grūtības, ar kurām mums nācās saskarties beigās:

  • ja projekta mape jau ir piepildīta ar lielu skaitu failu, tad komandas icacls palaišana esošajos sējumos var aizņemt ievērojamu laiku un dažos gadījumos izraisīt kļūmi (piemēram, ja ir gari failu ceļi);
  • papildus parametram /restore mums bija jāpievieno rindas ar parametru /reset gadījumā, ja mapes netika izveidotas, bet tika pārsūtītas no iepriekš esošām mapēm, ar atspējotām mantojuma tiesībām no saknes;
  • Daļa no skripta grupu izveidei bija jāizpilda uz katra meža patvaļīgi līdzstrāvas, problēma attiecas uz katra koka administratīvajiem kontiem.

Vispārējs secinājums: ļoti dīvaini, ka tirgū vēl nav nevienas līdzīgas funkcionalitātes komunālo pakalpojumu. Šķiet, ka ir iespējams ieviest līdzīgu funkcionalitāti, pamatojoties uz Sharepoint portālu.
Tāpat nav saprotams, ka sinology ierīcēs mapju tiesību iestatīšanai nav iespējams izmantot PoSH utilītus.

Ja vēlas, esmu gatavs padalīties ar skriptu, izveidojot kādu projektu githubā, ja kādam tas interesē.

Avots: www.habr.com

Pievieno komentāru