Grootskaalse toekenning van regte aan domeingebruikers uit verskillende woude

Blykbaar is my karma dit: om standaard take op allerhande nie-onbeduidende maniere te implementeer. As iemand 'n ander visie van die probleem het, bespreek dit asseblief sodat die kwessie uitgewerk kan word.

Een goeie oggend het 'n interessante taak ontstaan ​​om regte aan groepe gebruikers te versprei vir verskillende aandele wat subgidse van projekte met dokumentvouers bevat. Alles was reg en 'n skrif is geskryf om regte aan die dopgehou toe te ken. En toe blyk dit dat die groepe gebruikers van verskillende domeine, uit verskillende woude (vir diegene wat vergeet het wat dit is). Kom ons sê die deel self is op Synology media geleë, geregistreer in die FB-domein van die PSI-woud. Taak: om gebruikers van domeine in 'n ander woud toe te laat om toegang te hê tot die inhoud van hierdie deel, en baie selektief.

Na 'n rukkie het die tegniese spesifikasies die volgende vorm aangeneem:

• 2 woude: PSI bos, TG bos.

  

• Elke woud het 3 domeine: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Daar is 'n vertrouensverhouding tussen woude; Synology sien alle sekuriteitsgroepe in alle woude.
• Aandele en dopgehou/subvouers moet FB-domeinadministrateurrekeninge met FullControl-regte hê
• Die name van die dopgehou moet gesistematiseer word. Bestuur het die projek-ID's gekoördineer; Ek het besluit om die naam van die Sekuriteitsgroepe aan die projek-ID's te koppel.
• Projekvouers in stelselaandele moet 'n struktuur bevat wat vooraf voorberei is in 'n .xlsx-lêer, met toepaslike toegangsregte (R/RW/NA, waar NA – geen toegang)

  

• Dit behoort moontlik te wees om die regte van gebruikers/groeplede van een projek te beperk tot slegs sekere dopgehou van daardie projek. Die gebruiker het dalk nie toegang tot ander gidse/projekte nie, afhangende van groeplidmaatskap.
• Wanneer 'n projekgids geskep word, moet groepe so outomaties as moontlik in die toepaslike domeine geskep word met name wat ooreenstem met projek-ID's.

Aantekeninge by die tegniese spesifikasies

• Die opstel van vertroueverhoudings is nie by die omvang van die tegniese spesifikasies ingesluit nie
• Projek-ID bevat syfers en Latynse karakters
• Projekgebruikerrolle vir alle domeine het standaardname
• 'n .xlsx-lêer met dopgehou en toegangsregte (toegangsmatriks) word voorberei voor die aanvang van die hele projek
• By die implementering van projekte is dit moontlik om gebruikersgroepe in die ooreenstemmende domeine te skep
• Outomatisering word bereik deur gebruik te maak van standaard MS Windows administrasie gereedskap

Implementering van tegniese spesifikasies

Nadat hierdie vereistes geformaliseer is, is 'n taktiese pouse geneem om metodes te toets vir die skep van gidse en die toekenning van regte daaraan. Dit was bedoel om slegs PowerShell te gebruik, om nie die projek te bemoeilik nie. Soos ek vroeër geskryf het, het die skrifalgoritme redelik eenvoudig gelyk:

• ons registreer groepe met 'n naam afgelei van die projek-ID (byvoorbeeld KC40587) en die ooreenstemmende rolle gespesifiseer in die toegangsmatriks: KC40587-EN- vir ingenieur; KC40587-PM – vir produkbestuurder, ens.
• ons kry die SID's van die geskepte groepe
• registreer die projeklêer en die ooreenstemmende stel dopgehou (die lys subgidse hang af van die aandeel waarin dit geskep en in die toegangsmatriks gedefinieer is)
• wys regte aan groepe toe vir nuwe subgidse van die projek volgens die toegangsmatriks.

Probleme wat by stadium 1 ondervind word:

