Freeipa настройка dns сервера

Обновлено: 04.07.2024

FreeIPA - это комплексное решение по управлению безопасностью Linux-систем, 389 Directory Server, MIT Kerberos, NTP, DNS, Dogtag. Оно состоит из веб-интерфейса и интерфейса командной строки.
FreeIPA является интегрированной системой проверки подлинности и авторизации в сетевой среде Linux, FreeIPA сервер обеспечивает централизованную проверку подлинности, авторизацию и контроль за аккаунтами пользователей сохраняя сведения о пользователе, группах, узлах и других объектах необходимых для обеспечения сетевой безопасности.

Содержание

Установим необходимые пакеты:

Зададим имя сервера:

Для ускорения установки можно установить демон энтропии haveged:

Запускаем скрипт настройки сервера:

В пакетном режиме:

Внимание! Пароли должны быть не менее 8 символов

Обратите внимание на ответы на вопросы, не совпадающие с предложенными:

остальные вопросы выбираем по умолчанию (можно просто нажать Enter). Так же при установке попросят ввести пароль администратора системы и пароль администратора каталогов.

Для возможности управлять FreeIPA сервером из командной строки необходимо получить билет Kerberos:

Добавим в DNS запись о нашем сервере времени:

Проверить работу ntp сервера можно командой:

Также доступен веб-интерфейс по адресу:

и повторите снова.

CA-Less конфигурация требуется в тех случаях, когда у вас по какой-то причине нет возможности развернуть на FreeIPA сервис PKI dogtag. Например, это на данный момент невозможно сделать в некоторых сертифицированных конфигурациях. Если у вас не сертифицированный дистрибутив ALT, то пропустите пункт по настройке CA-Less репликации.

Установим необходимые пакеты:

Зададим имя сервера:

Подготовим сертификаты для сервера FreeIPA:

Создадим файл pwdfiles.txt с паролем, например 12345678:

Создадим базу данных NSS:

Создадим noise файл с рандомом:

Создаем CA сертификат:

Дайте следующие ответы:

Создадим запрос сертификата:

Подпишите запрос о выдаче сертификата сервера:

Дайте следующие ответы:

Экспорт сертификатов в правильные форматы. Импортируем полученный сертификат:

Экспортируйте сертификат CA в формате PEM:

Теперь установим CA-less IPA:

Вы также можете указать при установке опции --pkinit-cert-file=Файл, содержащий сертификат SSL Kerberos KDC и закрытый ключ и --pkinit-pin=Пароль от закрытого ключа Kerberos KDC.

После установки выполните:

И после убедитесь что команды:

Не срабатывают и выводят ошибки.

Внимание! Перед настройкой репликации необходимо выполнить установку клиента

Чтобы установить реплику, сначала создайте сертификаты для новой машины: создадим запрос сертификата и подпишем запрос о выдаче сертификата сервера и экспортируем сертификаты в правильные форматы, на этот раз задав $HOSTNAME имя хоста будущей реплики. Используйте Replica-Cert вместо Server-Cert и

/test_ca/servercert.p12: Создадим запрос сертификата для реплики:

Подпишите запрос о выдаче сертификата реплики:

Дайте следующие ответы:

Экспорт сертификатов в правильные форматы.

Импортируем полученный сертификат:

Для domain-level 1

Установим необходимые пакеты:

Зададим имя компьютера:

Добавим DNS сервер, для этого создадим файл /etc/net/ifaces/ens19/resolv.conf со следующим содержимым:

192.168.135.1 - IP-адрес нашего FreeIPA сервера.
Укажем службе resolvconf использовать DNS FreeIPA и наш домен для поиска.
Для этого в файл /etc/resolvconf.conf добавим/отредактируем следующие параметры:

Где ens19 -интерфейс на котором доступен FreeIPA сервер, example.test - наш домен.
Обновим DNS адреса:

После этого в файле /etc/resolv.conf должны появится строки:

Запускаем скрипт настройки клиента: в пакетном режиме:

Отвечаем yes вводим имя пользователя, имеющего право вводить машины в домен, и его пароль.

Пример успешного ввода в домен:

Внимание! Если при входе в домен возникает такая ошибка: Проверьте IP-адрес доменного DNS сервера в файле /etc/resolv.conf

В случае возникновения ошибки, необходимо перед повторной установкой запустить процедуру удаления:

Для работы sudo-политик для доменных пользователей на клиентской машине необходимо разрешить доступ к sudo:

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

Внимание! Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:

Добавим сервис в автозапуск:

Добавим список экспорта и применим изменения:

Добавить ipa сервис где nfs.testbc.testbe наш nfs сервер:

Добавляем в keytab:

Перезапустим nfs сервер:

Добавим правила автомонтирования:

Удалим пустую карту монтирования:

Настройка клиента: ipa-client-install Устанавливаем пакет freeipa-client-automount:

Проверим доступность nfs:

На IPA сервере: Создадим пользователя:

Предоставим пользователю права на запись:

Создадим домашнюю папку пользователя на nfs сервере:

Добавим правила автомонтирования:

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

Для отладки используйте:

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

Зададим имя сервера:

Теперь развернём и настроим клиента:

После выполнения этой операции хост ipabackup.example.test должен появиться в веб-интерфейсе FreeIPA. Переходим к настройке репликации LDAP-каталога:

