Grandskala asigno de rajtoj al domajnaj uzantoj de malsamaj arbaroj

Ŝajne mia karmo estas ĉi tio: efektivigi normajn taskojn en ĉiaj ne-trivialaj manieroj. Se iu havas alian vizion pri la problemo, bonvolu diskuti ĝin por ke la afero estu ellaborita.

Unu belan matenon ekestis interesa tasko distribui rajtojn al grupoj de uzantoj por malsamaj akcioj enhavantaj subdosierujojn de projektoj kun dokumentdosierujoj. Ĉio estis bona kaj skripto estis skribita por atribui rajtojn al la dosierujoj. Kaj tiam montriĝis, ke la grupoj devus enhavi uzantojn de malsamaj domajnoj, de malsamaj arbaroj (por tiuj, kiuj forgesis, kio ĝi estas). Ni diru, ke la parto mem troviĝas sur Synology-komunikiloj, registritaj en la FB-domajno de la PSI-arbaro. Tasko: permesi uzantojn de domajnoj en alia arbaro havi aliron al la enhavo de ĉi tiu parto, kaj tre selekteme.

Post iom da tempo, la teknikaj specifoj prenis la sekvan formon:

• 2 arbaroj: PSI-arbaro, TG-arbaro.

  

• Ĉiu arbaro havas 3 domajnojn: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Estas fidinda rilato inter arbaroj; Synology vidas ĉiujn Sekurecgrupojn en ĉiuj arbaroj.
• Akcioj kaj dosierujoj/subdosierujoj devas havi FB-domajnajn administrantajn kontojn kun FullControl-rajtoj
• La nomoj de la dosierujoj estu sistemigitaj. Administrado kunordigis la projektajn identigilojn; mi decidis ligi la nomon de la Sekurecaj grupoj al la projektaj identigiloj.
• Projektaj dosierujoj en sistemaj akcioj devas enhavi strukturon preparitan anticipe en .xlsx-dosiero, kun taŭgaj alirprivilegioj (R/RW/NA, kie NA - neniu aliro)

  

• Eblus limigi la rajtojn de uzantoj/grupanoj de unu projekto nur al certaj dosierujoj de tiu projekto. La uzanto eble ne havas aliron al aliaj dosierujoj/projektoj, depende de grupa membreco.
• Kiam oni kreas projektan dosierujon, grupoj devus esti kreitaj kiel eble plej aŭtomate en la taŭgaj domajnoj kun nomoj respondaj al projektaj identigiloj.

Notoj al la teknikaj specifoj

• Starigi fidajn rilatojn ne estas inkluzivita en la amplekso de la teknikaj specifoj
• Projekta ID enhavas nombrojn kaj latinajn signojn
• Projektaj uzantroloj por ĉiuj domajnoj havas normajn nomojn
• .xlsx-dosiero kun dosierujoj kaj alirrajtoj (alira matrico) estas preta antaŭ la komenco de la tuta projekto
• Dum efektivigo de projektoj, eblas krei uzantgrupojn en la respondaj domajnoj
• Aŭtomatigo estas atingita uzante normajn MS Windows-administrajn ilojn

Efektivigo de teknikaj specifoj

Post formaligado de tiuj postuloj, taktika paŭzo estis prenita por testi metodojn por krei adresarojn kaj atribui rajtojn al ili. Oni intencis uzi nur PowerShell, por ne malfaciligi la projekton. Kiel mi skribis pli frue, la skripto-algoritmo ŝajnis sufiĉe simpla:

• ni registras grupojn kun nomo derivita de la projekto ID (ekzemple KC40587) kaj la respondaj roloj specifitaj en la alirmatrico: KC40587-EN- por inĝeniero; KC40587-PM - por produktmanaĝero, ktp.
• ni ricevas la SID-ojn de la kreitaj grupoj
• registri la projektan dosierujon kaj la respondan aron da dosierujoj (la listo de subdosierujoj dependas de la parto en kiu ĝi estas kreita kaj difinita en la alirmatrico)
• atribui rajtojn al grupoj por novaj subdosierujoj de la projekto laŭ la alirmatrico.

Malfacilaĵoj renkontitaj en etapo 1:

• miskompreno de la metodo de specifo de la alirmatrico en la skripto (plurdimensia tabelo nun estas efektivigita, sed la vojo al plenigado de ĝi estas serĉata surbaze de la enhavo de la .xlsx dosiero/alira matrico)

  

• neeblo agordi alirrajtojn en SMB-akcioj sur sinologiaj diskoj uzante PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), pro kio multe da tempo estis perdita kaj ĉio devis esti adaptita al skriptoj uzante la icacls alirrajtojn redaktan ilon, kiu postulis la kreadon de meza deponejo de teksto kaj cmd dosieroj.

En la nuna reĝimo, la ekzekuto de cmd-dosieroj estas kontrolita permane, depende de la bezono registri dosierujon por la projekto.

Ankaŭ montriĝis, ke la skripto ankaŭ devas esti ekzekutita por registri grupojn en aliaj arbaroj (la termino Kruco-domajnoj estis uzata), kaj la proporcio povas esti ne nur 1 al unu, sed ankaŭ 1 al multaj.

Ĉi tio signifas, ke grupoj de aliaj transdomajnoj, inkluzive de najbara arbaro, nun povas postuli aliron al la rimedoj de iu ajn domajno. Por atingi unuformecon, estis decidite krei simetrian strukturon en la OU de ĉiuj servitaj domajnoj de ĉiuj arbaroj (nigraj vertikalaj ovaloj). Kiel oni diras, en la armeo ĉio estu malbela, sed uniforma:

Tiel, kiam oni registras projekton 80XXX en la TG-domajno, la skripto efektivigas:

1. kreado de la respondaj OU (ruĝaj horizontalaj ovaloj) en ĉi tiu domajno kaj transdomajnoj, tio estas, tiuj domajnoj kies dungitoj devas havi aliron al ĉi tiu rimedo.

2. plenigi OU per grupoj kun nomoj kiel -, Kie:

• SRC_ domajno - transdomajno kies dungitoj havos aliron al DST-domajnaj rimedoj
• DST_domain - la domajno al kies rimedoj, fakte, aliro devus esti disponigita, tio estas, pro kiu ĉio estis komencita
• — numero de projekto
• ROLOJ - nomoj de la roloj listigitaj en la alirmatrico.

3. legante la aron de SID-oj de ĉiuj grupoj de ĉiuj engaĝitaj domajnoj kaj konservante ĝin por posta datumtransdono al dosiero, kiu difinas la rajtojn al specifa projekta subdosierujo.

4. generacio de fontdosieroj (parametro /restore) kun aro de rajtoj por uzo de la icacKC-ilaĵo en rulebla dosierreĝimo "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"

5. kreante CMD-dosieron, kiu kombinas ĉiujn lanĉitajn icacls por ĉiuj projektaj dosierujoj

Kiel estis skribita pli frue, lanĉo de la plenumebla dosiero estas farita permane kaj taksado de la ekzekutrezultoj ankaŭ estas farita permane.

Malfacilaĵoj kiujn ni devis alfronti finfine:

• se la projekta dosierujo jam estas plenigita per granda nombro da dosieroj, tiam ruli la komandon icacls sur la ekzistantaj volumoj povas preni konsiderindan tempon, kaj en iuj kazoj kaŭzis malsukceson (ekzemple, kiam estas longaj dosiervojoj);
• krom la parametro /restore, ni devis aldoni liniojn kun la parametro /reset, se la dosierujoj ne estis kreitaj, sed estis translokigitaj el antaŭe ekzistantaj dosierujoj, kun heredaj rajtoj de la radiko malebligita;
• Parto de la skripto por krei grupojn devis esti ekzekutita sur arbitra dc de ĉiu arbaro, la problemo koncernas administrajn kontojn por ĉiu arbo.

Ĝenerala konkludo: estas tre strange, ke ankoraŭ ne ekzistas utilecoj kun simila funkcieco sur la merkato. Ŝajnas eble efektivigi similan funkciecon bazitan sur la Sharepoint-portalo.
Ankaŭ estas nekompreneble, ke ne eblas uzi PoSH-servaĵojn por agordi dosierujojn sur sinologiaj aparatoj.

Se vi deziras, mi pretas dividi la skripton kreante iun projekton sur github se iu interesiĝas.

fonto: www.habr.com