1,3K подписчиков

Установка резервного контроллера домена ALD Pro 2.2.1. Обучение по ALD Pro.

161 прочтение

5 мая

С развертыванием первого контроллера домена ALD Pro 2.2.1 Вы можете ознакомиться в статье или в видео.
В этой статье будут ссылки на первый контроллер, его имя dc1.ald.local, IP 10.0.2.7

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

Резервный сервер dc2.ald.local, должен быть с такими же системными параметрами как первый контроллер домена. Они должны быть равны по объему оперативной памяти и количеству ядер, т. к. реплика будет содержать в базе данных полную копию объектов каталога и должна принять на себя всю нагрузку при отключении основного контроллера.

Для установки клиентской и серверной части поддерживается ОС Astra Linux версии с 1.7.1 до 1.7.4 включительно, но модуль глобального каталога будет работать только на 1.7.4.

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

Предварительные настройки ОС

Нужно убедиться в правильности версии Astra Linux и в том что система работает в максимальном уровне защищенности (Смоленск):

sudo cat /etc/astra/build_version

sudo astra-modeswitch getname

Установку контроллера домена необходимо производить под высоким уровнем целостности (63) учетной записи администратора. Убедитесь, что Вы работаете под высоким уровнем целостности (63-й уровень МКЦ):

sudo pdp-id - смотрим по каким уровнем МКЦ работаем

sudo id - смотрим под каким пользователем работаем

Настройка сетевого интерфейса

Сетевые настройки резервного контроллера dc2 немного отличаются от первого контроллера, потому что разрешение имен на dc2 до продвижения должно выполняться через DNS службу основного контроллера dc1.

Отключите службу NetworkManager. Если Вы установили Astra Linux с графикой, то по умолчанию у Вас работает демон NetworkManager - менеджер сетевых подключений. NetworkManager может динамически менять настройки, что крайне полезно для рабочих станций, но может быть неудобно на серверах. NetworkManager рекомендуется использовать на рабочих станциях, однако на серверах рекомендуется использовать службу Networking (команды ifup/ifdown) как более легковесную. Нужно остановить службу NetworkManager, затем выключить и накинуть на нее маску, чтобы ее нельзя было случайно запустить.

sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManager
sudo systemctl status NetworkManager

Присвойте IP адрес интерфейсу. После отключения NetworkManager сетевые настройки нужно задавать в файлах interfaces и resolv.conf. Файл /etc/network/interfaces используется командами ifup/ifdown для конфигурирования сетевых интерфейсов. Служба каталога тесно интегрирована со службой разрешения имен, поэтому контроллер домена выступает еще и в качестве DNS-сервера. Адреса DNS-серверов через DHCP или вручную распространяются по хостам всей сети, поэтому на контроллере домена настоятельно рекомендуют устанавливать статический адрес. Командой ip a, смотрим какие есть сетевые интерфейсы на компьютере и настраиваем один из них в файле /etc/network/interfaces.

ip a

sudo nano /etc/network/interfaces - присвоим IP адрес 10.0.2.8 резервному контроллеру домена

Настройте файл /etc/resolv.conf. Для возможности обращения к первому контроллеру домена и публичным репозиториям следует настроить функцию разрешения имен. Файл /etc/resolv.conf определяет настройки для процедур разрешения имен из библиотеки glibc, которая используется в сетевых утилитах ping, dig и т. д. В этом файле следует указать ip адрес первого котроллера домена, в моем случае это 10.0.2.7. Кроме того необходимо указать поисковый домен (чтобы короткие имена дополнялись до FQDN) используя параметр search и задав ему значение как имя домена, в моем случае это ald.local.

sudo vim /etc/resolv.conf

В процессе продвижения контроллера домена скрипты автоматизации, которые его настраивают, правят файл /etc/resolv.conf - устанавливают в него адрес локальной петли и убирают оттуда адрес первого контроллера домена, а поисковый домен остается. В тот момент, когда файл /etc/resolv.conf уже изменен скриптами автоматизации, а служба BIND9 еще не поднялась, часть скриптов автоматизации не сможет завершиться корректно, потому что будет неудачная попытка разрешения имени. Такое поведение будет исправлено в следующих версиях ALD Pro. Чтобы сейчас решить данную проблему, необходимо запретить любые изменение файла /etc/resolv.conf до продвижения резервного контроллера домена. Это нужно сделать, назначив атрибут i файлу утилитой chattr.

sudo chattr +i /etc/resolv.conf

После настройки сетевого интерфейса выполняем следующие команды:

sudo ip addr flush dev eth0 - очищаем старое соединение

sudo systemctl restart networking - перезапускаем службу networking

sudo systemctl status networking - проверяем, что служба запустилась без ошибок

ping -c 4 dc1 - проверим что сеть работает пингом по IP адресу первого контроллера домена, и например, публичного репозитория.

Настроить имя хоста. Имя хоста должно быть задано в формате полного имени FQDN. При данном подходе вызов команды hostname без параметров будет выдавать FQDN хоста.

Если устанавливать имя хоста напрямую в файле /etc/hostname, то изменения вступят в силу только после перезагрузки, поэтому в Astra Linux рекомендуется это делать с помощью утилиты hostnamectl:

sudo hostnamectl set-hostname dc2.ald.local - присвоить хосту полное доменное имя FQDN

Настроить файл /etc/hosts. Для того чтобы имя контроллера всегда могло быть преобразовано в IP адрес, даже при недоступности DNS сервиса, в файл /etc/hosts требуется добавить строку, соответствующую его FQDN. В эту строку рекомендуется вписать не только полное, но короткое имя хоста, только первым по списку обязательно должно идти полное имя хоста, т. к. первое имя считается каноническим и будет возвращаться командой hostname -f, что требуется для корректной работы скриптов автоматизации. Писать имена необходимо в нижнем регистре. Еще крайне важно удалить строку (или закоментировать), связывающую имя хоста с адресом localhost, т. к. эти адреса имеют выше приоритет, а нам крайне важно, чтобы имя хоста разрешалось в локальный адрес, потому что некоторые службы могут прослушивать порты только на этом адресе.

sudo vim /etc/hosts - открыть файл на редактирование, пример на скриншоте ниже

10.0.2.8 - IP адрес резервного контроллера домена

Подключение репозиториев. Файлы программ Linux объединяются в пакеты и распространяются через специальные хранилища, называемые репозиториями. Основным файлом для хранения списка доступных репозиториев является /etc/apt/sources.list, дополнительные списки могут храниться в файлах *.list в директории /etc/apt/sources.list.d/. По умолчанию Astra Linux предлагает использовать репозитории stable, которые соответствуют последней версии операционной системы, но для работы с ALD Pro требуется переключить репозитории на frozen, чтобы гарантировать полную совместимость пакетов. Обязательными для версии ALD Pro 2.2.1 являются репозитории base и aldpro. В репозитории base продублированы репозитории main и update, поэтому можно указывать base вместо main и update. Пакеты из репозитория extended продублированы в репозитории aldpro, поэтому в данном случае репозиторий extended можно не указывать. Т.е. нужно указать репозитории или main + update + aldpro или base + aldpro.

sudo vim /etc/apt/sources.list - добавляем репозитории main и update или base.

Необходимо так же создать отдельный список для ALD Pro в файле /etc/apt/sources.list.d/aldpro.list командой:

sudo vim /etc/apt/sources.list.d/aldpro.list - добавляем репозиторий для установки пакетов самого ALD Pro.

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

sudo apt update - обновляем индексы пакетов

Обновление правильно делать в два шага. Сначала менять репозитории операционной системы и вызвать astra-update. Затем менять репозитории продукта и делать dist-upgrade. Операционная система и продукт используют разные стратегии обновления.

apt list --upgradable - посмотреть какие пакеты мы можем обновить

sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confnew - обновить пакеты

Ввод компьютера в домен ALD Pro

Для успешного ввода компьютера в домен требуется соблюдение нескольких условий:

У компьютера должно быть задано уникальное имя, которое еще не используется в домене
В качестве DNS-сервера должен быть указан IP адрес контроллера домена
Установлен пакет клиентского программного обеспечения aldpro-client

Проверка, что имя dc2 не используется в домене. В моем случае, имя компьютера будет dc2. Необходимо проверить уникальность имени в домене ald.local. Это можно сделать командой nslookup, которая входит в пакет dnsutil. Установим пакет dnsutils. Затем командой nslookup dc2 отправляем запрос в DNS сервер первичного контроллера домена. С помощью данной команды мы проверим, что хост с указанным именем не найден на DNS сервере:

sudo apt install dnsutils
nslookup dc2

Ответ, что запись в DNS не удалось найти:

Server: 10.0.2.7
Address: 10.0.2.7#53
** server can't find dc2: NXDOMAIN

Установка пакетов «ALD Pro» на резервный контроллер домена.

выполним команду:

sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -q aldpro-client

Если перезагружать пользовательский компьютер сейчас, то в сообщениях ядра можно будет увидеть ошибки запуска SSSD и зависящих от нее служб (журнал загрузки можно найти в файле /var/log/boot.log). Это происходит по причине того, что служба еще не настроена соответствующим образом (журнал службы sssd можно найти в файле /var/log/sssd/sssd.log).

