Привет, Хабр! В сегодняшнем материале рассмотрим два подхода к переносу ИТ-инфраструктуры на отечественную систему централизованного управления. В комплекте: обзор возможностей и пошаговая инструкция, как подготовить домен к миграции, установить доверительные отношения или создать параллельную инфраструткуру.
Еще недавно в любой относительно крупной ИТ-инфраструктуре всё строилось вокруг контроллера домена Active Directory на базе Microsoft Windows Server. Экосистема была удобна пользователям — купив лицензию на Windows Server и SCCM, администратор получал практически все, что ему нужно для управления. Конечно, некоторые сервисы были на базе open source продуктов, однако они не составляли ядро инфраструктуры.
С приходом импортозамещения ситуация изменилась — от зарубежных систем пришлось уходить. Кто-то начинал переход с клиентских машин (и понимал, что ими надо как-то управлять), кто-то искал аналоги сопутствующих сервисов, таких как: файловые хранилища, установка ОС, мониторинг, — и понимал, что все эти сервисы надо будет как-то «подружить» между собой. Кто-то решил начать с контроллера домена и наращивать инфраструктуру вокруг. Все эти подходы вполне правомерны и успешно используются.
Нам ближе подход «в центре всего есть контроллер». Сегодня мы расскажем, как наши заказчики переходят от инфраструктуры на базе продуктов Microsoft Windows на решения РЕД СОФТ.
Перед началом договоримся…
Существует несколько сценариев миграции. Следует понимать, что все эти сценарии «сферические в вакууме», их нужно адаптировать для каждого конкретного случая, однако, общие подходы стоит показать. Часть из этих сценариев рассмотрены в нашем обучающем курсе, другие будут добавлены в курс в будущем.
Напомним, что изменения в инфраструктуре необходимо сначала проверять в тестовой среде и только потом реализовывать изменения в продуктивной среде! Все трюки выполнены профессионалами, повторять можно и нужно, но сначала только в тестовом контуре.
Сценарий первый. Репликация
Когда лучше выбрать?
У вас есть контроллер на базе MS AD, к нему подключены клиентские машины на операционной системе Windows, предоставлены различные сервисы – файловое хранилище, возможность централизованно накатывать ОС на новые машины, клиентские машины получают настройки с помощью GPO. В общем, администратор счастлив и у него все работает.
Репликация — самый удобный, на наш взгляд, способ «переехать» с MS AD. При этом в отличие от описанных ниже способов, нет необходимости настраивать параллельный доступ к используемым сервисам из двух доменов. Просто добавляем новый контроллер домена РЕД АДМ в домен, проверяем работоспособность инфраструктуры и сервисов, и по готовности выводим контроллер домена Windows из эксплуатации.
Перед вводом новых контроллеров в домен нужно убедиться, что в нем отсутствуют ошибки репликации, а также пройден чек-лист «здоровье домена». Каждый системный администратор должен иметь такой чек-лист и периодически проверять «здоровье» вверенного ему домена.
Чек-лист проверки «здоровья домена»:
1. Проверяем состояние репликации
repadmin /replsum
repadmin /showrepl2. Проверяем состояние служб домена
dcdiag /qПроверяем, что все контроллеры домена (если их несколько) используют DFS-R для репликации SYSVOL
dfsrmig /getmigrationstateПроводим миграцию репликации SYSVOL на DFS-R, если она не была проведена ранее. Миграция необходима, если изначально домен был развернут с уровнем домена леса 2008 или ниже. Т.к. до 2008 для репликации каталога SYSVOL использовался механизм FRS.
Проводим диагностический отчет по репликации DFS-R
a. Оснастка DFS management → Replication → Create Diagnostic Report
b. При наличии ошибок — устраняем.
3. В оснастке DNS проверяем свойства прямых и обратных зон.
Свойства зоны → Вкладка General — Replication
Должен быть установлен один из первых двух вариантов.
Проверяем зону _msdcs на присутствие записей старых контроллеров, в случае необходимости — удаляем старые записи от несуществующих контроллеров.
4. Проверяем, что все FSMO роли находятся на действующих контроллерах домена
netdom query fsmo 5. Проводим анализ логов контроллера MS AD и убеждаемся в отсутствии ошибок.
Application and Services Logs -> Directory Service6. Проводим анализ логов DNS и убеждаемся в отсутствии ошибок
Application and Services Logs -> DNS ServerНастраиваем управление групповыми политиками
Вы можете подключить к контроллеру домена MS AD клиентские машины на Linux. Но теперь у вас может возникнуть вопрос: как ими управлять? Ведь групповые политики MS AD могут управлять только рабочими станциями на базе операционной системы Windows. Для управления рабочими станциями на Linux вы можете использовать такой инструмент, как Ansible. Придется самостоятельно писать плейбуки, не говоря уже о том, что этот инструмент работает только в режиме push.
А теперь хорошие новости — благодаря клиентскому приложению в РЕД АДМ, можно легко управлять групповыми политиками и использовать конфигурации как в формате push-, так и в формате pull. Про push- и pull- в РЕД АДМ мы писали в прошлых статьях, но напомним:
Push-режим позволяет отправить конфигурации непосредственно с РЕД АДМ. Этот способ не всегда удобен, ведь часть машин может быть выключена, или же настройки должны «приехать» в момент входа пользователя в систему.
С помощью pull- режима мы можем достигнуть поставленной цели. А чтобы клиентская машина вовремя запросила нужные данные с сервера, мы разработали клиентский агент РЕД АДМ.
Вводим контроллер домена РЕД АДМ
Следующим действием станет ввод контроллера домена РЕД АДМ в существующий домен на базе MS AD. Для упрощения жизни администратора это теперь можно сделать из графического интерфейса РЕД АДМ.
1. Сначала необходимо установить РЕД АДМ и создать локальную базу данных.
2. На этапе подключения или создания нового контроллера домена необходимо выбрать «подключиться к существующему». При подключении по доменному имени нужно проверить, что контроллер доступен по доменному имени с хоста, где установлен РЕД АДМ. Иначе говоря, проверить настройки DNS.
3. Чтобы можно было подключить РЕД АДМ к контроллеру домена на базе MS AD, необходимо разрешить возможность подключения по ldaps. Проще всего поднять на MS AD роль центра сертификации (если по каким-либо причинам вам не подходит этот вариант, можно воспользоваться документацией — в ней описано, как подключиться к MS AD без роли центра сертификации).
4. Наконец, нам остается только создать новый контроллер и присоединить его к существующему. Это делается через Управление доменом в РЕД АДМ. Вы просто нажимаете на кнопку «Добавить КД» и указываете — на каком хосте этот контроллер будет развернут и к какому контроллеру его нужно присоединить — остальное сделает за вас РЕД АДМ. Кстати, про управление контроллерами через интерфейс РЕД АДМ мы уже писали в предыдущей статье.
Мигрируем клиентские машины
Сейчас в инфраструктуре работают два контроллера домена, причем один из них может управлять Linux-машинами. Поэтому самое время начать постепенно переводить парк клиентских машин на РЕД ОС. Управление РЕД ОС будет производиться с помощью конфигураций из РЕД АДМ.
Гетерогенная среда — это хорошо, но надо сразу подумать о том, как мы будем выводить из инфраструктуры контроллер на базе MS AD. Сейчас, по сути, этот контроллер нужен для управления клиентскими хостами на Windows. Если вы планируете оставлять какие-то машины на Windows, то нужно сделать некоторые подготовительные действия.
1. Выполнить репликацию каталога SYSVOL. Это необходимо для того, чтобы все групповые политики, которые были созданы для хостов на Windows, не потерялись и продолжили работать. Почитать подробнее об этом этапе можно в документации.
2. После репликации каталога SYSVOL нам остается только передать роли FSMO с контроллера MS AD на контроллер РЕД АДМ. Для этого нужно перейти в Управление доменом, подраздел с Глобальной конфигурацией.
3. Для управления среплицированными политиками нужна машина с Windows, на которую необходимо установить RSAT
4. Выключаем контроллер на Windows, проверяем работоспособность групповых политик и понижаем роль первого контроллера и выводим его из эксплуатации.
Обратите внимание, что РЕД АДМ пока не работает с почтовым сервером MS Exchange. Поэтому, если такое решение еще используется в вашей инфраструктуре, полностью отказаться от контроллеров на MS Windows не получится. Однако вы можете рассмотреть варианты аналогичных сервисов от российских вендоров.
Теперь в нашей инфраструктуре нет контроллеров на базе MS AD, клиентские машины постепенно мигрируют с Windows на РЕД ОС, и администратор может заняться настройкой сопутствующих сервисов, например, файлового хранилища (но об этом мы расскажем в следующий раз).
Сценарий второй. Построение параллельной инфраструктуры
Когда лучше выбрать?
Бывают ситуации, когда невозможно произвести никаких действий с существующим доменом. В этом случае можно построить параллельную инфраструктуру на базе РЕД АДМ и выстроить между доменами доверительные отношения.
Плюсы такого решения — проводить миграцию можно длительное время, постепенно перемещая сопутствующие сервисы на новые решения. При этом не так важно, насколько корректно работает ваш исходный домен — например, в нем могут быть какие‑либо ошибки, которые вы не можете оперативно решить. Также в этом случае можно полностью избавится от унаследованных проблем в доменной инфраструктуре, создав всё заново.
Разворачиваем новый домен
Кратко рассмотрим процесс настройки доверительных отношений. Если вам нужны подробности – добро пожаловать в нашу документацию. В примерах будет использоваться исходных домен на MS AD — windows.red и новый домен на РЕД АДМ example.tst
1. Настройка доверительных отношений происходит после установки контроллера РЕД АДМ, поэтому первым пунктом вам необходимо будет установить РА и развернуть новый домен
2. На контроллере РЕД АДМ необходимо отредактировать файл /etc/named.conf и после корневой зоны «.» добавить зону пересылки запросов в доверенный домен:
zone "windows.red" IN {
type forward;
forwarders { 192.168.100.5; };
};Где в параметре forwarders необходимо указать адрес КД MS AD, с которым необходимо установить доверительные отношения.
3. На КД РЕД АДМ также отредактируем файл /etc/krb5.conf и в секции [realms] и [domain_realm]
[realms]
EXAMPLE.TST = {
kdc = dc1.example.tst
admin_server = dc1.example.tst
}
WINDOWS.RED = {
kdc = windc.windows.red
admin_server = windc.windows.red
}
[domain_realm]
.example.tst = EXAMPLE.TST
example.tst = EXAMPLE.TST
.windows.red = WINDOWS.RED
windows.red = WINDOWS.RED4. Далее на РА остается только перезапустить службы systemctl restart reddc named
5. На контроллере домена MS AD необходимо настроить сервер условной пересылки
Устанавливаем доверительные отношения
Теперь мы готовы к настройке доверительных отношений, осталось проверить доступность контроллеров друг с друга командой nslookup имя_КД.
Если сервера доступны, создаем доверительные отношения командой:
samba-tool domain trust create windows.red --type=external --direction=both --create-location=both -U Administrator@WINDOWS, …где:
type — тип доверительных отношений‑ external (внешнее) — РЕД АДМ поддерживает тип отношений external
direction — направление доверительных отношений, со следующими возможными значениями:
— both — двухсторонние доверительные отношения. Контроллер домена РЕД АДМ будет доверять контроллеру домена Active Directory и наборот — обе стороны смогут обмениваться аутентификационной информацией и ресурсами;
— outgoing — односторонние доверительные отношения только для исходящих запросов: например, контроллер домена Active Directory будет доверять контроллеру домена РЕД АДМ, например, при получении запросов на аутентификацию от пользователей из СК РЕД АДМ, но не наоборот;
— incoming — односторонние доверительные отношения только для входящих запросов: например, контроллер домена РЕД АДМ будет доверять контроллеру домена Active Directory, например, при получении запросов на аутентификацию от пользователей из домена Active Directory, но не наоборот.
В случае успешного создания доверительных отношений, в конце вывода результатов работы команды в терминал должна быть надпись success.
После построения доверительных отношений необходимо еще раз перезапустить службы reddc и named, проверить установленные доверительные отношения при помощи команды:
samba-tool domain trust listДля того, чтобы убедиться в корректности выполненных выше команд, стоит проверить целостность получения файла PAC dump при помощи следующей команды (запуск следует выполнять от root):
net ads kerberos pac dump -U Administrator@WINDOWS.REDИтак,
В этой статье мы рассмотрели основные сценарии миграции с существующей инфраструктуры, построенной на базе продуктов Windows, на продукты РЕД СОФТ с помощью возможностей РЕД АДМ.
Конечно же, у каждой миграции свои особенности, но общий подход к процессу будет именно таким. Надеюсь, сегодняшний материал помог вам узнать больше о путях перехода на отечественную систему централизованного управления ИТ-инфраструктурой.
