Мащабно назначаване на права на потребители на домейни от различни гори

Изглежда, че имам такава карма: да реализирам стандартни задачи по всякакви нетривиални начини. Ако някой има различна представа за проблема — моля да се присъедини към дискусията, за да обсъдим въпроса.

В едно прекрасно утро се появи интересна задача да раздам права на групи потребители на различни споделени ресурси, съдържащи подпапки с документи. Всичко вървеше добре и беше написан скрипт за назначаване на права на папките. И после стана ясно, че групите трябва да съдържат потребители от различни домейни, от различни гори (за тези, които забравиха какво е това). Да предположим, че самата споделена папка се намира на устройство Synology, регистрирано в домейн FB, в гората PSI. Задачата: да разрешим на потребителите домейни от другата гора да имат достъп до съдържанието на тази споделена папка, при което много избирателно.

Техническото задание (ТЗ) с течение на времето се оформяше в следния вид:

• 2 гори: Гора PSI, гора TG.

  

• Във всяка гора има по 3 домейна: PSI (ZG, PSI, FB); TG (TG, HU, KC).
• Между горите съществуват доверителни отношения, Synology вижда всички Security групи във всички гори.
• На споделените ресурси и папките/подпапките задължително трябва да има акаунти на администратори от домейн FB с права FullControl.
• Имената на папките на споделените ресурси трябва да бъдат систематизирани. Съгласуването на ID на проектите беше дело на ръководството, аз взех решение имената на Security групите да бъдат свързани с ID на проектите.
• Папките на проектите в системните споделени ресурси трябва да съдържат предварително подготвена структура в .xlsx файл, със съответните привилегии за достъп (R/RW/NA, където NA – достъпът е отказан)

  

• Трябва да бъде възможно да се ограничат правата на потребителите/членовете на група за един проект само до определени каталози на този проект. До другите каталози/проекти потребителят може да няма достъп, в зависимост от членството в групите.
• При създаване на папка на проект, максимално автоматично трябва да се създават групи в съответните домейни с имена, съответстващи на ID на проектите.

Забележки към ТЗ

• Настройката на доверителни отношения не е в обхвата на ТЗ
• ID на проекта съдържа цифри и латиница
• Ролите на потребителите на проектите за всички домейни имат типови имена
• Файлът .xlsx с папките и правата на достъп (матрица на достъпа) се подготвя преди започването на реализацията на целия проект
• При изпълнение на проекти е възможно създаване на потребителски групи в съответните домейни
• Автоматизацията се постига чрез използване на стандартните средства за администриране на MS Windows

Реализация на ТЗ

След формализиране на тези изисквания беше направена такатическа пауза за тестване на методите за създаване на каталози и назначаване на права върху тях. Беше планирано да се използва само PowerShell, за да не се усложнява проектът. Както вече споменах, алгоритъмът на скрипта изглеждаше относително прост:

• регистрираме групи с имена, произлизащи от ID на проекта (например KC40587) и съответните роли, посочени в матрицата за достъп: KC40587-EN - за инженер; KC40587-PM – за продукт мениджър и т.н.
• получаваме SID-овете на създадените групи
• регистрираме папката на проекта и съответния набор от каталози (списъкът на подпапките зависи от шера, в която се създава и е определен в матрицата за достъп)
• назначаваме права на новите подкаталози на проекта на групите според матрицата за достъп.

Трудности, с които се сблъсках на 1 етап:

• неразбиране за начина на задаване на матрицата за достъп в скрипта (в момента е реализиран многомерен масив, но се търси начин за попълването му на базата на съдържанието на .xlsx файл / матрица за достъп)

  

• невъзможност за задаване на права за достъп в SMB шари на накопители synology със средствата на 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, но и 1 към много.

Това означава, че достъпът до ресурсите на определен домейн вече може да бъде претендиран от групи от други кросс-домейни, включително съседен горски масив. За реализиране на единна структура беше взето решение за създаване на симетрична структура в OU на всички обслужвани домейни на всички гори (черни вертикални овали). Както се казва, в армията всичко трябва да бъде безупречно, но единно:

Така че, при регистрация на проекта 80XXX в домейна TG, скриптът извършва:

1. създаване на съответстваща OU (червени хоризонтални овали) в този домейн и кросс-домейни, тоест в тези домейни, служителите на които трябва да имат достъп до този ресурс.

2. попълване на OU с групи с имена от вида <SRC_domain><DST_domain><ID_project>-, където:

• SRC_domain – кросс-домен, служителите на който ще имат достъп до ресурсите на DST домейна
• DST_domain – домен, до ресурсите на който всъщност трябва да бъде предоставен достъп, тоест заради което всичко е замислено
• <ID_project> — номер на проекта
• ROLES – имена на роли, изброени в матрицата на достъпа.

3. прочитане на масива SID на всички групи на всички ангажирани домейни и запазване на него за последващо предаване на данни в файл, определящ права за конкретна подпапка на проекта

4. генериране на файлове-източници (параметър /restore) с набор от права за използване на утилитата icacKC в режим на изпълняем файл «icacKC "as-nasNNKCProjects" /restore C:TempKCKC40XXKC40XX.txt»

5. създаване на CMD файл, обединяващ всички изпълнявани icacls за всички папки на проекта

Както беше написано по-рано, стартирането на изпълняемия файл се извършва ръчно и оценката на резултатите от изпълнението също се извършва ръчно.

Трудностите, с които се сблъскахме в крайна сметка:

• ако папката на проекта вече е пълна с голямо количество файлове, отработването на командата icacls на наличните обеми може да отнеме значително време, а в някои случаи доведе до отказ (например при наличие на дълги пътища на файловете);
• освен параметъра /restore, се наложи да добавя редове с параметъра /reset на случай, че папките не са създавани, а са преместени от вече съществуващи папки, с изключени права на наследство от корена;
• част от скрипта за създаване на групи трябваше да се изпълни на произволен dc на всяка гора, проблемът засяга административните учетни записи за всяко дърво.

Общото заключение е, че е много странно, че на пазара все още няма утилити с такава функционалност. Явно е възможно реализирането на подобна функционалност на базата на портала Sharepoint.
Също така остава неясен фактът, че няма възможност за използване на PoSH утилити за задаване на права за папка на устройства sinology.

При желание съм готов да споделя скрипта, създавайки някакъв проект в github, ако това интересува някого.

Източник: habr.com