Введение

Первичная диагностика производится на настроенном контроллере ЕПП FreeIPA и предназначена для оценки текущего состояния домена (порядок установки и настройки контроллера см. в статье Контроллер ЕПП FreeIPA в Astra Linux).
Она поможет своевременно обнаружить и устранить ошибки установки, некорректную репликацию, проблемы с аутентификацией, несоответствия в DNS-записях и сбои в работе PKI-служб.
В статье будет рассмотрен ряд ручных и автоматических диагностик. Для большинства автоматических диагностик будет использован инструмент ipa-healthcheck. Ознакомиться с его функциональными возможностями более подробно можно в статье FreeIPA Health Check. Обзор функциональных возможностей.

Термины

Термин	Пояснение
Источник (source)	Модуль или пространство имён для сбора данных (например, ipahealthcheck.ipa.certs). Полный список источников см. Обзор источников и проверок для диагностики и мониторинга FreeIPA.
Проверка (check)	Конкретная проверка в рамках источника (например, IPADNSSystemRecordsCheck). Полный список проверок см. Обзор источников и проверок для диагностики и мониторинга FreeIPA.
CLI	Аббревиатура от Command Line Interface. Текстовый интерфейс для взаимодействия с операционной системой или программой через ввод команд в консоли, без использования графических элементов.
DogTag	Сокращенное название проекта Dogtag Certificate System. Встроенный центр сертификации контроллеров FreeIPA (см. FreeIPA: Подключение центра сертификации DogTag в Astra Linux Common Edition). Не входит в состав основного репозитория Astra Linux Special Edition.
CS	Аббревиатура от Certificate System. В контексте DogTag это подсистема, отвечающая за работу центра сертификации и связанных сервисов.
CA	Аббревиатура от Certificate Authority. В контексте DogTag это подсистема, отвечающая за выпуск, подпись и отзыв цифровых сертификатов, а также публикацию списков отозванных сертификатов (CRL) и работу OCSP-ответчика.
CRL	Аббревиатура от Certificate Revocation List. Периодически публикуемый центром сертификации (CA) файл, содержащий список отозванных цифровых сертификатов, срок доверия к которым прекращён.
KRA	Аббревиатура от Key Recovery Authority. В контексте DogTag это подсистема, обеспечивающая архивирование и восстановление закрытых ключей пользователей: при запросе сертификата приватный ключ шифруется и сохраняется в KRA, что позволяет восстановить доступ к данным, если оригинальный ключ утерян.
DSBLE, DSCLE, DSDSLE и т.д.	Аббревиатуры от Directory Server <сокращенное название проверки> Lint Error. Это специальный тип ошибки, который используется в механизме проверок 389-DS для описания несоответствий конфигурации и ACI (Access Control Instructions) в LDAP-сервере. Он возникает при выполнении команды dsctl <instance> healthcheck, служит для структурированного представления найденных проблем (код ошибки, уровень серьёзности, описание и контекст) для последующего ручного или автоматического их устранения.
CS.cfg	Главный файл конфигурации подсистемы DogTag CS. Создается при инициализации контроллера ЕПП FreeIPA с центром сертификации DogTag (см. FreeIPA: Подключение центра сертификации DogTag в Astra Linux Common Edition). В DogTag подсистемы запускаются независимо, каждая со своим CS.cfg: /etc/pki/pki-tomcat/ca/CS.cfg настраивает CA, /etc/pki/pki-tomcat/kra/CS.cfg настраивает KRA.
DNS	Аббревиатура от Domain Name System. Иерархическая распределённая система, преобразующая доменные имена в IP-адреса и обратно в Интернете.
LDAP	Аббревиатура от Lightweight Directory Access Protocol. Протокол прикладного уровня для доступа и управления распределённой каталоговой службой, широко используется для хранения и поиска информации об учётных записях, группах и политиках в сетях.
NSS	Аббревиатура от Network Security Services. Набор библиотек защитного преобразования, используемых приложениями и сервисами для работы с сертификатами, ключами и безопасными соединениями.
DS	Аббревиатура от Directory Server LDAP-сервер, реализованный на основе проекта 389 Directory Server, обеспечивающий хранение, поиск и модификацию данных каталоговой службы (учётные записи, группы, политики).
RUV	Аббревиатура от Replica Update Vector. Набор счётчиков состояния репликации в DS, хранящийся на каждом узле; позволяет определить, какие изменения между всеми участниками топологии уже переданы, а какие ещё нужно синхронизировать.
TLS/SSL	Аббревиатура от Transport Layer Security (TLS) и Secure Sockets Layer (SSL). Протоколы, обеспечивающие защитное преобразование и аутентификацию сетевых соединений в интернете и приложениях.
certmonger	Служба для автоматического управления жизненным циклом сертификатов: генерирует запросы, отслеживает их, обновляет истекающие сертификаты и взаимодействует с центром сертификации для их продления.
FQDN	Аббревиатура от Fully Qualified Domain Name. Полное доменное имя узла, включающее все уровни DNS-иерархии (например, host.example.com).
KDC	Аббревиатура от Key Distribution Center. Компонент Kerberos, отвечающий за аутентификацию клиентов и выдачу Ticket Granting Tickets и сервисных билетов (TGS)
TGT	Аббревиатура от Ticket Granting Ticket. В Kerberos-системе билет, выдаваемый KDC после аутентификации, позволяющий без повторного ввода пароля запрашивать сервисные билеты.
DNA	Аббревиатура от Distributed Numeric Assignment. Плагин 389 Directory Server, который автоматически распределяет диапазоны POSIX UID/GID между серверами — выделяет каждому мастеру и реплике поддиапазон из общего пространства идентификаторов, обеспечивая их уникальность и отказоустойчивость при создании новых учётных записей и групп
keytab	Файл “key table” Kerberos, хранящий длинно-срочные ключи одного или нескольких принципалов. Используется сервисами для автоматической аутентификации без ввода пароля.
Топология репликации	Схема взаимосвязей и соглашений репликации между IPA-серверами.
AD	Аббревиатура от Active Directory. Cлужба каталогов Microsoft для управления объектами Windows-домена (пользователи, компьютеры, политики). Использует LDAP, Kerberos и DNS для централизованной аутентификации и авторизации.
RID/SID	RID (Аббревиатура от Relative Identifier) Относительный идентификатор, присваиваемый объектам при создании и становящийся частью SID. SID (Аббревиатура от Security Identifier) Уникальный идентификатор безопасности в Windows AD, состоящий из доменного S-идентификатора и RID
IPA	Аббревиатура от Identity, Policy, Audit. Интегрированное решение для централизованного управления удостоверениями, политиками аутентификации и аудита на Linux/UNIX. Основано на LDAP, Kerberos, Dogtag и BIND.

Первичная диагностика Directory Server, включая репликацию

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

Также для большинства диагностических операций требуется наличие билета Kerberos администратора домена. Получить билет Kerberos можно с помощь команды kinit, указав пароль пользователя — владельца билета. Например, для пользователя admin (имя администратора домена по умолчанию):

kinit admin

Проверить наличие билета Kerberos можно с помощью команды klist.

klist

Например, для пользователя admin (имя администратора домена по умолчанию), вывод будет выглядеть так:

Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@TESTDOMAIN.TEST

Valid starting       Expires              Service principal
28.05.2025 12:50:01  29.05.2025 12:18:08  HTTP/ipasrv.testdomain.test@TESTDOMAIN.TEST
28.05.2025 12:50:01  29.05.2025 12:18:08  krbtgt/TESTDOMAIN.TEST@TESTDOMAIN.TEST

Ручная диагностика

Проверка имени хоста и DNS

В случае сбоев при разрешении имени доменного имени сервера или DNS-записей проверьте и скорректируйте их настройки. Подробнее см. Настройка серверов для FreeIPA и Настройка сетевых подключений в Astra Linux.

Чтобы проверить корректную настройку полного доменного имени (FQDN) используется команда:
hostname -f
Ожидается, что hostname -f выдаст полное доменное имя сервера, например:
ipasrv.testdomain.test

Для диагностики корректности записей DNS в составе пакета dnsutils предоставляется инструмент dig. Для выполнения диагностики:

Сделать прямой запрос (hostname → IP):

dig +short A $(hostname -f)

Команда используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы.
В примерах используется со следующими параметрами:

+short
выводит только ответ без заголовков и дополнительных сведений,
A
указывает на запрос A-записи (IPv4),
-x
сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,
$(hostname -f)
командная подстановка, возвращающая FQDN, соответствующий текущему хосту,
$(hostname -i)
командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста.

Ожидается, что команда вернет IPv4 адрес сервера, например:

10.192.5.243