Добавляем в DNS второй NTP-сервер:

Настроим репликацию DNS-зон:

Наконец, настроим репликацию CA:

После настройки и репликации контроллеров посмотреть топологию можно в веб-интерфейсе FreeIPA (IPA Server -> Topology -> Topology Graph).

FreeIPA использует Samba для интеграции в Active Directory. Для работы Samba необходим работающий стек IPv6.
Начальные данные:

IP адрес IPA сервера: 192.168.135.130
Имя IPA сервера: dcf
Имя IPA домена: domf.testf
NetBIOS имя IPA домена: DOMF
IP адрес AD DC: 192.168.135.150
Имя AD DC: dcc
Имя AD домена: domc.testc
NetBIOS имя AD домена: DOMC

Установим необходимые пакеты:

Настроим IPA для работы с доверительными отношениями:

Скрипт спросит необходимо ли конфигурировать slapi-nis плагин для поддержки работы старых клиентов (SSSD < 1.9) с пользователем из доверенного домена:

На IPA сервере добавлен хотя бы один пользователь (администратор сервера), поэтому скрипт предложит сгенерировать SID для всех существующих пользователей и груп:

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

Они должны быть открыты и доступны.
Настроим Samba:

Проверим проходит ли Samba аутентификацию Kerberos со стороны IPA сервера:

Настроим DNS на обоих серверах, чтобы они знали друг о друге:
На AD сервере создадим сервер условной пересылки для зоны IPA домена:

На IPA сервере так же добавим зону AD домена:

На AD сервере:
Проверим наличие записей для работы сервисов IPA на DNS-сервере AD.
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:

2. Запись отвечающая за имя Kerberos realm IPA домена:

3. После выполнения команды ipa-adtrust-install должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP:

Далее проверим наличие записей для работы сервисов AD на DNS-сервере AD.
4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:

На IPA сервере:
Проверим наличие записей для работы сервисов IPA на DNS-сервере IPA.
1. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:

2. Запись отвечающая за имя Kerberos realm IPA домена:

Далее проверим наличие записей для работы сервисов AD на DNS-сервере IPA. 4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:

Внимание! Если запись _kerberos._udp.dc._msdcs.domc.testc. не доступна проверьте _kerberos._tcp.dc._msdcs.domc.testc.

Добавление двунаправленных доверительных отношений леса (Forest Trust) с AD:
Имя доменного администратора Windows должно быть на латинице, кириллицу (Администратор) IPA не принимает.

Необходимо ввести пароль Administrator AD.
Далее необходимо запросить сервер AD о его доверенных доменах:

При этом IPA создаст нужные id-диапазоны для доверенных доменов.
Если мы добавим в лес еще один домен DOME.TESTE, то необходимо настроить DNS на обоих серверах, чтобы они видели друг друга.
И выполнить команду еще раз,чтобы IPA сервер узнал о нем:

Найти все доверенные домены можно и с помощью web-интерфейса. Для Перейдем в IPA Server -> Trusts и выберем нужный нам домен:

Нажмём кнопку Fetch domains это обновит список доверенных доменов:

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

1. Запросим ticket для IPA пользователя:

2. Запросим service ticket для сервиса из IPA домена:

3. Запросим service ticket сервиса из AD домена:

Если запрос service ticket для сервиса из AD домена прошел успешно, то у нас должен появиться междоменный ticket-granting ticket, его имя krbtgt/DOMC.TESTC@DOMF.TESTF:

Проверим имеет ли доступ к пользователям из доверенного домена рабочие станции IPA.
Для этого на рабочей станции IPA выполните команду:

Где u01domc это пользователь из AD домена. Обратите внимание, что не указана оболочка входа. Назначить оболочку входа для пользователей из доверенного домена можно добавив на сервере IPA в файл /etc/sssd/sssd.conf следующую строчку:

Вывод команды должен стать таким:

Внимание! Для корректной работы сервера IPA с пользователями доверенного домена AD необходимо обеспечить доступ сервиса sssd к /etc/krb5.keytab см. bug 33115 Внимание! Для входа AD пользователя в ALT рабочую станцию из IPA вводим имя пользователя в формате DOMC\username или DOMC.TESTC\username или username@domc username@domc.testc Внимание! Для входа IPA пользователя в windows рабочую станцию из AD вводим имя пользователя в формате DOMF.TESTF\username

Замените пароль на более сложный. Параметр passwordExpirationTime: 20380119031407Z означает, что срок действия пароля неограничен Причина использования такой учетной записи, а не создание обычной учетной записи пользователя IPA, и использование этой системы заключается в том, что системная учетная запись существует только для привязки к LDAP. Это не настоящий пользователь POSIX, он не может войти в систему и ему не принадлежат файлы. У этого пользователя нет особых прав и он не может ничего записывать какие-либо данные на сервер LDAP FreeIPA, только права на чтение.

Если необходимо добавить поля в вашу схему ldap, то реализация этого возможна через команду ldapmodify и добавление своих плагинов для отображения этих полей в WebUi.
Обычно файлы модификации схемы являются типом .ldif.
Пример:
Содержание файла addExtField.ldif

Детальное пояснение для блока:

dn - dn, в котором будет проводиться изменение. Добавление/удаление классов и т.д.

changetype - атрибут, отвечающий за тип изменений, которые будут происходить.(add, delete, modify, modrdn)

