Модуль 8. Управление топологией в домене

Введение

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

Повышение роли сервера до контроллера домена

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

С помощью увеличения числа контроллеров добиваются так же горизонтального масштабирования, а в крупных инфраструктурах дополнительные контроллеры могут устанавливаться в различных сегментах сети, чтобы ускорить обработку запросов от ближайших к ним пользователей — эта технология в Active Directory называется сайтами, а в FreeIPA ее называют локациями, что более точно отражает суть решаемой задачи.

Процедуру, в ходе которого сервер делают контроллером домена, называют повышением роли сервера или продвижением сервера до контроллера домена (англ. promoting). В системе ALD Pro эта операция выполняется в два шага:

• Установка ОС и ввод машины в домен.

• Дополнительные настройки сервера и повышение роли до контроллера домена через портал управления.

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

• Сервер должен быть установлен в режиме «Смоленск», имя хоста dc-2

• Служба NetworkManager отключена, настройка сетевого интерфейса выполнена с использованием файлов /etc/network/interfaces и /etc/resolv.conf

• Настройки сетевого интерфейса в /etc/network/interfaces

  • IP-адрес: 10.0.1.12

  • Маска: 255.255.255.0

  • Шлюз: 10.0.1.1

• В настройках /etc/resolv.conf в качестве DNS-сервера указан IP-адрес первого контроллера домена, в нашем случае это 10.0.1.11 и DNS-суффикс ald.company.lan (параметр search)

• В файле /etc/hosts добавлена статичная запись «10.0.1.12 dc-2.ald.company.lan dc-2», а строка с адресом 127.0.1.1 закомментирована.

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

Файл resolv.conf

При повышении роли сервера до контроллера домена скрипты FreeIPA автоматически вписывают адрес локальной петли 127.0.0.1 в качестве nameserver в конфигурационный файл /etc/resolv.conf. Однако сервер BIND9 может стартовать с задержкой в зависимости от производительности системы, и последующие скрипты автоматизации завершатся с ошибкой.

Скрипты автоматизации в будущем планируется доработать, но, чтобы сейчас гарантированно избежать такой ситуации перед продвижением контроллера, нужно запретить любые изменения этого файла. Сделать это можно путем назначения атрибута i файлу с помощью утилиты chattr:

admin@dc-2:~$ sudo chattr +i /etc/resolv.conf

После продвижения файл нужно разблокировать ключом -i

admin@dc-2:~$ sudo chattr -i /etc/resolv.conf

И, конечно же, заменить адрес DNS-сервера с 10.0.1.11 на 127.0.0.1

search ald.company.lan
nameserver 127.0.0.1

Группа ald trust admin

Перед добавлением резервного контроллера домена требуется проверить, что среди участников группы ald trust admin есть пользователь admin. Это необходимо для корректной установки компонентов, использующихся в интеграции с Microsoft AD DS. Добавить пользователя в группу можно командой:

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

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

Параметр gather_job_timeout

Если контроллер домена установлен на медленных дисках или испытывает высокую нагрузку в момент установки подсистем, Salt Master может не успевать вычитывать результаты заданий из базы данных в установленные таймауты и в журнале автоматизации будет появляться ошибка «Run failed on the minions».

Эта ошибка не является критичной, т.к. подсистема фактически установлена и корректно работает, но чтобы ее избежать в конфигурационном файле /etc/salt/master.d/master.conf рекомендуется увеличить значение gather_job_timeout до 100-300 секунд.

Продвижение сервера до контроллера домена с портала управления

Продвижение резервного контроля осуществляется с портала управления на странице Управление доменом ‣ Сайты и службы ‣ Контроллеры домена. Нажмите кнопку Новый контроллер домена, выберите из списка сервер dc-2.ald.company.lan и остальные параметры, как показано на рисунке рис. 304.

рис. 304 Добавление нового контроллера домена

Результат выполнения задания по установке резервного контроллера можно посмотреть в разделе Автоматизация ‣ Задания автоматизации, называться задание будет replica_install, как показано на рисунке рис. 305:

рис. 305 Журнал заданий автоматизации

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

sudo journalctl -f

Дополнительную информацию можно получить из отчета в результатах выполнения задания автоматизации.

После установки выполните следующие действия

• Разблокируйте файл /etc/resolv.conf и замените IP-адрес сервера DNS с 10.0.1.11 на 127.0.0.1, что бы DNS-запросы не уходили на первый контроллер домена, иначе никакой отказоустойчивости не получится

• Отключите DNSSEC и разрешите рекурсивную обработку и кэширование запросов в /etc/bind/ipa-options-ext.conf

Теперь, когда у нас есть установленная реплика, мы можем перейти к вопросам репликации.

Механизм репликации

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

Первый домен от Microsoft появился в 90-е годы в Windows NT и характеризовался наличием одного ведущего сервера PDC (Primary Domain Controller) и нескольких резервных реплик BDC (Backup Domain Controller). Для преобразования имен в домене использовался протокол NetBIOS, а для аутентификации — протокол NTLM.

Для своего времени это было инновационное решение, но очень скоро в мире UNIX появились более продвинутые технологии LDAP, DNS и Kerberos, которые лучше соответствовали потребностям предприятий, поэтому в Windows 2000 компания Microsoft выпустила переосмысленную версию домена под названием Active Directory.

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

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

• Согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу.

• Доступность (англ. availability) — запрос к системе не зависает и обрабатывается в установленные таймауты. Если запрос не может быть обработан, система так и должна об этом сказать, не заставляя пользователя ожидать бесконечно долго.

• Устойчивость к разделению (англ. partition tolerance) — при потере связи между частями системы обслуживание пользователя не прекращается.

Очевидно, что кластеры классических СУБД являются CA-системами, которые гарантируют согласованность данных, а вот служба каталога является AP-системой, которая фокусируется на устойчивости к разделению. Это не означает, что в домене нет согласованности данных, просто эта согласованность обеспечивается только «в конечном итоге».

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

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

Репликация в Windows

В отличие от модели репликации с единственным мастером, которая используется в системе Microsoft Windows NT, в домене Active Directory используется модель репликации с несколькими мастерами, поэтому изменения могут быть внесены на любом сервере и не всегда контроллеры в домене имеют идентичную информацию. Если же перестать вносить изменения в каталог, то через некоторое время контроллеры придут в согласованное состояние.

В ходе репликации контроллеры домена могут передавать друг другу изменения, выполненные на других узлах кластера, поэтому полная связанность «все со всеми» не требуется. Топология домена MS AD настраивается автоматически с помощью службы проверки согласованности знаний (англ. Knowledge Consistency Checker, KCC). При этом существуют значительные отличия в работе репликации внутри сайта и между сайтами.

При репликации данных внутри сайта MS AD стремится к тому, чтобы изменения как можно быстрее синхронизировались между контроллерами домена:

• Топология внутри сайта выстраивается автоматически службой KCC, которая объединяет узлы в кольца. Алгоритм стремится к тому, чтобы число прыжков ретрансляции (hop) было не больше трех. Когда количество контроллеров домена в сайте становится больше семи, создаются дополнительные связи для уменьшения числа ретрансляций.

• Репликация работает в режиме Pull, т.е. контроллер вытягивает изменения с другого сервера с помощью процедур удаленного вызова (англ. Remote Procedure Call, RPC), но извлечение данных начинается при получении соответствующего уведомления от передающей стороны, что гарантирует быстрое распространение изменений в сети.

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

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

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

• Для межсайтовой репликации KCC автоматически выбирает специальные сервера-плацдармы (bridgehead server), помимо этого, администратор домена может вручную указать контроллеры домена, которые будут выполнять роль сервера-плацдарма.

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

• Для оптимизации нагрузки на сеть траффик межсайтовой репликации дополнительно сжимается. В зависимости от пропускной способностью и надежности сети могут использоваться протоколы IP или SMTP (протокол электронной почты).

Для репликации данных контроллеры используют журналы изменений, в которых записи идентифицируются номером изменений (англ. update sequence number, USN) и отметкой времени (timestamp). Номер USN представляет из себя число, которое увеличивается на единицу при каждом изменении базы Active Directory, например, если ранее значение highestCommittedUSN было 49459, а теперь 49482, то это означает, что за прошедшее время с помощью этого контроллера в базу данных было внесено 23 изменения.

В ходе сессии репликации сервер запрашивает у партнера таблицу highestCommittedUSN по всем контроллерам в домене, сопоставляет с известными ему значениями и запрашивает разницу. Таблица, в которой хранится информация о highestCommittedUSN, называется вектором обновления, или up-to-date vector. Посмотреть ее можно с помощью утилиты repadmin.

