Миграция доменов Active Directory
Среда, 04 октября 2017 17:06

Миграция доменов Active Directory

Автор
Оцените материал
(6 голосов)

В предыдущих статьях рассказывалось о том, как установить и настроить полноценный домен Active Directory (установка домена и подключение DHCP сервера с динамическим обновлением DNS) на основе программных решений Samba 4.

Все установлено и работает. Но это хорошо, когда разворачивается новый домен. А что делать, если стоит задача перехода от уже установленного и работающего домена Microsoft Active Directory на решения, основанные на Samba? Вариантов всего два:

  1. Установить Samba DC в существующий домен Windows с последующей передачей ролей и вывода из эксплуатации контроллеров домена на Windows
  2. Установка рядом нового домена Samba DC с последующей миграцией групповых политик, пользователей и т.д. из домена Windows в новый домен.

В данной статье пойдет речь о более безопасном, но в то же время более сложном варианте: миграции в новый домен.

 Исходные данные.

Домен из которого необходимо произвести миграцию:

  1. Имя домена: SOURCE-WIN.RU
  2. Контроллер домена: DC-WIN-SOURCE.SOURCE-WIN.RU
  3. IP адрес КД: 192.168.20.2
  4. IP адрес DNS: 192.168.20.2

Домен в который необходимо произвести миграцию:

  1. Имя домена: DEST.LOC
  2. Контроллер домена: DEST-DC-03.DEST.LOC
  3. IP адрес КД: 192.168.20.103
  4. IP адрес DNS: 192.168.20.103

Разрешаем передачу зон из одного домена в другой.

В исходном домене:

 

Добавление разрешения на передачу зоны в MS DNS
Разрешение на передачу зоны

В домене назначения:

Добавляем строку разрешения передачи зон в файл /etc/named.conf раздел otions и перезапускаем сервер DNS (у нас установлен BIND9 в связке с Samba 4)

allow-transfer { 192.168.20.2; };

Перезапускаем BIND

systemctl restart named

Создание дополнительных зон для обоих доменов.

В исходном домене:

Дополнительная зона в MS DNS
Дополнительная зона домена назначения

В домене назначения:

Добавляем описание зоны в файл /etc/named.conf

zone "source-win.ru" {
                type slave;
                file "slaves/source-win.ru";
                masters {
                             192.168.20.2;
                             };
};

Перезапускаем BIND

systemctl restart named

Добавляем домен source-win.ru в список доменов поиска в файле /etc/resolv.conf

Проверяем корректность настроек:

В обоих доменах должны корректно разрешаться имена контроллеров домена (как короткие, так и полные).

Для успешной миграции из домена Windows в домен Samba в последнем нам нужно иметь "прокладку" в виде контроллера домена на Windows 2008 R2

Добавление контроллера домена Windows 2008 R2 в домен Samba DC

Процедура установки контроллера домена Windows 2008 R2 ничем не отличается от установки в стандартном окружении Windows. Есть тонкости настройки, которые мы и рассмотрим.

Т.к. DFS-R в домене Samba не работают, то свежеподнятый контроллер домена будет несколько "инвалидным" (отсутствуют сетевые шары NETLOGON и SYSVOL). Исправляем эту ситуацию.

Для синхронизации SYSVOL на контроллере домена Windows необходимо использовать утилиту ROBOCOPY.

Открываем оснастку taskschd.msc

По нажатию правой клавишей "Task Scheduler Library" выбираем "Create Task"

Вводим имя задания. Например "SysVol Replication"

Устанавливаем "Run whether user is logged on or not"

Задание репликации SYSVOL
Параметры задания репликации

На вкладке "Triggers" создаем новое расписание

Расписание репликации SYSVOL
Расписание выполнения задания

На вкладке "Actions" создаем само задание.

В поле "Action" выбираем"Start programm"

В поле "Program/script" указываем полный путь к файлу "robocopy.exe"

В поле "Add arguments (optional)" указываем параметры для старта программы: \\dest-dc-01\sysvol\dest.loc c:\windows\sysvol\domain\ /mir /sec

Репликация SYSVOL
Создание задания репликации SYSVOL

Дважды нажимаем "Ok", вводим пароль администратора домена и ждем первого срабатывания задания. После этого проверяем папку  C:\Windows|SYSVOL\domain

