Миграция Active Directory, подготовка инфраструктур

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

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

Два леса Active Directory, в каждом лесу по одному домену. Функциональные уровни лесов и доменов Windows 2008R2.

FQDN доменов:

source.local

destination.local

NETBIOS доменов:

SOURCE

DESTINATION

Контроллеры доменов:

dc01.source.local / 172.15.15.2

dc02.destination.local / 172.15.15.1

Миграция объектов и ресурсов выполняется из леса source.local в destination.local.

Шаги процесса миграции представлены в графическом ниже на рисунке1.

Рисунок 1.

Разрешение имен

При объединении двух инфраструктур необходимо, чтобы узлы из одного домена могли разрешать имена узлов другого домена и наоборот. Исторически сложилось так, что в сетях Windows сосуществуют две системы имен — DNS и NetBIOS.

Предпочтительная система имен это DNS. NetBIOS обычно используется для совместимости с предыдущими системами. Объединение имен NetBIOS необходимо настроить, если в среде существую приложения, которые используют эту систему имен.

Так как в рассматриваемой инфраструктуре разрешение имен обеспечивает механизм DNS рассмотрим варианты объединения DNS.

Пересылка(Forwarders)

Пересылка позволяет перенаправлять DNS-запросы, поступающие на локальный DNS-сервер, на указанные серверы DNS.

Сервер безусловной пересылки перенаправляет все запросы DNS. Сервер условной пересылки перенаправляет DNS запросы в зависимости от названия домена, содержащегося в запросе.

Использование условной пересылки удобно тем, что для ее настройки нужно только указать имя домена и IP-адрес DNS сервера.

Дополнительная зона

Для обеспечения отказоустойчивости службы DNS рекомендовано использовать несколько серверов DNS. Для обеспечения стандартных основных зон(не интегрированных в AD) создают дополнительные зоны, а серверы которые обслуживают дополнительную зону называют дополнительные серверы DNS.  Дополнительные серверы DNS получают информацию от главных серверов(master servers), а сам процесс называется передачей зоны. Так как Windows 2000 не поддерживает условной пересылки или зон-заглушек, для объединения используют дополнительные зоны.

Зона-заглушка

Зоны-заглушки(stub zone) по своему механизму разрешения имен схожи с пересылкой. Зона-заглушка содержит записи A и NS полномочных серверов зоны. Сервер DNS разрешает запросы узлов зоны, запрашивая указанные в списке серверы имен. Зоны-заглушки можно реплицировать с помощью стандартного механизма репликации AD. Отличие от пересылки заключается в том, что в случае создания дочерних доменов нет необходимости в дополнительных настройках, так как в старой зоне для этого дочернего домена появится две новые записи A и NS полномочных серверов.

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

Настройка пересылки представлена на рисунке 2.

Рисунок 2.

DNS Suffix Search List

С помощью пересылок компьютеры в доменах source.local и destination.local могут разрешать FQDN узлов. Проблемы могут возникнуть когда служба или пользователь попробуют разрешить короткое имя хоста в другом лесе. По умолчанию при разрешении коротких имен компьютер-член домена использует основной суффикс, который ему присваивается при вводе его в домен.  Для возможности разрешения коротких имен компьютеров другого леса можно использовать групповую политику DNS Suffix Search List. В домене destination.local список суффиксов должен выглядеть следующим образом(порядок важен): destination.local, source.local

В домене source.local: source.local, destination.local.

В моем сценарии в destination.local я изменю default domain policy в продуктивной среде, возможно проще будет создать отдельную политику.

Рисунок 3.

Проверка ipconfig/all

Рисунок 4.

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

Синхронизация времени

Синхронизация времени между доменами может быть выполнена несколькими способами:

1. Синхронизация времени от общего источника. Контроллеры домена исходного леса и контроллеры домена леса назначения, синхронизируются с единым источником времени.

2. Синхронизация между лесами. Контроллер домена исходного леса настраивается на синхронизацию времени с PDC Emulator целевого леса.

