Привет, Хабр! Меня зовут Дмитрий (@HaZkeR_Default), и я — инженер по инфраструктурным решениям в компании РЕД СОФТ. Моя работа связана с RED DC — контроллером домена, входящим в состав системы централизованного управления РЕД АДМ. В частности, я занимаюсь анализом проблем, возникающих у пользователей. Итак, я обнаружил, что 80% ошибок легко поправимы и закрадываются на этапе первичных настроек «Службы каталогов». Их можно избежать, выполнив проверки на стадии ввода или репликации.

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

Преамбула

В «инструкции по администрированию службы каталога» нас просят выполнить ряд действий, которые, на первый взгляд, кажутся базовыми. Но даже в простой задаче можно ошибиться, что в будущем приведет к неминуемым последствиям. Так давайте же сэкономим ваше время и нервы и детально разберемся, как правильно поднять отечественную службу каталогов RED DC.

Сразу уточню, что будем смотреть основательно. В РЕД АДМ большинство процессов, связанных с контроллером домена, переведены в веб-интерфейс. Однако бывают форс-мажорные ситуации, в которых его может быть недостаточно или наоборот, он будет избыточным. В таких случаях следует покопаться в логах. К тому же, так можно обнаружить любопытные (и часто мешающие) артефакты в ИТ-инфраструктуре. Поэтому перейдём на высший пилотаж и разберем, как поднять контроллер домена в ручном режиме.

С чего начать?

Конечно же, с РЕД ОС

Первое, что нам понадобится, это РЕД ОС Сервер минимальный. Версия операционной системы не имеет значения. Вы можете выбрать как РЕД ОС 7.3, так и РЕД ОС 8. Установите операционную систему и обновите её до самых последних обновлений.

Далее в системе нужно установить пакет reddc.rpm. И теперь мы готовы начинать.

Готовим окружение

Сначала нужно задать hostname для будущего контроллера домена, при этом обязательно в формате FQDN (от англ. Fully Qualified Domain Name). Например, если нужно ввести машину с именем dc-1 в домен redadm.reddc, то вашим FQDN будет dc-1.redadm.reddc

Задать имя машины можно с помощью системной утилиты hostnamectl:

hostnamectl set-hostname dc-1.redadm.reddc

Дальше, если следовать «руководству администратора подсистемы Службы каталога», нужно заполнить файлы конфигурации, а именно:

• /etc/chrony.conf – Основной файл конфигурации службы времени Chrony

• /etc/krb5.conf – Основной файл конфигурации службы Kerberos

• /etc/krb5.conf.d/crypto-policies – Файл крипто-политик ака, файл типов шифрований, которые будут использоваться

• /etc/named.conf – основной файл конфигурации службы DNS - BIND9

Предлагаю пройтись по всем файлам конфигураций и осуществить первичную настройку вместе.

Chrony. Время на исходе

Синхронизируем время

Точно настроенное время нужно для того, чтобы KDC (Key Distribution Center – центр распространения ключей) — корректно выдавал билеты. Даже малейшее расхождение в 5 минут может привести к деактивации билета.

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

• Для проверки времени достаточно ввести команду date в терминале. Отобразятся текущие дата и время.

• Чтобы увидеть текущий часовой пояс, можете воспользоваться командой timedatectl.

Ожидаемый вывод должен быть таким:

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

Чтобы проверить службу времени, нужно ввести в терминале команду:

systemctl status chronyd

Как вы можете заметить, служба Chrony активна и запущена.

Если нужно указать локальный сервер времени, расположенный внутри компании

Нужно поправить файл конфигурации. Откройте файл /etc/chrony.conf вашим любимым текстовым редактором.

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

• Директива server будет обозначать что это именно сервер, а не пул.

• IP адрес или имя – указание вашего сервера времени

• Iburst – это дополнительный ключ, который быстрее проводит синхронизацию.

Сохраните файл и перезапустите службы командой: systemctl restart chronyd. Подождите некоторое время, и выведите снова команду date.

Если вы всё сделали правильно, а ваш сервер времени настроен верно, то время будет синхронизировано с NTP-сервером.

Если же чуда не произошло, то убедитесь, что на вашей локальной машине или в сети открыт 123 порт по UDP. Проверить это можно с помощью утилиты nmap. Проверим порт:

dnf install nmap –y 

nmap –sU 10.10.11.2 –p U:123

Исправный вывод должен быть таким:

Стоит проверить, или что-ещё-может-пойти-не-так

Несмотря на то, что порт открыт, есть еще ряд проблем, которые могут помешать синхронизации времени. Например, в настройках NTP сервера указана конкретная подсеть обслуживания, а ваша машина находится в другой подсети. Из-за этого запросы вашей машины к серверу будут отброшены (Reject).

Также дополнительно проверьте статус службы chronyd, она явно сообщит, в чем может проблема.

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

Также у службы Chrony есть командлеты, которые начинаются с chronyc. Например, можно вывести текущие источники времени, используя: chronyc sources.

Krb5.conf. Предоставьте ваш билет, товарищ

Переходим к более сложной части, а именно — к настройке файла /etc/krb5.conf. Именно здесь появятся записи о вашем KDC. От правильной заполненности данного файла зависят работоспособность контроллера и корректная выдача TGT\TGS ключей.

На первый взгляд листинг krb5.conf может показаться сложным и запутанным для человека, который впервые поднимает контроллер домена на Linux. Сейчас будем разбираться. Итак, от нас требуется заполнить лишь ряд полей. Сначала их надо раскоментировать.

Вот так krb5.conf выглядит до заполнения:

Нас интересуют строчки:

default_realm — тут мы заполняем имя будущего или существующего контроллера домена. Обязательно в верхнем регистре! Официального требования, описанного в RFC документах нет, однако так сложилось исторически.

В секции realms нужно поменять почти всё:

• EXAMPLE.COM — замените на имя вашего домена.

• В значении строчек kdc и admin_server – пропишите fqdn имя текущей машины (мы его задавали в самом начале).

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

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

Crypto-policies, или сундук с криптой

Crypto-policies, он же файл крипто-политик, — это стандартный файл на всех linux машинах. В нем описаны все типы поддерживаемых шифрований. Приведем файл к виду:

Обратите внимание на используемые типы шифрования. Так, например, RC4-HMAC постепенно выходит из списка безопасных политик. Сверьтесь с вашими коллегами из отдела безопасности на тему разрешенных типов шифрования и исключите те, которые вам не требуется.

Исключениями могут стать типы шифрований DES-CBC-CRC, DES3-CBC-SHA1, DES-CBC-MD5. Они давно признаны небезопасными и слабыми. Однако могут пригодиться, если в вашей сети есть специфичные операционные системы или ПО, которое требует именно эти типы шифрования.

Named.conf: зона DNS-ответственности

Файл конфигурации named.conf напрямую отвечает за то, как будет работать BIND9. В нашем случае BIND9 будет работать с использованием библиотеки DLZ, которая хранит информацию напрямую в LDAP-каталоге.

Вот так должен выглядеть файл named.conf в заполненном варианте. Давайте разберем его подробнее.

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

Разбираем и настраиваем параметры правильно

listen-on port

Параметр, который пользователи забывают исправить чаще всего! Это строчка listen-on port 53 { 127.0.0.1; } — то, на каком адресе будет «слушать» DNS сервер. Многие оставляют данную строчку как есть. По умолчанию, когда вы поднимаете службы AD DS на Windows Server, в машине настройки DNS ссылаются на loopback-интерфейс. Если оставить эту строчку без изменений, то BIND9 будет «слушать» на loopback-интерфейсе и не сможет вам ответить. Поэтому указывайте именно IP-адрес текущей машины.

allow-query

Следующий параметр — allow-query {}; — отвечает за то, с каких адресов и подсетей будет отвечать вам BIND9. Можно выставить тут any, и DNS сервер будет отвечать всем подряд. Также вы можете поставить ограничения по подсетям или адресам, указав их в формате CIDR — 10.10.11.10/24, 10.10.11.0./24

dnssec-validation

Параметр dnssec-validation yes; надо перевести в значение no, если вы не планируете его настраивать.

keytab, forwarders и ответы

Следом нужно вставить блок из этих трех строчек:

tkey-gssapi-keytab "/opt/reddc/bind-dns/dns.keytab";
 minimal-responses yes;
 forwarders { 77.88.8.8; };

Первая строка определяет правила использования keytab-файла, который отвечает за обновление DNS записей. Вторая — это включение отправки минимальных ответов, чтобы не поступало слишком много сообщений. Третья строка — это опция forwarders, где вы через точку с запятой можете перечислить, к каким DNS серверам идти вашему серверу, если он не сможет разрешить запрос внутри сети.

Подключаем dlz библиотеку

В самом конце файла требуется вставить строчку:

include "/opt/reddc/bind-dns/named.conf";

Она будет отвечать за файл, который подключит dlz библиотеку.

Вы прошли 70% статьи

Получено достижение: «Боевое крещение первичной настройкой»

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

Новый контроллер и старый домен. Ищем проблемы

...до того, как они стали неприятностями.

