Масштабное назначение прав на пользователей доменов из разных лесов

Видимо у меня карма такая: реализовывать стандартные задачи всякими нетривиальными способами. Если у кого-то окажется другое видение проблемы — прошу в обсуждение, для проработки вопроса.

Одним прекрасным утром появилась интересная задача раздать права группам пользователей на разные шары, содержащие подпапки проектов с папками документов. Все было хорошо и был написан скрипт назначающий права на папки. А затем выяснилось, что группы должны содержать пользователей разных доменов, из разных лесов (для тех кто забыл что это). Допустим, сама шара, размещается на носителе 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 ко многим.

Это означает что на доступ к ресурсам какого-либо домена теперь могут претендовать группы из других кросс-доменов, в том числе соседнего леса. Для реализации единообразия, было принято решение о создания симметричной структуры в OU всех обслуживаемых доменов всех лесов (черные вертикальные овалы). Как говориться, в армии должно быть все безобразно, но единообразно:

Таким образом, при регистрации проекта 80XXX в домене TG, скриптом выполняется:

1. создание соответствующей OU (красные горизонтальные овалы) в данном домене и cross-доменах, то есть тех доменах, сотрудники которых должны иметь доступ к данному ресурсу.

2. наполнение OU группами с названиями вида <SRC_ domain><DST_domain><ID_project>-, где:

• SRC_ domain – cross-домен, сотрудники которого будут иметь доступ к ресурсам DST домена
• DST_domain – домен, к ресурсам которого, собственно, и должен быть предоставлен доступ, то есть ради чего все и затевалось
• <ID_project> — номер проекта
• ROLES – названия ролей, перечисленных в матрице доступа.

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

4. генерация файлов-источников (параметр /restore) с набором прав для использования утилитой icacKC в режиме исполняемого файла «icacKC "\\as-nasNN\KC\Projects" /restore C:\Temp\KC\KC40XX\KC40XX.txt»

5. создание файла CMD, объединяющего в себе все запускаемые icacls для всех папок проекта

Как было написано ранее, запуск исполняемого файла производится вручную и оценка результатов исполнения – также выполняется вручную.

Трудности с которыми пришлось столкнуться в итоге:

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

Общий вывод: очень странно что на рынке пока нет утилит с подобным функционалом. Представляется возможным реализация подобного функционала на базе портала Sharepoint.
Также предоставляется непонятным факт отсутствия возможности использования PoSH утилит задания прав на папку на устройствах sinology.

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