Իրավունքների լայնածավալ տրամադրում տարբեր անտառներից տիրույթից օգտվողներին

Ըստ երևույթին, իմ կարման սա է. ստանդարտ առաջադրանքների կատարումը բոլոր տեսակի ոչ տրիվիալ ձևերով: Եթե ​​ինչ-որ մեկը խնդրի վերաբերյալ այլ պատկերացում ունի, խնդրում եմ քննարկել այն, որպեսզի հարցը լուծվի:

Մի գեղեցիկ առավոտ հետաքրքիր խնդիր առաջացավ՝ իրավունքներ բաժանել օգտատերերի խմբերին փաստաթղթերի թղթապանակներով նախագծերի ենթաթղթապանակներ պարունակող տարբեր բաժնետոմսերի համար: Ամեն ինչ լավ էր, և գրվեց սկրիպտ՝ թղթապանակներին իրավունքներ վերագրելու համար։ Եվ հետո պարզվեց, որ խմբերը պետք է պարունակեն օգտվողներ տարբեր տիրույթներից, տարբեր անտառներից (նրանց համար, ովքեր մոռացել են, թե դա ինչ է). Ենթադրենք, բաժնետոմսն ինքնին գտնվում է Synology լրատվամիջոցում, որը գրանցված է PSI անտառի FB տիրույթում։ Առաջադրանք. թույլ տալ մեկ այլ անտառի տիրույթների օգտվողներին մուտք ունենալ դեպի այս համօգտագործման բովանդակությունը և շատ ընտրովի:

Որոշ ժամանակ անց տեխնիկական բնութագրերը ստացան հետևյալ ձևը.

• 2 անտառ՝ PSI անտառ, TG անտառ:

  

• Յուրաքանչյուր անտառ ունի 3 տիրույթ՝ PSI (ZG, PSI, FB); TG (TG, HU, KC):
• Անտառների միջև կա վստահության փոխհարաբերություն; Synology-ը տեսնում է բոլոր Անվտանգության խմբերը բոլոր անտառներում:
• Բաժնետոմսերը և պանակները/ենթաթղթապանակները պետք է ունենան FB տիրույթի ադմինիստրատորի հաշիվներ՝ FullControl իրավունքներով
• Թղթապանակների անվանումները պետք է համակարգված լինեն։ Ղեկավարությունը համակարգում էր նախագծի ID-ները, ես որոշեցի կապել Անվտանգության խմբերի անունը նախագծի ID-ների հետ:
• Ծրագրի թղթապանակները համակարգի բաժնետոմսերում պետք է պարունակեն նախապես պատրաստված կառուցվածք .xlsx ֆայլում, համապատասխան մուտքի արտոնություններով (R/RW/NA, որտեղ NA – մուտք չկա):

  

• Պետք է հնարավոր լինի սահմանափակել մեկ նախագծի օգտատերերի/խմբի անդամների իրավունքները տվյալ նախագծի միայն որոշակի դիրեկտորիաների վրա: Օգտագործողը կարող է մուտք չունենալ այլ գրացուցակներ/նախագծեր՝ կախված խմբի անդամությունից:
• Ծրագրի թղթապանակ ստեղծելիս խմբերը պետք է հնարավորինս ավտոմատ կերպով ստեղծվեն համապատասխան տիրույթներում՝ նախագծի ID-ներին համապատասխան անուններով:

Տեխնիկական բնութագրերի վերաբերյալ նշումներ

• Վստահության հարաբերությունների ստեղծումը ներառված չէ տեխնիկական բնութագրերի շրջանակում
• Ծրագրի ID-ն պարունակում է թվեր և լատիներեն նիշեր
• Ծրագրի օգտատերերի դերերը բոլոր տիրույթների համար ունեն ստանդարտ անուններ
• .xlsx ֆայլը թղթապանակներով և մուտքի իրավունքներով (մուտքի մատրիցա) պատրաստվում է մինչև ամբողջ նախագծի մեկնարկը
• Նախագծեր իրականացնելիս հնարավոր է ստեղծել օգտատերերի խմբեր համապատասխան տիրույթներում
• Ավտոմատացումը ձեռք է բերվում MS Windows-ի ստանդարտ կառավարման գործիքների միջոցով

Տեխնիկական բնութագրերի իրականացում

Այս պահանջները ֆորմալացնելուց հետո տակտիկական դադար է վերցվել դիրեկտորիաների ստեղծման և դրանց նկատմամբ իրավունքներ տրամադրելու մեթոդների փորձարկման համար: Նախատեսված էր օգտագործել միայն PowerShell-ը՝ նախագիծը չբարդացնելու համար։ Ինչպես ավելի վաղ գրել էի, սցենարի ալգորիթմը բավականին պարզ էր թվում.

• մենք գրանցում ենք խմբեր՝ նախագծի ID-ից ստացված անունով (օրինակ՝ KC40587) և մուտքի մատրիցայում նշված համապատասխան դերերով. KC40587-EN- ինժեների համար; KC40587-PM – արտադրանքի մենեջերի համար և այլն:
• ստանում ենք ստեղծված խմբերի SID-ները
• գրանցել նախագծի թղթապանակը և դիրեկտորիաների համապատասխան փաթեթը (ենթաթղթապանակների ցանկը կախված է այն բաժնետոմսից, որում այն ​​ստեղծվել և սահմանվել է մուտքի մատրիցայում)
• իրավունքներ վերագրել խմբերին նախագծի նոր ենթագրքերների համար՝ ըստ մուտքի մատրիցայի:

1-ին փուլում հանդիպող դժվարությունները.

• Սկրիպտում մուտքի մատրիցը նշելու ձևի սխալ ըմբռնում (բազմաչափ զանգվածն այժմ ներդրված է, բայց այն լրացնելու ուղին որոնվում է՝ հիմնվելով .xlsx ֆայլի/մուտքի մատրիցի բովանդակության վրա)

  

• SMB բաժնետոմսերում մուտքի իրավունքներ սահմանելու անհնարինությունը սինոլոգիական կրիչներ PoSH-ի միջոցով (https://social.technet.microsoft.com/Forums/en-US/3f1a949f-0919-46f1-9e10-89256cf07e65/error-using-setacl-on- nas -share?forum=winserverpowershell), ինչի պատճառով շատ ժամանակ կորավ, և ամեն ինչ պետք է հարմարեցվեր սկրիպտներին՝ օգտագործելով icacls մուտքի իրավունքներ խմբագրման օգտակար ծրագիրը, որը պահանջում էր տեքստի և cmd ֆայլերի միջանկյալ պահոցի ստեղծում:

Ընթացիկ ռեժիմում cmd ֆայլերի կատարումը վերահսկվում է ձեռքով, կախված նախագծի համար թղթապանակ գրանցելու անհրաժեշտությունից:

Պարզվեց նաև, որ սցենարը պետք է կատարվի նաև այլ անտառներում խմբեր գրանցելու համար (օգտագործվել է Cross-domains տերմինը), և հարաբերակցությունը կարող է լինել ոչ միայն 1-ը, այլ նաև 1-ը շատերին:

Սա նշանակում է, որ այլ խաչաձեւ տիրույթների խմբերը, ներառյալ հարևան անտառը, այժմ կարող են պահանջել մուտք գործել ցանկացած տիրույթի ռեսուրսներ: Միատեսակության հասնելու համար որոշվեց ստեղծել սիմետրիկ կառուցվածք բոլոր անտառների բոլոր սպասարկվող տիրույթների OU-ում (սև ուղղահայաց օվալներ): Ինչպես ասում են՝ բանակում ամեն ինչ պետք է տգեղ լինի, բայց միատեսակ.

Այսպիսով, TG տիրույթում 80XXX նախագիծը գրանցելիս սկրիպտը կատարում է.

1. համապատասխան OU-ի (կարմիր հորիզոնական օվալների) ստեղծում այս տիրույթում և խաչաձեւ տիրույթներում, այսինքն՝ այն տիրույթները, որոնց աշխատակիցները պետք է մուտք ունենան այս ռեսուրսը։

2. լրացնել OU խմբերով անուններով, ինչպիսիք են -, Որտեղ:

• SRC_ տիրույթ – խաչաձեւ տիրույթ, որի աշխատակիցները մուտք կունենան DST տիրույթի ռեսուրսներ
• DST_domain – այն տիրույթը, որի ռեսուրսներին, ըստ էության, պետք է հասանելի լինի, այսինքն՝ հանուն որի ամեն ինչ սկսվեց.
• - նախագծի համարը
• ROLES – մուտքի մատրիցայում թվարկված դերերի անունները:

3. կարդալ բոլոր ներգրավված տիրույթների բոլոր խմբերի SID-ների զանգվածը և պահպանել այն հետագա տվյալների փոխանցման համար ֆայլ, որը սահմանում է կոնկրետ նախագծի ենթաթղթապանակի իրավունքները:

4. սկզբնաղբյուր ֆայլերի ստեղծում (պարամետր /վերականգնում) icacKC կոմունալ ծրագրի կողմից գործարկվող ֆայլի ռեժիմում օգտագործելու իրավունքներով «icacKC «as-nasNNKCProjects» /restore C:TempKCKC40XXKC40XX.txt»

5. ստեղծելով CMD ֆայլ, որը միավորում է բոլոր գործարկված icacl-ները բոլոր նախագծի թղթապանակների համար

Ինչպես ավելի վաղ գրվել էր, գործարկվող ֆայլի գործարկումը կատարվում է ձեռքով, իսկ կատարման արդյունքների գնահատումը նույնպես կատարվում է ձեռքով:

Դժվարություններ, որոնց մենք ի վերջո ստիպված եղանք դիմակայել.

• եթե նախագծի թղթապանակն արդեն լցված է մեծ թվով ֆայլերով, ապա գոյություն ունեցող ծավալների վրա icacls հրամանի գործարկումը կարող է զգալի ժամանակ խլել և որոշ դեպքերում հանգեցնել ձախողման (օրինակ, երբ կան երկար ֆայլերի ուղիներ);
• բացի /restore պարամետրից, մենք պետք է տողեր ավելացնեինք /reset պարամետրով, եթե թղթապանակները չեն ստեղծվել, այլ փոխանցվել են նախկինում գոյություն ունեցող թղթապանակներից, արմատից ժառանգական իրավունքներն անջատված են.
• Խմբերի ստեղծման սցենարի մի մասը պետք է կատարվեր յուրաքանչյուր անտառի կամայական dc-ի վրա, խնդիրը վերաբերում է յուրաքանչյուր ծառի վարչական հաշիվներին:

Ընդհանուր եզրակացություն. շատ տարօրինակ է, որ նման ֆունկցիոնալությամբ կոմունալ ծառայություններ դեռևս չկան շուկայում։ Թվում է, թե հնարավոր է իրականացնել նմանատիպ գործառույթ՝ հիմնվելով Sharepoint պորտալի վրա:
Անհասկանալի է նաև, որ հնարավոր չէ օգտագործել PoSH կոմունալ ծառայությունները սինոլոգիական սարքերի վրա թղթապանակների իրավունքները սահմանելու համար:

Ցանկության դեպքում ես պատրաստ եմ կիսվել սցենարով` ստեղծելով ինչ-որ նախագիծ github-ում, եթե որևէ մեկը հետաքրքրված է:

Source: www.habr.com