Zřejmě mám takovou karmu: realizovat standardní úkoly různými netradičními způsoby. Pokud má někdo jiný pohled na problém – zvu vás k diskusi, abychom danou otázku probrali.
Jednoho krásného rána se objevila zajímavá úloha, jak přidělit práva skupinám uživatelů na různé sdílené složky obsahující podsložky projektů s dokumenty. Všechno bylo v pořádku a byl napsán skript, který přiřazoval práva na složky. A pak se ukázalo, že skupiny musí obsahovat uživatele z různých domén, z různých lesů (). Předpokládejme, že samotná sdílená složka se nachází na zařízení Synology, registrovaném v doméně FB, lesa PSI. Úkol: povolit uživatelům domén. jiného lesa přístup k obsahu této sdílené složky, a to velmi selektivně.
Zadání se po nějaké době vyjasnilo v následující podobě:
- 2 lesy: Les PSI, les TG.
- V každém lese jsou 3 domény: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Mezi lesy – důvěryhodné vztahy, Synology vidí všechny skupiny Security ve všech lesích.
- Na sdílených složkách a složkách/podsložkách musí být nutně účty administrátorů domény FB s právy FullControl.
- Názvy složek sdílené složky musí být systematizovány. Sjednávání ID projektů bylo provedeno vedením, rozhodl jsem se názvy skupin Security přiřadit k ID projektů.
- Složky projektů ve systémových sdílených složkách musí obsahovat předem připravenou strukturu v .xlsx souboru, se odpovídajícími privilegii přístupu (R/RW/NA, kde NA – přístup není k dispozici).
- Musí být možné omezit práva uživatelů/členů skupiny jednoho projektu pouze na určité adresáře daného projektu. K dalším adresářům/projektům nemusí mít uživatel přístup v závislosti na členství ve skupinách.
- Při zakládání složky projektu by měly být maximálně automaticky vytvářeny skupiny ve odpovídajících doménách, které nesou názvy odpovídající ID projektů.
Poznámky k zadání
- Nastavení důvěryhodných vztahů není součástí zadání.
- ID projektu obsahuje číslice a latinku.
- Role uživatelů projektů pro všechny domény mají typická názvy.
- Soubor .xlsx se složkami a právy přístupu (matice přístupu) je připravován před začátkem realizace celého projektu.
- Při realizaci projektů je možné vytváření skupin uživatelů v odpovídajících doménách.
- Automatizace je dosaženo pomocí standardních prostředků administrace MS Windows
Realizace technického zadání
Po formálním stanovení těchto požadavků byla učiněna taktická pauza na vyzkoušení metod vytváření katalogů a jejich přidělování práv. Používat se měl pouze PowerShell, aby se projekt nekomplikoval. Jak jsem již dříve zmiňoval, algoritmus skriptu se zdál být dostatečně jednoduchý:
- registrujeme skupiny nazvané podle ID projektu (například KC40587) a odpovídající role uvedené v matici přístupu: KC40587-EN- pro inženýra; KC40587-PM – pro produktového manažera atd.
- získáváme SID vytvořených skupin
- registrujeme složku projektu a odpovídající sadu katalogů (seznam podadresářů závisí na sdílení, v němž je vytvářen a je definován v matici přístupu)
- na nové podadresáře projektu přidělujeme práva skupinám podle matice přístupu.
Obtíže, kterým jsme čelili v 1. fázi:
- nepochopení způsobu zadávání matice přístupu ve skriptu (nyní je realizován vícerozměrný pole, ale hledá se způsob jeho vyplnění na základě obsahu .xlsx souboru/matice přístupu)
- nemožnost přidělovat přístupová práva ve SMB sdíleních na úložištích Synology pomocí prostředků PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), kvůli čemuž byla ztracena spousta času a bylo nutné přizpůsobit vše skriptům s použitím nástroje pro úpravu přístupových práv icacls, což vyžadovalo vytvoření mezistupňového úložiště textových a cmd souborů.
V aktuálním režimu je provádění cmd souborů kontrolováno ručně, v případě potřeby registrace složky pro projekt.
Také se ukázalo, že skript musí být prováděn i pro registraci skupin v jiných lesích (používali jsme termín Cross-domains), přičemž poměr nemusí být pouze 1 k 1, ale i 1 k mnoha.
To znamená, že na přístup k prostředkům nějaké domény nyní mohou žádat skupiny z jiných kros-domen, včetně sousedního lesa. Pro zajištění jednotnosti bylo rozhodnuto o vytvoření symetrické struktury v OU všech obsluhovaných domén všech lesů (černé vertikální ovály). Jak se říká, v armádě by mělo být vše chaotické, ale jednotné:
Při registraci projektu 80XXX v doméně TG skript provádí:
1. vytvoření odpovídající OU (červené vodorovné ovály) v této doméně a cross-doménách, tedy v těch doménách, jejichž zaměstnanci by měli mít přístup k tomuto zdroji.
2. naplnění OU skupinami s názvy ve formátu <SRC_domain><DST_domain><ID_project>-, kde:
- SRC_domain – cross-doména, jejíž zaměstnanci budou mít přístup k prostředkům domény DST
- DST_domain – doména, k jejímž prostředkům by měl být přístup poskytnut, tedy proč se to celé dělá
- <ID_project> — číslo projektu
- ROLES – názvy rolí uvedené v matici přístupu.
3. přečtení pole SID všech skupin všech zúčastněných domén a jeho uložení pro následný přenos dat do souboru, který definuje práva na konkrétní podsložku projektu
4. generování zdrojových souborů (parametr /restore) se sadou práv pro použití utilitou icacKC v režimu spustitelného souboru „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt“
5. vytvoření souboru CMD, který spojuje všechny spouštěné icacls pro všechny složky projektu
Jak bylo uvedeno dříve, spuštění spustitelného souboru se provádí ručně a hodnocení výsledků provedení se také provádí ručně.
Obtíže, se kterými se ve skutečnosti setkali:
- pokud je složka projektu již naplněna velkým množstvím souborů, pak provedení příkazu icacls na existujících objemech může trvat značnou dobu, a v některých případech vedlo k selhání (například při přítomnosti dlouhých cest k souborům);
- kromě parametru /restore bylo nutné přidat řádky s parametrem /reset pro případ, že by složky nebyly vytvořeny, ale byly přesunuty z již existujících složek, s vypnutými právy dědičnosti z kořene;
- část skriptu pro vytváření skupin bylo nutné spustit na libovolném dc každého lesa, problém se týká uživatelských administrativních účtů pro každý strom.
Obecný závěr: je velmi podivné, že na trhu zatím nejsou nástroje s podobnou funkčností. Realizace podobné funkčnosti na bázi portálu Sharepoint se jeví jako možná.
Také se zdá být nejasné, proč není možné používat PoSH nástroje pro nastavení práv na složku na zařízeních sinology.
Pokud by měl kdokoli zájem, jsem ochoten sdílet skript vytvořením projektu na github.
Zdroj: habr.com
