Tydligen är min karma detta: att implementera standarduppgifter på alla möjliga icke-triviala sätt. Om någon har en annan syn på problemet, vänligen diskutera det så att problemet kan lösas.
En vacker morgon uppstod en intressant uppgift att distribuera rättigheter till grupper av användare för olika delningar som innehåller undermappar till projekt med dokumentmappar. Allt var bra och ett manus skrevs för att tilldela rättigheter till mapparna. Och så visade det sig att grupperna skulle innehålla användare från olika domäner, från olika skogar (). Låt oss säga att själva andelen finns på Synology media, registrerad i FB-domänen i PSI-skogen. Uppgift: att tillåta användare av domäner i en annan skog att få tillgång till innehållet i denna del, och mycket selektivt.
Efter en tid tog de tekniska specifikationerna följande form:
- 2 skogar: PSI skog, TG skog.
- Varje skog har 3 domäner: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Det finns ett förtroendeförhållande mellan skogar; Synology ser alla säkerhetsgrupper i alla skogar.
- Delningar och mappar/undermappar måste ha FB-domänadministratörskonton med FullControl-rättigheter
- Namnen på mapparna bör systematiseras. Ledningen koordinerade projekt-ID:n, jag bestämde mig för att länka namnet på säkerhetsgrupperna till projekt-ID:n.
- Projektmappar i systemresurser måste innehålla en struktur förberedd i förväg i en .xlsx-fil, med lämpliga åtkomstbehörigheter (R/RW/NA, där NA – ingen åtkomst)
- Det bör vara möjligt att begränsa rättigheterna för användare/gruppmedlemmar i ett projekt till endast vissa kataloger i det projektet. Användaren kanske inte har tillgång till andra kataloger/projekt, beroende på gruppmedlemskap.
- När du skapar en projektmapp bör grupper skapas så automatiskt som möjligt i lämpliga domäner med namn som motsvarar projekt-ID:n.
Anmärkningar till de tekniska specifikationerna
- Att upprätta förtroenderelationer ingår inte i de tekniska specifikationerna
- Projekt-ID innehåller siffror och latinska tecken
- Projektanvändarroller för alla domäner har standardnamn
- En .xlsx-fil med mappar och åtkomsträttigheter (åtkomstmatris) förbereds innan hela projektet startar
- Vid implementering av projekt är det möjligt att skapa användargrupper i motsvarande domäner
- Automatisering uppnås genom att använda vanliga MS Windows-administrationsverktyg
Implementering av tekniska specifikationer
Efter att ha formaliserat dessa krav togs en taktisk paus för att testa 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 skrev tidigare verkade skriptalgoritmen ganska enkel:
- vi registrerar grupper med ett namn som kommer från projekt-ID (till exempel KC40587) och motsvarande roller som anges i åtkomstmatrisen: KC40587-SV- för ingenjör; KC40587-PM – för produktchef m.m.
- vi får SID för de skapade grupperna
- registrera projektmappen och motsvarande uppsättning kataloger (listan över undermappar beror på den del där den skapas och definieras i åtkomstmatrisen)
- tilldela rättigheter till grupper för nya underkataloger till projektet enligt åtkomstmatrisen.
Svårigheter i steg 1:
- missförstånd av metoden för att specificera åtkomstmatrisen i skriptet (en flerdimensionell array är nu implementerad, men sökvägen till att fylla den söks baserat på innehållet i .xlsx-filen/åtkomstmatrisen)
- omöjlighet att ställa in åtkomsträttigheter i SMB-resurser på synology-enheter med PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), på grund av vilket mycket tid gick förlorad och allt måste anpassas till skript med hjälp av redigeringsverktyget icacls åtkomsträttigheter, vilket krävde skapandet av ett mellanlager av text- och cmd-filer.
I det aktuella läget styrs exekveringen av cmd-filer manuellt, beroende på behovet av att registrera en mapp för projektet.
Det visade sig också att skriptet också skulle köras för att registrera grupper i andra skogar (begreppet Cross-domains användes), och förhållandet kan inte bara vara 1 till en, utan också 1 till många.
Detta innebär att grupper från andra tvärdomäner, inklusive en angränsande skog, nu kan göra anspråk på tillgång till resurserna för vilken domän som helst. För att uppnå enhetlighet beslöts att skapa en symmetrisk struktur i OU för alla betjänade domäner i alla skogar (svarta vertikala ovaler). Som de säger, i armén ska allt vara fult, men enhetligt:
Således, när du registrerar projekt 80XXX i TG-domänen, körs skriptet:
1. skapandet av motsvarande OU (röda horisontella ovaler) i denna domän och tvärdomäner, det vill säga de domäner vars anställda måste ha tillgång till denna resurs.
2. fylla OU med grupper med namn som -, Var:
- SRC_-domän – över flera domäner vars anställda kommer att ha tillgång till DST-domänresurser
- DST_domain – domänen till vars resurser i själva verket bör ges åtkomst, det vill säga för vars skull allt startades
- — projektnummer
- ROLLER – namn på rollerna som listas i åtkomstmatrisen.
3. läsa uppsättningen av SID för alla grupper av alla inblandade domäner och spara den för efterföljande dataöverföring till en fil som definierar rättigheterna till en specifik projektundermapp
4. generering av källfiler (parameter /restore) med en uppsättning rättigheter för användning av icacKC-verktyget i körbart filläge "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. skapa en CMD-fil som kombinerar alla lanserade icacls för alla projektmappar
Som skrevs tidigare, startar den körbara filen manuellt och utvärderingen av körningsresultaten görs också manuellt.
Svårigheter som vi fick möta till slut:
- om projektmappen redan är fylld med ett stort antal filer kan det ta lång tid att köra icacls-kommandot på de befintliga volymerna och i vissa fall leda till misslyckanden (till exempel när det finns långa filsökvägar);
- förutom parametern /restore, var vi tvungna att lägga till rader med parametern /reset om mapparna inte skapades, utan överfördes från tidigare befintliga mappar, med arvsrättigheter från roten inaktiverade;
- En del av skriptet för att skapa grupper måste köras på en godtycklig likström för varje skog, problemet gäller administrativa konton för varje träd.
Allmän slutsats: det är väldigt konstigt att det inte finns några verktyg med liknande funktionalitet på marknaden ännu. Det verkar möjligt att implementera sådan funktionalitet baserat på Sharepoint-portalen.
Det är också obegripligt att det inte är möjligt att använda PoSH-verktyg för att ställa in mapprättigheter på sinology-enheter.
Om så önskas är jag redo att dela skriptet genom att skapa något projekt på github om någon är intresserad.
Källa: will.com