• wanbegrip van die metode om die toegangsmatriks in die skrif te spesifiseer ('n multidimensionele skikking is nou geïmplementeer, maar die pad om dit te vul word gesoek gebaseer op die inhoud van die .xlsx-lêer/toegangsmatriks)

  

• onmoontlikheid om toegangsregte in SMB-aandele op sinologie-aandrywers in te stel met behulp van PoSH (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), waardeur baie tyd verlore gegaan het en alles by skrifte aangepas moes word deur die icacls-toegangsregte-redigeerhulpmiddel te gebruik, wat die skepping van 'n tussenbewaarplek van teks- en cmd-lêers vereis het.

In die huidige modus word die uitvoering van cmd-lêers met die hand beheer, afhangende van die behoefte om 'n gids vir die projek te registreer.

Dit het ook geblyk dat die skrif ook uitgevoer moet word om groepe in ander woude te registreer (die term Cross-domains is gebruik), en die verhouding kan nie net 1 tot een wees nie, maar ook 1 tot baie.

Dit beteken dat groepe van ander kruisdomeine, insluitend 'n naburige woud, nou toegang tot die hulpbronne van enige domein kan eis. Om eenvormigheid te bewerkstellig, is besluit om 'n simmetriese struktuur in die OU van alle bediende domeine van alle woude (swart vertikale ovale) te skep. Soos hulle sê, in die weermag moet alles lelik wees, maar eenvormig:

Dus, wanneer projek 80XXX in die TG-domein geregistreer word, voer die script uit:

1. skepping van die ooreenstemmende OU (rooi horisontale ovale) in hierdie domein en kruisdomeine, dit wil sê daardie domeine wie se werknemers toegang tot hierdie hulpbron moet hê.

2. vul OE met groepe met name soos -, waar:

• SRC_-domein – kruisdomein wie se werknemers toegang tot DST-domeinhulpbronne sal hê
• DST_domain – die domein tot wie se hulpbronne in werklikheid toegang verskaf moet word, dit wil sê, ter wille waarvan alles begin is
• — projeknommer
• ROLLE – name van die rolle wat in die toegangsmatriks gelys word.

3. lees die reeks SID's van alle groepe van alle betrokke domeine en stoor dit vir daaropvolgende data-oordrag na 'n lêer wat die regte op 'n spesifieke projek subgids definieer

4. generering van bronlêers (parameter /herstel) met 'n stel regte vir gebruik deur die icacKC-hulpprogram in uitvoerbare lêermodus "icacKC "as-nasNNKCProjects" /herstel C:TempKCKC40XXKC40XX.txt"

5. skep 'n CMD-lêer wat alle geloodsde icacls vir alle projekgidse kombineer

Soos vroeër geskryf, word die begin van die uitvoerbare lêer met die hand gedoen en die evaluering van die uitvoeringsresultate word ook met die hand gedoen.

Moeilikhede wat ons op die ou end moes trotseer:

• as die projeklêer reeds met 'n groot aantal lêers gevul is, kan die uitvoer van die icacls-opdrag op die bestaande volumes aansienlik tyd neem, en in sommige gevalle lei tot mislukking (byvoorbeeld wanneer daar lang lêerpaaie is);
• bykomend tot die /restore-parameter, moes ons reëls byvoeg met die /reset-parameter ingeval die vouers nie geskep is nie, maar oorgedra is vanaf voorheen bestaande vouers, met oorerwingsregte vanaf die wortel gedeaktiveer;
• Deel van die skrif vir die skep van groepe moes uitgevoer word op 'n arbitrêre GS van elke woud, die probleem gaan oor administratiewe rekeninge vir elke boom.

Algemene gevolgtrekking: dit is baie vreemd dat daar nog geen nutsprogramme met soortgelyke funksionaliteit op die mark is nie. Dit lyk moontlik om soortgelyke funksionaliteit te implementeer gebaseer op die Sharepoint-portaal.
Dit is ook onverstaanbaar dat dit nie moontlik is om PoSH-nutsprogramme te gebruik om vouerregte op sinologie-toestelle in te stel nie.

As jy wil, is ek gereed om die skrif te deel deur 'n projek op github te skep as iemand belangstel.

Bron: will.com