Storskalig tilldelning av rättigheter till användare av domäner från olika skogar

Tycks som jag har en sådan karma: att lösa standarduppgifter på olika icke-triviala sätt. Om någon har en annan syn på problemet, är ni välkomna att delta i diskussionen för att arbeta med frågan.

En vacker morgon dök det upp en intressant uppgift att ge rättigheter till användargrupper på olika delade mappar som innehåller undermappar för projekt med dokumentmappar. Allt gick bra och jag skrev ett skript för att tilldela rättigheter till mappar. Och sedan visade det sig att grupperna måste innehålla användare från olika domäner, från olika skogar (för dem som glömt vad detta är). Anta att själva delningen ligger på en Synology-enhet registrerad i domänen FB, skogarna PSI. Uppgiften: att tillåta användare domäner från en annan skog att få tillgång till innehållet i denna delning, och detta mycket selektivt.

Kravspecifikationen förändrades över tid till följande:

• 2 skogar: Skog PSI, skog TG.

  

• I varje skog finns det 3 domäner: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Mellan skogarna finns det förtroendeförbindelser, Synology ser alla säkerhetsgrupper i alla skogar.
• På delningarna och mapparna / undermapparna måste det finnas domän-FB-admins med FullControl-rättigheter.
• Namnen på delningsmapparna måste systematiseras. Ledningen ansvarade för godkännande av projekts ID, jag beslutade att knyta namnen på säkerhetsgrupperna till ID för projekten.
• Projektmappar i systemdelningar måste innehålla en i förväg förberedd struktur i en .xlsx-fil, med motsvarande åtkomsträttigheter (R / RW / NA, där NA innebär att åtkomst saknas)

  

• Det måste finnas möjlighet att begränsa rättigheterna för användare / medlemmar av en projektgrupp endast till specifika kataloger inom det aktuella projektet. Till andra kataloger / projekt kanske användaren inte har åtkomst, enligt medlemskap i grupper.
• Vid skapande av projektmappar ska grupper i motsvarande domäner automatiskt skapas med namn som motsvarar projekts ID.

Kommentarer till kravspecifikationen

• Inställning av förtroendeförbindelser ingår inte i kravspecifikationen
• Projektets ID innehåller siffror och latinska bokstäver
• Användarroller för projekt i alla domäner har standardnamn
• En .xlsx-fil med mappar och åtkomsträttigheter (åtkomstmatris) tas fram innan genomförandet av hela projektet
• Vid genomförande av projekt kan användargrupper skapas i motsvarande domäner
• Automatisering uppnås genom att använda befintliga administrationsverktyg i MS Windows

Genomförande av kravspecifikation

Efter formaliseringen av dessa krav togs en taktisk paus för att pröva metoder för att skapa kataloger och tilldela rättigheter till dem. Det var tänkt att endast använda PowerShell för att inte komplicera projektet. Som jag nämnde tidigare, föreslogs algoritmen för skriptet vara tillräckligt enkel:

• Vi registrerar grupper med namn som härstammar från projektets ID (till exempel KC40587) och motsvarande roller, angivna i åtkomstmatrisen: KC40587-EN - för ingenjören; KC40587-PM - för produktchefen osv.
• Vi får SID:er för skapade grupper
• Vi registrerar projektmappen och motsvarande uppsättning kataloger (listan över undermappar beror på den delade enhet där den skapas och definieras i åtkomstmatrisen)
• Vi tilldelar nya underkataloger projektets rättigheter enligt åtkomstmatrisen.

Svårigheter som vi stötte på under första etappen:

• Oförståelse av hur man ställer in åtkomstmatrisen i skriptet (just nu är en flerdimensionell array implementerad, men vi söker sätt att fylla den baserat på innehållet i .xlsx-filen/åtkomstmatrisen)

  

• Omöjlighet att ställa in rättigheter i SMB-delningar på Synology-lagringsenheter med hjälp av PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on-nas-share?forum=winserverpowershell), vilket gjorde att vi förlorade mycket tid och var tvungna att anpassa allt till skript som använde verktyget icacls för att redigera rättigheter, vilket krävde skapandet av ett mellanlager för text- och cmd-filer.

I det nuvarande läget kontrolleras körningen av cmd-filer manuellt, vid behov av att registrera mappen för projektet.

Det visade sig också att skriptet måste köras, inklusive för registrering av grupper i andra skogar (vi använde termen Cross-domains), där förhållandet inte bara kan vara 1 till 1, utan också 1 till många.

Detta betyder att grupper från andra kross-domaner, inklusive grannskogen, nu kan anspråka på tillgång till resurser i en viss domän. För att uppnå enhetlighet fattades beslutet att skapa en symmetrisk struktur i OU för alla betjänade domäner i alla skogar (svarta vertikala ovaler). Som man säger, i armén måste allt vara oordnat, men enhetligt:

Vid registrering av projektet 80XXX i domänen TG utförs följande av skriptet:

1. skapande av motsvarande OU (röda horisontella ellipser) i denna domän och tvärdomäner, det vill säga de domäner vars anställda ska ha tillgång till denna resurs.

2. fyllning av OU med grupper med namn av typen <SRC_domain><DST_domain><ID_project>-, där:

• SRC_domain – tvärdomän vars anställda kommer att ha tillgång till resurserna i DST-domänen
• DST_domain – domän vars resurser, som egentligen var syftet med allt detta, ska beviljas tillgång
• <ID_project> — projektets nummer
• ROLES – namn på rollerna som anges i åtkomstmatrisen.

3. läsa in arrayen SID för alla grupper i alla involverade domäner och spara den för senare överföring av data till en fil som definierar rättigheter för en specifik undermapp av projektet

4. generera källfiler (parameter /restore) med en uppsättning rättigheter för att använda verktyget icacKC i körbart läge "icacKC \"as-nasNNKCProjects\" /restore C:TempKCKC40XXKC40XX.txt"

5. skapa en CMD-fil som sammanfogar alla körbara icacls för alla mappar i projektet

Som nämnts tidigare utförs körningen av den körbara filen manuellt och utvärderingen av körresultaten sker också manuellt.

Svårigheterna som uppstod i slutändan:

• om projektmappen redan är fylld med många filer kan köra kommandot icacls på de befintliga volymerna ta betydande tid, och i vissa fall ledde det till avvisande (till exempel vid långa filvägar);
• förutom parametern /restore behövde jag lägga till rader med parametern /reset om mapparna inte skapades, utan flyttades från redan existerande mappar, med avstängda ärvda rättigheter från roten;
• att köra en del av skriptet för att skapa grupper var tvunget att göras på en godtycklig dc i varje skog, problemet berör administrativa användarkonton för varje träd.

Sammanfattningsvis: det verkar mycket märkligt att det fortfarande inte finns några verktyg på marknaden med liknande funktionalitet. Det förefaller genomförbart att implementera sådan funktionalitet baserat på SharePoint-portalen.
Det är också oklart varför det inte finns någon möjlighet att använda PoSH-verktyg för att ställa in rättigheter på mappar på sinology-enheter.

Vid önskemål är jag redo att dela skriptet om jag skapar något projekt på github, om det skulle vara av intresse för någon.

Källa: habr.com