По умолчанию источником времени в доменной структуре являются контроллеры корневого домена, выполняющие роль PDC Emulator.

Для настройки контроллеров PDC Emulator на синхронизацию времени с внешним источником можно выполнить с помощью команды:

w32tm /config /manualpeerlist:»IP-адрес или DNS-имя» /syncfromflags:manual /reliable:yes /update

<IP-адрес или DNS-имя> — внешний источник времени.

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

w32tm /stripchart /computer:<IP-адрес> /dataonly /samples:4

<IP-адрес> — контроллер исходного домена.

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

w32tm /config /syncfromflags:domhier /reliable:no /update

net stop w32time

net start w32time

Настройка доверительных отношений(аутентификация)

Доверительные отношения используются службами проверки подлинности и авторизации с целью предоставления пользователям в одном домене доступа к другим доменам.  Доверительные отношения могут быть разного типа:

• Двусторонние доверительные отношения
• Прямые доверительные отношения
• Доверительные отношения между лесами
• Внешние доверительные отношения
• Доверительные отношения сферы

В данной статье доверительные отношения не рассматриваются подробно, поэтому описание типов доверительных отношений можно посмотреть на странице Understanding Trust Types.

Доверительные отношения имеют направление. На рисунке 3 отображены однонаправленные доверительные отношения между двумя доменами. В этом случае пользователи из домена trusting могут проходить аутентификацию в домене trusted.

Рисунок 5.

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

Какой тип доверительных отношений выбрать?

В случае если функциональные уровни лесов ниже Windows 2003 создаются внешние доверительные отношения. Такие доверительные отношения не обладают свойством транзитивности и поэтому в случае если в лесу содержится несколько доменов доверительные отношения придется создавать для каждого домена отдельно.

В случае если функциональные уровни лесов Windows 2003 и выше, то можно создать доверительные отношения уровня леса. Такие доверительные отношения создаются на уровне корневого домена леса. Так как доверительные отношения уровня леса имеют свойство транзитивности, то все домены одного леса автоматически доверяют всем доменам другого леса.

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

• FQDN доменов совпадают;
• NetBIOS доменов совпадают;
• SID доменов совпадают.

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

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

Объекты в AD, которым предоставляется доступ к ресурсам называются принципалы безопасности. При создании каждому принципалу безопасности присваивается SID.  Еще один компонент безопасности — это объект к которому предоставляется доступ принципалам безопасности. Разрешения доступа, предоставляемые для этих объектов локализованы в списке контроля доступа ACL. В списках контроля доступа включены SID пользователей и групп.

Во время миграции пользователям, которых уже мигрировали в новый домен(destination.local) будет необходим доступ к ресурсам старого домена(source.local). Для этого был придуман механизм SIDHistory. SIDHistory это атрибут пользователя, куда во время миграции копируется SID пользователя из старого домена(source.local). Механизм доступа к ресурсам старого домена с помощью SID History отображен на рисунке 6.

Рисунок 6.

Пользователь source\testuser был перемещен с помощью ADMT в домен destination.local. В ходе миграции значение атрибута ObjectSID=SIDx  пользователя source\testuser было скопировано в атрибут SIDHistory=SIDx пользователя destination\testuser.

При попытке доступа пользователя destination\testuser к ресурсу Folder домена source.local в маркере безопасности содержится ObjectSID=SIDz и SIDHistory=SIDx, поэтому пользователю из нового домена будет обеспечен доступ к ресурсам старого домена.

Использование SIDHistory облегчает процесс доступа к ресурсам во время миграции, но при этом является серьезной угрозой безопасности. Поэтому было решено использовать фильтрацию SID.

Рассмотрим фильтрацию SID на рисунке 7.

Рисунок 7.

