четверг, 15 августа 2013 г.

Миграция 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 может включать несколько различных по сути правил



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

Комментариев нет:

Отправить комментарий

Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.