Миграция Dynamic Access Control claims между лесами Windows Server 2012

DISCLAIMER: статья не является официальным руководством к действию от вендора и т.д. Это попытка осмыслить возможности миграции, исходя из текущей ситуации, инструментов и опыта.

Недавно задался вопросом: как быть, если мне надо смигрировать лес Windows Server 2012 в новый лес на базе Windows Server 2012, и при этом у меня используется Claim Based Authentication, а не группы?

ADMT 3.2 - это только часть решения проблемы.

Для миграции claims нам понадобиться утилита Microsoft Data Classification Toolkit for Windows Server 2012. Она предоставляет необходимый функционал для миграции данных claims между лесами, а так же шаблонов классификации данных, их сравнения и т.д.

http://technet.microsoft.com/en-us/library/hh204743.aspx - читать тут;

http://www.microsoft.com/en-us/download/details.aspx?id=27123 - скачать тут;

Про неё написано очень мало, к сожалению. Минимально информация о утилите так же была представлена в Microsoft Virtual Academy, по-моему в курсе про Solution Accelerators.

Ставим мы данную утилиту на целевой и исходный сервера (к примеру:контроллеры домена или файловые серверы - последнее предпочтительнее) , которые работают на базе Windows Server 2012. Ставится она по-умолчанию в каталог Program Files (x86), внутри папки утилиты, нам интересна только папка TOOLS, где собстваенно содержаться скрипты импорта - экспорта claims, правил и политик.





































Порядок миграции у меня получился следующий:

1. Два леса объединяем отношениями доверия, настраиваем всё для миграции с помощью ADMT 3.2.;
2. Мигрируем пользователей и группы;
3. Миграция claims, CAR, CAP с помощью скриптов PowerShell утилиты Microsoft Data Classification Tool:

Сначала операция экспорта на исходном контроллере домена

 А затем операция импорта на целевой контроллер домена

 4. Переносим GPO с помощью Copy-GPO cmdlet или создаём заново;

 





ПРИМЕЧАНИЕ: на попытки играться с Migration Table в данном скриншоте не обращайте внимания, пытался придумать методику подставновки значений (см. ниже подробнее - в шаге № 5.2.)

5. Настройка необходимых политик:

5.1. целевого контроллера домена Default Domain Controllers Policy (ComputerPolicy->Administrative Templates->System->KDS-> KDC Support for claims, compound authentication and Kerberos Armoring) значение Supported

 

5.2. Переносим GPO, содержание настройки CAP. GPO переносилось с помощью Copy-GPO cmdlet, в левой части окна импортированные политики DAC, в правой - унаследованные при миграции GPO; Сопоставления не происходит. Migration Table не вариант, в связи с ограничениями http://technet.microsoft.com/en-us/library/cc739066(v=ws.10).aspx. Вероятно придётся писать какой либо скрипт на vbs, чтобы исправлять *.inf файлы нужного раздела GPO. 

Скриншот файла CAP.inf - после Copy-GPO содержит данные исходного домена

Исходя из архитектуры строение GPO, думаю это вполне возможно , как я понял, вопрос только в последних двух DC

 

После изменения значений DC на корректные для целевого домена всё автоматически заработало.

 

 

 

 

 

 

 

 

 

 

 





ПРИМЕЧАНИЕ! Возможно, удастся решить эту задачу с помощью Advanced Group Policy Management Tool  (AGPM) из пакета MDOP с меньшими трудозатратами.

6. Миграция файлового сервера в целевой домен;

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

Для этого, запускаем Microsoft Data Classification Toolkit и выполняем следующие действия (утилита установлена локально).

ПОДСКАЗКА! Одна политика Central Access Policy может включать несколько различных по сути правил

У кого есть идеи по улучшению процесса - пишите. Заметите неточности - пишите :)

  

 Доп. информация http://blogs.technet.com/b/askds/archive/2012/07/18/standardizing-dynamic-access-control-configuration-exporting-and-importing-dynamic-access-control-objects-between-active-directory-forests.aspx

•  

Поговорим о Dynamic Access Control

Наверное одна из наиболее понравившихся мне новинок в Windows Server 2012 - это Dynamic Access Control.

Помимо улучшений технологии сжатия PAC (Privilege Account Certificate) и увеличения размера буфера до 48 Kb в Windows Server 2012, это один из способов преодолеть проблему с переполнением маркера доступа TGT Kerberos и просто оптимизировать управление системой безопасности доступа к ресурсам в больших средах (о изменениях в Windwos Server 2012 R2 тут http://technet.microsoft.com/en-us/library/hh831747.aspx).

Размер маркера в билете Kerberos в системах предыдущего поколения составляет 12 Kb, это примерно около 1015 SID на одного пользователя.

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

Отчасти превышение размера маркера доступа вытекало из стратегий RBAC, а так же AGULP или AGLP - маркер доступа кэширует все группы, в которые входит пользователь. Пользовательские учётные записи включались в глобальные группы, затем в универсальные, а они уже  в локальные доменные, на которые уже и назначались разрешения (естественно в плоской модели леса универсальные группы не использовались).

Account - Global Security Group - Universal Security Group - Domain Local Security Group - Permissions

Account - Global Security Group - Domain Local Security Group - Permissions

  

Особенно, это было явно выраженно при назначение разрешений на сетевые ресурсы: разрешения мы предоставляли на сетевой ресурс с помощью одних групп и на NTFS с помощью других.

ИЗ ЖИЗНИ: В своей практике при построении модели безопасности, я всегда стараюсь минимизировать членство пользователя  в группах в рамках роли и не допускать более 3-х уровней вложенности групп. Так же, закладываю механизмы контроля за актуальностью выданых прав, хотя бы на уровне рекомендаций.

С другой стороны, если отходить от этих стратегий, то подчас инфраструктура назначения доступов становилась плохо управеляемой и запутанной, особенно при кросс назначениях один ко многим и это выливалось в громадные ACL на ресурсах, фантомные права у пользователей (которые уже  им не нужны), как следствие проблемы с безопасностью и т.д. - список довольно большой.

ПРИМЕЧАНИЕ! При миграции с помощью ADMT с использованием SIDHistory, если пользователь входил в исходном домене в 500 групп, то кол-во SID  в токене удвоится, что фактически спровоцирует проблему с переполнением токена; Поэтому перед миграцией необходимо избавиться от ненужного более членства в группах и фантомов.

С помощью технолгии DAC мы можем упростить сиутацию.

ПРИМЕЧАНИЕ! DAC использует CBAC Security Model - Claim Based Access Control Security Model.

Рассмотрим сценарий предоставления доступа к общему сетевому ресурсу с использованием DAC и claim based authentication.

В данном сценарии у нас есть два департамента: Finance и Information Technology и несколько пользователей, являющихся сотрудниками данных департаментов.

Каждый пользователь должнен получать доступ к своему ресурсу.

У нас есть два общих ресурса на файловом сервере на базе Windows Server 2012: одна общая папка для департамента Finance и вторая для Information Technology.

Разрешения на сетевой доступ по-умолчанию, добавлена только группа Authenticated Users с правами Read & Modify, а права NTFS аналогичны.

Пользователь Jane Dow относится к финансовому департаменту

Папка Finance содержит следующие свойства классификации:

 



За счёт того, что мы используем свойства пользователя, как claims, задействуя стандартные поля учётной записи (Department, email и т.д.) и классификацию ресурса или документа, мы, тем  самым, сокращаем количество необходимых групп для предоставления разрешеней. Вычисление прав происходит за счёт правил и политик DAC, распространяемых через групповые политики, а так же назначения политики DAC на общий ресурс.

К примеру, правило, которое я создал для департамента Finance выглядит следующим образом

ПРИМЕЧАНИЕ! Для работы данного функционала необходим Windows Server 2012 с ролью файлового сервера, Windows 8 клиент и контроллер домена на базе Windows Server 2012, DFL 2012. По данной ссылке есть информация, что DAC поддерживает 2008 R2 и Windows 7 в качестве клиентов, но я не проверял (подробнее тут http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/24/new-features-in-active-directory-domain-services-in-windows-server-2012-part-20-dynamic-access-control-dac.aspx)

Результатом работы правила, является получение доступа к ресурсу финансового департамента пользователем Dow Jane (Рис. 1) и Smith John, но отказ в доступе для пользователя Kiss Tom (Рис. 2).

Рис.1.

Рис. 2.

Особенно заманчивым данный сценарий выглядит в комбинации с AD RMS. Так же любопытны сценарии с закреплением возможности доступа с конкретного сетевого устройства и т. д.  Claims можно легко комбинировать, используя логику мастеров построения Target Resource правил и разрешений.

 

Несмотря на новшевства DAC, смешанные сценарии на основе RBAC и ACL плюс CBAC никто не отменял, на сколько мне известно ReFS до сих пор не умеет работать с политиками авторизации, да и в обычной жизни, не всегда всё просто.

Что касается хранения настроек DAC:

Сами claims и другие настройки DAC сохраняются в разделе Configuration леса со всеми вытекающими последствиями




Что касается первичного диагностирования и устранения проблем то следует обратить внимание вот на что:

1. Что является claims целевого ресурса? Какие выражения и Permissions содержаться в правиле?
2. DAC тесно связан с GPO: если не работает GPO - не работает DAC, так же необходимо проверить правильнось назначения CAR, CAP через GPO.
3. Можно посмотреть, что мешает получить доступ к ресурсу с помощью вкладки Effective Access в свойствах безопасности целевого ресурса (поле Access limited by). Тут мы можем поэксперементировать с пользователем, добавить или убрать дополнительную группу, членом, которой он является или claim пользователя

4. Мы можем посмотреть claim пользователя с помощью команды whoami /claims