Между Domain1 и Domain3 настроены односторонние доверительные отношения. Domain1 в этом примере является trusted доменом.  Пользователь user пытается получить доступ к серверу приложений(Application Server) расположенному в Domain3. В билете безопасности пользователя содержаться идентификаторы безопасности SID из Domain1(не картинке отображен два раза для группы и для пользователя), Domain2, Domain3.  Контроллер домена в Domain3 проверяет данные авторизации и фильтрует все SID, которые не принадлежат Domain1, даже если они находятся в Domain3 (это и есть значение SID History).

Как контроллер понимает какие SID нужно фильтровать?

При создании доверительных отношений на стороне доверяющего(trusting) домена Domain3 в контейнере System создается объект Trusted Domain object (TDO) в котором хранятся все SID доверяемого(trusted)  домена Domain1, поэтому все остальные SID считаются инородными.

В случае forest trust отключение фильтрации SID обеспечивается c помощью включения SIDHistory:

Netdom trust исходный_домен /d:домен_назначения /ud:”администратор домена_назначения” /pd:”пароль администратора домена_назначения” /uo:”администратор сходного_домена” /po:”пароль администратора исходного_домена” /EnableSidHistory:yes

В случае внешних доверительных отношений(external trusts)  отключение фильтрации SID обеспечивается с помощью отключения «карантина»:

Netdom trust исходный_домен /d:домен_назначения /ud:”администратор домена_назначения” /pd:”пароль администратора домена_назначения” /uo:”администратор сходного_домена” /po:”пароль администратора исходного_домена” /Quarantine:no

Отличие фильтрации внешних доверительных отношений от фильтрации доверительных отношений леса заключается в том, что на стороне доверенного домена(trusted) в TDO внешних доверительных отношений содержаться только SID доверяемого домена(trusting) и поэтому, если в универсальной группе будут SID из других доменов леса они будут отфильтрованы. В TDO доверительных отношений леса содержаться SID всех доменов доверяемого леса и поэтому проблем с группами не будет, а фильтроваться будут только инородные SID из атрибута SIDHistory.

Фильтрация SID всегда настраивается на стороне доверяющего домена(Trusting domain), там у нас находятся ресурсы и к ним пользователи будут получать доступ по атрибуту SID History, поэтому команду отключения фильтрации в этом случае необходимо выполнить на контроллере домена source.local. В рассматриваемом примере отключение фильтрации SID для доверительных отношений уровня леса обеспечивается включением SID History, после включения SIDHistory выполнена проверка, см. рисунок 8.

Рисунок 8.

ADMT

Для миграции объектов и трансляции безопасности используется Acctive Directory Migration Tool (ADMT), последнюю версию ADMT 3.2 и PES можно скачать с официального сайта Microsoft.

Требования и рекомендации для по установке:

Требования:

На локальном компьютере, где будет установлен ADMT должен быть создан Instance SQL Express:

• SQL Server 2005 Express must be installed with Service Pack 3 (SP3)
• SQL Server 2008 Express must be installed with Service Pack 1 (SP1)
• SQL Management Studio (не обязательно)

На любом компьютере может быть настроен Instanсe SQL 2005 или SQL 2008 (платные версии).

Поддерживаются операционные системы  Windows Server 2008/2008 R2, 2012/2012R2

Предустановлен Net Framework 3.5

Рекомендации:

Я рекомендую устанавливать ADMT на выделенном сервере, во-первых не очень хорошей практикой является установка/удаление дополнительных приложений на контроллерах доменов. Во-вторых для проведения миграции могут быть использованы различные дополнительные механизмы автоматизации, использующие например SMS, SCCM, которые потребуют дополнительных ресурсов.

Сама процедура установки тривиальна и не требует подробного описания, тем более что инструкция есть в ADMT Guide.

Распространенные ошибки, которые возникают при установке ADMT можно посмотреть в блоге разработчиков AD

В рассматриваемом сценарии я сделал допущение, по причине того, что мой тестовый стенд не может выделить слишком много ресурсов, ADMT установлен на сервере dc02.destination.local / 172.15.15.1 (сервер ADMT рекомендуется устанавливать в целевом лесе).

(Опционально) В исходном домене source.local создать локальную группу SOURCE$$$  (При первом запуске ADMT сам создаст группу).

— В исходном и конечном доменах (source.local, destination.local) настроить аудит следующих событий:

В Default Domain Controllers Policy в разделе Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Audit Policy

параметр Audit account management — Success, Failure

параметр Audit directory service access — Success

Рисунок 9.

Для исходного домена, который обслуживают контроллеры доменов ниже Windows 2003 для доступа к базе данных SAM с помощью удаленного вызова процедур, на PDC эмуляторе необходимо изменить значение TcpipClientSupport,в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA на 1 (REG_DWORD). После завершения работы с реестром перезагрузить сервер.

PES

ADMT использует Password Export Server(PES) сервис для миграции паролей пользователей. PES устанавливается на контроллере в исходном (source) домене. На сервере PES представлен как сервис, рекомендуется, чтобы сервис запускался вручную непосредственно перед миграцией учетных записей пользователей.

1. На сервере, где установлен ADMT(dc02.destination.local / 172.15.15.1) создать ключ шифрования

admt key /option:create /sourcedomain:source.local /keyfile:c:\peskey.pes /keypassword:P@ssw0rd

Рисунок 10

2. Установить PES на сервере dc01.source.local / 172.15.15.2

Скопировать файл peskey.pes на сервер dc01.source.local / 172.15.15.2

Запустить инсталляцию PES на сервере dc01.source.local / 172.15.15.2

Рисунок 11.

Принять условия лицензирования

Рисунок 12.

Выбрать файл, который был создан ранее с помощью ADMT

Рисунок 13.

Указать пароль, который был указан при создании файла шифрования (P@ssw0rd)

Рисунок 14.

Запустить установку

Рисунок 15.

Указать учетную запись для запуска сервиса PES

Рисунок 16.

Завершить установки и перезагрузить компьютер

Рисунок 17.

После перезагрузки компьютера зайти в сервисы (services.msc) и запустить сервис  Password Export Server service.

Учетная запись мигратора

Для успешной миграции объектов между доменами source.local и destination.local необходимо назначить соответствующие права учетной записи мигратора. В таблице 1 отображены разрешения в доменах для миграции объектов AD.

Таблица 1.

Migration object	Credentials necessary in source domain	Credentials necessary in target domain
User/managed service account/group without SID history	Delegated Read all user information permission on the user OU or group OU and domain administrator credential	Delegated Create, delete, and manage user accounts, Create, delete, and manage groups, and Modify the membership of a group for the user OU or the group OU and local administrator on the computer where ADMT is installed
User/managed service account/group with SID history	Delegated Read all user information permission on the user OU or group OU and domain administrator credential	Delegated permission on the user OU or the group OU, extended permission to migrate SID history, and local administrator on the computer on which ADMT is installed
Computer	Domain administrator or administrator in the source domain and on each computer	Delegated permission on the computer OU and local administrator on the computer on which ADMT is installedNoteIf the computer has a managed service account installed, you need to supply credentials that have permission to update the security descriptor of the managed service account in the target domain.
Profile	Local administrator or domain administrator	Delegated permission on the user OU and local administrator on the computer on which ADMT is installed.NoteYou might need to complete additional preparation steps if you migrate roaming profiles for computers that run Windows Vista or Windows 7. For more information, see Preparing for migration of roaming profiles with computers that run Windows Vista and Windows 7.

Для решения вопроса с разрешениями поступают следующим образом(разбираю на примере моего сценария):

1. Создается учетная запись destination/migrator.

2. Создается глобальная группа destination/MIGRATORS, куда добавляется пользователь destination/migrator.

3. Группа destination/MIGRATORS добавляется в группу destination/Domain Administrator

4. Группа destination/MIGRATORS добавляется в группу source/Administrators

Так же для того, чтобы ADMT агент успешно отработал на рабочих станциях(АРМ) и серверах домена source.local, группа destination/MIGRATORS должна входить в локальные группы администраторов АРМ и серверов.

Добавить группу destination/MIGRATORS в локальные администраторы хостов можно с помощью скриптов или групповых политик(Restricted Groups).

Для этого в source.local создается новый объект GPO  «Local Admins»  и в разделе Restricted Groups создать группу Administrators, куда потом можно добавить все группы, которые должны находится в локальных администраторах.

Рисунок 18.

ВНИМАНИЕ!!! В случае, если Restricted Groups настроены следующим образом все учетные записи, которые были добавлены в локальные администраторы будут удалены! Таким методом удобно пользоваться, если уже существует политика Restricted Groups.

В случае если требуется добавить группу destination/MIGRATORS не затронув существующих пользователей в группах локальных администраторов необходимо настроить Restricted Groups следующим образом:

Рисунок 19.

В случае, если пользователю MIGRATOR не хватит прав при попытке установки агента появится следующая ошибка(в данном скриншоте исходный домен называется viktorp.club):

При первом открытии ADMT у меня возникла следующая ошибка:

Рисунок 20.

Для ее решения нужно дать необходимые разрешения для учетный записи MIGRATOR

Для этого необходимо установить SQL Server Management Studio

Подключиться к  серверу «.\sqlexpress»

В разделе Security/Logins добавить учетную запись мигратора (migrator см. ниже) и назначить ей соответствующие разрешения для базы ADMT.

Рисунок 21.

Основные общие шаги по подготовке к миграции выполнены.

(Опционально)

Так как у меня тестовый стенд я создал 100 пользователей с паролем P@ssw0rd в разделе в OU «SOURCE_USERS» с помощью следующего скрипта Power Shell :

$title = @(

‘Сетевой инженер’,

‘SAP департамент’,

‘Безопасность’,

‘Microsoft департамент’,

‘UNIX департамент’,

‘Финансы’,

‘Внешние сотрудники’)
New-ADOrganizationalUnit -Name «SOURCE_USERS» -Path «dc=source,dc=local»
1..100 | Foreach-Object {

$r = Get-Random -Minimum 0 -Maximum 7

New-ADUser -Name «User$_» -OtherAttributes @{title=$title[$r];Description=$title[$r]} -AccountPassword (ConvertTo-Securestring -AsPlainText «P@ssw0rd» -Force) -Path «ou=SOURCE_USERS,dc=source,dc=local» -Enabled $true }

Тестирование

После того, как инфраструктуры были подготовлены к миграции, необходимо проверить работу ADMT:

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

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

Для тестирования необходимо запустить ADMT от имени пользователя DESTINATION\MIGRATOR и запустить «User Account Migration Wizard».

При первом запуске помощника, при попытке выбора опции «migrate User SIDs» to target domain» у меня появилась ошибка:

Ошибка связана с тем, что в исходном домене source.local, был не верно указан тип группы SOURCE$$$, группа должна быть Domain Local.

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

1. Корректность миграции SID History и доверительные отношения между лесами.

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

В домене DESTINATION просмотреть атрибут SidHistory у User1.

dsquery * -filter «&(objectcategory=user)(samaccountname=user1)» -attr objectsid sidHistory

Выполнить вход на рабочую станцию используя учетные данные DESTINATION\User1 и проверить доступность ресурсов на файл-сервере домена source.local.

При корректно работающих доверительных отношениях и отключенной фильтрации SID HIstory пользователь(DESTINATION\User1) должен успешно аутентифицироваться и авторизоваться на файл-сервере в домене SOURCE.

2. Корректность миграции паролей

Выполнить вход на рабочую станцию используя учетные данные DESTINATION\User1 указав старый пароль.

P.S. Кто дочитал до конца 🙂 прошу писать в комментарии правки/комментарии, буду очень признателен!

P.S.S. Спасибо за помощь коллеге по цеху Геннадию Ефимову