უფლებების ფართომასშტაბიანი მინიჭება დომენის მომხმარებლებისთვის სხვადასხვა ტყეებიდან

როგორც ჩანს, ჩემი კარმა ასეთია: სტანდარტული ამოცანების განხორციელება ყველა სახის არა ტრივიალური გზით. თუ ვინმეს აქვს პრობლემის განსხვავებული ხედვა, გთხოვთ განიხილოთ ის, რომ საკითხი დამუშავდეს.

ერთ მშვენიერ დილას გაჩნდა საინტერესო დავალება მომხმარებელთა ჯგუფებისთვის უფლებების განაწილება სხვადასხვა გაზიარებებზე, რომლებიც შეიცავს პროექტების ქვესაქაღალდეებს დოკუმენტების საქაღალდეებით. ყველაფერი კარგად იყო და დაიწერა სკრიპტი საქაღალდეებზე უფლებების მინიჭებისთვის. შემდეგ კი აღმოჩნდა, რომ ჯგუფები უნდა შეიცავდეს მომხმარებლებს სხვადასხვა დომენიდან, სხვადასხვა ტყეებიდან (მათთვის, ვინც დაავიწყდა რა არის). ვთქვათ, თავად გაზიარებული ფაილი მდებარეობს Synology დისკზე, რომელიც რეგისტრირებულია PSI ტყის FB დომენში. ამოცანაა მომხმარებლებისთვის ნებართვის მიცემა დომენები სხვა ტყეს, რათა ჰქონოდა წვდომა ამ ბურთის შიგთავსზე და ძალიან შერჩევით.

გარკვეული პერიოდის შემდეგ, ტექნიკურმა მახასიათებლებმა შემდეგი ფორმა მიიღო:

• 2 ტყე: PSI ტყე, TG ტყე.

  

• თითოეულ ტყეს აქვს 3 დომენი: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• არსებობს ნდობის ურთიერთობა ტყეებს შორის;
• აქციებს და საქაღალდეებს/ქვესაქაღალდეებს უნდა ჰქონდეთ FB დომენის ადმინისტრატორის ანგარიშები FullControl უფლებებით
• საქაღალდეების სახელები სისტემატიზებული უნდა იყოს. მენეჯმენტმა კოორდინაცია გაუწია პროექტის ID-ებს.
• პროექტის საქაღალდეები სისტემის გაზიარებებში უნდა შეიცავდეს წინასწარ მომზადებულ სტრუქტურას .xlsx ფაილში, შესაბამისი წვდომის პრივილეგიებით (R/RW/NA, სადაც NA – წვდომის გარეშე)

  

• შესაძლებელი უნდა იყოს ერთი პროექტის მომხმარებლების/ჯგუფის წევრების უფლებების შეზღუდვა ამ პროექტის მხოლოდ გარკვეული დირექტორიებით. მომხმარებელს შეიძლება არ ჰქონდეს წვდომა სხვა დირექტორიებზე/პროექტებზე, ეს დამოკიდებულია ჯგუფის წევრობაზე.
• პროექტის საქაღალდის შექმნისას ჯგუფები უნდა შეიქმნას რაც შეიძლება ავტომატურად შესაბამის დომენებში პროექტის ID-ების შესაბამისი სახელებით.

ტექნიკური მახასიათებლების შენიშვნები

• ნდობის ურთიერთობის დამყარება არ შედის ტექნიკური მახასიათებლების ფარგლებში
• პროექტის ID შეიცავს ნომრებს და ლათინურ სიმბოლოებს
• პროექტის მომხმარებლის როლებს ყველა დომენისთვის აქვს სტანდარტული სახელები
• .xlsx ფაილი საქაღალდეებით და წვდომის უფლებებით (წვდომის მატრიცა) მზადდება მთელი პროექტის დაწყებამდე.
• პროექტების განხორციელებისას შესაძლებელია მომხმარებელთა ჯგუფების შექმნა შესაბამის დომენებში
• ავტომატიზაცია მიიღწევა სტანდარტული MS ადმინისტრაციული ინსტრუმენტების გამოყენებით. Windows

ტექნიკური მახასიათებლების განხორციელება

ამ მოთხოვნების გაფორმების შემდეგ, ტაქტიკური პაუზა იქნა მიღებული დირექტორიების შექმნისა და მათზე უფლებების მინიჭების მეთოდების შესამოწმებლად. გამიზნული იყო მხოლოდ PowerShell-ის გამოყენება, რათა არ გართულდეს პროექტი. როგორც ადრე დავწერე, სკრიპტის ალგორითმი საკმაოდ მარტივი ჩანდა:

• ჩვენ ვარეგისტრირებთ ჯგუფებს პროექტის ID-დან მიღებული სახელით (მაგალითად KC40587) და დაშვების მატრიცაში მითითებულ შესაბამის როლებს: KC40587-EN- ინჟინრისთვის; KC40587-PM – პროდუქტის მენეჯერისთვის და ა.შ.
• ვიღებთ შექმნილი ჯგუფების SID-ებს
• დაარეგისტრირეთ პროექტის საქაღალდე და დირექტორიების შესაბამისი ნაკრები (ქვესაქაღალდეების სია დამოკიდებულია წილზე, რომელშიც ის იქმნება და განსაზღვრულია წვდომის მატრიცაში)
• ჯგუფებისთვის უფლებების მინიჭება პროექტის ახალ ქვედირექტორიებში წვდომის მატრიცის მიხედვით.

სირთულეები, რომლებიც გვხვდება პირველ ეტაპზე:

• სკრიპტში წვდომის მატრიცის მითითების მეთოდის არასწორად გაგება (მრავალგანზომილებიანი მასივი ახლა დანერგილია, მაგრამ მისი შევსების გზას ეძებენ .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-ში (შავი ვერტიკალური ოვალები). როგორც ამბობენ, ჯარში ყველაფერი უნდა იყოს მახინჯი, მაგრამ ერთგვაროვანი:

ამრიგად, პროექტის 80XXX დარეგისტრირებისას TG დომენში, სკრიპტი ახორციელებს:

1. ამ დომენში შესაბამისი OU (წითელი ჰორიზონტალური ოვალების) შექმნა და ჯვარედინი დომენები, ანუ ის დომენები, რომელთა თანამშრომლებსაც უნდა ჰქონდეთ წვდომა ამ რესურსზე.

2. OU შევსება ჯგუფებით ისეთი სახელებით, როგორიცაა -, სად:

• SRC_ დომენი – ჯვარედინი დომენი, რომლის თანამშრომლებს ექნებათ წვდომა DST დომენის რესურსებზე
• DST_domain – დომენი, რომლის რესურსებზე, ფაქტობრივად, უნდა იყოს უზრუნველყოფილი წვდომა, ანუ რისთვისაც ყველაფერი დაიწყო
• - პროექტის ნომერი
• ROLES – წვდომის მატრიცაში ჩამოთვლილი როლების სახელები.

3. ყველა ჩართული დომენის ყველა ჯგუფის SID-ების მასივის წაკითხვა და მისი შენახვა ფაილში მონაცემების შემდგომ გადასატანად, რომელიც განსაზღვრავს უფლებებს კონკრეტული პროექტის ქვესაქაღალდეზე

4. წყაროს ფაილების გენერირება (პარამეტრი / აღდგენა) უფლებების ნაკრებით icacKC უტილიტას მიერ შესრულებადი ფაილის რეჟიმში გამოსაყენებლად "icacKC "as-nasNNKCProjects" / აღდგენა C:TempKCKC40XXKC40XX.txt"

5. CMD ფაილის შექმნა, რომელიც აერთიანებს ყველა გაშვებულ icacl-ს პროექტის ყველა საქაღალდესთვის

როგორც ადრე დაიწერა, შესრულებადი ფაილის გაშვება ხდება ხელით და შესრულების შედეგების შეფასება ასევე ხელით.

სირთულეები, რომელთა წინაშეც საბოლოოდ მოგვიწია:

• თუ პროექტის საქაღალდე უკვე ივსება დიდი რაოდენობით ფაილებით, მაშინ არსებულ ტომებზე icacls ბრძანების გაშვებას შეიძლება მნიშვნელოვანი დრო დასჭირდეს და ზოგიერთ შემთხვევაში გამოიწვიოს წარუმატებლობა (მაგალითად, როდესაც არსებობს ფაილის გრძელი ბილიკები);
• გარდა /restore პარამეტრისა, უნდა დაგვემატებინა ხაზები /reset პარამეტრით იმ შემთხვევაში, თუ საქაღალდეები არ შექმნილა, მაგრამ გადატანილი იყო ადრე არსებული საქაღალდეებიდან, ფესვიდან მემკვიდრეობის უფლებების გამორთვა;
• ჯგუფების შექმნის სკრიპტის ნაწილი უნდა შესრულებულიყო თითოეული ტყის თვითნებურ დკ-ზე, პრობლემა ეხება თითოეული ხის ადმინისტრაციულ ანგარიშებს.

ზოგადი დასკვნა: ძალიან უცნაურია, რომ მსგავსი ფუნქციონირების კომუნალური საშუალებები ჯერ არ არის ბაზარზე. როგორც ჩანს, მსგავსი ფუნქციის განხორციელება შესაძლებელია Sharepoint პორტალზე დაყრდნობით.
ასევე გაუგებარია, რომ შეუძლებელია PoSH უტილიტების გამოყენება სინოლოგიურ მოწყობილობებზე საქაღალდის უფლებების დასაყენებლად.

სურვილის შემთხვევაში, თუ ვინმე დაინტერესდება, მზად ვარ გავუზიარო სკრიპტი github-ზე რაიმე პროექტის შექმნით.

წყარო: www.habr.com