Важно: данная утилита является однонаправленной. Т.е. содержимое папки \\dest-dc-01\sysvol\dest.loc копируется на КД windows, но не наоборот.

Содержимое SYSVOL синхронизировалось. Но т.к. DFS-R на windows в домене Samba не работает, Windows думает, что репликация отсутствует и не показывает шары NETLOGON и SYSVOL. Для включения этих шар в реестре Windows достаточно изменить один ключ:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]

изменяем "SysVolReady" с "0" на "1" и перезагружаем сервер. После перезагрузки шары NETLOGON и SYSVOL появятся на этом сервере.

Далее необходимо на этот контроллер домена передать все роли. Передача осуществляется стандартными средствами. Чуть подробнее о трех ролях: "SchemaMaster", "DomainDnsMaster", "ForestDnsMaster"

Для передачи роли "SchemaMaster" необходимо на КД Windows зарегистрировать один файл:

regsvr32 schmmgmt.dll

После этого открыть mmc и добавить оснастку "Active Directory Schema" и в ней уже стандартным способом передать требуемую роль.

Для передачи "DomainDnsMaster" и "ForestDnsMaster" требуется оснастка ADSI Edit

Открываем оснастку и выбираем точку соединения: DC=DomainDnsZones,DC=dest,DC=loc

Для "ForestDnsMaster" соответственно: DC=ForestDnsZones,DC=dest,DC=loc

Открываем в правом окне элемент CN=Infrastructure и изменяем параметр fSMORoleOwner. Находим имя сервера текущего хозяина и меняем его на имя сервера КД windows.

 

Создание доверительных отношений между доменами.

В исходном домене необходимо открыть оснастку "Active Directory - домены и доверие".

Открыть свойства домена.

Перейти на вкладку "Отношения доверия" и нажать на "Создать отношения доверия"

Доверительные отношения между доменами
Домены и доверия

После этого запустится мастер создания доверительных отношений.

В первом окне запроса вводим имя нашего домена, куда будет производится миграция.

Домен назначения
Задаем имя домена назначения

Тип доверия выбираем "Доверие леса"

Создание ловерия между лесами

Указываем двухстороннее направление отношения доверия.

Направление междоменного доверия
Направление отношения доверия

Говорим, что отношение доверия необходимо создать в обоих доменах

Стороны отношения доверия
Задаем стороны отношения доверия

Задаем имя и пароль пользователя в удаленном домене, обладающего правами администратора домена

Пользователь и пароль для создания отношений
Указываем имя администратора удаленного домена

Остальные шаги оставляем без изменений.

В итоге получили двухсторонние доверительные отношения между доменами.

Доверительные отношения между доменами
Двухсторонние доверительные отношения между доменами.

Подготовка доменов к миграции.

Для проведения миграции из одного домена в другой нам необходимо иметь в целевом домене рабочую станцию с установленной ОС Windows, начиная с версии 7. На рабочей станции необходимо установить пакет remote Server Administrator Tools (RSAT) для соответствующей версии Windows.

С помощью оснастки "Active Directory - пользователи и компьютеры" создаем необходимую структуру OU для нашего нового домена.

Для успешной миграции объектов из исходного домена в новый домен необходим пакет ADMT версии не ниже 3.2 и утилита миграции паролей PWDMIG. Обе утилиты можно взять в свободном доступе на сайте Microsoft. Для установки ADMT необходимо установить на рабочую станцию MS SQLExpress 2008 SP1.

Этапы установки пропущу, т.к. там все достаточно просто.

Включение политики аудита.

Необходимо настроить политику аудита в обоих доменах.

Для этого лучше всего настроить новую групповую политику и привязать ее к OU Domain Controllers. В режиме редактирования политики раскрываем ветку Computer Configuration-Polices-Windows settings-Security-Local-Audit и устанавливаем политики "Audit account management" в Success и Failure, и "Audit directory service access" в Success.

Политика аудита
Политика аудита для контроллеров домена

Включение фильтрации SID:

Для исключения возможных проблем при переносе истории SID, в обоих доменах необходимо выполнить следующую команду.

В целевом домене:

netdom trust dest.loc /domain:source-win.ru /quarantine:No /userD:administrator/passwordD:Pass

В исходном домене:

