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

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

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

ТЗ через некоторое время вырисовывалось в следующем виде:

  • 2 леса: Лес PSI, лес TG.

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

    image
  • Должна быть возможность ограничить права пользователей/членов группы одного проекта только определенными каталогами данного проекта. К другим каталогам/проектам пользователь может не иметь доступа, согласно членства в группах.
  • При заведении папки проекта максимально автоматически должны создаваться группы в соответствующих доменах с названиями соответствующими ID проектов.

Примечания к ТЗ


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

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


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

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

Трудности, с которыми пришлось столкнуться на 1 этапе:

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

    image
  • невозможность задания прав доступа в 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-файлов контролируется вручную, по факту необходимости регистрации папки для проекта.

image

Также оказалось, что выполняться скрипт должен в том числе и для регистрации групп в других лесах (использовали термин Cross-domains), причем соотношение может быть не только 1 к одному, но и 1 ко многим.

image

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

image

Таким образом, при регистрации проекта 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 для всех папок проекта

image

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

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

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

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

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

Подробнее
Реклама

Комментарии 5

    0
    Вот вроде и полезная статья, однако привкус какой то остается.
    Я не буду спрашивать почему при таком тесном взаимодействии лесов два.

    1. Синложи наверняка принадлежит какой то конкретной организации относящейся к какому то конкретному домену, почему доступ туда просто не прописан группами этого домена? Это сильно бы упростило управление.
    2. Шару синлоджи можно же опубликовать через какой нить виндосервер, и уже на нем нарезать права без лютого бреда с икаклом и цмдшниками.

    Ну и замечание про картинки — это лютый капец. Я понимаю, что и хочется показать как и гемморой лечится, и лишнюю инфу не слить. С такими картинками у Вас ни то, ни другое не получилось.
      0
      Отвечаю по пунктам:
      1. Если вы попытаетесь включить в Security Universal группу пользователей соседнего доверенного леса, то у вас это не получится.
      2. А чем вам это поможет? Все равно шара будет находиться на synology, которая не даст возможности PoSh нарезать эти права.
      Развитие идеи с группами для одного домена конкретного леса, скажем нарезав только в корневом домене, явно требует осмысления, спасибо.
      Картинки при случае постараюсь поправить, но концепт и смысл они отражают полностью: лучше делать все единообразно, чтобы потом с легкостью использовать в скриптах.
        0
        Для пользователей из леса с которым, есть доверительные отношения используется группа типа Domain local. Не слишком наглядно, но тем не менее отлично работает. Даже с тройным не транзитивным треугольным лесным доверием.

        В предложенном мной варианте с Synology публикуется не как шара, а как iSCSI хранилище. Хранилище презентуется в любой Windows Server, в нем же создается том, сразу с поддержкой дедупликации, а права на файловой системе режутся уже самой виндой. Все остальное автоматизируется без лишних костылей. Конечно это лишняя точка отказа и недоступности, но преимущества и легкость управления, по-моему, это с лихвой компенсируют.

        Ну и так, чисто о терминологии и картинках:
        По тексту не указывается, что ZG, FB, HU, KC являются поддоменами, если смотреть на картинку (если это домены второго уровня, то связь должна быть с вершины корневого домена). В то время как на одном из запортаченных скриншотов имя домена начинается на la*, а его упоминания в статье нет.

        концепт и смысл они отражают полностью
        Увы, они это делают только в Вашем сознании. Мы же, не знакомые с нюансами, видим просто труднособираемые обрывки.

        Попробуйте дать вычитать статью другу ИТшнику не знакомому с вашей инфраструктурой, и попросите что бы он объяснил что же Вы сделали и как.

        Но за труд, всеравно, спасибо.
          0
          Сергей, вам спасибо за замечания. Картинки исправлю, как обещал.
          Вариант с iSCSI хранилищем — любопытен, но в моем случае его просто некуда мапить. Отдельного сервера файлопомойки — нет (цена лицензии MS в HA кластере и т.п.).
          А вот по замечанию «права режутся самой виндой» — готов поспорить )). Cамо оно ничего не сделается. Если знаете какую-то автоматизацию разграничения прав под кросс-доменам/деревьям, прошу порекомендовать, думаю не только мне интересно будет. Группу Domain local выбрать при назначении прав — не удается, хотя в материалах указывали что это должно работать. Попробуйте сами, хоть в тестовой песочнице ))
            0
            Про «права режутся самой виндой» говорилось, что когда презентовано iSCSI хранилище, то томом полностью управляет винда. Синлоджи видит это как датастор без подробностей о внутренностях.

            Нет автоматизаций данного процесса кроме самописных если вы бедны, для совсем богатых существуют решения IdM, но даже там это нужно нужно и долго настраивать. Зато гарантированный порядок.

            Про группы мне нет необходимости тестировать, у меня три леса дружат. Все шишки давно набиты. Напомню немного матчасти:
            Глобальная — В членов можно добавить только учетки/группы из домена в котором находится группа.
            Универсальная — В членов группы можно добавить любую учетку/группу в рамках леса вне зависимости от того в каком домене создана группа.
            Локальная в домене — В членов группы можно добавить любую учетку/группу в рамках леса вне зависимости от того в каком домене создана группа, так же учетные записи/группы из других лесов. Однако эту группу нельзя добавлять членом в группы других доменов леса/лесов, в том числе и при наследовании.

            Оснастка даст Вам конвертировать группу из «Универсальная» в «Локальная в домене», только в случае соответствия всем требованиям по составу группу и наследованию. Что бы потом в нее вносить изменения нужно полностью закрыть диалог управления группой, выждать секунд 10 и только потом пытаться редактировать.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое