Moje karma je zřejmě taková: realizovat standardní úkoly všemožnými netriviálními způsoby. Pokud má někdo jinou představu o problému, prosím prodiskutujte to, aby bylo možné problém vyřešit.
Jednoho krásného rána vyvstal zajímavý úkol distribuovat práva skupinám uživatelů k různým sdílením obsahujícím podsložky projektů se složkami dokumentů. Vše bylo v pořádku a byl napsán skript pro přiřazení práv ke složkám. A pak se ukázalo, že skupiny by měly obsahovat uživatele z různých domén, z různých lesů (). Řekněme, že samotná sdílená položka se nachází na médiu Synology, registrovaném ve FB doméně lesa PSI. Úkol: umožnit uživatelům domén v jiné doménové struktuře přístup k obsahu této sdílené složky, a to velmi selektivně.
Po nějaké době měly technické specifikace následující podobu:
- 2 lesy: PSI les, TG les.
- Každá doména má 3 domény: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Mezi doménovými strukturami existuje důvěryhodný vztah; Synology vidí všechny skupiny zabezpečení ve všech doménových strukturách.
- Sdílené složky a složky/podsložky musí mít účty správce domény FB s právy FullControl
- Názvy složek by měly být systematizovány. Vedení koordinovalo ID projektu, rozhodl jsem se propojit název skupin zabezpečení s ID projektu.
- Projektové složky v systémových sdílených položkách musí obsahovat předem připravenou strukturu v souboru .xlsx s příslušnými přístupovými právy (R/RW/NA, kde NA – bez přístupu)
- Mělo by být možné omezit práva uživatelů/členů skupiny jednoho projektu pouze na určité adresáře tohoto projektu. Uživatel nemusí mít přístup k jiným adresářům/projektům v závislosti na členství ve skupině.
- Při vytváření projektové složky by měly být skupiny vytvořeny pokud možno automaticky v příslušných doménách s názvy odpovídajícími ID projektu.
Poznámky k technickým specifikacím
- Nastavování důvěryhodných vztahů není zahrnuto v rozsahu technických specifikací
- ID projektu obsahuje čísla a znaky latinky
- Uživatelské role projektu pro všechny domény mají standardní názvy
- Před zahájením celého projektu je připraven .xlsx soubor se složkami a přístupovými právy (access matrix)
- Při realizaci projektů je možné vytvářet skupiny uživatelů v odpovídajících doménách
- Automatizace je dosažena použitím standardních administračních nástrojů MS Windows
Implementace technických specifikací
Po formalizaci těchto požadavků byla učiněna taktická pauza na testování metod vytváření adresářů a přidělování práv k nim. Bylo zamýšleno používat pouze PowerShell, aby se projekt nekomplikoval. Jak jsem psal dříve, algoritmus skriptu se zdál docela jednoduchý:
- registrujeme skupiny s názvem odvozeným z ID projektu (například KC40587) a odpovídajícími rolemi uvedenými v přístupové matici: KC40587-EN- pro inženýra; KC40587-PM – pro produktového manažera atd.
- získáme SID vytvořených skupin
- zaregistrovat složku projektu a odpovídající sadu adresářů (seznam podsložek závisí na sdílené složce, ve které je vytvořena a definována v přístupové matici)
- přiřadit práva skupinám pro nové podadresáře projektu podle přístupové matice.
Potíže, které se vyskytly ve fázi 1:
- nepochopení způsobu, jak specifikovat přístupovou matici ve skriptu (nyní je implementováno vícerozměrné pole, ale cesta k jeho naplnění se hledá na základě obsahu .xlsx souboru/přístupové matice)
- nemožnost nastavení přístupových práv ve sdílených složkách SMB na jednotkách synology pomocí 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ž se ztratilo mnoho času a vše se muselo přizpůsobit skriptům pomocí utility pro úpravu přístupových práv icacls, což vyžadovalo vytvoření meziúložiště textových a cmd souborů.
V aktuálním režimu je spouštění cmd souborů řízeno ručně v závislosti na nutnosti registrace složky pro projekt.
Ukázalo se také, že skript by měl být spuštěn i pro registraci skupin v jiných lesích (používal se termín Cross-domains) a poměr může být nejen 1 ku jedné, ale i 1 ku mnoha.
To znamená, že skupiny z jiných domén, včetně sousední doménové struktury, si nyní mohou nárokovat přístup ke zdrojům libovolné domény. Pro dosažení jednotnosti bylo rozhodnuto vytvořit symetrickou strukturu v OU všech obsluhovaných domén všech lesů (černé svislé ovály). Jak se říká, v armádě by mělo být všechno ošklivé, ale jednotné:
Při registraci projektu 80XXX v doméně TG tedy skript provede:
1. vytvoření odpovídajících OU (červené vodorovné ovály) v této doméně a mezi doménami, tedy těch domén, jejichž zaměstnanci musí mít přístup k tomuto zdroji.
2. vyplnění organizační jednotky skupinami s názvy jako -, kde:
- Doména SRC_ – mezi doménami, jejichž zaměstnanci budou mít přístup ke zdrojům domény DST
- DST_domain – doména, k jejímuž prostředkům by měl být ve skutečnosti poskytnut přístup, to znamená, kvůli které bylo vše spuštěno
- — číslo projektu
- ROLE – názvy rolí uvedených v přístupové matici.
3. načtení pole SID všech skupin všech zapojených domén a jeho uložení pro následný přenos dat do souboru, který definuje práva ke konkrétní podsložce projektu
4. generování zdrojových souborů (parametr /restore) se sadou práv pro použití obslužným programem icacKC v režimu spustitelných souborů „icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. vytvoření souboru CMD, který kombinuje všechny spuštěné icacls pro všechny složky projektu
Jak bylo napsáno dříve, spuštění spustitelného souboru se provádí ručně a vyhodnocení výsledků spuštění se také provádí ručně.
Potíže, kterým jsme nakonec museli čelit:
- pokud je složka projektu již naplněna velkým počtem souborů, může spuštění příkazu icacls na existujících svazcích trvat značně dlouho a v některých případech vedlo k selhání (například když jsou cesty k souborům dlouhé);
- kromě parametru /restore jsme museli přidat řádky s parametrem /reset pro případ, že složky nebyly vytvořeny, ale byly přeneseny z již existujících složek, se zakázanými dědickými právy od roota;
- Část skriptu pro vytváření skupin bylo nutné spustit na libovolném DC každého lesa, problém se týká administrativních účtů pro každý strom.
Obecný závěr: je velmi zvláštní, že na trhu zatím nejsou žádné utility s podobnou funkčností. Zdá se, že podobnou funkcionalitu lze implementovat na portálu Sharepoint.
Nepochopitelné je také to, že není možné použít PoSH utility pro nastavení práv složek na sinologických zařízeních.
V případě potřeby jsem připraven sdílet skript vytvořením nějakého projektu na githubu, pokud by měl někdo zájem.
Zdroj: www.habr.com