Сделать обратный PTR-запрос (IP → hostname):

dig +short -x $(hostname -i)

Команда используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы.
В примерах используется со следующими параметрами:

+short
выводит только ответ без заголовков и дополнительных сведений,
A
указывает на запрос A-записи (IPv4),
-x
сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,
$(hostname -f)
командная подстановка, возвращающая FQDN, соответствующий текущему хосту,
$(hostname -i)
командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста,
$(hostname -d)
командная подстановка, возвращающая домен, соответствующий текущему хосту.

Ожидается, что команда вернёт полное доменное имя сервера с точкой на конце, например:

ipasrv.testdomain.test.

Сделать SRV-запрос для службы LDAP по протоколу TCP:

dig +short SRV _ldap._tcp.$(hostname -d)

Команда используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы.
В примерах используется со следующими параметрами:

+short
выводит только ответ, без заголовков и дополнительных сведений,
A
указывает на запрос A-записи (IPv4),
-x
сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,
$(hostname -f)
командная подстановка, возвращающая FQDN, соответствующий текущему хосту,
$(hostname -i)
командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста,
$(hostname -d)
командная подстановка, возвращающая домен, соответствующий текущему хосту.

Ожидается, что команда вернет блок ANSWER вида:

10 100 389 ipasrv.testdomain.test.
0 100 389 ipasrv.testdomain.test.
0 100 389 ipacln.testdomain.test.

Сделать SRV-запросы для службы Kerberos по протоколам TCP и UDP:

dig +short SRV _kerberos._udp.$(hostname -d)
dig +short SRV _kerberos._tcp.$(hostname -d)

Команда используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы.
В примерах используется со следующими параметрами:

+short
выводит только ответ, без заголовков и дополнительных сведений,
A
указывает на запрос A-записи (IPv4),
-x
сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,
$(hostname -f)
командная подстановка, возвращающая FQDN, соответствующий текущему хосту,
$(hostname -i)
командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста,
$(hostname -d)
командная подстановка, возвращающая домен, соответствующий текущему хосту.

Ожидается, что команда вернет блок ANSWER вида:

0 100 88 ipasrv.testdomain.test.
0 100 88 ipacln.testdomain.test.

Проверка доступности сетевых портов

Для диагностики доступности сетевых портов в составе пакета freeipa-server предоставляется инструмент ipa-replica-conncheck. Требуется репликация с минимум двумя узлами: ведущим (master) и ведомым (slave/replica). Для выполнения диагностики:

На ведомом узле проверить доступность сетевых портов ведущего узла при помощи команды:

sudo ipa-replica-conncheck -m ipasrv.testdomain.test -r TESTDOMAIN.TEST -k ipasrv.testdomain.test -p admin -w 12345678 -a

sudo ipa-replica-conncheck -m <HOST> -r <REALM> -k <HOST> -p <PRINCIPAL> -w <PASSWORD> -a

Эта команда проводит двухфазную проверку сетевого взаимодействия между уже существующими ведущими и ведомыми узлами реплики FreeIPA. Сначала тестируется доступность TCP-портов ведущего узла (389, 636, 88, 464, 80, 443), а затем автоматически по SSH инициирует обратную проверку тех же портов с ведущего на ведомый узел. Ошибки «Failed to bind» при этом свидетельствуют лишь о занятости портов штатными службами, но не об их недоступности.

Используются следующие параметры:

-m <HOST>
указывает FQDN или IP-адрес ведущего узла, к которому ведомый узел должен подключиться в первой фазе проверки,
-r <REALM>
имя IPA Kerberos области (realm) (обычно домен в верхнем регистре); без него инструмент не сможет получить билет и завершится ошибкой,
-k <HOST>
FQDN или IP-адрес KDC для Kerberos аутентификации (по умолчанию совпадает с ведущим узлом),
-p <PRINCIPAL>
имя Kerberos принципала (например, admin), под которым будет совершена аутентификация перед проверкой,
-w <PASSWORD>
пароль указанного принципала (в кавычках, если содержит спецсимволы); является небезопасным, при отсутствии параметра инструмент запросит его интерактивно,
-a
автоматически запускает на ведомом узле вторую фазу проверки: по SSH заходит на ведущий узел и выполняет ipa-replica-conncheck --replica <REPLICA> для диагностики связи ведущий → ведомый.

Check connection from replica to remote master 'ipasrv.testdomain.test':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
389 tcp: Failed to bind
636 tcp: Failed to bind
88 tcp: Failed to bind
88 udp: Failed to bind
464 tcp: Failed to bind
464 udp: Failed to bind
80 tcp: Failed to bind
443 tcp: Failed to bind
Get credentials to log in to remote master
Check RPC connection to remote master
Retrying using SSH...
Check SSH connection to remote master
Execute check on remote master

Дополнительно вручную проверить порты 88 и 464 протокола UDP. Сделать это можно при помощи команды на ведомом узле, например:

nc -vuz ipasrv.testdomain.test 88 464

Команда сканирует указанные UDP-порты (88 и 464) на хосте ipasrv.testdomain.test, не передавая реальных данных и выводит подробную информацию о статусе каждого порта (открыт/закрыт). Поставляется с пакетом netcat-openbsd.
Используются следующие параметры:

-v
включает подробный режим,
-u
заставляет использовать UDP вместо TCP при соединении с портами,
-z
включает режим сканирования без передачи данных: netcat лишь пытается установить соединение и сразу его закрывает, что полезно при проверке портов.

Connection to ipasrv.testdomain.test (10.192.5.244) 88 port [udp/kerberos] succeeded!
Connection to ipasrv.testdomain.test (10.192.5.244) 464 port [udp/kpasswd] succeeded!

Проверка списков реплик и соглашений репликации

Для диагностики доступности узлов в текущей топологии, а также для диагностики актуальности репликации узлов в составе пакета freeipa-server предоставляется инструмент ipa-replica-manage. Для выполнения диагностики:

На любом узле вывести базовый список узлов при помощи команды:

sudo ipa-replica-manage list

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

ipasrv.testdomain.test: master
ipacln.testdomain.test: master

На любом узле вывести подробный статус соглашений репликации для конкретного узла, например:

sudo ipa-replica-manage list ipasrv.testdomain.test -v

ipa-replica-manage list <HOST> -v

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

Используются следующие параметры:

<HOST>
FQDN узла для которого будет выводиться подробный статус соглашений,
-v
включает подробный режим.

Пояснение вывода команды:

last init status
код результата последней инициализации реплики (0 = успешно, иначе ошибка),
last init ended
время завершения инициализации,
last update status
код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
last update ended
время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).

ipacln.testdomain.test: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2025-05-28 19:51:44+00:00
  last update status: Error (0) Replica acquired successfully: Incremental update succeeded
  last update ended: 2025-05-28 23:59:09+00:00

На любом узле вывести значения счётчиков изменений (RUV) при помощи команды:

sudo ipa-replica-manage list-ruv

Команда позволяет получить значения счётчиков изменений (RUV) для всех реплик как в доменной части, так и (при наличии DogTag) в службе сертификатов. По сравнению с простым выводом топологии она даёт представление о точке синхронизации каждой реплики, что помогает оперативно выявлять узлы, отстающие по приёму изменений. Если счётчик одного узла существенно меньше, чем у остальных, значит он не подтянул последние операции (создание/удаление/изменение записей) из домена или CA.

Replica Update Vectors:
        ipasrv.testdomain.test:389: 4
        ipacln.testdomain.test:389: 3
Certificate Server Replica Update Vectors:
        No CS-RUVs found.

Replica Update Vectors:
        ipasrv.testdomain.test:389: 4
        ipacln.testdomain.test:389: 3
Certificate Server Replica Update Vectors:
        ipasrv.testdomain.test:389: 6

На любом узле вывести назначенные UID/GID-диапазоны (DNA-ranges) при помощи команды:

sudo ipa-replica-manage dnarange-show

Команда выводит назначенные UID/GID-диапазоны (DNA) для каждого сервера; для реплик без созданных пользователей выводит «No range set». Помогает убедиться, что новые реплики получили корректный диапазон при создании первой записи; отсутствие диапазона у «визуально активной» реплики указывает, что на ней ещё не создавались пользователи или группы.

ipasrv.testdomain.test: 1188400002-1188500499
ipacln.testdomain.test: 1188500504-1188599999

Для диагностики доступности узлов, участвующих в репликации сертификатов DogTag CA в составе пакета freeipa-server предоставляется инструмент ipa-careplica-manage. Для выполнения диагностики:

На любом узле вывести базовый список узлов участвующих в репликации сертификатов DogTag CA при помощи команды:

sudo ipa-csreplica-manage list

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

ipasrv.testdomain.test: master
ipacln.testdomain.test: master

На любом узле вывести подробный статус соглашений репликации сертификатов DogTag CA для конкретного узла, например:

sudo ipa-csreplica-manage list ipasrv.testdomain.test -v

ipa-careplica-manage list <HOST> -v

Команда выводит детальную информацию о всех соглашениях репликации сертификатов DogTag CA для указанного узла: статус и метки времени последних инициализаций и обновлений реплик.

Используются следующие параметры:

<HOST>
FQDN узла для которого будет выводиться подробный статус соглашений сертификатов DogTag CA,
-v
включает подробный режим.

Пояснение вывода команды:

last init status
код результата последней инициализации реплики (0 = успешно, иначе ошибка),
last init ended
время завершения инициализации,
last update status
код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
last update ended
время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).

ipacln.testdomain.test
  last init status: Error (0) Total update succeeded
  last init ended: 2025-05-28 10:22:34+00:00
  last update status: Error (0) Replica acquired successfully: Incremental update succeeded
  last update ended: 2025-05-28 21:32:10+00:00

Проверка суффиксов репликации

Для диагностики наличия и корректности LDAP-суффиксов репликации в составе пакета freeipa-server предоставляется инструмент ipa с командами topologysuffix-find, ipa topologysuffix-show, ipa topologysuffix-verify. Для выполнения диагностики:

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

sudo ipa topologysuffix-find --all

Показывает топологические суффиксы LDAP domain и ca (только при наличии центра сертификации DogTag), которые участвуют в репликации, вместе с полным набором их атрибутов и метаданных. Помогает понять, почему нужные данные не реплицируются между серверами. Также сразу видно отсутствие или некорректность суффиксов в топологии, что указывает на проблемы конфигурации репликации.

Пояснение вывода команды:

dn
полный DN записи в LDAP,
Имя суффикса
значение атрибута cn, задающее понятное имя суффикса,
DN управляемого суффикса LDAP
показывает базовый DN LDAP-суффикса,
nsDS5ReplicaStripAttrs
список атрибутов, исключаемых из репликации,
nsDS5ReplicatedAttributeList
список атрибутов, которые будут реплицироваться, за исключением тех, что перечислены после ключевого слова EXCLUDE,
nsDS5ReplicatedAttributeListTotal
список всех атрибутов, которые будут реплицированы полностью, за исключением тех, что перечислены после ключевого слова EXCLUDE,
objectClass
указывает, к каким объектным классам относится запись.

---------------------------------------------
установлено соответствие 1 суффикса топологии
---------------------------------------------
  dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
  Имя суффикса: domain
  DN управляемого суффикса LDAP: dc=testdomain,dc=test
  nsds5replicastripattrs: modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp
  nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
  nsds5replicatedattributelisttotal: (objectclass=*) $ EXCLUDE entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
  objectclass: top, iparepltopoconf
---------------------------------
Количество возвращённых записей 1
---------------------------------

----------------------------------------------
установлено соответствие 2 суффиксов топологии
----------------------------------------------
  dn: cn=ca,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
  Имя суффикса: ca
  DN управляемого суффикса LDAP: o=ipaca
  objectclass: top, iparepltopoconf

  dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
  Имя суффикса: domain
  DN управляемого суффикса LDAP: dc=testdomain,dc=test
  nsds5replicastripattrs: modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp
  nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
  nsds5replicatedattributelisttotal: (objectclass=*) $ EXCLUDE entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
  objectclass: top, iparepltopoconf
---------------------------------
Количество возвращённых записей 2
---------------------------------

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

sudo ipa topologysuffix-verify domain

ipa topologysuffix-verify <SUFFIX>

Команда выполняет проверку репликационной топологии для указанного LDAP-суффикса, анализируя объекты «topology suffix» и связанные с ними «topology segment» и убеждаясь, что между всеми серверами настроены двунаправленные соглашения репликации. Если обнаруживается хоть один сегмент с односторонней связью или разрыв репликации, команда выводит сообщение об ошибке, что позволяет быстро выявить и устранить сбои в репликации. При отсутствии каких-либо проблем команда завершится без ошибок, подтверждая целостность конфигурации.

Используется следующий параметр:

<SUFFIX>
Имя суффикса репликации. Например domain или ca.

=================================================================
Топология репликации суффикса "domain" соответствует требованиям.
=================================================================