add: attributeTypes - добавление атрибута, далее идёт описание атрибута.
2.25.28639311321113238241701611583088740684.14.2.2 - уникальный идентификатор атрибута. Можно написать любой.

NAME 'favoriteColorName' - По другому можно назвать - primary name. Название атрибута.

EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch - эти атрибуты заданы для проверки соответствия содержания атрибута правилам caseIgnoreMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 - OID типа данных

Все изменения в схеме производятся от пользователя - Directory manager.

Изменение схемы ldap:

После изменения схемы, путем добавления нового objectclass, нужно чтобы эти поля еще можно было редактировать в web-интерфейсе. Для этого необходимо сделать палагин. В примере использовано 3 атрибута, для них сделаем 3 отдельных плагина:

1. Создание папки:

2. Создание самого плагина:

В схеме бы добавлен атрибут типа boolean, для него можно сделать радиокнопки:

После необходимо добавить новое поле в "Default user objectclasses" (находится IPA Server -> Configuration) созданный objectclass (customPerson) и появятся поля в web-интерфейсе. Для того чтобы пользователь мог их редактировать, необходимо изменить привилегии в группе ipausers.

Сервер №1 c freeipa: dc1.testbc.testgl

Сервер №2 с репликой freeipa: dc2.testbc.testgl

Сервер №3 с haproxy: haproxy.testbc.testgl

Инструкция для настройки сервера №1 и №2: FreeIPA

Сохранить оригинальный конфигурационный файл:

Запустить сервис haproxy:

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

Результат: ldap всегда доступен.

Пользовательские или хост группы можно легко перестроить на основе новых или обновленных правил automember. Команда automember rebuild только добавляет новые отношения для групп, она не удаляет те, которые не соответствуют правилам automember. Недавно добавленная команда вызовет задачу в rebuild automember, создав запись LDAP в cn = automember rebuild membership, cn = tasks, cn = config. Плагин automember в настоящее время проверяет операции Add(добавления), чтобы увидеть, есть ли запись соответствует одному из определенных правил automember. Существующие записи не проверяются когда они изменяются. Чтобы применить правило для всех записей, надо добавить задачу к плагину automember. Создатель задачи обеспечит фильтр поиска и базу. Все совпадающие записи будут проверяться в соответствии с определенными правилами automember, чтобы увидеть если они должны быть добавлены в какие-либо группы. Это позволяет добавить запуск атрибуты(значения) после того, как запись была первоначально добавлена, а затем вызвать задачу(выполнить) обновления automember. Ipa automember-rebuild может использоваться для восстановления членства для всех объектов определенного типа:

Он также может использоваться для восстановления членства для указанных записей:

Добавление новой группы хостов:

Добавить новый хост:

Добавить automember rule:

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

Мы добавим второй сервер FreeIPA и настроим репликацию с первым. Предполагается, что у нас уже есть сам сервер — в противном случае, нужно сначала выполнить действия из инструкции Установка и использование FreeIPA на CentOS.

Процедура выполняется по следующему плану:

Подключение вторичного сервера к FreeIPA в качестве клиента.
Изменение принадлежности к группе для узла вторичного сервера.
Настройка репликации.

Наша инструкция подойдет для Rocky Linux или CentOS 7.

Подготовка вторичного сервера

Для работы FreeIPA принципиально важны правильные настройки времени, DNS и брандмауэра.

Клиентские компьютеры (а первое, что мы делаем, это настраиваем наш вторичный сервер в качестве клиента FreeIPA) должны быть настроены на использование DNS-сервера, который мы сконфигурировали на сервере FreeIPA во время его установки. В сетевых настройках указываем использовать наш сервер ipa для разрешения имен:

Пример настройки сети в CentOS / Rocky Linux
Настройка сети с помощью netplan (Debian, Ubuntu).
В устаревающих системах на основе deb настройка выполняется в файле /etc/network/interfaces (опция dns-nameservers) или /etc/resolv.conf (опция nameserver).

После внесения изменений мы должны перезагрузить сетевые службы и, желательно, убедиться, что используется нужный DNS-сервер (с помощью команды nslookup или dig).

Время

Установим часовой пояс:

timedatectl set-timezone Europe/Moscow

* в данном примере используется московское время.

Затем устанавливаем и запускаем утилиту для синхронизации времени chrony.

yum install chrony

systemctl enable chronyd --now

Имя сервера

Для корректной работы вторичного сервера, необходимо, задать ему полное доменное имя (FQDN). Выполняем команду:

hostnamectl set-hostname ipa-server-2.dmosk.local

* где ipa-server-2.dmosk.local — имя сервера, которое будет использоваться.

Брандмауэр

Необходимо открыть несколько портов, которые используются службами FreeIPA:

firewall-cmd --permanent --add-port=53/ --add-port=/tcp --add-port=/ --add-port=123/udp --add-port=/tcp

SELinux

Отключаем SELinux командами:

Установка FreeIPA и подключение к основному серверу

Устанавливаем freeipa-server. Команды немного отличаются в зависимости от версии CentOS.

а) для Rocky Linux / CentOS 8:

dnf install @idm:DL1

yum install ipa-server ipa-server-dns

* предполагается, что мы будем реплицировать данные каталога + DNS, поэтому мы установим также пакет ipa-server-dns.

После установки пакетов ipa-server и ipa-server-dns можно переходить к подключению к основному серверу.

Выполним конфигурирование клиента командой:

ipa-client-install --mkhomedir --domain=dmosk.local --realm=DMOSK.LOCAL --server=ipa-server.dmosk.local

Если в нашей сети всего один FreeIPA, система предупредит, что автообнаружение серверов для аварийного переключения не может работать. Соглашаемся и отвечаем yes:

If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes

Система отобразить настройки LDAP в консоли, например:

Client hostname: ipa-server-2.dmosk.local
Realm: DMOSK.LOCAL
DNS Domain: DMOSK.LOCAL
IPA Server: ipa-server.dmosk.local
BaseDN: dc=dmosk,dc=local

Если эти настройки верны, отвечаем положительно на запрос Continue to configure the system with these values?

Continue to configure the system with these values? [no]: yes

Система спросит, от какого пользователя производить настройку — вводим admin:

User authorized to enroll computers: admin

Password for admin@DMOSK.LOCAL:

Начнется процесс конфигурации — после его завершения:

.
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring DMOSK.LOCAL as NIS domain.
Client configuration complete.
The ipa-client-install command was successful

. сразу проверим, что клиент может получать билет от сервера:

. и вводим пароль от пользователя admin.

Проверяем, что билет получен:

Ответ должен быть, примерно, следующим:

Ticket cache: KCM:0
Default principal: admin@DMOSK.LOCAL

Valid starting Expires Service principal
09/20/2021 16:23:05 09/21/2021 15:25:28 krbtgt/DMOSK.LOCAL@DMOSK.LOCAL

Клиент настроен. Удаляем полученный билет:

И переходим к добавлению нового узла в группу серверов IPA.

Настройка на сервере FreeIPA

На стороне сервера IPA нам необходимо добавить узел для нашего вторичного сервера в группу ipaservers. Это можно сделать в веб-интерфейсе (раздел Идентификация - Группы - Группы узлов). Но мы рассмотрим пример для работы из командной строки.

Авторизовываемся в консоли от администратора:

Добавляем наш хост в группу ipaservers:

ipa hostgroup-add-member ipaservers --hosts ipa-server-2.dmosk.local

Мы должны увидеть что-то на подобие:

Host-group: ipaservers
Description: IPA server hosts
Member hosts: ipa-server.dmosk.local, ipa-server-2.dmosk.local
-------------------------
Number of members added 1

Теперь можно переходить к настройке репликации.

Настройка репликации

Репликация будет настраиваться в несколько шагов:

Настройка DNS для корректного разрешения имен в момент конфигурирования реплики.
Настройка репликации каталога.
Репликация центра сертификации.

Рассмотрим их выполнение подробнее.

1. Добавление записей в DNS

На сервере создаем запись PTR в обратной зоне DNS. Это можно сделать через веб-интерфейс в разделе Сетевые службы - DNS - Зоны DNS.

А также, в момент установки у нас еще нет корректно работающей DNS на вторичном узле, но система может требовать разрешения имени хоста — добавим нужную запись в hosts:

.
192.168.0.15 ipa-server.dmosk.local
192.168.0.16 ipa-server-2.dmosk.local

* предполагается, что у нас хост ipa-server с адресом 192.168.0.15 и ipa-server-2 с 192.168.0.16.

2. Репликация каталога

ipa-replica-install --setup-dns --no-forwarders

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

Lookup failed: Preferred host ipa-server-2.dmosk.local does not provide DNS.
Reverse DNS resolution of address 192.168.0.16 (ipa-server-2.dmosk.local) failed. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.)
Continue? [no]: yes

. либо возвращаемся к вопросу добавления записи PTR — возможно, была допущена ошибка.

Ждем — в конечном итоге мы увидим:

.
The ipa-replica-install command was successful

3. Установка ipa-ca

После настройки репликации мы увидим предупреждение:

WARNING: The CA service is only installed on one server (ipa-server.dmosk.local).
It is strongly recommended to install it on another server.
Run ipa-ca-install(1) on another master to accomplish this.

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

Дожидаемся ее выполнения. Мы должны увидеть:

.
Done configuring certificate server (pki-tomcatd).
Updating DNS system records

После настройки репликации

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

Рассмотрим процесс подробнее.

1. Проверка работы DNS.

С любого компьютера в сети выполняем dns-запрос к новому серверу, например:

nslookup ipa-server.dmosk.local 192.168.0.16

* в данном примере мы делаем запрос адреса для первичного сервера через DNS вторичного.

Система должна вернуть ответ на подобие:

Name: ipa-server.dmosk.local
Address: 192.168.0.15

2. Проверяем состояние работы контроллеров.

Для этого есть утилита ipa-healthcheck. Ставим ее командой:

yum install ipa-healthcheck

Для общего анализа вводим:

Для проверки репликации:

ipa-healthcheck --source ipahealthcheck.ds.replication --failures-only

3. Смена DNS.

И так, у нас дополнительный сервер IPA и DNS. Стоит добавить вторичный сервер, как альтернативный DNS на серверах и клиентах.

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

Примеры настроек сети для различных систем:

Debian, Ubuntu с помощью netplan.
В устаревающих системах на основе deb настройка выполняется в файле /etc/network/interfaces (опция dns-nameservers) или /etc/resolv.conf (опция nameserver).

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

Возможные ошибки

Рассмотрим некоторые ошибки, с которыми сталкивался я при работе с репликой FreeIPA.

No DNA range defined

С данной ошибкой мы, скорее всего, столкнемся при проверке ipa-healthcheck на вторичном сервере. Полный текст:

. No DNA range defined. If no masters define a range then users and groups cannot be created.

Причина: данное предупреждение нам говорит о том, что на вторичном сервере не задан диапазон DNA, который определяет начальный и конечный идентификаторы создаваемых объектов (UIDs). Таким образом, вторичный сервер не сможет использоваться для создания новых объектов.

Решение: задаем данный диапазон. Это можно сделать с мастера.

Она нам покажет, какие на данный момент заданы диапазоны, например:

ipa-server.dmosk.local: 849400000-849599999
ipa-server-2.dmosk.local: No range set

* как видим, для нашего нового сервера ipa-server-2.dmosk.local диапазон не задан.

Посмотреть начальное значение и максимальное для количества идентификатором можно командой:

Разбиваем наш диапазон на два:

ipa-replica-manage dnarange-set ipa-server.dmosk.local 849400000-849499999

ipa-replica-manage dnarange-set ipa-server-2.dmosk.local 849500000-849599999

Готово — теперь оба наших сервера могут выдавать идентификаторы для объектов.

PKINIT certificate request failed

Ошибка появляется в момент настройки CA на реплике на одном из этапов команды ipa-ca-install. Полный текст:

При этом, сама настройка CA отрабатываем корректно.

Для решения выполним команду, которую нам рекомендует мастер настройки:

Удаление узла

Если у нас появилась необходимость удалить один из серверов FreeIPA, мы должны удалить настройку реплики и после уже можно удалять саму роль FreeIPA.

Список текущих серверов можно посмотреть командой:

Для удаления реплики вводим (на любом хосте FreeIPA):

ipa-replica-manage del ipa-server.dmosk.local

* указываем, что мы отключаем реплику для сервера ipa-server.dmosk.local.

Теперь удаляем настройку для FreeIPA (на хосте, который нужно удалить):

ipa-server-install --uninstall -U

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

Дополнительные настройки

Рассмотрим настройки, которые не являются обязательными, но могут оказаться полезными.

Создание SRV для сервиса синхронизации времени

Данная запись не является обязательной и не создается по умолчанию ни при поднятии мастера, ни при настройке реплики. Давайте это исправим:

ipa dnsrecord-add dmosk.local _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa-server.dmosk.local.

ipa dnsrecord-add dmosk.local _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa-server-2.dmosk.local.

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

Смена диапазона идентификаторов

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

Сменить настройки диапазона нельзя — система выдаст ошибку. Но мы можем создать новый диапазон и использовать его.

ipa idrange-add "New Range" --base-id=50000 --range-size=20000

* в данном примере мы создаем диапазон с названием New Range, первый идентификатор равен 50000, всего идентификаторов 20000.

Теперь мы можем назначить значения из нового диапазона для наших серверов:

ipa-replica-manage dnarange-set ipa-server.dmosk.local 50000-59999

ipa-replica-manage dnarange-set ipa-server-2.dmosk.local 60000-69999

Смена CRL generation master

Для инфраструктуры FreeIPA характерно использование только одного мастера по отзыву сертификатов (Certificate Revocation List). Проверить статус работы сервиса можно командой:

CRL generation: enabled

. то данный сервер является мастером.

Если мы хотим перенести данную роль на другой сервер, то сначала мы отключаем crlgen на текущем сервере:

Продолжаем тему импортозамещения в IT. Актуально не только для гос. учреждений, но и для тех организаций которые считают что цены на MS Windows неадекватно завышены, а функционал для их задач избыточен. Здесь и приходит на помощь сообщество свободного программного обеспечения.

Ранее речь шла о замене MS Active Directory на свободный аналог Samba DC. Это решение почти полностью заменяет (с некоторыми ограничениями) MS AD. Хорошо работает, если в сети остаются много ПК под управлением Windows. Но как и MS AD практически не работает с клиентами Unix (Linux). Если стоит задача полностью в сети избавиться от Microsoft, то одно из решений использовать сервер идентификации и авторизации FreeIPA.

Все работы будут производится на ОС Rosa Cobalt (он же CentOS 7, он же RedHat 7)

В данном примере мы рассмотрим конфигурацию из трех серверов IPA (два в центральном офисе и один в удаленном). А также создадим доверительные отношения между доменом IPA и доменом MS Active Directory.

dc01.rpn.loc - первый сервер в корневом домене
Имя сервера - dc01
FQDN - dc01.rpn.loc
IP - 192.168.20.105
Домен IPA (REALM)- RPN.LOC
dc02.rpn.loc - второй сервер в корневом домене
Имя сервера - dc02
FQDN - dc02.rpn.loc
IP - 192.168.20.106
Домен IPA (REALM)- RPN.LOC
dc.01.rpn.loc - сервер в удаленном офисе
Имя сервера - dc
FQDN - dc.01.rpn.loc
IP - 192.168.20.107
Домен IPA (REALM)- RPN.LOC
addc.win.loc - контроллер домена Active Directory в центральном офисе
Имя сервера - addc
FQDN - adsc.win.loc
IP - 192.168.20.108
Домен AD (REALM)- WIN.LOC