C:\> repadmin /showutdvec dc1 dc=win,dc=company,dc=lan
Default-First-Site-NameDC2 @ USN 49482 @ Time 2024-06-21 09:39:49
Default-First-Site-NameDC1 @ USN 30651 @ Time 2024-06-21 09:38:24

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

• Изменение атрибута существующей записи

  В этом случае AD руководствуется версией и датой изменений. Более приоритетным считается изменение, у которого выше номер версии. Если номер версии будет совпадать, то AD сочтет более приоритетным то изменение, которое было сделано последним по метке времени.

• Создание записей с одинаковым отличительным именем DN (distinguished name)

  В этом случае более приоритетным будет запись, у которой больше значение GUID. Вторая запись будет переименована в Name#CNF:userGUID, где символ # указывает на то, что эта запись является дубликатом. Если вам потребуется задействовать дублирующую запись, ее потребуется переименовать вручную.

• Создание записи в удаленном контейнере

  Если на одном контроллере удалить пустое организационное подразделение «Прочие сотрудники», а на другом контроллере в тоже самое время создать в этом подразделении нового сотрудника, то запись будет перемещена в контейнер с именем LostAndFound. Получить доступ к этому контроллеру можно через оснастку Пользователи и компьютеры (Users and Computers) в расширенном режиме (Advanced).

Репликация в ALD Pro

После установки второго контроллера домена вы можете посмотреть информацию о топологии на странице Управление доменом ‣ Сайты и службы ‣ Соглашения о репликации. Репликация ALD Pro (FreeIPA) во многом работает также как в MS AD, но есть и ряд отличий.

За работу репликации в 389 Directory Server отвечает плагин Multimaster Replication Plugin. Алгоритм его работы основан на использовании журнала изменений, который хранится в отдельной базе данных. Для работы механизма репликации требуются заранее установленные соглашения о репликации, за управление которыми отвечает плагин IPA Topology Configuration.

Журнал изменений (начиная c версии ALSE 1.7.4) храниться в файле /var/lib/dirsrv/slapd-<Имя_Инстанса>/db/userRoot/replication_changelog.db, например /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/db/userRoot/replication_changelog.db. Настройки этого журнала можно найти в записи с DN cn=changelog,cn=userRoot,cn=ldbm database,cn=plugins,cn=config.

рис. 306 Срок хранения записей в журнале

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

Период в 30 дней считается оптимальным с точки зрения соотношения размера журнала и «безопасного» периода невозможности выполнить репликацию. Однако, при необходимости, этот период может быть изменен. Для этого, в записи с DN «cn=changelog,cn=userRoot,cn=ldbm database,cn=plugins,cn=config» можно задать два атрибута:

• nsslapd-changelogmaxage — максимальный возраст записей в журнале изменений (по умолчанию 30 дней)

• nsslapd-changelogmaxentries — максимальное количество записей в журнале (по умолчанию значение не задано)

В старых версиях 389-ds-base (для ALSE 1.7.3 и ниже) журнал и настройки хранились в каталоге /var/lib/dirsrv/slapd-<Имя_Инстанса>/cldb и в записи с DN cn=changelog5,cn=config соответственно.

Примечание

В службе каталога 389 Directory Server существует так же дополнительный механизм репликации, артефакты которого могут сбивать вас с толку. Этот механизм реализован в соответствии с RFC 4533 и за его работу отвечают плагины Content Synchronization (frontend) и Retro Changelog Plugin (backend). Он предназначен для интеграции с внешними приложениями, например, почтой или корпоративным порталом, которым нужно поддерживать актуальную информацию о пользователях, группах и других объектах каталога.

Поставщики и потребители

Репликация работает по обычному LDAP-протоколу с шифрованием (порт 389 + StartTLS). Сервер, передающий изменения, называется Поставщиком, а сервер, принимающий изменения, называется Потребителем. По итогам репликации на Потребителе формируется полная копия данных каталога, поэтому его также называют Репликой.

В домене FreeIPA, как и в домене MS AD, каждая реплика является Мастером, то есть доступна на запись и с ее помощью можно вносить изменения в каталог. Такую репликацию, когда один и тот же сервер в разные моменты времени выступает то в роли Поставщика, то в роли Потребителя, называют репликацией с несколькими Ведущими серверами.

В отличии от MS AD репликация в домене ALD Pro (FreeIPA) всегда инициируется Поставщиком, а не Потребителем (т.е. работает по модели Push). В сеансе репликации Поставщик подключается к Потребителю, выполняя аутентификацию по протоколу Kerberos с использованием учетной записи ldap/dc-1.ald.company.lan. Затем Поставщик запрашивает у Потребителя сводную информацию о состоянии его репликации (так называемую таблицу RUV, Replica Update Vector), чтобы определить, есть ли у него для Потребителя актуальные изменения, и запускает передачу данных.

Соглашение о репликации

В домене ALD Pro нет службы KCC как в MS AD, поэтому топологию нужно настраивать вручную через создание сегментов и соглашений о репликации.

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

Примечание

Обратите внимание, что в интерфейсе ALD Pro есть небольшое упрощение в терминологии, поэтому то, что в ALD Pro называют «соглашениями о репликации», в FreeIPA на самом деле является «сегментами».

Если у сервера более одного соглашения, то сервер устанавливает исходящие сессии репликации по каждому из этих соглашений по очереди. Для повышения отказоустойчивости рекомендуется создавать не менее двух исходящих соглашений о репликации, так как при надежности одного соединения в 90% два соединения дадут две девятки 90% + 10%*90% = 99%.

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

Примечание

Продуктовая команда проводила успешное тестирование топологии «звезда», в которой у центрального контроллера было более 150 соглашений о репликации. Проблемы возникали только в том случае, когда сервер терял сетевую связанность с десятками реплик сразу.

Соглашение настраивается на Поставщике, хранится в его файле dse.ldif и доступно через LDAP в ветке с DN «cn=mapping tree,cn=config». Соглашение содержит следующую информацию:

• Адрес сервера Потребителя, на который нужно передавать данные (nsDS5ReplicaHost и nsDSReplicaPort)

• Способ передачи данных (nsDS5ReplicaTransportInfo, по умолчанию LDAP)

• Способ аутентификации (nsDS5ReplicaBindMethod=SASL/GSSAPI)

• Суффикс базы данных для репликации (nsDS5ReplicaRoot, по умолчанию dc=ald,dc=company,dc=local)

• Атрибуты, которые должны или не должны реплицироваться (nsDS5ReplicatedAttributeList, nsDS5ReplicatedAttributeListTotal, nsds5ReplicaStripAttrs)

рис. 307 Параметры соглашения о репликации

Кроме обязательных параметров есть много дополнительных, которые позволяют, например, установить расписание репликации (nsDS5ReplicaUpdateSchedule).

Журнал изменений

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

Прямого доступа к журналу через LDAP у нас нет, но с помощью утилиты dbscan можно прочитать файл изменений:

admin@dc-1:~$ sudo dbscan -f /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/db/userRoot/replication_changelog.db | head -n 15
dbid: 66158532000000040000
   encrypted: no
   replgen: 1712686215 Tue Apr 9 21:10:15 2024
   csn: 66158532000000040000
   uniqueid: 88e30e06-bf4e11ee-9d29cb43-d00727f4
   dn: cn=repl keep alive 4,dc=ald,dc=company,dc=lan
   operation: modify
         keepalivetimestamp: 20240409181015Z
         modifiersname: cn=Multisupplier Replication Plugin,cn=plugins,cn=config
         modifytimestamp: 20240409181015Z
         entryusn: 1394188

dbid: 66158534000000040000
   encrypted: no

Размер журнала будет зависеть от количества изменений в каталоге и от параметров в DN «cn=changelog,cn=userRoot,cn=ldbm database,cn=plugins,cn=config», которые определяют максимальное количество записей в журнале и их максимальный возраст:

• nsslapd-changelogmaxage — максимальный возраст записей в журнале изменений (по умолчанию 30 дней)

• nsslapd-changelogmaxentries — максимальное количество записей в журнале (по умолчанию значение не задано)

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

Порядковый номер изменения (CSN)

Для эффективного решения конфликтов репликации каждое изменение идентифицируется порядковым номером изменения CSN (Change Sequence Number или Change State Number), которое представляет из себя 20-разрядное число в шестнадцатеричной системе счисления, например, 64a0238f 0008 0003 0000, где:

1. Часть A (метка времени) — разряды 1-8 (64a0238f) — это часть идентификатора в формате временной метки в unix time_t (количество секунд с начала эпохи), которая обычно соответствует моменту времени, когда изменение было сделано на Ведущей реплике.

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

2. Часть B (порядковый номер) — разряды 9-12 (0008) — это часть идентификатора, которая определяет порядковый номер изменения в пределах значения числа «A». Позволяет идентифицировать до 65 536 изменений (16⁴), поэтому, как только указанный диапазон будет исчерпан, значение числа «A» должно быть увеличено на единицу, а нумерация числа «B» начнется с начала.

3. Часть С (идентификатор реплики) — разряды 13-16 (0003) — это часть идентификатора, соответствующая номеру Ведущего сервера, через который было внесено данное изменение в каталог.

   Уникальный номер Ведущего сервера должен быть в диапазоне до 65 534. Последнее значение 65 535 используется для обозначения «read-only» реплик, которые называются Хабами, но не путайте их с RODC в терминологии MS AD, т.к. в них не заложена какая-то особая логика работы с хешами пользовательских паролей.

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

4. Часть D (резерв) — разряды 17-20 (0000) — это часть идентификатора, зарезервированная для возможности расширения функциональности протокола репликации в будущем.

Алгоритм репликации

Репликация использует журнал изменений и порядковые номера CSN. Упрощенно алгоритм выглядит следующим образом:

1. В сеансе репликации Поставщик запрашивает у Потребителя, какой номер последнего изменения по Ведущему серверу «X» ему известен (CSN Max).

2. Далее Поставщик сравнивает полученное значение CSN Max с своим собственным значением CSN Max по этому Ведущему серверу «X».

3. Если окажется, что собственное значение у Поставщика больше, чем значение, полученное от Потребителя, значит у Поставщика есть более свежие обновления по указанному Ведущему серверу «X». В этом случае Поставщик передаст Потребителю новые данные.

В действительности для повышения производительности 389 Directory Server использует так называемые вектора обновления реплик (Replica Update Vector, RUV), которые позволяют уменьшить нагрузку на диск и центральный процессор за счет сокращения количества обращений к журналу изменений.

Каждый вектор содержит четыре значения:

• Replica Id — идентификатор Ведущего сервера, который является источником прямых изменений.

• URL — адрес Ведущего сервера для обращения по LDAP.

• Min CSN — номер первого изменения от данного Ведущего сервера в журнале изменений текущего сервера.

• Max CSN — номер последнего изменения от данного Ведущего сервера в журнале изменений текущего сервера.

С учетом RUV алгоритм репликации выглядит следующим образом:

• В начале сеанса репликации Поставщик берет свою таблицу RUV и загружает копию таблицы RUV Потребителя. Значения Max CSN берутся из этих таблиц вместо прямых обращений к журналам изменений.

• После завершения репликации по конкретному Ведущему серверу Потребитель сохраняет в свою таблицу RUV (а конкретнее в строку по этому Ведущему серверу) крайнее значение CSN, которое стало ему известно от Поставщика.

• Новое значение CSN в RUV Потребителя будет использовано в качестве стартовой точки в следующем сеансе репликации.

Актуальные значения векторов хранятся в памяти сервера, но их можно посмотреть с помощью утилиты dsconf, подкоманда replication get-ruv:

admin@dc-1:~$ sudo dsconf -D 'cn=Directory Manager' -w Astra_Linux_174 ALD-COMPANY-LAN replication get-ruv --suffix dc=ald,dc=company,dc=lan
RUV:        {replica 4 ldap://dc-1.ald.company.lan:389} 65b8bb9f000100040000 6643fc28000000040000
Replica ID: 4
LDAP URL:   ldap://dc-1.ald.company.lan:389
Min CSN:    2024-01-30 09:04:31 1 0 (65b8bb9f000100040000)
Max CSN:    2024-05-15 00:04:56 (6643fc28000000040000)

RUV:        {replica 3 ldap://dc-2.ald.company.lan:389} 65b8bba3000100030000 6616b4be000000030000
Replica ID: 3
LDAP URL:   ldap://dc-2.ald.company.lan:389
Min CSN:    2024-01-30 09:04:35 1 0 (65b8bba3000100030000)
Max CSN:    2024-04-10 15:48:14 (6616b4be000000030000

Рассмотрим работу алгоритма репликации на примере соглашения dc3 — dc4, когда dc-3 выступает в роли Поставщика, а dc-4 в роли Потребителя. Для наглядности будем обозначать номера изменений Max CSN с помощью одноразрядных целых чисел.

рис. 308 Пример репликации с использованием значения MAX CSN

Поставщик dc-3 подключается к Потребителю dc-4 и построчно сверяет свою таблицу RUV с таблицей RUV, полученной от Потребителя.

• По строке #1 видно, что «3 > 1», а значит, у Поставщика dc-3 есть два изменения, о которых еще не знает Потребитель dc-4, поэтому принимается решение о том, чтобы их передать. После получения новых изменений Потребитель в своей таблице RUV для реплики dc-1 обновит CSN Max.

• По строке #2 видно, что «4 < 5», т.е. у Поставщика dc-3 даже более старые данные, чем у Потребителя dc-4, но репликации не происходит, так как в рамках текущей сессии репликации сервер dc-4 выступает в роли Потребителя.

• По строке #3 видно, что «7 = 7», т.е. оба сервера обладают одинаковыми данными.

• По строке #4 ситуация аналогична строке #2.

Примечание

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

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

Конфликты репликации

Конфликты репликации в домене ALD Pro (FreeIPA) решаются примерно так же, как в MS AD:

• Изменение атрибута существующей записи

  В этом случае FreeIPA руководствуется значением CSN — приоритет отдается тому изменению, у которого номер больше, поэтому ручное вмешательство не требуется.

• Создание записей с одинаковым отличительным именем DN

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

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

  1. uid=figaro,cn=users,cn=accounts,dc=ald,dc=company,dc=lan

  2. nsuniqueid=7341f021-20b331ee-a3ef96aea91d3705+uid=figaro,cn=users,cn=accounts,dc=ald,dc=company,dc=lan

  Обработка конфликта будет происходить на каждом контроллере домена индивидуально, а операция переименования записи в nsuniqueid+uid не отразится в журнале изменений. К переименованной записи будет добавлен так же класс объекта ldapsubentry и операционный атрибут nsds5ReplConflict.

• Создание записи в удаленном контейнере

  В системе ALD Pro структурные подразделения реализованы через ссылки в атрибуте rbtadp, поэтому при создании пользователя в удаленном подразделении мы получим просто неработающую ссылку, которую можно будет легко исправить в карточке объекта. Однако, подобные ситуации могут возникать, например, при редактировании объектов групповых политик.

  Если на одном контроллере домена удалить запись, а на другом в тот же момент создать ее потомка, то механизм разрешения конфликтов автоматически создаст запись с классом glue взамен удалённой родительской записи. Обработка конфликта будет происходить на каждом контроллере домена индивидуально в момент его появления, и эти изменения не отразятся в журнале изменений changelog.

  Запись с классом glue будет иметь атрибуты «objectClass: glue», «objectClass: extensibleobject» и «nsds5ReplConflict: deletedEntryHasChildren». В зависимости от ситуации удалённая родительская запись может быть создана одним из следующих способов:

  1. Созданием новой записи с классом glue и минимальным набором атрибутов.

  2. Восстановлением удалённой записи из надгробия (англ. tombstone) и превращением её в запись с классом glue.

  3. Превращением еще не удаленной записи в запись с классом glue.

Оптимизация межсайтовой репликации

В домене ALD Pro (FreeIPA) в отличие от MS AD внутрисайтовая и межсайтовая репликации по умолчанию ничем не отличаются. Однако в соглашениях о репликации есть несколько атрибутов, с помощью которых вручную можно добиться некоторых оптимизаций.

Параметр nsds5ReplicaEnabled

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

Параметр	Описание
DN запись	cn=ReplicationAgreementName,cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимое значение	on | off
Значение по умолчанию	on
Синтаксис	строка

Параметр nsDS5ReplicaUpdateSchedule

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

Параметр	Описание
DN запись	cn=ReplicationAgreementName,cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимое значение	Расписание задается строкой в формате XXXX-YYYY 0123456, где XXXX — время начала, YYYY — время окончания в формате HHMM, числа 0123456 — дни недели, начиная с воскресенья.
Значение по умолчанию	Если параметр не задан, предполагается значение 0000-2359 0123456, т.е. соглашение активно все время
Синтаксис	строка
Пример	nsDS5ReplicaUpdateSchedule: 0000-2359 0123456

Параметр nsslapd-connection-buffer

Параметр устанавливает поведение буферизации соединения. Возможные значения:

1. 0 — отключить буферизацию. Только одиночные блоки данных (Protocol Data Unit, PDU) считываются за раз.

2. 1 — обычный фиксированный размер LDAP_SOCKET_IO_BUFFER_SIZE в 512 байт.

3. 2 — адаптируемый размер буфера.

Значение #2 обеспечивает более высокую производительность, если клиент отправляет большой объем данных, что лучше соответствует межсайтовому характеру репликации.

Параметр	Описание
DN запись	cn=config
Допустимые значения	0 | 1 | 2
Значение по умолчанию	1
Синтаксис	integer
Пример	nsslapd-connection-buffer: 1

Параметры nsDS5ReplicaBusyWaitTime и nsDS5ReplicaSessionPauseTime

Параметр BusyWaitTime устанавливает задержку в секундах, которую Поставщик должен выждать, прежде чем предпринимать повторную попытку соединения с Потребителем после того, как тот вернул ответ «занято». Значение по умолчанию 3 сек. Параметр SessionPauseTime устанавливает задержку в секундах, которую Поставщик должен выждать между сеансами обновления. Значение по умолчанию равно 0 сек.

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

Параметр nsDS5ReplicaBusyWaitTime	Описание
DN запись	cn= ReplicationAgreementName, cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимые значения	Любое допустимое целое число
Значение по умолчанию	3
Синтаксис	Integer
Пример	nsDS5ReplicaBusyWaitTime: 3

Параметр nsDS5ReplicaSessionPauseTime	Описание
DN входа	cn=ReplicationAgreementName, cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимые значения	Любое допустимое целое число
Значение по умолчанию	0
Синтаксис	Целое число
Пример	nsDS5ReplicaSessionPauseTime: 0

Параметры nsds5ReplicaFlowControlWindow и nsds5ReplicaFlowControlPause

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

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

Параметр nsds5ReplicaFlowControlPause	Описание
DN запись	cn=ReplicationAgreementName, cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимые значения	от 0 до максимальной длины 64 бита
Значение по умолчанию	2000
Синтаксис	Integer
Пример	nsds5ReplicaFlowControlPause: 2000

Параметр nsds5ReplicaFlowControlWindow	Описание
DN запись	cn=ReplicationAgreementName, cn=replica,cn=suffixDN,cn=mapping tree,cn=config
Допустимые значения	от 0 до максимальной длины 64 бита
Значение по умолчанию	1000
Синтаксис	Целое число
Пример	nsds5ReplicaFlowControlWindow: 1000

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

Общее управление потоком обновлений дает потребителю время (2000 мс) перед отправкой дополнительных записей [отправлено msgid: xxx, rcv: yyy])
Если полное обновление не удается, вы можете попытаться увеличить nsds5ReplicaFlowControlPause и/или уменьшить nsds5ReplicaFlowControlWindow в конфигурации соглашения реплики.

FSMO роли в MS AD

В домене MS AD все контроллеры равны, но некоторые равнее других. Для уменьшения вероятности конфликтов и оптимизации работы репликации в MS AD есть пять ролей хозяина операций (flexible single-master operator, FSMO):

1. Новый домен в лес доменов MS AD может добавить только хозяин именования доменов (Domain Naming Master).

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

   Кстати, в ALD Pro сделан первый шаг на пути реализации лесов и с версии 2.3.0 вы уже сможете установить доверительные отношения между доменами ALD Pro. Это позволит создать дополнительные периметры безопасности, т. к. хеши паролей не покидают периметр домена, и снизить требования к аппаратным характеристикам контроллеров.

2. Схему каталога в MS AD может изменить только хозяин схемы (Schema Master).

   В службе каталога FreeIPA нет выделенной роли, изменить схему можно с любого контроллера в домене. Более того, вы можете не только добавлять, но и удалять атрибуты и классы объектов, хотя эти изменения относятся к небезопасным и их рекомендуется избегать.

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

3. Изменить фантомные объекты, являющиеся ссылками на объекты из других доменов леса в MS AD может только хозяин инфраструктуры (Infrastructure Master).

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

4. Диапазоном свободных идентификаторов в домене MS AD распоряжается только хозяин RID (Relative ID Master или RID Master). Этот хозяин выдает другим контроллерам свободные идентификаторы по 500 штук. Контроллеры запрашивают следующую пачку, когда количество свободных идентификаторов становится меньше 100.

   В службе каталога FreeIPA нет хозяина RID, им может стать любой контроллер домена. Если контроллеру потребуется идентификатор, то он заберет у соседа не 500 идентификаторов, а сразу половину всего оставшегося диапазона. За работу этого механизма отвечает плагин динамического назначения номеров DNA. Посмотреть DNA диапазоны, назначенные серверам, можно командой ipa-replica-manage dnarange-show.

5. И самая нагруженная роль в MS AD — это эмулятор PDC (Primary Domain Controller Emulator, PDC Emulator). Без этого контроллера все продолжает работать, но не так хорошо, как вместе с ним. Он отвечает за следующие операции:

   1. Является источником времени для контроллеров в домене.

      В домене ALD Pro эту функцию выполняют корневые NTP-сервера.

   2. В приоритетном порядке получает изменения паролей, чтобы успешно перепроверять аутентификацию пользователей, если пароль оказался неверным. Это ускорить распространение паролей в сети, уменьшая вероятность блокировки пользователей сразу после смены пароля.

      Учитывая, что в условиях недоступности эмулятора PDC проблем с паролями в домене не возникает, эта оптимизация не считается критически важной и в FreeIPA ее нет.

   3. Редактирование групповых политик по умолчанию выполняется через эмулятор PDC. Если эмулятор будет недоступен, то оснастка попросит указать явно контроллер, через который нужно вносить изменения.

      В FreeIPA и ALD Pro указанный подход не используется. Конфликты репликации объектов GPO без каких-либо проблем решаются в штатном порядке.

   4. Редактирование пространства имен DFS по умолчанию выполняется через эмулятор PDC, но конфликты при редактировании этих данных могли бы решаться и в штатном порядке.

Работа механизмов автоматического обнаружения сервисов

В домене ответственность за балансировку всегда возлагается на клиента. Механизмы AD и FreeIPA (SSSD) очень похожи, поэтому разберем подробно только одну сторону вопроса.

Автоматическое обнаружение при вводе хоста в домен утилитой ipa-client-install

Ввод машины в домен осуществляется с помощью утилиты aldpro-client-installer, которая по цепочке вызывает astra-freeipa-client и ipa-client-install. Передача параметров выполняется так, как представлено в таблице 1.

табл. 28 Передача параметров при вводе машины в домен

aldpro-client-installer →	astra-freeipa-client →	ipa-client-install
получает: --domain ald.company.lan --account admin --password 'AstraLinux_172' --host pc-1 --gui --force	получает: -d ald.company.lan -u admin -p AstraLinux_172 -y --par "--hostname=pc-1.ald.company.lan --force-join"	получает: 'domain_name': None, 'principal': 'admin', 'host_name': 'pc-1.ald.company.lan', 'force': False, 'force_join': True, 'mkhomedir': True, и др., при этом пароль не логируется
вызывает astra-freeipa-client -d "{domain_name}" -u "{login}" -p "{password}" -y --par "--hostname={host}.{domain_name} {" --force-join" if force else ""}"	вызывает ipa-client-install -U -p $username -w $userpass $par перед этим устанавливает hostnamectl set-hostname $compname.${domain,,}

Механизм автоматического обнаружения сервисов предусмотрен только в скрипте ipa-client-install и работает для определения следующих параметров:

• Realm/DNS Domain: ALD.COMPANY.LAN/ald.company.lan

  Область Керберос и fqdn домена, отличаются обычно только регистром символов. Можно сделать так, чтобы эти значения были разными, но такие настройки сложны и не имеют значительных преимуществ, поэтому не рекомендуются.

• IPA Server: dc-1.ald.company.lan

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

• Client hostname: pc-1.ald.company.lan

  FQDN имя, которое должно быть у компьютера после ввода в домен, DNS зона должна совпадать с fqdn домена. Если значения не будут совпадать, то работа хоста будет нарушена. Разработчики специально не сделали такую проверку, т.к. это дает гибкость в некоторых сценариях развертывания.

Если домен не указан явно через параметр --domain, то скрипт будет пытаться получить это значение из следующих источников:

• из параметра --host;

• из текущего имени компьютера hostname (используется имя, а не fqdn, т. е. это то значение, которое возвращает команда hostname, а не hostname -f);

• из файла resolv.conf, параметры search и domain.

Проверка имени домена выполняется путем извлечения SRV записей для протокола ldap по tcp. Для каждого fqdn скрипт проверяет все компоненты домена вверх по иерархии, поэтому, к примеру, если в переменной hostname было значение «pc-1.ald.company.lan», то скрипт установки проверит следующие SRV-записи:

• _ldap._tcp.ald.company.lan

• _ldap._tcp.company.lan

• _ldap._tcp.lan

Обратите внимание, что утилита astra-freeipa-client нарушает логику передачи параметров, т.к. вызывает утилиту ipa-client-install с значением {„domain_name“: None}, но перед этим она устанавливает в системе имя хоста «pc-1.ald.company.lan», поэтому ввод машины в домен отрабатывает корректно.

Сервер IPA можно указать явно через параметр server, но в том случае параметр domain также должен быть задан в явном виде. Если параметр server не будет указан, то сервер будет найден через поиск SRV-записей _ldap._tcp.DOMAIN.

При использовании опции server в файлы sssd.conf и krb5.conf будет внесен фиксированный список серверов. Параметр можно указывать несколько раз подряд, чтобы задать для переменной ipa_server список значений.

Автоматическое обнаружение сервисов в SSSD

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

[sssd]
domains = ald.company.lan

[domain/ald.company.lan]
id_provider = ipa
ipa_server = _srv_, dc-1.ald.company.lan
ipa_domain = ald.company.lan
ipa_hostname = pc-1.ald.company.lan
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True

Рассмотрим ключевые параметры бэкенда:

• ipa_provider — указывает, что в качестве поставщика идентификационных данных будет выступать сервер IPA

• ipa_server — задает список FQDN-имен и IP-адресов контроллеров домена в порядке, в каком нужно к ним подключаться. Может использоваться также служебное имя «_srv_», соответствующее механизму автоматического обнаружения (service discovery) через поиск SRV-записей «_ldap._tcp.DOMAIN», как указано в RFC 2782.

• ipa_backup_server — с помощью этого параметра можно указать список резервных серверов, которые будут выбираться только в случае недоступности основных. Этот параметр не предполагает возможности использования механизма автообнаружения.

• ipa_domain — указывает имя домена IPA. Это необязательный параметр, если он не указан, то используется доменное имя из названия конфигурации.

• ipa_hostname — требуется устанавливать на машинах, где имя хоста не соответствует полному имени компьютера, которое используется в домене IPA для идентификации этого хоста.

Записи SRV, создаваемые FreeIPA для своих сервисов, существенно отличаются от тех, которые можно создать вручную из интерфейса. Этим записям в каталоге назначен класс idnsTemplateObject и задано дополнительное свойство «idnsTemplateAttribute;cnamerecord», которое определяет шаблон подстановки для поддержки технологии сайтов (локаций).

рис. 309 Записи шаблонов, реализующие поддержку сайтов

Для привязки серверов к локациям у дочерних записей DN «cn=servers,cn=dns,dc=ald,dc=company,dc=lan» задано значение атрибута «idnsSubstitutionVariable;ipalocation», соответствующее имени сайта, в котором находится этот сервер.

рис. 310 Запись контроллера с информацией о принадлежности к сайту

Например, в домене из пяти контроллеров при обращении к DNS серверу 10.0.1.11 (dc-1.ald.company.lan) служба BIND9 выполняет подстановку и возвращает результат для _ldap._tcp.hq_locations.ald.company.lan, что соответствует сайту hq (англ. head quarters — головной офис). В список будут включены все контроллеры домена, но для серверов из сайта hq приоритет будет равен 0, а у всех остальных 50, поэтому служба SSSD в первую очередь будет обращаться к контроллерам из «своего» сайта, к которому компьютер косвенно привязан через обслуживающий его DNS-сервер.

 $ nslookup -q=SRV _ldap._tcp.ald.company.lan
 Server:         127.0.0.1
 Address:        127.0.0.1#53

 _ldap._tcp.ald.company.lan    canonical name = _ldap._tcp.hq._locations.ald.company.lan.
 _ldap._tcp.hq._locations.ald.company.lan      service = 50 100 389 dc-4.ald.company.lan.
 _ldap._tcp.hq._locations.ald.company.lan      service = 0 100 389 dc-1.ald.company.lan.
 _ldap._tcp.hq._locations.ald.company.lan      service = 0 100 389 dc-2.ald.company.lan.
 _ldap._tcp.hq._locations.ald.company.lan      service = 50 100 389 dc-3.ald.company.lan.
 _ldap._tcp.hq._locations.ald.company.lan      service = 50 100 389 dc-5.ald.company.lan.

После того, как список серверов определен, SSSD начинает искать доступный контроллер. Сначала SSSD выполняет поиск по серверам с приоритетом 0 из того же сайта, и только в случае неудачи переключается на остальные. Если компьютер работает в домене ALD Pro (FreeIPA), то проверка выполняется по одному серверу, а если провайдером выступает AD, то сервера проверяются группами по 5 штук, но доступность контроллера в любом случае определяется возможностью совершения анонимных LDAP-запросов.

SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeature

Если служба SSSD сможет получить TGT/TGS билеты для доступа к LDAP, используя /etc/krb5.keytab файл хоста, то она выполнит еще несколько авторизованных запросов для получения дополнительной информации о диапазонах идентификаторов, участии хоста в группах и др. настройках.

...
SRCH base="fqdn=pc-1.ald.company.lan,cn=computers,cn=accounts,dc=ald,dc=company,dc=lan" scope=0 filter="(objectClass=*)" attrs="objectClass cn memberOf ipaUniqueID"
...

Адрес сервера, с которым происходил обмен, будет сохранен как активный сервер, а FQDN остальных контроллеров, полученных через SRV-запрос, служба сохранит, как обнаруженные сервера (Discovered IPA servers).

Информацию о результатах автоматического обнаружения можно узнать с помощью утилиты sssctl из состава пакета sssd-tools. Данный инструмент администрирования взаимодействует со службой SSSD через Ответчик IFP по протоколу DBus.

$ sssctl domain-list
ald.company.lan

$ sssctl domain-status ald.company.lan
Online status: Online

Active servers:
IPA: dc-1.ald.company.lan

Discovered IPA servers:
- dc-1.ald.company.lan
- dc-3.ald.company.lan
- dc-2.ald.company.lan
- dc-4.ald.company.lan
- dc-5.ald.company.lan
- dc-1.ald.company.lan

Автоматическое обнаружение сервисов в библиотеке libkrb5

На обычном компьютере в домене

Для администрирования компьютеров в домене системные администраторы часто используют утилиты из пакета krb5-user, такие как kinit, klist и др., которые обращаются к функциям библиотеки libkrb5.

rood@pc-1:~# ldd $(which kinit)
...
        libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x0000721d7c1b5000)
...

Настройки этой библиотеки задаются в файле /etc/krb5.conf, но при установке sssd в папку плагинов libkrb5 копируется файл sssd_krb5_locator_plugin.so, поэтому, если служба sssd включена, то при выполнении kinit учитываются настройки из /etc/sssd/sssd.conf.

rood@pc-1:~# dpkg -S /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so
sssd-common: /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so

На доменном компьютере в файле sssd.conf в секции [domain/ald.company.lan] в параметре ipa_server первым значением по умолчанию идет «_srv_», поэтому служба sssd выполняет поиск сервера kdc через обращение к SRV записям _kerberos._tcp.ald.company.lan

[domain/ald.company.lan]
...
ipa_server = _srv_, dc-1.ald.company.lan
...

После автоматического обнаружения сервера провайдер аутентификации (auth-provider) службы sssd записывает IP-адрес контроллера и FQDN-имена еще двух запасных серверов в файл kdcinfo и функции Kerberos будут использовать эти данные для подключения.

 rood@pc-1:~# sssctl domain-status ald.company.lan
 Online status: Online

 Active servers:
 IPA: dc-1.ald.company.lan

 Discovered IPA servers:
 - dc-5.ald.company.lan
 - dc-1.ald.company.lan
 - dc-4.ald.company.lan
 - dc-3.ald.company.lan
 - dc-2.ald.company.lan
 - dc-1.ald.company.lan

# cat /var/lib/sss/pubconf/kdcinfo.ALD.COMPANY.LAN
10.0.1.11
dc-4.ald.company.lan
dc-3.ald.company.lan

Например, при выполнении kinit запрос сначала будет направляться к серверу c IP-адресом 10.0.1.11, в случае его недоступности к серверу dc-4.ald.company.lan, далее к dc-3.ald.company.lan и только в случае недоступности всех трех серверов запрос завершится ошибкой.

Если в параметре ipa_server убрать значение «_srv_» и оставить только FQDN контроллера, через который этот хост был введен в домен, то после перезапуска sssd все Kerberos-запросы пойдут только через указанный сервер.

Если службу sssd выключить, то библиотека libkrb5 будет выполнять поиск контроллера штатными механизмом. По умолчанию в файле /etc/krb5.conf, в секции [libdefaults] установлен параметр dns_lookup_kdc = true, поэтому поиск сервера будет выполняться через обращение к SRV-записям, но отличие будет состоять в том, что libkrb5 не поддерживает кэширования, поэтому автоматическое обнаружение будет срабатывать каждый раз при обращении к функциям библиотеки.

rood@pc-1:~# cat /etc/krb5.conf
[libdefaults]
...
  dns_lookup_kdc = true
...

Файл конфигурации krb5.conf позволяет отключать автоматическое обнаружение, тогда с помощью параметра kdc можно будет указать конкретный сервер

rood@pc-1:~# cat /etc/krb5.conf
[libdefaults]
...
  dns_lookup_kdc = false
...
[realms]
  ALD.COMPANY.LAN = {
    kdc = dc-1.ald.company.lan
...
  }

На контроллере домена

На контроллерах домена kinit ведет себя иначе, чем на доменных компьютерах, т.к. кроме службы sssd устанавливается еще и служба winbind, у которой есть собственный плагин winbind_krb5_locator.so.

 admin@dc-1:~$ ls -l /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/
 итого 36
 -rw-r--r-- 1 root root 19248 ноя 22 2021 sssd_krb5_locator_plugin.so
 -rw-r--r-- 1 root root 14840 июн 6 2022 winbind_krb5_locator.so

 admin@dc-1:~$ dpkg -S /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/winbind_krb5_locator.so
 winbind: /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/winbind_krb5_locator.so

Активный контроллер домена, предлагаемый службой winbind можно узнать через команду dsgetdcname утилиты wbinfo:

 root@dc-3:~# wbinfo --dsgetdcname ALD
 dc-2.ald.company.lan
 \\10.0.1.12
 1
 7afac3a6-d0e1-4bbf-85ab-04710eeee49e
 ald.company.lan
 ald.company.lan
 0xe00003fd
 Default-First-Site-Name
 Default-First-Site-Name

 root@dc-3:~# env KRB5_TRACE=/dev/stdout kinit admin <<< AstraLinux_172 | grep 10.0.1
 [23264] 1690099753.374402: Initiating TCP connection to stream 10.0.1.12:88
 [23264] 1690099753.374403: Sending TCP request to stream 10.0.1.12:88
 [23264] 1690099753.374404: Received answer (542 bytes) from stream 10.0.1.12:88
 [23264] 1690099753.374405: Terminating TCP connection to stream 10.0.1.12:88
 [23264] 1690099753.374432: Initiating TCP connection to stream 10.0.1.12:88
 [23264] 1690099753.374433: Sending TCP request to stream 10.0.1.12:88
 [23264] 1690099753.374434: Received answer (1587 bytes) from stream 10.0.1.12:88
 [23264] 1690099753.374435: Terminating TCP connection to stream 10.0.1.12:88

В поставке Samba идет также утилита net, которая тоже выдает информацию о KDC, но ее результаты расходятся с тем, какой сервер фактически используют утилиты kinit.

 root@dc-1:~# net ads info
 Failed to get server's current time!
 LDAP server: 10.0.1.13
 LDAP server name: dc-3.ald.company.lan
 Realm: ALD.COMPANY.LAN
 Bind Path: dc=ALD,dc=COMPANY,dc=LAN
 LDAP port: 389
 Server time: Чт, 01 янв 1970 03:00:00 MSK
 KDC server: 10.0.1.12
 Server time offset: 0
 Last machine account password change: Чт, 01 янв 1970 03:00:00 MSK

Автоматическое обнаружение сервисов в клиенте IPA

Для автоматизации управления доменом системные администраторы используют утилиту ipa, которая обращается к одному из контроллеров домена через REST API, используя прозрачную Kerberos-аутентификацию. После ее использования в связке ключей можно увидеть появление сервисного билета на доступ к службе HTTP конкретного контроллера.

root@dc-1:~# kinit admin
Password for admin@ALD.COMPANY.LAN:
root@dc-1:~# klist
Ticket cache: KEYRING:persistent:959800000:krb_ccache_mkw306I
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
13.08.2023 23:04:53  14.08.2023 23:04:50  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
root@dc-1:~# ipa user-show admin
  Имя учётной записи пользователя: admin
  Фамилия: Administrator
  Домашний каталог: /home/admin
  Оболочка входа: /bin/bash
  Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN
  UID: 959800000
  ID группы: 959800000
  Учётная запись отключена: False
  Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
  Пароль: True
  Участник групп: admins, trust admins, lpadmin
  Роли: ALDPRO - Main Administrator
  Доступные ключи Kerberos: True
root@dc-1:~# klist
Ticket cache: KEYRING:persistent:959800000:krb_ccache_mkw306I
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
13.08.2023 23:04:59  14.08.2023 23:04:50  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
13.08.2023 23:04:53  14.08.2023 23:04:50  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

1. Сначала используется значение директивы xmlrpc_uri из файла /etc/ipa/default.conf

2. Если сервер, указанный в default.conf, окажется недоступен, утилита ipa через запрос SRV записей _ldap._tcp.DOMAIN получит список всех доступных серверов и будет перебирать их случайным образом.

На контроллерах домена в файле /etc/ipa/default.conf указан также параметр ldap_uri, который определяет адрес для подключения бэкенда REST API к LDAP-каталогу. По умолчанию предполагается, что бэкенд подключается только к той службе каталога, которая работает на том же сервере, поэтому подключение выполняется через UNIX-сокет по ldapi (LDAP Over Interprocess Communication facilities, IPC).

rood@dc-1:~# cat /etc/ipa/default.conf
...
ldap_uri = ldapi://%2Frun%2Fslapd-ALD-COMPANY-LAN.socket
...

Автоматическое обнаружение сервисов клиентом LDAP

Для работы компьютера в домене утилиты OpenLDAP (ldapsearch, ldapmodify и др.) не требуются, но пакет ldap-utils устанавливается и настраивается автоматически для упрощения отладки возникающих проблем. За настройку LDAP-клиента отвечает скрипт ipaclient/install/client.py, который устанавливает в файле /etc/ldap/ldap.conf следующие параметры по умолчанию:

• TLS_CACERT /etc/ssl/certs/ca-certificates.crt

  Определяет путь к файлу с цепочкой SSL-сертификатов для проверки безопасности подключения по LDAPS и при использовании команды StartTLS.

• URI ldaps://dc-1.ald.company.lan

  Определяет протокол подключения LDAPS и путь к LDAP-серверу по умолчанию. Значение в файле соответствует адресу контроллера домена, через который был выполнен ввод машины в домен. Это значение не обновляется динамически, поэтому при недоступности данного сервера утилиты перестанут работать без указания другого сервера в явном виде через параметр -H.

• BASE dc=ald,dc=company,dc=lan

  Определяет DN записи, которая будет использоваться в качестве базы поиска по умолчанию.

• SASL_MECH GSSAPI

  Определяет механизм аутентификации, по умолчанию используется GSSAPI, т. е. Kerberos-аутентификация через связку ключей Linux.

Для обеспечения отказоустойчивости скриптов автоматизации вы можете использовать, например, результат автоматического обнаружения сервисов из файла kdcinfo:

ldapsearch -H ldaps://$(tail -n 1 /var/lib/sss/pubconf/kdcinfo.ALD.COMPANY.LAN)

Автоматическое обнаружение сервисов ALD Pro

Автоматическое определение сервисов для подключения агентов Salt Minion и Zabbix выполняет скрипт /opt/rbta/aldpro/client/bin/aldpro-service-discovery.py. Агент групповых политик Salt Minion Standalone выполняет самостоятельно.

Для определения списка серверов скрипт aldpro-service-discovery.py запрашивает SRV-записи _ldap._tcp.DOMAIN, в качестве FQDN домена используя значение параметра domain секции global из файла /etc/ipa/default.conf. В предыдущих реализациях в список вносились только контроллеры из того же сайта, с версии 1.4.0 скрипт вносит в начало списка контроллеры из того же сайта, а в конец добавляет все остальные.

Агент Zabbix отвечает за передачу данных на сервер мониторинга. Он может работать как в активном, так и в пассивном режимах. Настройки подключения к серверу находятся в файле /etc/zabbix/zabbix_agentd.conf.d/00-servers.conf Для определения сервера мониторинга скрипт aldpro-service-discovery.py выполняет запрос к REST API /discover/api/ds/monitoring/servers.

Агент Syslog-NG отвечает за передачу событий в подсистему журналирования. Он не предусматривает поддержки автоматического обнаружения сервисов и конфигурируется через SaltStack, за что отвечает скрипт syslogng_install.sls из папки /etc/salt/states/aldpro/automations/subsystems/projects/.

Отладка репликации

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

Получение сводной информации о соглашениях (dsconf)

Утилита dsconf показывает информацию по соглашениям о репликации текущего сервера, запускать нужно от имени root:

localadmin@dc-2:~$ sudo dsconf -j ALD-COMPANY-LAN replication status --suffix dc=ald,dc=company,dc=lan
{
   "type": "list",
   "items":  [
       {
            "agmt-name": [
               "meTodc-1.ald.company.lan"
            ],
            "replica": [
                "dc-1.ald.company.lan:389"
            ],
            "replica-enabled": [
                "on"
            ],
            "update-in-progress": [
                "FALSE"
            ],
            "last-update-start": [
                "20231121133318Z"
            ],
            "last-update-end": [
                "20231121133318Z"
            ],
            "number-changes-sent": [
                "3:3/19 "
            ],
            "number-changes-skipped": [
                "unavailable"
            ],
            "last-update-status": [
                "Error (0) Replica acquired successfully: Incremental update succeeded"
            ],
            "last-init-start": [
                "19700101000000Z"
            ],
            "last-init-end": [
                "19700101000000Z"
            ],
            "last-init-status": [
                "unavailable"
            ],
            "reap-active": [
                "0"
            ],
            "replication-status": [
                "Not in Synchronization: supplier (655ca929000300030000) consumer (Unavailable) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)"
            ],
            "replication-lag-time": [
                "unavailable"
            ]
       }
   ]
}

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

localadmin@dc-2:~$ sudo apt install jq -y;
localadmin@dc-2:~$ sudo -i;
localadmin@dc-2:~$ (printf 'SUFFIX \tAGREEMENT \tSTATE \tTIME-SINCE \tLDAP-STATUS \tREPL-STATUS \n'; dsconf -j ALD-COMPANY-LAN replication list | jq '.items[]' -r | xargs -P8 -i -- dsconf -j ALD-COMPANY-LAN repl-agmt list --suffix={} | jq '.items[].attrs | (.nsds5replicalastupdatestatusjson[0] | fromjson) as $status | [.nsds5replicaroot[0], .cn[0], $status.state, $status.date, $status.ldap_rc_text, $status.repl_rc_text] | @tsv' -r | sort ) | column -s$'\t' -t;exit

рис. 311 Информация о соглашении в табличном виде.

Сравнение данных между двумя контроллерами (ds-replcheck)

Для проверки состояния репликации между двумя конкретными серверами RedHat предлагает использовать утилиту ds-replcheck. Секция «Supplier RUV» показывает данные, известные о Мастере (Поставщике) на Реплике (Потребителе), а секция «Replica RUV» наоборот показывает, данные о Реплике (Потребителе), известные на Мастере (Поставщике).

ds-replcheck online -D "cn=Directory Manager" -m ldap://dc-1.ald.company.lan:389 -r ldap://dc- 2.ald.company.lan:389 -b dc=ald,dc=company,dc=lan

localadmin@dc-2:~$ ds-replcheck online -D "cn=Directory Manager" -m ldap://dc-1.ald.company.lan:389 -r ldap://dc-2.ald.company.lan:389 -b dc=ald,dc=company,dc=lan
Enter password:
================================================================================
Replication Synchronization Report (Tue Nov 21 16:55:30 2023)
================================================================================


Database RUV's
=====================================================

Supplier RUV:
 {replica 3 ldap://dc-2.ald.company.lan:389} 655ca76b000000030000 655ca929000300030000
 {replica 4 ldap://dc-1.ald.company.lan:389} 655ca759000000040000 655cb587000000040000
 {replicageneration} 655ca758000000040000

Replica RUV:
 {replica 3 ldap://dc-2.ald.company.lan:389} 655ca76b000000030000 655caa96000000030000
 {replica 4 ldap://dc-1.ald.company.lan:389} 655ca759000000040000 655cb587000000040000
 {replicageneration} 655ca758000000040000

 Replication State: Supplier and Replica are in perfect synchronization


 Entry Counts
 =====================================================

 Supplier: 2318
 Replica: 2318

 Tombstones
 =====================================================

 Supplier: 8
 Replica: 8

 Entry Inconsistencies
 =====================================================

 uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
 -------------------------------------------------------
 - Attribute 'krblastfailedauth' is different:
      Supplier:
        - Origin value: b'20231121123000Z'

      Replica:
        - Value:      20231121130311Z
        - State Info: krbLastFailedAuth;adcsn-655caa8f000000030000;vucsn-655caa8f000000030000:
 20231121130311Z
        - Date: Tue Nov 21 16:03:11 2023

 krbprincipalname=ldap/dc- 1.ald.company.lan@ALD.COMPANY.LAN,cn=services,cn=accounts,dc=ald,dc=company,dc=lan
 ------------------------------------------------------------------------------------------------------------
 - Replica missing attribute: "krbloginfailedcount"

 idnsname=ald.company.lan.,cn=dns,dc=ald,dc=company,dc=lan
 ---------------------------------------------------------
 - Attribute 'idnssoaserial' is different:
      Supplier:
        - Value:      1700571291
        - State Info: idnsSOAserial;adcsn-655ca896000100040000;vucsn-655ca896000100040000:
 1700571291
        - Date: Tue Nov 21 15:54:46 2023
      Replica:
        - Value:      1700571405
        - State Info: idnsSOAserial;adcsn-655ca90d000000030000;vucsn-655ca90d000000030000:
 1700571405
        - Date: Tue Nov 21 15:56:45 2023


 idnsname=1.0.10.in-addr.arpa.,cn=dns,dc=ald,dc=company,dc=lan
 -------------------------------------------------------------
 - Attribute 'idnssoaserial' is different:
      Supplier:
        - Value:      1700571207
        - State Info: idnsSOAserial;adcsn-655ca846000900040000;vucsn-655ca846000900040000:
 1700571207
        - Date: Tue Nov 21 15:53:26 2023

      Replica:
         - Value:      1700571406
         - State Info: idnsSOAserial;adcsn-655ca90e000000030000;vucsn-655ca90e000000030000:
 1700571406
        - Date: Tue Nov 21 15:56:46 2023


 krbprincipalname=DNS/dc- 1.ald.company.lan@ALD.COMPANY.LAN,cn=services,cn=accounts,dc=ald,dc=company,dc=lan
 -----------------------------------------------------------------------------------------------------------
 - Replica missing attribute: "krbloginfailedcount"
 krbprincipalname=ipa-dnskeysyncd/dc-1.ald.company.lan@ALD.COMPANY.LAN,cn=services,cn=accounts,dc=ald,dc=company, dc=lan
 -----------------------------------------------------------------------------------------------------------------------

 - Replica missing attribute: "krbloginfailedcount"

 krbprincipalname=DNS/dc- 2.ald.company.lan@ALD.COMPANY.LAN,cn=services,cn=accounts,dc=ald,dc=company,dc=lan
 -----------------------------------------------------------------------------------------------------------
 - Supplier missing attribute: "krbloginfailedcount"

 - Replica's State Info: krbLoginFailedCount;vucsn-655ca847000700030000: 0
 - Date: Tue Nov 21 15:53:27 2023


 krbprincipalname=ipa-dnskeysyncd/dc -2.ald.company.lan@ALD.COMPANY.LAN,cn=services,cn=accounts,dc=ald,dc=company, dc=lan
 ------------------------------------------------------------------------------------------------------------------------
 - Supplier missing attribute: "krbloginfailedcount"

 - Replica's State Info:  krbLoginFailedCount;vucsn-655ca84e000100030000: 0
 - Date: Tue Nov 21 15:53:34 2023


 Result
 =====================================================

 There are replication differences between Supplier and Replica

Сводная статистика по состоянию репликации (checkipaconsistency)

Внимание

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

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

sudo -i

Теперь выполним установку вспомогательных пакетов:

apt install libsasl2-dev python-dev libldap2-dev libssl-dev python-pip

Проверим работоспособность pip и установим утилиту cipa:

pip --version
pip install --user checkipaconsistency

Добавим ссылку на запуск по сокращенному имени cipa:

ln -s /root/.local/bin/cipa /usr/bin/cipa

Проверим репликацию. Чтобы пароль не сохранился в истории, вы можете отключить ее или добавить пробел в начало строки.

root@dc-2:~# set +o history
root@dc-2:~# cipa -d ald.company.lan -W 'AstraLinux_174'
Initial config saved to /root/.config/checkipaconsistency - PLEASE EDIT IT!
+--------------------+---------+---------+-------+
| FreeIPA servers:   | dc-2    | dc-1    | STATE |
+--------------------+---------+---------+-------+
| Active Users       | 1       | 1       | OK    |
| Stage Users        | 0       | 0       | OK    |
| Preserved Users    | 0       | 0       | OK    |
| Hosts              | 3       | 3       | OK    |
| Services           | 9       | 9       | OK    |
| User Groups        | 6       | 6       | OK    |
| Host Groups        | 1       | 1       | OK    |
| Netgroups          | 0       | 0       | OK    |
| HBAC Rules         | 2       | 2       | OK    |
| SUDO Rules         | 0       | 0       | OK    |
| DNS Zones          | 2       | 2       | OK    |
| Certificates       | 0       | 0       | OK    |
| LDAP Conflicts     | 0       | 0       | OK    |
| Ghost Replicas     | 0       | 0       | OK    |
| Anonymous BIND     | ROOTDSE | ROOTDSE | OK    |
| Microsoft ADTrust  | False   | True    | FAIL  |
| Replication Status | dc-1 0  | dc-2 0  | OK    |
+--------------------+---------+---------+-------+
root@dc-2:~# set -o history

Примечание

Если в момент повышения роли сервера пользователь «admin» не состоял в группе «ald trust admin», то в выводе этой команды вы увидите, что проверка Microsoft ADTrust на dc-2 была провалена, т.е. там будет False.

+--------------------+---------+---------+-------+
| FreeIPA servers:   | dc-2    | dc-1    | STATE |
+--------------------+---------+---------+-------+
. . .
| Microsoft ADTrust  | False   | True    | FAIL  |
| Replication Status | dc-1 0  | dc-2 0  | OK    |
+--------------------+---------+---------+-------+

В этом случае вам необходимо будет:

• Все-таки добавить пользователя «admin» в группу «ald trust admin»

• Выполнить команду sudo ipa-adtrust-install на dc-2

Просмотр количества изменений по соглашению (ldapsearch)

Довольно полезным видится атрибут nsds5replicaChangesSentSinceStartup, который может показать, сколько изменений прошло через конкретное соглашение о репликации:

admin@dc-1:~$ ldapsearch -LLL -b 'cn=mapping tree,cn=config' '(objectClass=nsDS5ReplicationAgreement)' nsds5replicaChangesSentSinceStartup | perl -MMIME::Base64 -Mutf8 -pe 's/^([-a-zA-Z0-9;]+):(:\s+)(\S+)$/$1.$2.&decode_base64($3)/e'
. . .
nsds5replicaChangesSentSinceStartup: 4:255/43681

Просмотр журнала изменений (dbscan)

В ходе расследования инцидентов вам может потребоваться заглянуть в журнал изменений, сделать это можно с помощью утилиты dbscan:

admin@dc-1:~$ sudo dbscan -f /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/db/userRoot/replication_changelog.db | head -n 15
dbid: 66158532000000040000
       encrypted: no
       replgen: 1712686215 Tue Apr 9 21:10:15 2024
       csn: 66158532000000040000
       uniqueid: 88e30e06-bf4e11ee-9d29cb43-d00727f4
       dn: cn=repl keep alive 4,dc=ald,dc=company,dc=lan
       operation: modify
               keepalivetimestamp: 20240409181015Z
               modifiersname: cn=Multisupplier Replication Plugin,cn=plugins,cn=config
               modifytimestamp: 20240409181015Z
               entryusn: 1394188

dbid: 66158534000000040000
       encrypted: no

Просмотр таблицы RUV (dsconf)

Посмотреть таблицу RUV можно с помощью команды replication get-ruv утилиты dsconf:

sudo dsconf -D 'cn=Directory Manager' -w Astra_Linux_174 ALD-COMPANY-LAN replication get-ruv --suffix dc=ald,dc=company,dc=lan

 admin@dc-1:~$ sudo dsconf -D 'cn=Directory Manager' -w Astra_Linux_174 ALD-COMPANY-LAN replication get-ruv --suffix dc=ald,dc=company,dc=lan
 RUV:        {replica 4 ldap://dc-1.ald.company.lan:389} 65b8bb9f000100040000 6643fc28000000040000
 Replica ID: 4
 LDAP URL:   ldap://dc-1.ald.company.lan:389
 Min CSN:    2024-01-30 09:04:31 1 0 (65b8bb9f000100040000)
 Max CSN:    2024-05-15 00:04:56 (6643fc28000000040000)

 RUV:        {replica 3 ldap://dc-2.ald.company.lan:389} 65b8bba3000100030000 6616b4be000000030000
 Replica ID: 3
 LDAP URL:   ldap://dc-2.ald.company.lan:389
 Min CSN:    2024-01-30 09:04:35 1 0 (65b8bba3000100030000)
 Max CSN:    2024-04-10 15:48:14 (6616b4be000000030000

Просмотр конфликтов репликации (dsconf)

Конфликты репликации можно посмотреть через dsconf или прямыми запросами в LDAP:

sudo dsconf -D "cn=Directory Manager" ldap://dc-1.ald.company.lan repl-conflict list dc=ald,dc=company,dc=lan

 admin@dc-1:~$ sudo dsconf -D "cn=Directory Manager" ldap://dc-1.ald.company.lan repl-conflict list dc=ald,dc=company,dc=lan
 Enter password for cn=Directory Manager on ldap://dc-1.ald.company.lan:
 There were no conflict entries found under the suffix

Повторная инициализация контроллера

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

1. Открыть страницу «Управление доменом –> Сайты и службы –> Соглашения о репликации».

2. Открыть соглашение о репликации, в котором участвует контроллер, восстановленный из резервной копии.

3. Нажать на кнопку «Переинициализировать контроллер домена» рядом с тем контроллером, который был восстановлен из резервной копии.

рис. 312 Переинициализация контроллера домена

То же самое можно сделать и из командной строки. Для переинициализации заходим на поврежденную реплику и запускаем команду реинициализации:

admin@dc-1:~$ sudo ipa-replica-manage re-initialize --from dc-2.ald.company.lan

Где:

• ключ re-initialize — это подкоманда реинициализации реплики;

• ключ --from - указывает реплику, с которой нужно забрать исходные данные, например, dc-2.ald.company.lan.

Механика работы плагина топологии и односторонние соглашения о репликации

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

Как вы уже знаете, в домене FreeIPA есть сегменты и соглашения. Напомним, что сегменты являются реплицируемой информацией и находятся в корневом суффиксе домена «cn=domain,cn=topology,cn=ipa,cn=etc,dc=ald,dc=company,dc=lan», а соглашения о репликации находятся в «cn=replica,cn=dc\3Dald\2Cdc\3Dcompany\2Cdc\3Dlan,cn=mapping tree,cn=config» и не реплицируются между контроллерами.

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

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

Проблема «односторонних соглашений репликации» возникает по причине «гонок» между двумя взаимообратными процессами:

1. первый процесс отвечает за создание соглашений о репликации для новой реплики;

2. второй процесс отвечает за удаление соглашений при удалении сегментов топологии.

Проблема решается увеличением таймаута nsslapd-topo-plugin-startup-delay, например, до 40 секунд, и будет применена в одном из следующих релизов. Но, если вам потребуется исправить «односторонние» соглашения на работающем стенде, то нужно выполнить следующие команды:

$ kinit admin
$ ldapsearch -LLL -o ldif-wrap=no -b "cn=domain,cn=topology,cn=ipa,cn=etc,dc=ald,dc=company,dc=lan" "(ipaReplTopoSegmentDirection=left-right)" > left-right.ldif
$ cat left-right.ldif | sed 's/-to-/-from-/' | sed 's/left-right/right-left/' > right-left.ldif
$ ldapadd -f right-left.ldif

Как видите, сначала мы выгружаем односторонние Сегменты в файл left-right.ldif. Затем делаем две подстановки «-to-» на «-from-» и «left-right» на «right-left», сохраняя результаты в новом файле. И на последнем шаге загружаем полученные записи в каталог. После чего останется только перезапустить службу каталога на проблемных контроллерах.

Допустим, у нас было одностороннее соглашение в направлении dc-1 => dc-2. В момент загрузки контроллеров будут выполнены следующие действия:

1. Плагин топологии dc-2 увидит rigth-left Сегмент в обратном направлении без соответствующего Соглашения о репликации и создаст его.

2. После создания Сегмента плагин топологии dc-2 добавит к Соглашению о репликации атрибут ipaReplTopoManagedAgreementState, чтобы это Соглашение можно было удалить через управление топологией.

3. Плагин топологии dc-1 обнаружит, что в домене есть два взаимообратных «Left-Right» и «Right-Left» Сегмента, поэтому Сегмент dc-2 => dc-1 он удалит, а для Сегмента dc-1 => dc-2 изменит направление с «Left-Right» на «Both».

Практика и тестирование

• Практическая работа: Модуль 8. Управление топологией в домене
• Тест: Модуль 8. Управление топологией в домене

Заключение

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

Дополнительные источники информации:

• Теорема CAP