Tilsynelatende er karmaen min dette: å implementere standardoppgaver på alle mulige ikke-trivielle måter. Hvis noen har en annen visjon om problemet, vennligst diskuter det slik at problemet kan løses.
En vakker morgen dukket det opp en interessant oppgave med å distribuere rettigheter til grupper av brukere for forskjellige delinger som inneholder undermapper til prosjekter med dokumentmapper. Alt var i orden og det ble skrevet et manus for å tildele rettigheter til mappene. Og så viste det seg at gruppene skulle inneholde brukere fra forskjellige domener, fra forskjellige skoger (). La oss si at selve delingen er plassert på Synology media, registrert i FB-domenet til PSI-skogen. Oppgave: å tillate brukere av domener i en annen skog å ha tilgang til innholdet i denne andelen, og veldig selektivt.
Etter en tid tok de tekniske spesifikasjonene følgende form:
- 2 skoger: PSI-skog, TG-skog.
- Hver skog har 3 domener: PSI (ZG, PSI, FB); TG (TG, HU, KC).
- Det er et tillitsforhold mellom skoger; Synology ser alle sikkerhetsgrupper i alle skoger.
- Delinger og mapper/undermapper må ha FB-domeneadministratorkontoer med FullControl-rettigheter
- Navnene på mappene bør systematiseres. Ledelsen koordinerte prosjekt-ID-ene; Jeg bestemte meg for å knytte navnet på sikkerhetsgruppene til prosjekt-ID-ene.
- Prosjektmapper i systemdelinger må inneholde en struktur forberedt på forhånd i en .xlsx-fil, med passende tilgangsrettigheter (R/RW/NA, der NA – ingen tilgang)
- Det bør være mulig å begrense rettighetene til brukere/gruppemedlemmer av ett prosjekt til kun enkelte kataloger i det prosjektet. Brukeren har kanskje ikke tilgang til andre kataloger/prosjekter, avhengig av gruppemedlemskap.
- Når du oppretter en prosjektmappe, bør grupper opprettes så automatisk som mulig i de aktuelle domenene med navn som tilsvarer prosjekt-IDer.
Merknader til de tekniske spesifikasjonene
- Oppretting av tillitsforhold er ikke inkludert i de tekniske spesifikasjonene
- Prosjekt-ID inneholder tall og latinske tegn
- Prosjektbrukerroller for alle domener har standardnavn
- En .xlsx-fil med mapper og tilgangsrettigheter (tilgangsmatrise) utarbeides før oppstart av hele prosjektet
- Ved implementering av prosjekter er det mulig å opprette brukergrupper i de tilsvarende domenene
- Automatisering oppnås ved å bruke standard MS Windows-administrasjonsverktøy
Implementering av tekniske spesifikasjoner
Etter å ha formalisert disse kravene, ble det tatt en taktisk pause for å teste metoder for å lage kataloger og tildele rettigheter til dem. Det var ment å kun bruke PowerShell, for ikke å komplisere prosjektet. Som jeg skrev tidligere, virket skriptalgoritmen ganske enkel:
- vi registrerer grupper med et navn avledet fra prosjekt-ID (for eksempel KC40587) og de tilsvarende rollene spesifisert i tilgangsmatrisen: KC40587-EN- for ingeniør; KC40587-PM – for produktsjef, etc.
- vi får SID-ene til de opprettede gruppene
- registrer prosjektmappen og det tilsvarende settet med kataloger (listen over undermapper avhenger av andelen den er opprettet i og definert i tilgangsmatrisen)
- tildele rettigheter til grupper for nye underkataloger til prosjektet i henhold til tilgangsmatrisen.
Vanskeligheter på trinn 1:
- misforståelse av metoden for å spesifisere tilgangsmatrisen i skriptet (en flerdimensjonal matrise er nå implementert, men banen til å fylle den søkes basert på innholdet i .xlsx-filen/tilgangsmatrisen)
- umulighet å angi tilgangsrettigheter i SMB-aksjer på synology-stasjoner ved å bruke PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), på grunn av dette gikk mye tid tapt og alt måtte tilpasses skript ved hjelp av redigeringsverktøyet icacls tilgangsrettigheter, som krevde opprettelsen av et mellomlager av tekst- og cmd-filer.
I gjeldende modus styres utføringen av cmd-filer manuelt, avhengig av behovet for å registrere en mappe for prosjektet.
Det viste seg også at skriptet også skulle kjøres for å registrere grupper i andre skoger (betegnelsen Cross-domains ble brukt), og forholdet kan ikke bare være 1 til en, men også 1 til mange.
Dette betyr at grupper fra andre tverrdomener, inkludert en naboskog, nå kan kreve tilgang til ressursene til et hvilket som helst domene. For å oppnå ensartethet ble det besluttet å lage en symmetrisk struktur i OU for alle betjente domener i alle skoger (svarte vertikale ovaler). Som de sier, i hæren skal alt være stygt, men uniform:
Derfor, når du registrerer prosjekt 80XXX i TG-domenet, kjører skriptet:
1. opprettelse av tilsvarende OU (røde horisontale ovaler) i dette domenet og på tvers av domener, det vil si de domenene hvis ansatte må ha tilgang til denne ressursen.
2. fylle OU med grupper med navn som -, hvor:
- SRC_ domene – kryssdomene hvis ansatte vil ha tilgang til DST-domeneressurser
- DST_domain - domenet hvis ressurser faktisk skal gis tilgang, det vil si for at alt ble startet
- — prosjektnummer
- ROLLER – navn på rollene som er oppført i tilgangsmatrisen.
3. lese utvalget av SID-er for alle grupper av alle involverte domener og lagre det for påfølgende dataoverføring til en fil som definerer rettighetene til en bestemt prosjektundermappe
4. generering av kildefiler (parameter /restore) med et sett med rettigheter for bruk av icacKC-verktøyet i kjørbar filmodus "icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt"
5. lage en CMD-fil som kombinerer alle lanserte icacls for alle prosjektmapper
Som det ble skrevet tidligere, startes den kjørbare filen manuelt og evaluering av kjøringsresultatene gjøres også manuelt.
Vanskeligheter som vi måtte møte til slutt:
- hvis prosjektmappen allerede er fylt med et stort antall filer, kan det ta lang tid å kjøre icacls-kommandoen på de eksisterende volumene, og i noen tilfeller føre til feil (for eksempel når det er lange filstier);
- i tillegg til parameteren /restore, måtte vi legge til linjer med parameteren /reset i tilfelle mappene ikke ble opprettet, men ble overført fra tidligere eksisterende mapper, med arverettigheter fra roten deaktivert;
- En del av skriptet for å lage grupper måtte kjøres på en vilkårlig dc av hver skog, problemet gjelder administrative kontoer for hvert tre.
Generell konklusjon: det er veldig merkelig at det ikke er noen verktøy med lignende funksjonalitet på markedet ennå. Det ser ut til å være mulig å implementere lignende funksjonalitet basert på Sharepoint-portalen.
Det er også uforståelig at det ikke er mulig å bruke PoSH-verktøy for å angi mapperettigheter på sinology-enheter.
Hvis ønskelig, er jeg klar til å dele skriptet ved å lage et prosjekt på github hvis noen er interessert.
Kilde: www.habr.com