Tila ang aking karma ay ito: upang ipatupad ang mga karaniwang gawain sa lahat ng uri ng mga di-maliit na paraan. Kung ang isang tao ay may ibang pananaw sa problema, mangyaring pag-usapan ito upang maayos ang isyu.
Isang magandang umaga isang kawili-wiling gawain ang lumitaw upang ipamahagi ang mga karapatan sa mga grupo ng mga gumagamit para sa iba't ibang bahagi na naglalaman ng mga subfolder ng mga proyekto na may mga folder ng dokumento. Maayos ang lahat at may isinulat na script para magtalaga ng mga karapatan sa mga folder. At pagkatapos ay lumabas na ang mga grupo ay dapat maglaman ng mga gumagamit mula sa iba't ibang mga domain, mula sa iba't ibang kagubatan (). Sabihin nating ang share mismo ay matatagpuan sa Synology media, na nakarehistro sa FB domain ng PSI forest. Gawain: upang payagan ang mga gumagamit ng mga domain sa ibang kagubatan na magkaroon ng access sa mga nilalaman ng bahaging ito, at napakapili.
Pagkaraan ng ilang oras, ang mga teknikal na pagtutukoy ay kinuha ang sumusunod na anyo:
- 2 kagubatan: kagubatan ng PSI, kagubatan ng TG.
- Ang bawat kagubatan ay may 3 domain: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- May ugnayang tiwala sa pagitan ng mga kagubatan; Nakikita ng Synology ang lahat ng grupo ng Seguridad sa lahat ng kagubatan.
- Ang mga pagbabahagi at mga folder/subfolder ay dapat may mga FB domain administrator account na may mga karapatan sa FullControl
- Ang mga pangalan ng mga folder ay dapat na sistematiko. Pinag-ugnay ng pamamahala ang mga ID ng proyekto; nagpasya akong i-link ang pangalan ng mga pangkat ng Seguridad sa mga ID ng proyekto.
- Ang mga folder ng proyekto sa mga bahagi ng system ay dapat maglaman ng istraktura na inihanda nang maaga sa isang .xlsx file, na may naaangkop na mga pribilehiyo sa pag-access (R/RW/NA, kung saan NA β walang access)
- Posibleng paghigpitan ang mga karapatan ng mga user/miyembro ng grupo ng isang proyekto sa ilang partikular na direktoryo lamang ng proyektong iyon. Maaaring walang access ang user sa ibang mga direktoryo/proyekto, depende sa membership ng grupo.
- Kapag gumagawa ng folder ng proyekto, dapat na awtomatikong gawin ang mga grupo hangga't maaari sa naaangkop na mga domain na may mga pangalang nauugnay sa mga project ID.
Mga tala sa teknikal na pagtutukoy
- Ang pag-set up ng mga ugnayan ng tiwala ay hindi kasama sa saklaw ng mga teknikal na detalye
- Ang Project ID ay naglalaman ng mga numero at Latin na character
- Ang mga tungkulin ng user ng proyekto para sa lahat ng domain ay may mga karaniwang pangalan
- Ang isang .xlsx file na may mga folder at mga karapatan sa pag-access (access matrix) ay inihanda bago magsimula ang buong proyekto
- Kapag nagpapatupad ng mga proyekto, posibleng lumikha ng mga pangkat ng user sa mga kaukulang domain
- Ang pag-aautomat ay nakakamit sa pamamagitan ng paggamit ng karaniwang mga tool sa pangangasiwa ng MS Windows
Pagpapatupad ng mga teknikal na pagtutukoy
Matapos gawing pormal ang mga kinakailangang ito, isang taktikal na paghinto ang ginawa upang subukan ang mga pamamaraan para sa paglikha ng mga direktoryo at pagtatalaga ng mga karapatan sa kanila. Ito ay nilayon na gumamit lamang ng PowerShell, upang hindi gawing kumplikado ang proyekto. Tulad ng isinulat ko kanina, ang script algorithm ay tila medyo simple:
- nagrerehistro kami ng mga pangkat na may pangalang hango sa project ID (halimbawa KC40587) at ang mga kaukulang tungkuling tinukoy sa access matrix: KC40587-EN- para sa inhinyero; KC40587-PM β para sa product manager, atbp.
- nakukuha namin ang mga SID ng mga nilikhang grupo
- irehistro ang folder ng proyekto at ang kaukulang hanay ng mga direktoryo (ang listahan ng mga subfolder ay nakasalalay sa bahagi kung saan ito nilikha at tinukoy sa access matrix)
- Nagtatalaga kami ng mga karapatan sa mga pangkat sa mga bagong subdirectory ng proyekto ayon sa access matrix.
Mga paghihirap na nakatagpo sa yugto 1:
- hindi pagkakaunawaan sa paraan ng pagtukoy ng access matrix sa script (isang multidimensional array ay ipinapatupad na ngayon, ngunit ang landas sa pagpuno nito ay hinahanap batay sa mga nilalaman ng .xlsx file/access matrix)
- imposibilidad ng pagtatakda ng mga karapatan sa pag-access sa mga pagbabahagi ng SMB sa mga synology drive gamit ang PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), dahil kung saan maraming oras ang nawala at ang lahat ay kailangang iakma sa mga script gamit ang icacls access rights editing utility, na nangangailangan ng paglikha ng intermediate repository ng text at cmd file.
Sa kasalukuyang mode, ang pagpapatupad ng mga cmd file ay kinokontrol nang manu-mano, depende sa pangangailangan na magrehistro ng isang folder para sa proyekto.
Ito rin ay lumabas na ang script ay dapat ding isagawa upang magrehistro ng mga grupo sa iba pang mga kagubatan (ang terminong Cross-domain ang ginamit), at ang ratio ay maaaring hindi lamang 1 sa isa, kundi pati na rin 1 sa marami.
Nangangahulugan ito na ang mga grupo mula sa iba pang mga cross-domain, kabilang ang isang kalapit na kagubatan, ay maaari na ngayong mag-claim ng access sa mga mapagkukunan ng anumang domain. Upang makamit ang pagkakapareho, napagpasyahan na lumikha ng isang simetriko na istraktura sa OU ng lahat ng mga domain ng serbisyo ng lahat ng kagubatan (mga itim na patayong oval). Tulad ng sinasabi nila, sa hukbo ang lahat ay dapat na pangit, ngunit uniporme:
Kaya, kapag nagrerehistro ng proyekto 80XXX sa TG domain, ang script ay nagpapatupad ng:
1. paglikha ng kaukulang OU (mga pulang pahalang na oval) sa domain na ito at mga cross-domain, iyon ay, ang mga domain na ang mga empleyado ay dapat magkaroon ng access sa mapagkukunang ito.
2. pagpuno sa OU ng mga pangkat na may mga pangalan tulad ng -, kung saan:
- SRC_ domain β cross-domain na ang mga empleyado ay magkakaroon ng access sa DST domain resources
- DST_domain - ang domain kung saan ang mga mapagkukunan, sa katunayan, ay dapat magbigay ng access, iyon ay, para sa kapakanan kung saan nagsimula ang lahat
- β numero ng proyekto
- ROLES β mga pangalan ng mga tungkuling nakalista sa access matrix.
3. binabasa ang hanay ng mga SID ng lahat ng grupo ng lahat ng kasangkot na domain at i-save ito para sa kasunod na paglilipat ng data sa isang file na tumutukoy sa mga karapatan sa isang partikular na subfolder ng proyekto
4. pagbuo ng mga source file (parameter /restore) na may hanay ng mga karapatan para magamit ng icacKC utility sa executable file mode βicacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. paglikha ng CMD file na pinagsasama ang lahat ng inilunsad na icacls para sa lahat ng mga folder ng proyekto
Tulad ng naisulat kanina, ang paglulunsad ng executable file ay ginagawa nang manu-mano at ang pagsusuri ng mga resulta ng pagpapatupad ay ginagawa din nang manu-mano.
Mga paghihirap na kinailangan naming harapin sa huli:
- kung ang folder ng proyekto ay napuno na ng isang malaking bilang ng mga file, kung gayon ang pagpapatakbo ng icacls na utos sa mga umiiral na volume ay maaaring tumagal ng malaking oras, at sa ilang mga kaso ay humantong sa pagkabigo (halimbawa, kapag may mahabang landas ng file);
- bilang karagdagan sa parameter na /restore, kailangan naming magdagdag ng mga linya na may parameter na /reset kung sakaling hindi nalikha ang mga folder, ngunit inilipat mula sa dati nang umiiral na mga folder, na may mga karapatan sa pamana mula sa root na hindi pinagana;
- Ang bahagi ng script para sa paglikha ng mga grupo ay kailangang isagawa sa isang arbitrary na dc ng bawat kagubatan, ang problema ay may kinalaman sa mga administratibong account para sa bawat puno.
Pangkalahatang konklusyon: kakaiba na wala pang mga utility na may katulad na pag-andar sa merkado. Mukhang posible na ipatupad ang naturang pag-andar batay sa portal ng Sharepoint.
Hindi rin maintindihan na hindi posible na gumamit ng PoSH utilities para sa pagtatakda ng mga karapatan sa folder sa mga device ng sinology.
Kung ninanais, handa akong ibahagi ang script sa pamamagitan ng paglikha ng ilang proyekto sa github kung may interesado.
Pinagmulan: www.habr.com