1. Проверка ответа DNS сервера вашего контроллера домена

Часто бывают ситуации, при которых домен, к которому вы подключаетесь, недоступен по доменному имени (DNS). Это может быть проблема сетевой связанности или неправильной настройки на стороне.

Для базовой диагностики поможет командаnslookup <FQDN DC>. Введите в терминале nslookup windows.domain 

Вывод должен отобразить адреса существующих контроллеров домена. Результат может быть таким:

Если ваш вывод не похож на такой, значит, у вашего DNS сервера на стороне есть проблема. Например, вы можете получить:

Это означает, что машина не смогла разрезолвить имя вашего домена.

Самое первое и базовое, что напрашивается, это классическая проверка порта через nmap:

Так, например, nmap может сообщить, что порт закрыт. Это говорит о том, что либо на сторонней машине не работает сервер, либо закрыт порт.

Другая ситуация, когда вы получаете ответ такого формата:

Это значит, что удаленный хост существует. Но что-то отфильтровало ваш запрос. Например, это может быть firewall. В таком случае нужно найти препятствие и устранить его. Без корректно работающего DNS не будет работать практически ничего.

2. Проверка ответа KDC сервера на выдачу билета

Не раз встречал такую ситуацию: подаем команду на ввод, и буквально через пару секунд ввод завершается с ошибкой Cannot contact any KDC for realm. Выясняется, что либо закрыт 88 порт, либо недоступен DNS, либо на стороне мертв KDC.

Заранее проверяйте работоспособность удаленного КД. Вы можете проверить 88 порт, использовав nmap.

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

3. Проверка SRV-записей LDAP-каталога

Далеко не лишним будет проверить наличие SRV записей на контроллере домена. Если они повреждены или отсутствуют, то ввод в домен может завершиться с ошибкой. Например, определение LDAP-каталога, к которому надо подключиться, выполняется с использование ldap-srv записи. Если такой записи не будет, то ввод не состоится.

Проверка LDAP-записей

Через nslookup, либо через dig -type=SRV ldap.tcp.red.adm dig -type=SRV kerberos.tcp.red.adm

4. Проверьте правильность команды на ввод в домен

...а также её ключи, содержимое, прописан ли REALM в верхнем регистре, а пользователь точно доменный и имеет права на изменения LDAP каталога.

Каждый домен имеет свою историю

Даже все эти проверки не дают стопроцентную гарантию того, что ввод в домен состоится успешно. У вас может возникнуть резонный вопрос: «Почему так?»

Ответ прост — у каждого домена есть своя история. Могут всплыть подводные камни, которые не выловишь базовыми проверками. Вот несколько примеров:

• Контроллер домена был поднят еще с 2000 версии, и в процессе эксплуатации зона _msdcs не была вынесена.

• Или, например, основной контекст домена DNS, который зовется как DomainDnsZones, находится не в отдельном контексте, а в контексте домена в DC=domain,DC=ru —> CN=System,CN=MicrosoftDNS. Соответственно, зона прямого просмотра не была пересоздана.

• Проблемой может стать поломанный объект. Контроллер Windows успешно переместил этот объект в карантинную зону и теперь игнорирует. Такие объекты могут появляться в процессе длительной эксплуатации домена. Их можно найти, если сделать семантический анализ базы. Или включить отладку в реестре на Windows Server, который имеет роли AD DS.

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

Щепотка сомнений реверс-инженера

Пожалуй, мы рассмотрели все возможные проверки и настройки, и даже обсудили специфику работы с существующими доменами. Возможно, кто-то нашёл подводные камни, а кто-то только приступит к настройке контроллера. А кто-то прочитал, вздохнул, и спрашивает: «Столько нюансов! Почему у меня всё работает сразу и без озвученных манипуляций?» — А вы уверены, что работает корректно? :)

Не раз в своей практике сталкивался с тем, что пользователи вводят RED DC далеко не первый контроллер домена Windows, и у них всё работает. А потом мы включаем отладку в реестре и находим зависшие объекты, которые не реплицируются между контроллерами. Или CNF записи в контексте Configuration... Или DomainDnsZones, которые ведут в никуда...

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

Вы прошли 100% статьи

Получено достижение: «Погружение в историю»

На этом моя статья подходит к концу. Был ли это лёгкий спидран или обстоятельная пошаговая настройка — надеюсь, что вам было интересно узнать о том, как работает РЕД АДМ и как обойти стороной самые распространённые ошибки при вводе контроллера и старте репликации.

Материал объёмный, и в процессе чтения наверняка возникли вопросы — вы можете задавать их в комментариях.