Дано: 2 домена в разных лесах- source.local, target.local. Уровень работы обоих лесов 2003 native.
В целевом домене есть КД с win 2008R2. В исходном домене поднят Project Server, в целевом - SharePoint.
Необходимо: произвести миграцию пользователей из source.local в target.local. При этом должны сохраниться права доступа к ресурсам, права к записям SharePoint и ProjectServer. Так же по возможности должны быть перемещены профили (локальные) для прозрачности перехода в новый домен для пользователей. Так же должен использоваться DHCP сервер целевого домена.
Решение:
Миграция пользователей и групп будет осуществляться с помощью утилиты ADMT 3.2 - согласно рекомендациям компании Майкрасофт, в случае если в целевом домене используется КД на базе ОС win 2008 R2 следует использовать данную версию утилиты ADMT).
Из постановки задачи видно, что миграция должна осуществляться с использованием истории SID, для сохранения прав доступа.
Настройка доверительных отношений.
Прежде всего необходимо настроить доверие между доменами. Открываем оснастку "Active Directory Domains and trusts". Правой кнопкой по названию домена - свойства.
В открывшемся окошке переходим на вкладку "Trusts"
По нажатию кнопки внизу окна "New Trust" начинаем создание доверительных отношений между доменами.
В первом окошке указываем имя домена, с которым хотим наладить "дружбу".
Вносим учётную запись целевого домена, под которой будет осуществляться миграция, в группу администраторов домена источника.
Настройка DNS.
Так же необходимо настроить DNS сервера доменов. Один из вариантов - расположить вторичные зоны (secondary) перекрёстно друг к другу: зону source.local в DNS target.local, зону target.local - в DNS source.local. Мной использовался так же вариант - перекрёстных зон заглушек (stub zone).
Установка ADMT
Для начала выясним какая версия утилиты ADMT требуется, исходя из следующей таблицы:
|
Версия ADMT
|
Платформа
для
установки
|
Требования к домену-источнику (source domain)
|
Требования к целевому домену (target domain)
|
Поддерживаемые
платформы для миграции
|
|
Win Server 2003
|
Домен-источник может содержать КД под управлением Windows NT, Windows 2000 Server, или Windows Server 2003.
Нет требования к уровню работы домена.
|
Минимальный уровень целевого домена Windows 2000 native.
|
Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, и Windows Server 2003.
|
|
|
Windows Server 2008
|
Домен-источник может содержать КД под управлением Windows 2000 Server, Windows Server 2003, или Windows Server 2008. Нет требований к режиму работы домена, но ADMT v3.1 не может использоваться для миграции из Win NT4 домена.
|
Минимальный уровень работы целевого домена -Windows 2000 native.
Если целевой домен содержит КД под управлением Windows Server 2008 R2, необходимо использовать ADMT v3.2.
Для получения более полной информации ознакомьтесь с записью Базы Знаний Microsoft article 976659 .
|
Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, и Windows Server 2008.
|
|
|
Windows Server 2008 R2
|
Минимальный уровень работы домена-источника-Windows Server 2003.
|
Минимальный уровень работы целевого домена-Windows Server 2003.
|
Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, и Windows Server 2008 R2.
|
Дальнейшее описание основывается на использовании версии 3.2, т.к. в целевом домене присутствует КД (контроллер домена) под управлением ОС Windows Server 2008R2.
Более подробно установка PES будет рассмотрена далее.
Active Directory Migration Tools версии 3.2, в отличи от предшествующих версий данной утилиты, требует установленного MSSQL сервера (может использовать издание Express). Подходят MSSQL 2005 SP3 и 2008 SP1, что примечательно с версией MSSQL 2008R2 утилита работать не может. Останавливаться подробно на развёртывании SQL сервера не буду, т.к. подходят параметры по-умолчанию. Дальнейшее описание основывается на использовании Win Server 2008R2 и MSSQL 2005 Std SP3 (просто был дистриб под рукой). Установка ADMT довольно простая, лишь пара вопросов мастера установки. Единственное что может вызвать сложность - указать базу для работы: не смотря на то что в текстовой подсказке указано ".\SQLExpress" по дефолту, у меня подключилось как просто "localhost", без указания инстанса.
Устанавливать утилиту необходимо в целевой домен.
Если в исходном домене присутствуют ПК, под управлением ОС Windows XP, Vista (до SP1), 2000, а КД целевого домена под управлением ОС Windows 2008 и выше, то необходимо на каждом контроллере целевого домена исправить (создать) ключ реестра:
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters
ключ : AllowNT4Crypto
тип: REG_DWORD
значение: 1.
Включение политики аудита.
Так же необходимо настроить политику аудита в обоих доменах.
Для этого править групповую политику Default Domain Controller Policy: Computer Configuration-Polices-Windows settings-Security-Local-Audit
Устанавливаем политики "Audit account management" в Success и Failure, и "Audit directory service access" в Success.
Выключение фильтрации SID:
Выполняется в обоих доменах, во избежании возможных проблем при переносе истории SID.
Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd
Т.е. в нашем случае:
Netdom trust target.local /domain: source.local /quarantine:No /userD:administrator/passwordD:Pass
Более подробно о фильтрации SID можно посмотреть тут
Установка PES
Для миграции паролей требуется утилита Password Export Server (PES) версии 3.1 (для всех версий утилиты ADMT). Скачать можно с офф.сайта Microsoft. Устанавливать в домене-источнике (source.local), используя при установке ключ, сгенерированный на компьютере целевого домена, на котором установлена утилита ADMT.
Генерируем ключ командой admt,
admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*
Получившийся файл переносим на КД в исходном домене. При установке PES указываем путь на этот файл, и пароль, если указывали его при генерации ключа. Появляется служба с ручным режимом запуска. Рекомендуется запускать её только при миграции.
Права и ограничения
Для миграции компьютеров и локальных профилей пользователей утилите ADMT необходимы права администратора в исходном домене. Проще всего распространить групповую политику на добавление группы Domain admins целевого домена в локальную группу администраторов:
Создаём групповую политику, в редакторе переходим к пункту Computer conf.-Windown Settings- Security Settings-Restricted Groups. Клик правой кнопкой - добавить группу - вносим Administrators. В члены данной группы заносим Domain admins обоих доменов. ВНИМАНИЕ: данная политика заменит содержимое локальной группы Администраторы на указанные в политике (в рассмотренном случае - source\Domain Admins; targer\Domain Admin) плюс локальная запись Администратор. Всё остальные пользователи из неё убираются.
Так же рекомендуется для Windows XP выключить брандмауэр (firewall). Сделать это можно так же через групповую политику.
Начало миграции
Теперь можно вплотную приступить к миграции домена. Первым делом - потестировать (вообще рекомендую подобные вещи вначале тестировать в виртуальной среде). Тестирование заключается в миграции специально подготовленной группы
В исходном домене создаём локальную группу source_domain$$ (в нашем случае группа будет называться source$$). Не добавляйте в неё пользователей! Эта группа нужна для инициализации миграции, и проверки миграции SID.
Открываем консоль ADMT. В открывшейся оснастке правой кнопкой на Active Directory Migration Tools - Group Account Migration Wizard.
|
После миграции просматриваем лог на предмет ошибок и предупреждений (не ленимся). Проверяем пункт "Migrate Security Identifiers" - должен стоять yes.
В логах может встретиться предупреждение о несовпадении схем доменов, и то что некоторые атрибуты не перенесутся. Это получается из-за несовпадений схемы :) в моём случае схема одного из доменов была расширена Exchange сервером. Вообщем не критично, но лучше сразу убедиться что вызывает данное предупреждение.
Миграция служебных учётных записей
Мастер миграции служебных записей (Service Account Migration Wizard) проверяет серевера, указанные администратором, на наличие служб, работающих под доменным учётными записями. Пароли таких записей не мигрируют. Для миграции: в оснастке ADMT выбираем пункт Service Account Migration Wizard. Далее выполняем следующую последовательность действий:
|
Wizard page
|
Action
|
|
Domain Selection
|
Выбираем домены. В Source domain соотв. исходный, в target - целевой. |
|
Update Information
|
Выбираем Yes, update the information. |
|
Computer Selection Option
|
Выбираем Select computers from domain. В пункте Service Account Selection, добавляем учётные записи из исходного домена, которые хотим мигрировать. |
|
Agent Dialog
|
В открывшемся окне Agent Actions, выбираем пункт Run pre-check and agent operation, и запускаем Start. После окончания обязательно просмотреть лог миграции и Agent Detail на наличие ошибок и предупреждений. |
|
Service Account Information
|
Выбираем любые учётные записи, которые не были отмечены как служебные, и жмём Skip/Include |
|
Completing the Service Account Migration Wizard
|
Завершаем миграцию, нажатием Finish.
|
Миграция групп
Следующим этапом идёт миграция глобальных групп. (стоит сразу отметить, что встроенные группы не мигрируют). При дальнейшей миграции пользователей, членство в группах будет восстановлено автоматически.
Для миграции так же, как и в прошлых пункатх, открываем ADMT, выбираем "Group Account Migration Wizard". Далее действуем согласно таблице:
|
Wizard page
|
Action
|
|
Domain Selection
|
Выбираем домены. В Source domain соотв. исходный, в target - целевой. |
| Group Selection | Выбираем "Select groups from domain". Добавляем группы для миграции |
|
Organizational Unit Selection
|
|
|
Group Options
|
Выбираем "Migrate Group SIDs to target domain", с остальных пунктов необходимо снять галочки выбора. |
|
User Account
|
Указываем учётные данные пользователя, имеющего права администратора в исходном домене. |
|
Conflict Management
|
Выбираем пункт "Do not migrate source object if a conflict is detected in the target domain" (не мигрировать, в случае обнаружения конфликтов с объектами целевого домена). |
Для миграции пользователей с переносом истории SID необходимо предварительно мигрировать все учётные записи. При этой миграции, учётные записи переносятся отключенными, со сгенерированным паролем. Пользователи продолжают использовать учётные записи в исходном домене. В дальнейшем будет произведена повторная миграция пользователей, но уже с необходимыми атрибутами.
Открываем консоль ADMT, выбираем пункт "User Account Migration Wizard". Далее, согласно таблице:
|
Wizard page
|
Action
|
|
User Selection
|
Выбираем "Select users from domain", далее добавляем пользователей. На следующей странице выбираем подразделение, куда разместить учётные записи после миграци.
|
|
Password Options
|
Выбираем пункт "Do not update passwords for existing users" и "Generate complex passwords", для генерации пароля.
|
|
Account Transition Options
|
В "Target Account State" отмечаем "Disable target accounts", для отключения перенесенных записей в целевом домене. Включаем опцию "Migrate user SIDs to target domains"
|
|
User Options
|
Отмечаем пункты "Translate roaming profiles" и "Fix users’ group memberships", с остальных пунктов галочку снимаем.
|
|
Object Property Exclusion и Conflict Management
|
Снимаем галочку "Exclude specific object properties from migration".
|
| Conflict Management | Выбираем пункт "Do not migrate source object if a conflict is detected in the target domain." |
Перенос локальных профилей
Перед миграцией ПК, необходимо перенести локальные профили пользователей. На данном этапе целесообразно выделить группы пользователей, отражающих порядок миграции. Дальнейшие этапы мигарции проводить не над всем списком пользователей, а над этими группами.
На момент переноса профилей, и миграции ПК не должно быть активных пользовательских сессий. Для переноса (трансляции) профилей: в оснастке ADMT, выбираем пункт "Security Translation Wizard"
|
Wizard page
|
Action
|
|
Computer Selection
|
Выбираем пункт "Select from domain", и добавляем необходимые ПК, согласно группе миграции.
|
|
Translate Objects
|
Отмечаем пункт "User Profiles"
|
|
Security Translation Options
|
Отмечаем пункт "Replace"
|
|
Заканчиваем wizard
|
Заканчиваем wizard, жмём Готово. После закрытия мастера откроется окно Агента ADMT
|
|
ADMT Agent Dialog
|
Выбираем пункт "Run pre-check and agent operation" и запускаем |
| Настройки ADMT Agent | При необходимости, можно предварительно запустить проверку Precheck, если нет уверенности в доступности ПК. |
После завершения работы мастера и агента, просматриваем логи Агента на наличие ошибок.
|
Wizard page
|
Action
|
|
Computer Selection и Organization Unit
|
Выбираем пункт "Select from domain", и добавляем необходимые ПК, согласно группы миграции. (те же пк, что и в прошлом пункте). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
|
|
Translate Objects и Security Translation Options
|
Выбираем Локальные группы, и Права пользователей. В следующем пункте выбираем "Add"
|
|
Computer Options
|
В данном пункте выбираем, через какое время, после работы мастера, ПК будет перезагружен. По-умолчанию 5 минут.
|
|
Object Property Exclusion
|
В данном пункте можно выбрать, какие параметры схемы исключить из миграции.
|
|
Conflict Management
|
Выбираем пункт "Do not migrate source object if a conflict is detected in the target domain", дабы исключить перезапись объектов, если они уже существуют. |
| ADMT Agent Dialog | Выбираем пункт "Run pre-check and agent operation" и запускаем |
После завершения работы мастера и агента, проверяем их лог файлы на наличие ошибок, и корректность переноса. В ходе работы агента, компьютер будет автоматически перезагружен, и включен в целевой домен.
После миграции ПК пользователей, необходимо повторно мигрировать соответсвтующие учётные записи пользователей. На этот раз переносится пароль, и целевая учётная запись включается: После выбора домена:
|
Wizard page
|
Action
|
|
Выбор пользователей и OU для миграции
|
Выбираем пункт "Select from domain", и добавляем необходимые учётные записи, согласно группы миграции. (те же пк, что и в прошлых пунктах). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
|
|
Параметры пароля
|
Отмечаем пункт Migrate Password.
Указываем сервер PES (настраивали в прошлых пунктах)
|
|
Account Transition Options
|
На данном пункте оставляем целевую учётную запись включенной (Target Account), исходную учётную запись выключаем (Source), либо указываем через сколько дней её отключить.
Отмечаем пукнт "Migrate user SIDs to target domain", для копирования истории SID в целевой домен.
|
|
Параметры пользователя
|
Указываем учётную запись, из под которой будет осуществляться доступ в исходный домен. Переходим на следующий пункт "User options", отмечаем пункты "Translate roaming profiles" (перенос перемещаемых профилей), "Update user rights" (обновление прав пользователей), "Fix users’ group memberships" (исправить членство в группах). Убрать галочку с пункта "Migrate associated user groups".
|
|
Object Property Exclusion
|
Убрать галочку "Exclude specific object properties from migration" |
|
Conflict Management
|
Отмечаем пункт Migrate and merge conflicting objects. (мигрировать и объединить конфликтующие объекты) Убираем галочки с пунктов "Before merging remove user rights for existing target accounts" (перед объединением (слиянием) - очистить матрицу прав пользователя), и "Move merged objects to specified target Organizational Unit" (переместить объект после объединения в указанное организационное подразделение). |