Nagyszabású jogok hozzárendelése a különböző erdőkből származó tartományfelhasználókhoz

Nyilván a karmám a következő: standard feladatokat mindenféle nem triviális módon végrehajtani. Ha valaki másképp látja a problémát, kérjük, beszélje meg, hogy a probléma megoldható legyen.

Egy szép reggelen érdekes feladat merült fel, hogy a projektek almappáját és dokumentummappákat tartalmazó különböző megosztásokhoz jogokat osszunk ki felhasználói csoportoknak. Minden rendben volt, és egy szkriptet írtak a mappákhoz való jogok hozzárendeléséhez. Aztán kiderült, hogy a csoportoknak különböző tartományokból, különböző erdőkből származó felhasználókat kell tartalmazniuk (azoknak, akik elfelejtették, mi az). Tegyük fel, hogy maga a megosztás a Synology adathordozón található, a PSI-erdő FB tartományában regisztrálva. Feladat: lehetővé tenni egy másik erdőben lévő tartományok felhasználóinak, hogy hozzáférjenek ennek a megosztásnak a tartalmához, méghozzá nagyon szelektíven.

Egy idő után a műszaki specifikációk a következő formát öltötték:

• 2 erdő: PSI erdő, TG erdő.

  

• Minden erdőnek 3 tartománya van: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Az erdők között bizalmi kapcsolat van; a Synology az összes biztonsági csoportot látja az összes erdőben.
• A megosztásoknak és mappáknak/almappáknak FullControl jogosultságokkal rendelkező FB domain rendszergazdai fiókkal kell rendelkezniük
• A mappák neveit rendszerezni kell. A menedzsment koordinálta a projektazonosítókat, úgy döntöttem, hogy a biztonsági csoportok nevét összekapcsolom a projektazonosítókkal.
• A rendszermegosztásokban lévő projektmappáknak tartalmazniuk kell egy .xlsx fájlban előre elkészített struktúrát, megfelelő hozzáférési jogosultságokkal (R/RW/NA, ahol NA – nincs hozzáférés)

  

• Lehetővé kell tenni, hogy egy projekt felhasználói/csoporttagjainak jogait csak a projekt bizonyos könyvtáraira korlátozzák. Előfordulhat, hogy a felhasználó nem fér hozzá más könyvtárakhoz/projektekhez, a csoporttagságtól függően.
• Projektmappa létrehozásakor a csoportokat a lehető legautomatikusabban kell létrehozni a megfelelő tartományokban a projektazonosítóknak megfelelő névvel.

Megjegyzések a műszaki adatokhoz

• A bizalmi kapcsolatok létrehozása nem tartozik a műszaki előírások hatálya alá
• A projektazonosító számokat és latin karaktereket tartalmaz
• A projekt felhasználói szerepkörei minden tartományban szabványos névvel rendelkeznek
• A teljes projekt megkezdése előtt elkészül egy .xlsx fájl mappákkal és hozzáférési jogokkal (hozzáférési mátrix).
• A projektek megvalósítása során lehetőség nyílik felhasználói csoportok létrehozására a megfelelő tartományokban
• Az automatizálás az MS Windows szabványos adminisztrációs eszközeivel valósul meg

Műszaki előírások megvalósítása

A követelmények formalizálása után egy taktikai szünetet tartottunk a könyvtárak létrehozásának és a hozzájuk való jogok hozzárendelésének módszereinek tesztelésére. Csak a PowerShell használatát tervezték, hogy ne bonyolítsák a projektet. Ahogy korábban írtam, a script algoritmus meglehetősen egyszerűnek tűnt:

• csoportokat regisztrálunk a projektazonosítóból (például KC40587) származó névvel és a hozzáférési mátrixban megadott megfelelő szerepekkel: KC40587-EN- for engineer; KC40587-PM – termékmenedzsernek stb.
• megkapjuk a létrehozott csoportok SID-jét
• regisztrálja a projektmappát és a megfelelő könyvtárkészletet (az almappák listája attól függ, hogy milyen megosztásban van létrehozva és a hozzáférési mátrixban definiált)
• a hozzáférési mátrixnak megfelelően rendelje hozzá a jogokat a csoportokhoz a projekt új alkönyvtáraihoz.

Az 1. szakaszban tapasztalt nehézségek:

• félreértés a szkriptben a hozzáférési mátrix megadásának módszerével kapcsolatban (most egy többdimenziós tömb van megvalósítva, de a kitöltési útvonalat a .xlsx fájl/elérési mátrix tartalma alapján keresik)

  

• nem lehet hozzáférési jogosultságokat beállítani az SMB-megosztásokhoz a PoSH használatával a synology meghajtókon (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), ami miatt sok idő veszett el, és mindent az icacls hozzáférési jogosultság-szerkesztő segédprogramjával kellett szkriptekhez igazítani, amihez szükség volt egy köztes szöveg- és cmd-fájlok tárának létrehozására.

A jelenlegi módban a cmd fájlok végrehajtása manuálisan vezérelhető, attól függően, hogy a projekthez mappát kell regisztrálni.

Az is kiderült, hogy a szkriptet más erdőkben lévő csoportok regisztrálásához is le kell hajtani (a Cross-domains kifejezést használták), és az arány nem csak 1 az egyhez, hanem 1 a sokhoz is lehet.

Ez azt jelenti, hogy más tartományok közötti csoportok, beleértve a szomszédos erdőket is, mostantól hozzáférést igényelhetnek bármely tartomány erőforrásaihoz. Az egységesség elérése érdekében úgy döntöttek, hogy szimmetrikus struktúrát hoznak létre az összes erdő összes kiszolgált tartományában (fekete függőleges oválisok). Ahogy mondják, a hadseregben mindennek csúnyának, de egységesnek kell lennie:

Így a 80XXX projekt regisztrálásakor a TG tartományban a szkript a következőket hajtja végre:

1. a megfelelő szervezeti egység (piros vízszintes ovális) létrehozása ebben a tartományban és a kereszttartományokban, vagyis azon tartományokban, amelyek alkalmazottainak hozzáféréssel kell rendelkezniük ehhez az erőforráshoz.

2. az OU-k megtöltése olyan nevű csoportokkal, mint -, Ahol:

• SRC_ tartomány – több tartomány, amelynek alkalmazottai hozzáférhetnek a DST tartomány erőforrásaihoz
• DST_domain – az a tartomány, amelynek erőforrásaihoz valójában hozzáférést kell biztosítani, vagyis amiért minden elindult
• - projekt szám
• ROLES – a hozzáférési mátrixban felsorolt ​​szerepkörök nevei.

3. az összes érintett tartomány összes csoportjának SID tömbjének beolvasása és mentése későbbi adatátvitelhez egy fájlba, amely meghatározza a projekt egy adott almappájának jogait

4. forrásfájlok generálása (paraméter /restore) az icacKC segédprogram általi futtatható fájlmódban való használatra való jogosultságokkal: „icacKC "as-nasNNKCCrojects" /restore C:TempKCKC40XXKC40XX.txt

5. CMD-fájl létrehozása, amely egyesíti az összes elindított icacl-ot az összes projektmappához

Ahogy korábban írtuk, a futtatható fájl indítása manuálisan történik, és a végrehajtási eredmények kiértékelése is manuálisan történik.

Nehézségek, amelyekkel a végén szembe kellett néznünk:

• ha a projektmappa már tele van nagyszámú fájllal, akkor az icacls parancs futtatása a meglévő köteteken jelentős időt vehet igénybe, és bizonyos esetekben meghibásodáshoz vezethet (például hosszú fájlútvonalak esetén);
• a /restore paraméter mellett sorokat kellett hozzáadnunk a /reset paraméterrel arra az esetre, ha a mappák nem jöttek létre, hanem korábban létező mappákból kerültek át, a gyökér öröklődési jogai letiltva;
• A csoportok létrehozására szolgáló szkript egy részét minden erdő tetszőleges DC-jén kellett végrehajtani, a probléma az egyes fák adminisztrációs fiókjaira vonatkozik.

Általános következtetés: nagyon furcsa, hogy még nincsenek hasonló funkcionalitású közművek a piacon. Hasonló funkciók megvalósítása lehetségesnek tűnik a Sharepoint portálon.
Az is érthetetlen, hogy Sinology eszközökön nem lehet PoSH segédprogramokat használni mappajogok beállítására.

Ha szükséges, kész vagyok megosztani a szkriptet úgy, hogy létrehozok egy projektet a githubon, ha valakit érdekel.

Forrás: will.com