netdom trust source-win.ru /domain:dest;loc /quarantine:No /userD:administrator/passwordD:Pass

Права и ограничения.

Для миграции компьютеров и локальных профилей пользователей утилите ADMT необходимы права администратора в исходном домене.

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

Административные права пользователю другого домена
Административные права пользователю другого домена

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

  1. Старый способ - "конфигурация компьютера - конфигурация Windows - Параметры безопасности - Группы с ограниченным доступом"
  2. Способ поновей. Более гибкий и продвинутый - "конфигурация компьютера - настройка - Параметры панели управления - Локальные пользователи и группы"

Установка PES.

Для миграции паролей требуется утилита Password Export Server (PES). Скачивается с официального сайта Microsoft вместе с утилитой ADMT. Устанавливать PES необходимо в домене-источнике (source-win.ru), используя при установке ключ, сгенерированный на компьютере целевого домена (dest.loc), на котором установлена утилита ADMT. Формат команды:

admt key /option:create /sourcedomain: /keyfile: /keypassword:{|*

Получившийся файл переносим на КД в исходном домене. При установке PES указываем путь на этот файл, и пароль, если указывали его при генерации ключа. Появляется служба с ручным режимом запуска. Рекомендуется запускать её только при миграции. Небольшая тонкость: установку PES необходимо производить на КД исходного домена ТОЛЬКО из командной строки, открытой от имени администратора. Иначе установщик не сможет установить сгенерированный файл. После установки заходим в оснастку "Службы", находим вновь созданную службу "Password Export Server Service". Открываем свойства этой службы. Режим запуска стоит "Вручную". Эту службу необходимо будет запустить на этапе переноса пользователей и паролей. Самое главное: на вкладке "Вход в систему" необходимо настроить запуск этой службы от имени пользователя целевого домена, который будет производить миграцию.

Делегация прав истории SID

Заходим в «AD - Пользователи и компьютеры» в домене источнике. Правый щелчок на корень доменного дерева, там «Делегирование управления». Стартует мастер делегирования. В нём на первом шаге «Далее», на втором выбираем нужного нам админа, на третьем шаге «Создать особую задачу для делегирования», на четвертом переключатель в верхнем положении «этой папки, существующим в ней объектам ...», а вот на пятом шаге нужно поставить птичку на пункте «Миграция журналов SID»

Включение «SID History on a trust»

Для включения «SID History on a trust» необходимо выполнить в обоих доменах команду:

netdom trust {FQDN.domain.name} /domain:{FQDN.domain.name} /enableSIDhistory:yes

Здесь нужно быть внимательным, чтоб не перепутать имена исходного и целевого домена в этой команде. Если команда выполняется на исходнике, то на первом месте идет исходник, на втором идёт целевой домен. На втором домене всё наоброт. Сперва указывается целевой, потом исходный.

Миграция домена.

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

В исходном домене создаём локальную группу SourceDomain$$$. Пользователей в эту группу добавлять не нужно.  Эта группа необходима для включения аудита и дальнейшей проверки благополучной миграции SID.

Открываем консоль ADMT. В открывшейся оснастке правой кнопкой на Active Directory Migration Tools - Group Account Migration Wizard.

В открывшемся мастере в окне Domain Selection выбираем источник минрации "source-win.ru" и целевой домен "dest.loc":

Миграция домена - выбор источника и назначения
Выбор домена источника и домена назначения

 На следующем окне выбираем "Select groups from domain":

Group Selection
Указываем, что надо выбирать группы из домена источника

Нажимаем "Add" и выбираем группу SourceDomain$$$

Выбор группы для миграции
Выбираем группу SourceDomain$$$

Далее назначаем OU в цедевом домене, куда следует поместить эту группу:

Выбор контейнера назначения
Назначаем контейнер для миграции группы

В следующем окне выбираем "Migrate group SIDs to target domain". С остальных пунктов выбор снимаем.

Параметры миграции
Выбор параметра "Migrate group SIDs to target domain"

 Вводим учетные данные пользователя с правами администратора домена в исходном домене:

Учетная запись администратора домена источника
Ввод учетных данных администратора домена

На следующем шаге "Object Property Exclusion" оставляем все без изменения (ничего не выбрано)

На шаге "Conflict Management" отмечаем "Do not migrate source object if a conflict is detected in the target domain"

Разрешение конфликтов
Не мигрировать объекты с обнаруженными конфликтами в целевом домене

Жмем "Далее" "Готово". Наблюдаем за результатом.

После миграции просматриваем лог на предмет ошибок и предупреждений (не ленимся). Проверяем пункт "Migrate Security Identifiers" - должен стоять yes.

В логах может встретиться предупреждение о несовпадении схем доменов, и то что некоторые атрибуты не перенесутся. Это получается из-за несовпадений схемы (например схема в исходном домене была расширена MS Exchange). Ошибка не критична, но лучше сразу выяснить, что ее вызывает.

Миграция служебных учетных записей.

Мастер миграции служебных записей (Service Account Migration Wizard) проверяет серевера, указанные администратором, на наличие служб, работающих под доменным учётными записями. Пароли таких записей не мигрируют. Для миграции: в оснастке ADMT выбираем пункт Service Account Migration Wizard. Далее выполняем следующую последовательность действий:

Выбираем исходный и целевой домен:

Миграция домена - выбор источника и назначения
Выбор домена источника и домена назначения

Выбираем обновление информации для сервисных учетных записей.

Обновление информации
Обновить информацию о сервисных учетных данных

На следующих шагах выбираем Select computers from domain. В пункте Service Account Selection, добавляем учётные записи из исходного домена, которые хотим мигрировать.

Выбор компьютеров
Выбор компьютеров в исходном домене, с которых хотим мигрировать сервисные учетные данные

В открывшемся окне Agent Actions, выбираем пункт Run pre-check and agent operation, и запускаем Start. После окончания обязательно просмотреть лог миграции и Agent Detail на наличие ошибок и предупреждений.

Миграция сервисных учетных данных

По окончании работы агента жмем "Close".

В открывшемся окне "Service Account Information" выбираем любые учётные записи, которые не были отмечены как служебные, и жмём "Skip/Include"

Завершаем миграцию нажатием "Finish"

Миграция групп.

Следующим этапом идёт миграция глобальных групп. (стоит сразу отметить, что встроенные группы не мигрируют). При дальнейшей миграции пользователей, членство в группах будет восстановлено автоматически.
Для миграции так же, как и в прошлых пункатх, открываем ADMT, выбираем "Group Account Migration Wizard".

Шаги аналогичны для миграции тестовой группы. На этапе выбора групп необходимо выбрать группы, которые мы хотим перенести.

Выбираем контейнер в целевом домене, куда мы хотим их перенести. В дальнейшем эти группы можно будет переместить в соответствии со структурой нового домена.

В окне "Group Option" оставляем только "Migrate Group SIDs to target domain". С остальных пунктов снимаем выделение.

Вводим логин и пароль доменного администратора источника.

В окне обработки конфликтов выбираем "Do not migrate source object if a conflict is detected in the target domain".

Жмем "Далее" и "Готово". Наблюдаем за состоянием миграции.

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

Миграция учетных данных пользователей

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

В консоле ADMT, выбираем пункт "User Account Migration Wizard".

Первые шаги такие же, как и для миграции групп. В окне "User Selection Option" выбираем "Select user from domain". Выбираем пользователей исходного домена и указываем контейнер, куда следует поместить учетные записи в новом домене.

В окне "Password option" выбираем "Do not update passwords for existing users" и "Generate complex passwords", для генерации пароля.

Опции пароля
Задаем параметры миграции учетных записей

В "Target Account State" отмечаем "Disable target accounts", для отключения перенесенных записей в целевом домене. Включаем опцию "Migrate user SIDs to target domains"

Параметры миграции
Задаем параметры миграции учетных записей

Вводим учетные данные администратора исходного домена.

В "User Options" отмечаем пункты "Translate roaming profiles" и "Fix users’ group memberships", с остальных пунктов выделение снимаем.

Параметры пользователя
Задаем параметры для миграции учетных записей

В окне "Object Property Exclusion" снимаем выбор (если он есть) "Exclude specific object properties from migration"

В окне обработки конфликтов выбираем "Do not migrate object if conflict is detected in the target domain"

Жмем "Далее" и "Готово". Смотрим результат и лог миграции.

Перенос локальных профилей.

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

На момент переноса профилей, и миграции ПК не должно быть активных пользовательских сессий. Для переноса (трансляции) профилей: в оснастке ADMT, выбираем пункт "Security Translation Wizard"

 На этапе "Computer Selection" выбираем пункт "Select from domain" и добавляем необходимые ПК.

В окне "Translate object" отмечаем только "User profiles"

В окне "Security Translation Option" выбираем "Replace"

В открывшемся окне Agent Dialog выбираем "Run pre-check and agent operation". Жмем "Start" и ждем пока агент установится на выбранные компьютеры и закончит работу. После этого не забываем смотреть логи на наличие ошибок и при необходимости исправляем их.

Миграция ПК

После переноса профилей, следующим этапом будет миграция ПК в новый домен. Во время миграции на ПК не должно быть активных пользовательских сессий. В процессе миграции компьютер будет перезагружен.
Открываем ADMT, выбираем пункт Computer Migration Wizard
В окне "Computer Selection и Organization Unit" выбираем пункт "Select from domain", и добавляем необходимые ПК. Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
В окнах "Translate Objects" и "Security Translation Options" устанавливаем "Local ghroups" и "User rights".
В окне "Security Translation Option" устанавливаем  "Add"
В "Computer Options" устанавливаем время, через которое компьютер уйдет в перезагрузку
В окне исключений ничего не выбираем.
В окне обработки конфликтов выбираем "Do not migrate source object if a conflict is detected in the target domain", что бы исключить перезапись объектов, если они уже существуют.
Жмем "Готово". Наблюдаем результат и смотрим логи.
В открывшемся окне "Agent Dialog" выбираем пункт "Run pre-check and agent operation" и запускаем и смотрим за результатом
После завершения работы мастера и агента, проверяем их лог файлы на наличие ошибок, и корректность переноса. В ходе работы агента, компьютер будет автоматически перезагружен, и включен в целевой домен.

Повторная миграция учетных записей пользователей.

После миграции ПК пользователей, необходимо повторно мигрировать соответсвтующие учётные записи пользователей. На этот раз переносится пароль, и целевая учётная запись включается: После выбора домена:
В окне "User Selection" выбираем пользователей, чьи ПК были перенесены на предыдущем шаге.
Затем указываем контейнер в целевом домене, куда необходимо поместить учетные записи пользователей.
В окне "Password Option" указываем "Migrate passwords", снимаем выделение с "Do not update passwords for existing users" и указываем сервер PES (настраивалось ранее).
В окне "Account Transition Options" включаем целевую учетную запись "Enable target accounts" и выключаем запись в домене источнике "Disable source accounts". Отмечаем пукнт "Migrate user SIDs to target domain", для копирования истории SID в целевой домен.
Вводим учетные данные администратора домена источника.
В окне "User options", отмечаем пункты "Translate roaming profiles" (перенос перемещаемых профилей), "Update user rights" (обновление прав пользователей), "Fix users’ group memberships" (исправить членство в группах). Убрать галочку с пункта "Migrate associated user groups".
В окне исключений ничего не выделяем.
В обработке конфликтов отмечаем пункт "Migrate and merge conflicting objects" (мигрировать и объединить конфликтующие объекты). Убираем галочки с пунктов "Before merging remove user rights for existing target accounts" (перед объединением (слиянием) - очистить матрицу прав пользователя), и "Move merged objects to specified target Organizational Unit" (переместить объект после объединения в указанное организационное подразделение).
Жмем "Готово". Смотрим за процессом. По окончании смотрим логи на наличие ошибок. Если они есть - исправляем и повторяем миграцию.
 
После миграции учетных записей пользователей в новом домене они разблокируются. На каждую учетную запись ставится свойство "Требовать смены пароля при следующем входе в систему". По желанию можно оставить или снять это свойство.
Пользователю при входе на свой компьютер остается только ввести свою учетную запись нового домена и загрузиться. Профиль успешно перенесен.

Миграция серверов

Пользователи и компьютеры успешно перенесены в новый домен. Теперь осталось перенести сервера, которые еще находятся в старом домене. Порядок и расписание миграции необходимо продумывать с особой тщательностью, дабы избежать возможных проблем с недоступностью сервисов.
Я рекомендую переносить сервера только после переноса пользователей и ПК. Но как всегда бывают исключения. Это зависит от сервисов, работающих в компании. Перенос любого сервера требует индивидуального подхода и внимания к деталям (как пример - перенос MSSQL сервера в составе других служб).
Примеры переноса различных сервисов будут рассмотрены в одной из следующих статей.

Миграция доменных политик.

 
Будем считать, что мы успешно перенесли пользователей, их компьютеры и сервера в новый домен. Проверили и поправили права доступа на сетевых ресурсов в соответствии с новым доменом. Но остается одна проблема: в старом домене активно использовались доменные политики для управления windows ПК пользователей. Эти политики так же требуют миграции в новый домен. Дополнительного инструмента для этого не требуется. Все делается через стандартную оснастку "Управление группорвыми политиками".
 
В первую очередь в домене-источнике создадим копию текущих групповых политик с помощью консоли GPMC. Для этого запустите консоль gpmc.msc, перейдите в раздел Group Policy Objects и в контекстном меню выберите пункт Backup Up All (Архивировать все...).
Создание резервной копии групповых политик
В открывшемся мастере указываем место, куда мы собираемся сохранить резервную копию и описание данного архива.
Миграция групповых политик
Нажимаем кнопку "Архивировать" и смотрим за процессом создания архива. После завершения создания архива нужно внимательно прочитать окно "Состояние" на предмет выявления ошибок. Если ошибки есть, то их следует исправитть и повторить создание архива.
В каталоге с резервной копией должны появится несколько каталогов, соответствующих содержимому доменного каталога с политиками (\\source-win.ru\SYSVOL\domain\Policies).
Архив доменных политик
Следующий шаг – импорт политик в домен назначения. Прежде, чем приступить к переносу, нужно избавиться в старых политиках о любых упоминаниях или ссылок на ресурсы исходного домена (ссылки на домен, его объекты, SID-ы и пр.), исправив их на значения нового домена. Для этого нам понадобится утилита Migration Table Editor, которая входит в состав консоли GPMC.
Копируем папку с архивом групповых политик на ПК в новом домене (на котором будем производить работы) и запускаем оснастку "Управление групповыми политиками", переходим на уровень Group Policy Objects. В контекстном меню выбераем пункт Open Migration Table Editor (Открыть редактор таблиц миграции) (утилиту можно запустить вручную, находится она тут: C:\Windows\System32\mtedit.exe).
В открывшемся окне утилиты выбираем меню Tools -> Populate from Backup (Сервис -> Заполнить из архивной копии). Указываем папку с содержимым архива групповых политик, выбираем политики, которые нужно обработать и нажимаем Ok.
Миграция доменных политик
В открывшейся табличке отобразится список всех нестандартных атрибутов групповых политик первичного домена. Наша задача – найти любые упоминания старого домена или его ресурсов: UNC пути, доменные группы и учетные записи, имена ПК и серверов, SID – ы и т.д. и заменить их данные, соответствующие новому домену.
Миграция доменных политик
После того, как вся проверка будет окончена, нужно сохранить результаты в специальный файл с расширением .migtable (файл имеет xml формат). В итоге у нас получился файл соответствуй между различными объектами и именами двух доменов.
Подготовительные операции завершены и теперь переходим непосредственно к импорту старых политик в новый домен. Для этого в консоли GPMC необходимо создать новый пустой объект групповой политики с именем, аналогичному имени политики в старом домене. По правой кнопке мыши на вновь созданной политике в меню выбераем пункт Import Settings (Импорт параметров).
В открывшемся мастере указываем путь к каталогу с резервной копией политик исходного домена и выбераем политику, настройки которой нужно импортировать.
Миграция GPO
В окне Migrating References выберите опцию Using this migration table to map them in the destination GPO, и укажите путь к ранее созданному файлу .migtable. Нажмите Next, после чего должен осуществится процесс импорта настроек старой политики в новую по правилам, указанным в файле миграции.
Таким же способом нужно перенести все оставшиеся политики. Осталось привязать перенесенные политики к нужным OU, предварительно протестировав их работу на тестовых пользователях/компьютерах.

Удаление контролера домена Windows AD из домена Samba AD

Для удаления нашего промежуточного контролера домена на Windows необходимо предпринять следующие шаги:
  1. В оснастке "Домены и доверия" удаляем доверительные отношения между старым и новым доменами.
  2. Удаляем "ведомую" (secondary) зону старого домена.
  3. В оснастке "Сайты и службы" в свойствах "NTDC Settings" удаляемого контролера домена снимаем галочку "Глобальный каталог"
  4. Передаем семь ролей на остающиеся контролеры домена. Передача ролей описывалась в этой статье выше.
  5. После того, как все роли переданы, удаляем контролер домена командой DCPROMO. Если удаление не удалось, то делаем принудительное удаление с параметром /forceremoval
  6. Если удаление контролера домена пришлось делать принудительно, то на любом контролере домена Samba AD выполняем следующую команду:
    samba-tool domain demote --remove-other-dead-server=dest-dc-03
  7. После этого во всех оснастках Active Directory проверяем наличие оставшихся следов удаляемого сервера. Если они есть, то лучше всего запустить на ПК с Windows скрипт от Microsoft:
    REM    ========================================================== 
    REM                GUI Metadata Cleanup Utility 
    REM             Written By Clay Perrine 
    REM                          Version 2.5 
    REM    ========================================================== 
    REM     This tool is furnished "AS IS". NO warranty is expressed or Implied. 
     
    on error resume next 
    dim objRoot,oDC,sPath,outval,oDCSelect,objConfiguration,objContainer,errval,ODCPath,ckdcPath,myObj,comparename 
     
    rem =======This gets the name of the computer that the script is run on ====== 
     
    Set sh = CreateObject("WScript.Shell") 
    key= "HKEY_LOCAL_MACHINE" 
    computerName = sh.RegRead(key & "\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName\ComputerName") 
     
    rem === Get the default naming context of the domain==== 
     
    set objRoot=GetObject("LDAP://RootDSE") 
    sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
     
    rem === Get the list of domain controllers==== 
     
    Set objConfiguration = GetObject(sPath) 
    For Each objContainer in objConfiguration 
        outval = outval & vbtab &  objContainer.Name & VBCRLF 
    Next 
    outval = Replace(outval, "CN=", "") 
     
    rem ==Retrieve the name of the broken DC from the user and verify it's not this DC.=== 
     
    oDCSelect= InputBox (outval," Enter the computer name to be removed","") 
    comparename = UCase(oDCSelect) 
     
    if comparename = computerName then 
        msgbox "The Domain Controller you entered is the machine that is running this script." & vbcrlf & _ 
            "You cannot clean up the metadata for the machine that is running the script!",,"Metadata Cleanup Utility Error." 
        wscript.quit 
    End If 
     
    sPath = "LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
    Set objConfiguration = GetObject(sPath) 
     
    For Each objContainer in objConfiguration 
        Err.Clear 
        ckdcPath = "LDAP://" & "CN=" & oDCSelect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
        set myObj=GetObject(ckdcPath) 
        If err.number <>0 Then 
            errval= 1 
        End If 
    Next 
     
    If errval = 1 then 
        msgbox "The Domain Controller you entered was not found in the Active Directory",,"Metadata Cleanup Utility Error." 
        wscript.quit 
    End If 
     
    abort = msgbox ("You are about to remove all metadata for the server " & oDCSelect & "! Are you sure?",4404,"WARNING!!") 
    if abort <> 6 then 
        msgbox "Metadata Cleanup Aborted.",,"Metadata Cleanup Utility Error." 
        wscript.quit 
    end if 
     
    oDCSelect = "CN=" & oDCSelect 
    ODCPath ="LDAP://" & oDCselect & ",OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
    sSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext") 
    Set objConfiguration = GetObject(sSitelist) 
    For Each objContainer in objConfiguration 
        Err.Clear 
        sitePath = "LDAP://" & oDCSelect & ",CN=Servers," &  objContainer.Name & ",CN=Sites,CN=Configuration," & _ 
            objRoot.Get("defaultNamingContext") 
        set myObj=GetObject(sitePath) 
        If err.number = 0 Then 
            siteval = sitePath 
        End If     
    Next 
     
    sFRSSysvolList = "LDAP://CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & _ 
        objRoot.Get("defaultNamingContext") 
    Set objConfiguration = GetObject(sFRSSysvolList) 
     
    For Each objContainer in objConfiguration 
        Err.Clear 
        SYSVOLPath = "LDAP://" & oDCSelect & ",CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System," & _ 
            objRoot.Get("defaultNamingContext") 
        set myObj=GetObject(SYSVOLPath) 
        If err.number = 0 Then 
            SYSVOLval = SYSVOLPath 
        End If 
    Next 
     
    SiteList = Replace(sSitelist, "LDAP://", "") 
    VarSitelist = "LDAP://CN=Sites,CN=Configuration," & objRoot.Get("defaultNamingContext") 
    Set SiteConfiguration = GetObject(VarSitelist) 
     
    For Each SiteContainer in SiteConfiguration 
        Sitevar = SiteContainer.Name 
        VarPath ="LDAP://OU=Domain Controllers," & objRoot.Get("defaultNamingContext") 
        Set DCConfiguration = GetObject(VarPath) 
        For Each DomContainer in DCConfiguration 
            DCVar = DomContainer.Name 
            strFromServer = "" 
            NTDSPATH =  DCVar & ",CN=Servers," & SiteVar & "," & SiteList 
            GuidPath = "LDAP://CN=NTDS Settings,"& NTDSPATH  
            Set objCheck = GetObject(NTDSPATH) 
            For Each CheckContainer in objCheck 
    rem ====check for valid site paths ======================= 
                ldapntdspath = "LDAP://" & NTDSPATH 
                Err.Clear 
                set exists=GetObject(ldapntdspath) 
                If err.number = 0 Then 
                    Set oGuidGet = GetObject(GuidPath) 
                    For Each objContainer in oGuidGet 
                        oGuid = objContainer.Name 
                        oGuidPath = "LDAP://" & oGuid & ",CN=NTDS Settings," & NTDSPATH   
                        Set objSitelink = GetObject(oGuidPath) 
                        objSiteLink.GetInfo 
                        strFromServer = objSiteLink.Get("fromServer") 
                        ispresent = Instr(1,strFromServer,oDCSelect,1) 
     
                        if ispresent <> 0 then 
                            Set objReplLinkVal = GetObject(oGuidPath) 
                            objReplLinkVal.DeleteObject(0) 
                        end if 
                    next 
     
                    sitedelval = "CN=" & comparename & ",CN=Servers," & SiteVar & "," & SiteList 
                    if sitedelval = ntdspath then 
                        Set objguidpath = GetObject(guidpath) 
                        objguidpath.DeleteObject(0) 
                        Set objntdspath = GetObject(ldapntdspath) 
                        objntdspath.DeleteObject(0) 
                    end if 
                End If 
            next 
        next 
    next 
    Set AccountObject = GetObject(ckdcPath) 
    temp=Accountobject.Get ("userAccountControl") 
    AccountObject.Put "userAccountControl", "4096" 
    AccountObject.SetInfo 
    Set objFRSSysvol = GetObject(SYSVOLval) 
    objFRSSysvol.DeleteObject(0) 
    Set objComputer = GetObject(ckdcPath) 
    objComputer.DeleteObject(0) 
    Set objConfig = GetObject(siteval) 
    objConfig.DeleteObject(0) 
    oDCSelect = Replace(oDCSelect, "CN=", "") 
    msgval = "Metadata Cleanup Completed for " & oDCSelect 
    msgbox  msgval,,"Notice." 
    wscript.quit
    
    Впрочем я рекомендую запустить этот скрипт в любом случае. При запуске скрипт покажет список контролеров домена, присутствующих в AD. Если удаляемого контролера домена в списке нет, то все Ок. Можно жать "Отмена". Если в списке имя удаляемого контролера домена присутствует, то набираем его и запускаем скрипт. В процессе работы этого скрипта в AD очищаются все метаданные удаляемого контролера домена.
  8. И последним шагом нужно сделать проверку и ремонт (если требуется) базы данных AD:
    samba-tool dbcheck --fix --yes
    

В итоге по программе "импортозамещения" мы имеем работающий домен Active Directory со всеми пользователями и настройками старого домена.

Дополнительная информация

Прочитано 24187 раз Последнее изменение Пятница, 03 ноября 2017 23:50
Авторизуйтесь, чтобы получить возможность оставлять комментарии
Madwavenew
Top
Этот шаблон Joomla был скачан с сайта ДжуМикс.