При установке клиента в системе устанавливается более 130 зависимостей, отдельного внимания из которых заслуживают freeipa, sssd, krb5, ldap-utils, chrony, salt, zabbix-agent, syslog-ng и td-agent.

Ввод компьютера в домен под учетной записью администратора домена

set +o history
sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --domain ald.local --account admin --password 'P@ssw0rd' --host dc2 --gui --force
set -o history

domain - имя домена, которое вы выбрали, в моем случае - ald.local

account - логин администратора домена

password - пароль администратора домена

host - имя компьютера в нижнем регистре

gui - использовать интерактивный режим

force - продолжить ввод компьютера в домен, даже если в домене для его имени уже есть учетная запись. Требуется в тех случаях, когда администратор переустанавливает операционную систему и хочет ввести компьютер в домен с тем же именем.

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

Для применения всех настроек выполните перезагрузку компьютера:

sudo reboot

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

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

Продвижение компьютера до контроллера домена через портал управления

Перед добавлением резервного контроллера домена требуется проверить, что пользователь admin состоит в группе ald trust admin, это необходимо для корректной установки компонентов для работы контроллера в доверительных отношениях Microsoft AD DS.

Используемая учетная запись администратора должна обладать достаточными правами и входить в группу ald trust admin для установки компонентов, необходимых для использования доверительных отношений с Microsoft AD DS.

Добавляем admin в группу ald trust admin командой на контроллере домена dc1:

ipa group-add-member 'ald trust admin' --user admin

У меня пользователь уже был добавлен в эту группу ранее.

Продвижение резервного контроля осуществляется с портала управления на странице «Контроллеры домена» ( Управление доменом - Сайты и службы - Контроллеры домена ).

Нажмите кнопку «Новый контроллер домена», выберите из списка сервер dc2.ald.local и остальные параметры, как показано на рисунке ниже:

Результат выполнения задания по установке резервного контроллера можно посмотреть в разделе «Задания автоматизации» ( Автоматизация - Задания автоматизации ), идентификатор задания будет replica_install, как показано на рисунке ниже:

Процесс развертывания у меня занял примерно 30 минут, важно кол-во CPU.

Дополнительную информацию о процессе установке можно получить на dc2 в журналах /var/log/apt/term.log и /var/log/salt/minion или воспользоваться утилитой journalctl с параметром -f, которая позволяет получить информацию из systemd в режиме реального времени.

sudo journalctl-f

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

Проверка работы и настройка нового контроллера домена

После завершения задания, проверим, что получили билет Kerberos на dc2 под учетной записью admin:

klist

Получить билет можно командой kinit admin:

kinit admin

Проверим состояние служб ipa:

sudo ipactl status

Настройка файла /etc/resolv.conf.

Что бы DNS трафик не шел на первый котроллер домена, если с локальным сервером DNS все в порядке, добавим в начало файла /etc/resolv.conf строчку nameserver 127.0.0.1. Для этого мы должны предварительно убрать атрибут, запрещающий любое изменение файла /etc/resolv.conf, выполнив команду:

sudo chattr -i /etc/resolv.conf

vim /etc/resolv.conf

Отключение DNSSEC

Служба bind9 по умолчанию использует механизм DNSSEC для проверки ответов, но его лучше отключить, т. к. технология все еще не получила широкого распространения, и ошибки в настройках зон могут приводить к невозможности разрешения имен. Для этого в файле /etc/bind/ipa-options-ext.conf для параметра «dnssec-validation» рекомендуется задать значение «no». Сделать это можно командой:

sudo sed -i 's/dnssec-validation yes/dnssec-validation no/g' /etc/bind/ipa-options-ext.conf

Проверим, что настройки применились командой:

sudo grep "dnssec-validation" /etc/bind/ipa-options-ext.conf

Разрешение рекурсивных запросов и кеширования

Еще одной особенностью настроек bind9 по умолчанию является запрет на обработку рекурсивных DNS запросов от клиентов, находящихся за пределами той же подсети, в которой находится сам DNS-сервер. Сделано это для предотвращения DDoS-атак с DNS-усилением, но эта защита не актуальна для контроллеров домена, которые работают в закрытом периметре, поэтому в файле ipa-options-ext.conf рекомендуется задать также значение «any» для параметров «allow-recursion» и «allow-query-cache» или определить в файле /etc/bind/ipa-ext.conf список доверенных сетей.
Изменим настройки bind командой: