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

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

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

Таблица 22 Передача параметров при вводе машины в домен

aldpro-client-installer >	astra-freeipa-client >	ipa-client-install
получает: --domain ald.company.lan --account admin --password 'AstraLinux_176' --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, и др.
вызывает: /usr/bin/astra-freeipa-client -d "{domain_name}" -u "{login}" -y --par "--hostname=pc-1.ald.company.lan --force-join"	устанавливает: hostnamectl set-hostname $compname. ${domain} и далее вызывает: ipa-client-install -U -p $username -w $userpass $par

Механизм автоматического обнаружения сервисов предусмотрен только в скрипте 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-записи:

1. _ldap._tcp.ald.company.lan

2. _ldap._tcp.company.lan

3. _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

Ключевые параметры бэкенда:

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

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

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

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

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

Рисунок 37 Шаблон записи для SRV-записей в DNS

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

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

Рисунок 38 Атрибут idnsSubstitutionVariable для контроллера домена dc-1

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-запросов, например, выдержка из журнала /var/log/dirsrv/access.log:

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

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

...
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 напрямую через SBus.

sudo sssctl domain-list

Результат выполнения список доменов:

ald.company.lan

Вывести статус по имени домена:

sudo 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.

sudo ldd $(which kinit) | grep libkrb5

Результат выполнения:

libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fa558914000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fa5588cb000)

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

sudo 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.

cat /etc/sssd/sssd.conf

Параметр ipa_server в конфигурационном файле sssd.conf:

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

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

sudo 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

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

sudo cat /var/lib/sss/pubconf/kdcinfo.ALD.COMPANY.LAN

где ALD.COMPANY.LAN - домен предприятия.

Результат выполнения:

10.0.1.12
dc-1.ald.company.lan
dc-3.ald.company.lan

Например, при выполнении kinit запрос сначала будет направляться к серверу c IP адресом 10.0.1.11, в случае его недоступности к серверу dc-2.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 не поддерживает кэширование, поэтому автоматическое обнаружение будет срабатывать каждый раз при обращении к функциям библиотеки.

sudo cat /etc/krb5.conf | grep dns_lookup_kdc

Результат выполнения команды:

dns_lookup_kdc = true

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

sudo cat /etc/krb5.conf

Настройка параметра kdc на конкретный сервер dc-1:

[libdefaults]
...
dns_lookup_kdc = false
...
[realms]
 ALD.COMPANY.LAN = {
  kdc = dc-1.ald.company.lan
  ...
 }

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

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

ls -l /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/

Результат выполнения на dc-1:

-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

Посмотреть какому пакету принадлежит файл библиотеки можно командой:

sudo 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:

wbinfo --dsgetdcname ALD.COMPANY.LAN

Результат выполнения команды:

dc-1.ald.company.lan
\\10.0.1.11
1
f35731b8-81fe-46c3-ac8f-feb6deb55889
ald.company.lan
ald.company.lan
0xe00003fd
Default-First-Site-Name
Default-First-Site-Name

Включить отладку Kerberos для проверки работы можно включив переменную KRB5_TRACE:

sudo i
set +o history
env KRB5_TRACE=/dev/stdout kinit admin <<< AstraLinux_176
set -o history
exit

Результат выполнения трассировки:

[3126] 1696423198.013624: Getting initial credentials for admin@ALD.COMPANY.LAN
[3126] 1696423198.013626: Sending unauthenticated request
[3126] 1696423198.013627: Sending request (191 bytes) to ALD.COMPANY.LAN
[3126] 1696423198.013628: Initiating TCP connection to stream 10.0.1.11:88
[3126] 1696423198.013629: Sending TCP request to stream 10.0.1.11:88
[3126] 1696423198.013630: Received answer (513 bytes) from stream 10.0.1.11:88
[3126] 1696423198.013631: Terminating TCP connection to stream 10.0.1.11:88
[3126] 1696423198.013632: Response was from master KDC
[3126] 1696423198.013633: Received error from KDC: -1765328359/Additional pre-authentication required
[3126] 1696423198.013636: Preauthenticating using KDC method data
[3126] 1696423198.013637: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[3126] 1696423198.013638: Selected etype info: etype aes256-cts, salt "T1!dGW5C](`}^?2R", params ""
[3126] 1696423198.013639: Received cookie: MIT1\x00\x00\x00\x01uw\x951\xbb\x06ew\x88]G\xa7\x87J\xf3\x02\xcb\xaf\x97<:\x0d\xa1\xb0\x96\xb4,\xbc\xd2\xb6\x0c\xce\xa4"?\xa6\xe8\xf1\xa5\xf4\xe6K\x01\x00\xe2\x02Z6\x18#M\xf8\xd4w\x17\xcd\xc5S\xe8\x13;\xa6\x01t2\xc6M\xdf\xddHIs{#\xc9\x15\xe2\x9d\x1f\x9c\xd20.\x00 gG\x9d\xfb\x0c\x80\x04'\x9f\x8bZJt-S'\x06\x97\xd8\x92;\xa5^~Ep*\x81T\xff\x7f\xd0\xb7\x9b\xf6Y\xf4\xdb\xd9,\xbb\x1a\x93\xd8\xca
[3126] 1696423198.013640: PKINIT client has no configured identity; giving up
[3126] 1696423198.013641: Preauth module pkinit (147) (info) returned: 0/Success
[3126] 1696423198.013642: PKINIT client received freshness token from KDC
[3126] 1696423198.013643: Preauth module pkinit (150) (info) returned: 0/Success
[3126] 1696423198.013644: PKINIT client has no configured identity; giving up
[3126] 1696423198.013645: Preauth module pkinit (16) (real) returned: 22/Недопустимый аргумент
[3126] 1696423198.013646: SPAKE challenge received with group 1, pubkey 2F4F0F1B95AF467E3A718CB0B881B2C73FA1D9D132FC15DCD0CE504BC58ED756
Password for admin@ALD.COMPANY.LAN:
[3126] 1696423198.013647: SPAKE key generated with pubkey EFFC0DE0B82CEEBD2B715C87EED0EA086C5F8E9E79570593A4C302125DE253D8
[3126] 1696423198.013648: SPAKE algorithm result: 5C447C5BB317672F202E15DC5B54C2DB2288D87D7AE12F75A9FFB6F825A0D930
[3126] 1696423198.013649: SPAKE final transcript hash: F2250C79047924FEAD1416E2B75948CCF3BABD80E9B821CA03C47A74D1D69985
[3126] 1696423198.013650: Sending SPAKE response
[3126] 1696423198.013651: Preauth module spake (151) (real) returned: 0/Success
[3126] 1696423198.013652: Produced preauth for next request: PA-FX-COOKIE (133), PA-SPAKE (151)
[3126] 1696423198.013653: Sending request (450 bytes) to ALD.COMPANY.LAN
[3126] 1696423198.013654: Initiating TCP connection to stream 10.0.1.11:88
[3126] 1696423198.013655: Sending TCP request to stream 10.0.1.11:88
[3126] 1696423198.013656: Received answer (1575 bytes) from stream 10.0.1.11:88
[3126] 1696423198.013657: Terminating TCP connection to stream 10.0.1.11:88
[3126] 1696423198.013658: Response was from master KDC
[3126] 1696423198.013659: AS key determined by preauth: aes256-cts/297C
[3126] 1696423198.013660: Decrypted AS reply; session key is: aes256-cts/D405
[3126] 1696423198.013661: FAST negotiation: available
[3126] 1696423198.013662: Initializing KEYRING:persistent:1421600000:krb_ccache_zlQRxEn with default princ admin@ALD.COMPANY.LAN
[3126] 1696423198.013663: Storing admin@ALD.COMPANY.LAN → krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN in KEYRING:persistent:1421600000:krb_ccache_zlQRxEn
[3126] 1696423198.013664: Storing config in KEYRING:persistent:1421600000:krb_ccache_zlQRxEn for krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN: fast_avail: yes
[3126] 1696423198.013665: Storing admin@ALD.COMPANY.LAN → krb5_ccache_conf_data/fast_avail/krbtgt\/ALD.COMPANY.LAN\@ALD.COMPANY.LAN@X-CACHECONF: in KEYRING:persistent:1421600000:krb_ccache_zlQRxEn
[3126] 1696423198.013666: Storing config in KEYRING:persistent:1421600000:krb_ccache_zlQRxEn for krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN: pa_type: 151
[3126] 1696423198.013667: Storing admin@ALD.COMPANY.LAN → krb5_ccache_conf_data/pa_type/krbtgt\/ALD.COMPANY.LAN\@ALD.COMPANY.LAN@X-CACHECONF: in KEYRING:persistent:1421600000:krb_ccache_zlQRxEn

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

sudo net ads info

Результат выполнения:

Failed to get server's current time!
LDAP server: 10.0.1.11
LDAP server name: dc-1.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.11
Server time offset: 0
Last machine account password change: Чт, 01 янв 1970 03:00:00 MSK

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

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

klist

В результате в списке только krbtgt билет:

Ticket cache: KEYRING:persistent:1421600000:krb_ccache_zlQRxEn
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
04.10.2023 15:52:52  05.10.2023 15:52:47  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

ipa user-show admin

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

Имя учётной записи пользователя: admin
Фамилия: Administrator
Домашний каталог: /home/admin
Оболочка входа: /bin/bash
Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN
UID: 1421600000
ID группы: 1421600000
Учётная запись отключена: False
Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
Link to head department: ald.company.lan
Пароль: True
Участник групп: admins, lpadmin, trust admins, ald trust admin
Роли: ALDPRO - Main Administrator
Доступные ключи Kerberos: True

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

Ticket cache: KEYRING:persistent:1421600000:krb_ccache_zlQRxEn
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
04.10.2023 15:54:55  05.10.2023 15:52:47  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
04.10.2023 15:52:52  05.10.2023 15:52:47  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

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

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

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

cat /etc/ipa/default.conf | grep ldap_uri

Результат выполнения:

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 — определяет путь к файлу с цепочкой SSL сертификатов для проверки безопасности подключения по LDAPS и при использовании команды StartTLS.

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

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

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

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

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

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

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

Для определения списка серверов скрипт 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/.