Важно. В общем случае имя DNS домена и REALM в домене IPA могут быть различными. Но в этом случае невозможно будет настроить доверительные отношения между IPA и MS Active Directory (более подробно об этом речь пойдет ниже). Нам же нужно будет затем настроить доверительные отношения между доменами. Поэтому имена доменов (DNS и REALM) мы делаем одинаковыми.

Первый сервер FreeIPA

Устанавливаем ОС в режиме минимальной установки
Подключаем необходимые репозитарии (на Rosa Cobalt правим файл /etc/yum.repos.d/rels.repo , на CentOS подключаем репозитарий EPEL )
В CentOS 8 (RH 8) включаем необходимые компоненты:
Обновляем систему.
Если в локальной сети не используется ipv6, то отключаем его.
Добавляем в файл /etc/hosts данные нашего сервера:
Устанавливаем необходимые пакеты: Все зависимые пакеты установятся автоматически.
Небольшая хитрость (глюк), касающаяся CentOS 8.
По умолчанию устанавливаются (на момент написания статьи) FreeIPA Server 4.8.0-13 и Samba 4.10.
Но если в дальнейшем планируется использовать доверительные отношения с доменом Active Directory, то в данной связке ничего не получиться. Дело в том, что в составе FreeIPA Server идет модуль, заточенный для работы с Samba 4.9.1 и Samba в составе FreeIPA просто не может стартовать. Поэтому сразу откатываем версию самбы до 4.9.1:
Замыкаем запросы DNS на этот же сервер. Приводим файл /etc/resolv.conf к виду:
Открываем в файерволе необходимые порты:
На всякий случай в файл /etc/named.conf вносим изменения: " dnssec-validation no " необходимо, что бы заработал форвардинг на внешний DNS. Если внешний DNS поддерживает dnssec, то можно ничего не менять.
Запускаем DNS сервер
Запускаем установку сервера IPA:

Устанавливаем сервер репликации FreeIPA

Выполняем шаги 1-10 раздела "Первый сервер FreeIPA" с поправками на новое имя сервера и IP адрес. В настройках сервера DNS указываем адрес первого сервера FreeIPA
В файл /etc/hosts кроме устанавливаемого сервера вносим так же данные нашего первого сервера FreeIPA
Файл /etc/resolv.conf оставляем без изменений (указываем в качестве DNS сервера установленный первый сервер FreeIPA).
Файл /etc/named.conf оставляем без изменений.
Для установки сервера репликации в первую очередь устанавливаем ipa клиент: После выполнения этой операции хост dc02.rpn.loc должен появиться в веб-интерфейсе FreeIPA. Переходим к настройке репликации LDAP-каталога.
Останавливаем и запрещаем автозапуск сервера chronyd:
Вносим в файл /etc/ntp.conf данные нашего первого контроллера: Остальные сервера точного времени запрещаем.
Запускаем ntpd и разрешаем его автозапуск:
После этого выполняем собственно установку репликации LDAP-каталога:
Добавляем в DNS второй NTP сервер:
Устанавливаем репликацию DNS зон:
После окончания установки перезагружаем сервер
Устанавливаем репликацию CA:
Исправляем файл /etc/ntp.conf (убираем левые сервера времени и назначаем наш первый контроллер в качестве единственного сервера времени)
Если что-то пошло не так, то выполняем: Устраняем ошибки и повторяем все начиная с п.5
После настройки и репликации контроллеров посмотреть топологию можно в веб-интерфейсе FreeIPA (IPA Server -> Topology -> Topology Graph).

Установка сервера FreeIPA в филиале.

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

Домен Active Directory - сложная система. Он включает в себя логически структурированный набор ресурсов (машины, пользователи, службы и т. Д.), Которые принадлежат потенциально нескольким доменам DNS. Несколько доменов DNS могут быть частью одного домена AD (где домен AD по определению совпадает с областью AD Kerberos). Несколько доменов AD можно объединить в лес. Самый первый домен AD, созданный в лесу, называется корневым доменом леса . Верхнее имя основного домена DNS домена AD используется как имя домена Kerberos AD.

Домен IPA представляет собой сложную систему. Он включает в себя логически структурированный набор ресурсов (машины, пользователи, службы и т.д.), Которые принадлежат потенциально нескольким доменам DNS. В отличие от Active Directory у нас есть один домен / область IPA для развертывания, а для Active Directory этот единственный домен IPA выглядит как отдельный лес Active Directory. Active Directory считает основной домен DNS, используемый в качестве основы для области Kerberos FreeIPA, как корневой домен леса для домена FreeIPA (например, корневой домен леса для Active Directory).

Когда вы устанавливаете первый сервер FreeIPA, вы всегда определяете имя области Kerberos для этой установки. При выборе названия области выполните следующие правила:

Серверы и клиенты FreeIPA могут распространяться в разных географических точках. Механизм местоположения DNS позволяет разделить топологию на отдельные области, называемые местоположениями (отображение в географические области). Клиенты, использующие записи DNS SRV (например, SSSD) в определенном месте, затем используют серверы из того же места, что и первые (ближайшие серверы FreeIPA), и серверы из разных мест в качестве резервной копии (удаленные серверы FreeIPA).

При планировании развертывания важно иметь в виду, что функции DNS в FreeIPA требуют, по крайней мере, одного DNS-сервера в каждом месте.

FreeIPA работает в реплицированной среде с несколькими мастер-серверами. Количество серверов зависит от нескольких факторов:

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

Как правило, рекомендуется иметь по меньшей мере 2-3 реплики в каждом центре обработки данных. В каждом центре обработки данных должна быть по крайней мере одна реплика с дополнительными услугами FreeIPA, такими как PKI или DNS, если они используются. Обратите внимание, что не рекомендуется иметь более 4 соглашений о репликации на каждую реплику. В следующем примере показана рекомендуемая инфраструктура:

Можно приступить к установки сервера в филиале.

В оснастке управления FreeIPA создаем два новых местоположения (Сервера IPA -> IPA Locations): "centr" и "filial01"
Заходим в созданный "centr" и добавляем два установленных ранее сервера FreeIPA.
Высветится предупреждение, что необходимо перестартовать добавленные сервера. Выполняем поочередно на каждом из серверов:
Сервер в филиале будет принадлежать DNS зоне (субдомену)"01.rpn,loc". В оснастке управления DNS сервером создаем новую зону "01.rpn.loc"
В настройках зоны параметр "Динамическое обновление" переключаем на значение "Верно". Ставим галочку в параметре "разрешить синхронизацию PTR". Нажимаем "Сохранить".
В зоне " rpn.loc " создаем запись типа "A", соответствующую нашему серверу в филиале (dc.01.rpn.loc с ip адресом 192.168.20.107) (т.е. необходимо добавить запись с именем " dc.01 ")
Повторяем шаги с 1 по 14 раздела "Устанавливаем сервер репликации FreeIPA".
Назначаем серверу в филиале местоположение "filial01"
Добавляем репликацию на второй сервер центрального офиса: Этим мы создаем репликацию LDAP между серверами dc02.rpn.loc и dc.01.rpn.loc
То же самое проводим для CA (имя суффикса вводим "CA")
Более наглядно и может быть быстрее можно сделать в вэб-интерфейсе управления FreeIPA (Сервер IPA -> Topology Graph)

Установка клиента FreeIPA на рабочую станцию и подключение к серверу.

Работы будут проводится на рабочей станции ROSA Cobalt WS. На CentOS и RedHat действия аналогичные.

Рабочая станция будет находится в филиале и принадлежать домену 01.centr.rpn.

Устанавливаем имя компьютера:
Настраиваем DNS на сервер в этом домене (dc.01.rpn.loc)
Устанавливаем необходимые пакеты:
Останавливаем и запрещаем автозапуск сервиса chronyd.
Запускаем установку клиента:
После этого можно входить на компьютер под учетной записью пользователя FreeIPA.
Если машина до этого была в других доменах или есть проблемы со входом пользователей рекомендуется очистить кэш sssd:

Создание доверительных отношений с MS ActiveDirectory

Сервер IPA:
Имя сервера: dc01.rpn.loc
IP адрес: 192.168.20.105
Домен IPA: rpn.loc
Realm: RPN.LOC
Сервер AD:
Имя сервера: addc.win.loc
IP адрес: 192.168.20.2
Домен AD: win.loc

Настраиваем доверительные отношения.

Настраиваем DNS на обоих серверах, для того что бы они знали друг о друге:
- На сервере IPA:
  - В параметрах зоны "rpn.loc" добавляем адрес DNS сервера AD (192.168.20.2)
  - Создаем зону перенаправления DNS "win.loc". В Параметре "Перенаправление зон" указываем адрес DNS сервера AD
- На сервере АД:
  - В свойствах зоны "win.loc" переходим на вкладку "Передача зон" и либо разрешаем передачу зон на любой сервер, либо указываем IP адрес сервера IPA
  - В разделе "Сервер условной пересылки" создаем новый сервер. В поле DNS-домен вводим домен IPA сервера (rpn.loc). В поле IP адреса вводим адрес сервера IPA.
Небольшое отступление в теорию. На практике встречается достаточно редко, но упомянуть об этом стоит.
Если AD являетя поддоменом IPA (т.е. AD домен - addomain.ipadomain.example.com , IPA домен - ipadomain.example.com )
В этом случае на IPA сервере необходимо добавить записи A и NS для AD домена: В домене AD можно использовать один из двух способов.
Первый: настраивается глобальная переадресация для пересылки DNS запросов в домен IPA: Второй: настроить зону DNS для репликации master-slave. Затем данные для этой зоны будут периодически копироваться с главного (сервера IPA) на подчиненный (сервер AD).
Для этого сначала явно разрешите передачу зоны на сервере IPA: Затем добавляем DNS зону IPA в домен AD: Следующий экзотический вариант: домен IPA является субдоменом AD (домен IPA - ipadomain.addomain.example.com , домен AD - addomain.example.com )
В этом случае домене AD необходимо добавить записи A и NS для домена IPA:
Настраиваем сервер IPA: Скрипт спросит необходимо ли настраивать slapi-nis плагин для поддержки работы старых клиентов (SSSD < 1.9) с пользователем из доверенного домена: Отвечаем YES
На IPA сервере добавлен хотя бы один пользователь (администратор сервера), поэтому скрипт предложит сгенерировать SID для всех существующих пользователей и групп: Отвечаем YES
Настраиваем Samba на сервере IPA: Проверим проходит ли Samba аутентификацию Kerberos со стороны IPA сервера:
Проверка конфигурации DNS:
- На сервере Active Directory:
  Проверим наличие записей для работы сервисов IPA на DNS-сервере AD.
  Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP: Запись отвечающая за имя Kerberos realm IPA домена: После выполнения команды ipa-adtrust-install должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP: Далее проверим наличие записей для работы сервисов AD на DNS-сервере AD.
  Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:
- На сервере IPA
  Проверим наличие записей для работы сервисов IPA на DNS-сервере IPA.
  Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP: Запись отвечающая за имя Kerberos realm IPA домена: После выполнения команды ipa-adtrust-install должны появится записи отвечающие за работу сервисов MS DC Kerberos через UDP и LDAP через TCP: Далее проверим наличие записей для работы сервисов AD на DNS-сервере IPA. 4. Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP: Внимание! Если запись _kerberos._udp.dc._msdcs.source-win.loc. не доступна проверьте _kerberos._tcp.dc._msdcs.source-win.loc.
Добавление двунаправленных доверительных отношений леса (Forest Trust) с AD:
- Если мы имеем пароль администратора домена Active Directory: Будет выдан запрос пароля администратора домена Active Directory после чего установятся доверительные отношения между доменами.
  По умолчанию устанавливается одностороннее доверие. Для установления двухстороннего доверия необходимо добавить параметр"--two-way=true"
  В документации сказано, что устанавливаются двух сторонние отношения между доменами. Но таким способом почему то мне их установить не удалось на ОС "ROSA Cobalt". Постоянно операция завершалась словами "Внутренняя ошибка" без всяких коментариев (на CentOS доверия установились без каких-либо проблем). Пришлось пойти немного другим путем. Выполняем команду: Важно заметить , что в этом случае устанавливаются доверительные отношения типа "внешние не транзетивные" Транзетивное доверие типа "лес" мне таким способом установить не удалось.

Создаем внешнюю группу в IPA для доверенного домена:
Создаем POSIX группу для внешней группы ad_admins_external
Добавляем пользователей из доверенного домена во внешнюю группу: При запросе членов группы оставляем пустой ответ и нажимаем Enter
ПРИМЕЧАНИЕ. Поскольку аргументы в приведенной выше команде содержат обратную косую черту, пробелы и т. д., обязательно нужно использовать кавычки (').
Добавляем внешнюю группу в POSIX группу:

Создание аккаунта для доступа к LDAP

Некоторые сервисы использующие LDAP требуют предварительно настроенной учетной записи. Использование обычной учетной записи пользователя предпочтительней, но не всегда это целесообразно делать. Можно сделать системную учетную запись следующим образом на сервере FreeIPA используя пароль Directory :

Привет, меня зовут Денис, и я около двух лет работаю DevOps инженером в компании Altenar. Наша инфраструктура располагается как в Google Cloud, так и в собственном облаке на базе VMWare, в котором находится более 200 серверов и виртуальных машин.

Когда количество Linux машин в компании достаточно велико, то рано или поздно возникает необходимость в централизованном управлении доступом к серверам и если в случае с Windows использование AD является индустриальным стандартом, то, когда дело доходит до Linux приходится использовать такие инструменты как FreeIPA.

FreeIPA (Free Identity, Policy and Audit) ─ это open-source решение для Linux (аналогичное MS Active Directory), которое обеспечивает централизованное управление учетными записями и централизованную аутентификацию.

Необходимо отметить, что у RedHat есть решение IdM, которое является частью RHEL. Они технически идентичны с FreeIPA и, можно сказать, что FreeIPA является upstream версией для IdM на которой обкатываются новые фичи (как Fedora для RHEL).

FreeIPA использует клиент-серверную модель. Клиентом может быть любая Linux машина, которая настроена для взаимодействия с FreeIPA (IdM) контроллером домена. Клиент осуществляет взаимодействие с помощью Kerberos, NTP, DNS сервисов и сертификатов.

Как настроить решение с репликацией из двух FreeIPA серверов с DNS можно почитать в этой статье, а для установки FreeIPA клиентов нам понадобится:
● Функционирующий FreeIPA контроллер с настроенным DNS сервером
● Один CentOS 7 сервер по крайней мере с 1GB памяти.
● Ansible version: 2.8+
● Terraform version: 0.13+

Конечно, можно устанавливать FreeIPA клиентов вручную. Это можно сделать в 3 шага:
1) Установить пакет yum install ipa-client
2) Запустить скрипт установки ipa-client-install
3) Пройти по шагам, ответив на вопросы установщика.

Playbook для запуска роли выглядит так:

Изначально мы также использовали ansible для создания DNS записей.

При этом возникала проблема: чтобы создать dns запись необходимо было сначала явно указать IP адрес ">" в inventory файле, что было не очень удобно.

И так как мы используем в том числе Terraform в нашем частном облаке и стараемся придерживаться подхода IaC был найден terraform-provider-freeipa, который позволил нам добавлять DNS записи при создании виртуальных машин.

В результате мы получаем готовую DNS запись при создании виртуальной машины.

И ничто нам не мешает продолжить установку FreeIPA клиента с помощью Ansible роли.

Так выглядит процесс создания DNS записей и установки FreeIPA клиентов у нас в Altenar. Надеюсь, что наш опыт был вам полезен, ну а мы в свою очередь продолжим делиться лайфхаками.

Читайте также: