Active directory migration tool windows server 2019

Данная пошаговая наглядная статья описывает миграцию пользователей и их паролей, а так же компьютеров между доменами с помощью инструмента Active Directory Migration Tool. Для выполнения миграции через ADMT необходимо выполнить следующие условия:
— доверительные отношения между доменами
— отключение фильтрации SID, если пользователю необходим доступ к ресурсам без изменений
— учётная запись, под который выполняется миграция, должна быть членом группы Administrators в исходном домене
— учётная запись, под который выполняется миграция, должна быть членом локальной группы Administrators в каждом компьютере
— для установки ADMT v3.2 необходимо установить MS SQL Express
— для миграции паролей на контроллере исходного домена устанавливается утилита PES
— во время миграции компьютера на нём не должно быть активных сессий

Тестовый стенд реализован на следующем железе. Все образы дисков хранятся на Storage Spaces из 4 HDD:

Тестовая сеть.
Исходный домен:
DC01.OLD.EXONIX.RU — 192.168.0.10
CLI01 — 192.168.0.11
Домен назначения:
DC03.NEW.EXONIX.MOSCOW — 172.30.130.10
ADMT. NEW.EXONIX.MOSCOW — 172.30.130.11
DC02.MAIN .EXONIX.MOSCOW — 10.10.11.10 — используется только как родительский домен в лесу.
Маршрутизация сетей
ROUTER — все сети

Новый домен с имеющемся лесу создаётся при выборе следующей опции:

Результат настройки доверий между лесами должен выглядеть следующим образом:

Для работы ADMT 3.2 необходимо установить бесплатный SQL Express. В моей статье я буду использовать MS SQL 2012 Express, который устанавливается почти с настройками по умолчанию.

Проверка членства администратора целевого домена в группе Administrators исходного домена:

Отключение фильтрации SID в доменах, а так же создание ключа для установки PES.

Установка PES на контроллере исходного домена запускается из командной строки, запущенной с правами Администратора, в противном случае пароль для ключа не будет приниматься.

После установки PES необходимо перезагрузить сервер и в службах вручную включить службу PES.

В исходном домене создаются соответвующая NetBios имени группа с областью действия «Доменно локальная» как показано ниже:

Приступаем к тестовой миграции группы old$$$. Для миграции SID необходимо включить Audit Account Management в обоих доменах. Это можно сделать вручную через локальные политики контроллера домена, который будет указываться во время миграции (или групповые для OU Domain Controllers если таковых несколько, и будет указываться автовыбор контроллера домена) или ADMT это сделает сам как будет показано ниже:

Записываем имена доменов и выбираем контроллеры доменов. Выбор контроллера для исходного домена обязателен, если в домене их больше одного, а PES установлен только на одном из них.

Выбираем ранее созданную группу и указываем путь в AD куда мигрировать.

ADMT предлагает включить Аудит на указанных контроллерах домена в каждом домене:

Выбираем опции при разрешении конфликтов:

После миграции смотрим логи на предмет миграции SID.

Так же SID можно увидеть в аттрибуте sIDHistory. В Событиях можно посмотреть сообщение 4765:

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

Во время миграции пользователя можно задать миграцию и всех групп, в которые он входит. В моём случае, пользователь входит в одну группу:

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

При повторной миграции пользователя скопируется его пароль, а так же будет установлен аттрибут — смена пароля при первом входе.

Приступаем к миграции компьютера, выбрав соответствующее действие и опции. Рекомендую перед переносом реального пользовательского компьютера протестировать миграцию его клона в тестовой среде, и проверить работоспособность пользовательских приложений, которые используют сертификаты. Например, клиент-банки.

Миграция компьютера в другой домен завершена. Пользователь может залогинится на своём компьютере в новом домене.
Для того, чтобы отключить Аудит, включённый ADMT, необходимо открыть оснастку локальных политик контроллера домена:

Во время переноса может возникнуть ошибка подключения к компьютеру. Это связанно с фаерволом, в котором необходимо включить все правила File Sharing:

Если возникнет ошибка: ERR2:7674 Unable to determine the local path for ADMIN share on the machine ‘CLI01’. rc=-2147024891 — это означает, что нет административных прав на данный компьютер для учётной записи, которая выполняет миграцию. Решается добавлением этой учётной записи в локальную группу Администраторы с помощью групповых политик Restricted Groups.

Сведения о поддержке ADMT и PES

В этой статье описываются сведения о средстве миграции Active Directory версии 3.2 (ADMT версии 3.2) и сервере экспорта паролей версии 3.1 (PES версии 3.1).

Исходная версия продукта: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4089459

Аннотация

В этой статье данная статья содержит бесплатные средства миграции Active Directory и документацию. Это средства ADMT v3.2 и PES 3.1. В этой статье также описываются известные проблемы и ограничения, связанные с этим инструментарием.

Руководство по ADMT

В следующем руководстве содержится руководство по переносу доменов с помощью средства миграции Active Directory:

• ADMT не обновлен для переноса Windows 8.1 и 10 рабочих станций.
• Windows Server 2012, Windows Server 2012 R2 и более поздние версии Windows Server не проверялись на современные приложения и миграции профилей. Ваш опыт может отличаться в зависимости от многих факторов, включая переносимую версию Windows. Используйте набор инструментов на свой риск.
• Альтернатива набору средств ADMT также доступна в службах Microsoft Services:Active Directory Migration Services(ADMS). Это средство работает в облаке Azure. Сведения о начальном уровне см. в подстановок «Попробовать Premier: консолидация каталогов с Windows Azure службами миграции Active Directory и службой миграции Microsoft Azure Active Directory».

