A felhasználói jogok széleskörű kijelölése különböző erdőkből származó domainekhez.

Úgy tűnik, hogy ilyen a karmám: a szokásos feladatokat valahogy nem szokványosan megvalósítani. Ha valakinek más véleménye van a problémáról — várom a hozzászólásokat a téma megvitatásához.

Egy szép reggelen egy érdekes feladat merült fel, hogy jogokat kell kiosztani felhasználói csoportoknak különféle megosztásokon, amelyek projektalakú almappákat és dokumentumok mappáit tartalmazzák. Minden jól ment, és egy szkriptet írtam a mappák jogainak kiosztására. Aztán kiderült, hogy a csoportoknak felhasználókat kell tartalmazniuk különböző tartományokból, különböző erdőkből (akik elfelejtették, mi ez). Tegyük fel, hogy a megosztás maga a Synology eszközön helyezkedik el, amely a FB tartományban van regisztrálva, a PSI erdőben. Feladat: lehetővé tenni a domainok másik erdő felhasználói számára a hozzáférést ennek a megosztásnak a tartalmához, nagyon szelektíven.

A műszaki specifikáció idővel a következő formát öltötte:

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

  

• Minden erdőben 3 tartomány található: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Az erdők között bizalmi kapcsolatok vannak, a Synology látja az összes Security csoportot minden erdőben.
• A megosztásoknak és mappáknak/alapmappáknak mindenképpen tartalmaznia kell a FB tartomány adminisztrátorainak fiókját FullControl jogokkal.
• A megosztások mappáinak neveit rendszerezni kell. A projektek ID-jainak összehangolásával a vezetőség foglalkozott, úgy döntöttem, hogy a Security csoportok neveit a projektek ID-jához kötöm.
• A projektek mappáinak a rendszeres megosztásokban előre elkészített struktúrát kell tartalmazniuk egy .xlsx fájlban, a megfelelő hozzáférési jogosultságokkal (R/RW/NA, ahol NA – hozzáférés hiánya)

  

• Lehetőség kell, hogy legyen a projekt egy csoportjába tartozó felhasználók/jelenlévők jogait csak a projekt adott mappáira korlátozni. Más mappákra/projektetekre a felhasználónak nem lehet hozzáférése a csoporttagsága szerint.
• A projektmappa létrehozásakor a megfelelő tartományokban a projektek ID-jához kapcsolódó csoportoknak automatikusan létre kell jönniük.

Megjegyzések a műszaki specifikációhoz

• A bizalmi kapcsolatok beállítása nem tartozik a műszaki specifikáció keretei közé.
• A projekt ID számokat és betűket tartalmaz.
• A projektek felhasználói szerepei minden tartományban tipikus elnevezésekkel rendelkeznek.
• A hozzáférési jogokkal rendelkező mappák (.xlsx fájl) elkészítése a projekt megvalósulása előtt történik.
• A projektek megvalósítása során lehetőség van felhasználói csoportok létrehozására a megfelelő tartományokban.
• Az automatizálás a MS Windows rendszergazdálkodási eszközeinek használatával valósítható meg

A követelmények megvalósítása

A követelmények formalizálása után taktikai szünetet tartottunk a könyvtárak létrehozásának módszerei és az azokhoz való jogok kijelölésének tesztelésére. Csak a PowerShell-t terveztük használni, hogy ne bonyolítsuk a projektet. Ahogy korábban írtam, a szkript algoritmus viszonylag egyszerűnek tűnt:

• regisztráljuk a csoportokat, amelyek neve a projekt ID-ból származik (például KC40587), és a hozzájuk tartozó szerepekkel, amelyeket a hozzáférési mátrixban jelöltünk: KC40587-EN - mérnök számára; KC40587-PM - termékmenedzser számára stb.
• megkapjuk a létrehozott csoportok SID-jeit
• regisztráljuk a projekt mappát és a megfelelő könyvtárkészletet (az alkönyvtárak listája a megosztástól függ, ahol létrehozzák, és a hozzáférési mátrixban van meghatározva)
• hozzárendeljük az új projekt alkönyvtárakhoz a jogokat a hozzáférési mátrix szerint.

Az első szakaszban felmerülő nehézségek:

• a hozzáférési mátrix meghatározásának módjának félreértése a szkriptben (jelenleg többdimenziós tömb valósult meg, de a .xlsx fájl/teljesítési mátrix tartalmára alapozva keresnek utat a kitöltéshez)

  

• A Synology tárolókon a SMB megosztásokhoz való hozzáférési jogok beállításának lehetetlensége PoSH eszközökkel (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell) miatt rengeteg időt veszítettünk, és alkalmazkodnunk kellett mindenhez az icacls jogosultságszerkesztő eszközzel készült szkriptekhez, ami közbenső szöveges és cmd fájlok létrehozását igényelte.

A jelenlegi módban a cmd-fájlok végrehajtását manuálisan ellenőrzik, a projekthez szükséges mappák regisztrálásának tényéhez igazodva.

Azt is meg kellett állapítanunk, hogy a szkriptet más erdőkben a csoportok regisztrálására is végre kell hajtani (a Cross-domains kifejezést használtuk), ráadásul a kapcsolatok nemcsak egy-az-egyhez, hanem egy-a-sokhoz is viszonyulhatnak.

Ez azt jelenti, hogy egy domain erőforrásaihoz való hozzáférésre most más kereszt-domainekből származó csoportok is jelentkezhetnek, beleértve a szomszédos erdőt is. Az egységesség megvalósítása érdekében a kezelt domainek összes erdőjében szimmetrikus struktúra létrehozásáról döntöttek (fekete függőleges oválisok). Ahogy mondani szokták, a hadseregben mindennek rendezetten, de egységesen kell lennie:

Így a 80XXX projekt regisztrálásakor a TG domainben a következő történik:

1. a megfelelő OU (piros vízszintes oválisok) létrehozása ebben a domainben és cross-domainokban, vagyis azokban a domainekben, ahol a munkatársaknak hozzáférésük kell legyen ehhez az erőforráshoz.

2. az OU feltöltése olyan nevű csoportokkal, mint <SRC_domain><DST_domain><ID_project>-, ahol:

• SRC_domain – cross-domain, ahol a munkatársak hozzáférnek a DST domain erőforrásaihoz
• DST_domain – a domain, amelynek erőforrásaihoz hozzáférést kell biztosítani, vagyis amiért az egész megvalósult
• <ID_project> — a projekt száma
• ROLES – a jogosultsági mátrixban felsorolt szerepkörök nevei.

3. a SID tömb olvasása az összes érintett domain összes csoportjából és annak mentése egy fájlba a projekt adott almappájára vonatkozó jogosultságok meghatározásához

4. forrásfájlok generálása (paraméter /restore) a jogosultságok készletével az icacKC segédprogram használatához az "icacKC \"as-nasNNKCProjects\" /restore C:TempKCKC40XXKC40XX.txt" végrehajtható állomány módban

5. CMD fájl létrehozása, amely magában foglalja az összes icacls parancsot a projekt összes mappájához

Ahogy korábban írtam, a végrehajtható fájl indítása manuálisan történik, és az eredmények értékelése is manuálisan történik.

A végén felmerült nehézségek:

• ha a projekt mappa már tele van sok fájllal, akkor az icacls parancs végrehajtása az aktuális mennyiségek mellett jelentős időt vehet igénybe, és bizonyos esetekben megtagadáshoz vezetett (például hosszú fájlútvonalak esetén);
• a /restore paraméter mellett hozzá kellett adni a /reset paramétert is, arra az esetre, ha a mappák nem létrejöttek, hanem már létező mappákból transferálták őket, a gyökérből származó öröklési jogokkal kikapcsolva;
• a csoportok létrehozására vonatkozó szkript egy részét véletlenszerű dc-n kellett végrehajtani minden egyes erdőben, a probléma a számviteli adminisztrátori fiókokat érinti minden fánál.

Összegzés: nagyon furcsa, hogy a piacon jelenleg nincsenek hasonló funkciókkal rendelkező segédprogramok. Lehetőség van ennek a funkciónak a megvalósítására a Sharepoint portál alapján.
Az is érthetetlen, hogy miért nem lehet PoSH segédprogramokat használni a mappára vonatkozó jogok beállításához a sinology készülékeken.

Kérés esetén kész vagyok megosztani a szkriptet, ha valaki érdeklődik iránta, létrehozva egy projektet a githubon.

Forrás: habr.com