Известные проблемы и ограничения

Установка PES в Windows Server 2012 и более поздних версиях

В старых руководствах ADMT не упоминается необходимость запуска файла pedmig.msi командной pedmig.msi с повышенными уровнями. Это требование упоминается в последнем руководстве ADMT. Последнее руководство датировано 26 февраля 2018 г. и доступно в Центре загрузки Майкрософт.

Компьютер с ADMT не должен использовать Credential Guard

На рабочей станции, управляющей миграцией, миграция не делается сама по себе. Перемещение объекта выполняется на целевом контроллере домена (DC). Он делегирует пользователя, запускающего задачу миграции при миграции пользователя из домена источника.

По умолчанию контроллеры домена настроены для бесконтактного делегирования, которое больше не разрешено Credential Guard.

Если ADMT установлен на рядовом сервере под управлением Windows Server 2016 или более поздней версии, необходимо отключить Credential Guard для запуска миграции. Также можно переместить установку ADMT в целевой домен DC, где не требуется делегировать. Кроме того, Credential Guard не поддерживается на целевых DCS.

DC не может использовать неоконченные делегирования

Из-за имеющихся векторов атаки Корпорация Майкрософт ограничивает и блокирует использование неограниченного делегирования. Это также влияет на компьютеры. ADMT занося в журнал следующую ошибку:

Ошибка журнала ADMT: не удалось переместить исходный объект. Убедитесь, что учетная запись вызываемого пользователя не помечена как конфиденциальную и поэтому не может быть делегирована. hr=0x8009030e в пакете безопасности нет учетных данных

Изменение поведения для Windows Server 2008 R2 содержится в 12 марта 2019 г. — KB4489885 (обновление толькодля системы безопасности).

Microsoft PFE обсуждает эту проблему в теме «Избавиться от учетных записей, которые используют неподдержимое делегированное делегирования Kerberos». В другом блоге описывается план выпуска.

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

В Windows Server 2008 R2 или более ранней версии Windows Server можно переместить установку ADMT только в целевой домен DC. После этого у вас нет необходимости делегировать.

Для подключения к SQL Server на компьютере ADMT должен быть включен TLS 1.0 SQL Server

Если TLS 1.0 отключен, на компьютере ADMT вы получите сообщение, похожее на следующее:

Не удается проверить неудались действия. : DBManager.ImanaDB.1 : [DBNETLIB][ConnectionOpen (SECCreateCredentials())] Ошибка безопасности SSL.

Кроме того, если TLS 1.0 отключен, средство администрирования не загружает оснастку при ее открывании. Вы получаете сообщение, похожее на следующее:

Пользователи, работающие под управлением ADMT, не должны быть членами размежести проверки подлинности

Учетная запись пользователя, используемая для переноса SidHistory, не должна быть в области проверки подлинности. При переносе SidHistory между лесами целевой dc создает сетевой сеанс на исходный dc и аутентификацию с помощью NTLM. Для учетных записей администраторов, которые находятся в области проверки подлинности, в некоторых ОС NTLM не разрешен для этих учетных записей пользователей по умолчанию или отключен пользователями.

Домены в потоке проверки подлинности задач ADMT не должны ограничивать NTLM

По той же причине, что и для предотвращения разграничения проверки подлинности, домены, используемые для миграции ADMT SidHistory, не должны ограничивать использование NTLMодной из политик.

SQL Server версий

Проверка версий для SQL Server с ADMT не проводится. Последние тесты были проведенны в 2013 г. Поэтому компьютеры, работающие под управлением SQL Server 2014 и более поздних версий, не протестировали. Выполните собственное тестирование ADMT в тестовой среде перед использованием средства для переноса в производственную среду.

Групповые управляемые учетные записи служб

27 февраля 2018 г. в руководстве ADMT описывается, как обрабатывать управляемые учетные записи служб, реализованные в Windows Server 2008 R2. Тестирование групповых управляемых учетных записей служб (GMSA) не было. Учитывая особую обработку этих учетных записей в нескольких местах, следует следовать следующим рекомендациям:

• Не пытайтесь перенести GMSA через границы леса.
• При попытке переместить GMSA в лес следует соблюдать осторожность.

Клиентские операционные системы

Несмотря на то что последний инструментарий был выпущен после выхода Windows 8.0, тестирование переноса учетных записей компьютера Windows 8.xand 10.x и, в частности, не было тестирования для полной миграции профилей пользователей.

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

Повторная миграция для обновления паролей

Некоторые клиенты запускают повторную миграцию учетных записей для переноса нового пароля из учетной записи источника в новую учетную запись в другом лесу. ADMT не предназначен для этого подхода. Он отслеживает каждое задание миграции в своей базе данных. Со временем размер базы данных ADMT увеличивается. В конечном итоге может возникнуть следующее:

База данных превышает лицензированный размер базы данных (для SQL express Deployments).

База данных превышает доступное место на диске на компьютерах, на которых SQL Server.

Задания миграции замедляются. Это происходит потому, что средство сканирует историю миграции при запуске нового задания.

Если вы собираетесь использовать ADMT таким образом в течение нескольких недель или месяцев и у вас есть расписание частой синхронизации, мы рекомендуем решение на основе решения синхронизации, например Microsoft Identity Manager.