Модуль 5. Работа Linux-компьютера в домене

Введение

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

Служба sssd

Краткий обзор

За работу компьютера в домене отвечает служба sssd, которая была создана в рамках проекта FreeIPA и является на сегодняшний день лучшим решением для обеспечения работы компьютера Linux в составе доменов на базе FreeIPA, MS Active Directory, Samba AD, MIT KDC или даже простого LDAPv3. Однако максимально свои возможности sssd раскрывает, конечно же, когда на бэкенде у нее служба каталога FreeIPA, и продукт ALD Pro построен как раз на базе этой службы каталога, поэтому в конфигурационных файлах /etc/sssd/sssd.conf на доменных компьютерах будет указан поставщик «ipa»:

admin@pc-1:~$ sudo cat /etc/sssd/sssd.conf | grep id_provider
id_provider = ipa

Как рассказывал Александр Боковой, один из ведущих разработчиков FreeIPA, официально аббревиатура sssd расшифровывается как System Security Services Daemon (Демон служб системной безопасности), но на самом деле эти слова были подобраны под имена четырех основателей: Simo Sorce, Sumit Bose, Stephen Gallagher и Dmitri Pal. Так что еще один наш бывший соотечественник Дмитрий Пал внес огромный вклад в развитие систем идентификации Linux.

Основная задача службы sssd заключается в предоставлении доступа к информации удаленной службы каталога и механизмам централизованной аутентификации. Для обработки запросов на аутентификацию служба sssd на доменных компьютерах встраивает свой модуль pam_sss.so в PAM-стек, см. файлы common-* из папки /etc/pam.d:

admin@dc-1:~$ ls /etc/pam.d
chfn                                   common-session.pam-old  runuser
chpasswd                               cron                    runuser-l
chsh                                   cups                    samba
common-account                         fly-dm                  sshd
common-account.pam-old                 fly-dm-greeter          sssd-shadowutils
common-auth                            fly-dm-np               su
common-auth.pam-old                    fly-wm                  sudo
common-password                        login                   su-l
common-password.pam-old                newusers                sumac.xauth
common-session                         other                   systemd-user
common-session-noninteractive          passwd
common-session-noninteractive.pam-old  polkit-1

Для обработки запросов на идентификацию служба sssd встраивает свои модули в NSS-стек, см. файл /etc/nsswitch.conf.

admin@dc-1:~$ cat /etc/nsswitch.conf
...
passwd: files sss
group: files sss
shadow: files sss
gshadow: files
...

Управление службой осуществляется через systemctl с помощью стандартного набора команд start, stop, restart и status, но не пытайтесь проверять команду stop из непривилегированной сессии, поскольку остановить службу вы сможете, а запустить повторно уже нет, т.к. выполнение команд из-под sudo вам станет недоступно и придется ждать пару минут, пока служба sssd будет запущена автоматически.

admin@pc-1:~$ systemctl status sssd
sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Apr 2025-04-07 22:38:35 MSK; 15s ago
 Main PID: 3740 (sssd)
    Tasks: 4 (limit: 4597)
   Memory: 10.1M
   CGroup: /system.slice/sssd.service
           ├─3740 /usr/sbin/sssd -i --logger=files
           ├─3741 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain ald.company.lan --uid 0 --gid 0 --logger=files
           ├─3742 /usr/lib/x86_64-linux-gnu/sssd/sssd_ifp --uid 0 --gid 0 --logger=files
           └─3743 /usr/lib/x86_64-linux-gnu/sssd/sssd_pac --uid 0 --gid  --logger=files

Модули службы sssd и другие клиентские приложения реализуют поддержку протокола Kerberos не напрямую, а через общий программный интерфейс сервисов безопасности (англ. Generic Security Services API, GSSAPI). Это позволяет заменять библиотеки, используемые GSS-API, без необходимости переписывать все приложения.

Для поддержки протокола Kerberos V5 через GSSAPI используются библиотеки libgssapi-krb5, librkb5 и др. В соответствии с настройкой default_ccache_name из конфигурационного файла /etc/krb5.conf для хранения полученных билетов библиотека использует связку ключей Linux (KEYRING). Управлять билетами можно с помощью утилит из пакета krb5-user, таких как kinit, klist, kdestroy, kvno и др.

Интерфейс GSSAPI позволяет не только устанавливать безопасный контекст, но и выполнять шифрование сообщений. Поэтому при выполнении LDAP-запросов с аутентификацией по Kerberos данные будут зашифрованы внутри средствами GSSAPI.

Архитектура службы sssd

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

В состав службы входят следующие компоненты:

• монитор (англ. Monitor);

• серверные части или Бэкенды (англ. Backends);

• ответчики (англ. Responders);

• клиентские библиотеки и приложения.

рис. 257 Архитектура службы sssd

Монитор (Monitor)

Служба sssd.service порождает процессы всех других компонентов и управляет ими, обеспечивая их слаженную работу, поэтому службу называют «Монитором», т.к. в английском языке это слово имеет также значение «Наставник», что довольно точно отражает роль данного компонента.

Монитор взаимодействует с остальными компонентами по протоколу S-Bus, который является собственной реализацией протокола D-Bus, т.е. компоненты не регистрируют себя в системной шине D-Bus и обратиться к ним напрямую не получится. Для возможности управления службой по D-Bus предназначен ответчик IFP (англ. info pipe), через него, например, утилита sssctl получает информацию об активном контроллере, который обслуживает хост.

На рис. 258 представлена диаграмма процесса загрузки службы:

• В момент запуска Монитор анализирует файл конфигурации sssd.conf (1) и загружает его в кэш /var/lib/sss/db/config.ldb (2).

• Далее Монитор, используя системные вызовы, порождает процесс Бэкенда (3), который загружает информацию из config (4, 5) и регистрирует себя в Мониторе (6).

• На следующем шаге Монитор порождает Ответчиков NSS и PAM (7), которые считывают информацию из config (8, 9) и регистрируются в Мониторе (10) и Бэкенде (11).

рис. 258 Диаграмма загрузки службы sssd

Помимо внутреннего взаимодействия через SBus, служба sssd использует UNIX-сигналы, например, в тех случаях, когда процесс завис и не отвечает через SBus. Обработчики сигналов обычно интегрированы с главным циклом событий tevent с использованием вызова tevent_add_signal:

• SIGTERM — сигнал на завершение работы процесса.

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

• SIGUSR1 / SIGUSR2 — сигналы на переключение Бэкенда в автономный режим и обратно. Если сигнал будет направлен Монитору, то он перешлет его всем своим дочерним процессам sssd_be.

• SIGHUP — может быть передан Монитору, после чего тот начнет новый лог-файл и вызовет метод сброса журналов управляемым процессам, что крайне удобно при отладке. Кроме того, процессы sssd_be перечитают resolv.conf, а процесс sssd_nss выполнит очистку быстрого кэша.

Серверные части или Бэкенды (Backends)

Бэкенд (англ. Backend, BE) – это процесс приложения /usr/lib/x86_64-linux-gnu/sssd/sssd_be, который запускается Монитором для взаимодействия с доменом в соответствии с настройками секции [domain/<имя_домена>] конфигурационного файла /etc/sssd/sssd.conf. Бэкенд не является монолитом и в зависимости от настроек подключает один и более Поставщиков данных (англ. Data Provider, DP), каждый из которых представляет собой совместно используемую библиотеку (англ. Shared Object, SO).

admin@dc-1:~$ sudo ps -aux | grep sssd_be
[sudo] пароль для admin:
root       724  0.0  0.5 118844 23728 ?        S    12:05   0:00 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain ald.company.lan --uid 0 --gid 0 --logger=files
admin     5921  0.0  0.0   6168   812 pts/0    S+   12:16   0:00 grep sssd_be

Рассмотрим описание бэкендов в конфигурационном файле командой:

admin@pc-1:~$ sudo cat /etc/sssd/sssd.conf
[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
...

Библиотеки поставщиков службы sssd находятся в каталоге /usr/lib/x86_64-linux-gnu/sssd/, и за работу компьютера в домене ALD Pro (FreeIPA), например, отвечает Поставщик ipa, которому соответствует библиотека libsss_ipa.so. Если же ввести компьютер Linux напрямую в домен Active Directory, то будет использоваться libsss_ad.so.

Каждый Поставщик данных может оказывать Бэкенду sssd следующие услуги:

• Идентификация (id_provider) — предоставление информации о пользователях, служебных учетных записях, группах и так далее.

• Аутентификация (auth_provider) — проверка аутентичности пользователей и служб.

• Авторизация (access_provider) — проверка прав доступа на запуск служб на уровне HBAC.

• Поставщик sudo (sudo_provider) — предоставление информации о правилах SUDO на повышение привилегий.

• И другие.

Разные модули могут использовать разные настройки, например, для Поставщика ipa требуется задать параметр ipa_server, который используется для определения контроллера домена FreeIPA, с которым требуется поддерживать соединение, а для Поставщика ad аналогичным параметром будет ad_server.

По умолчанию в конфигурационном файле sssd.conf для домена явно задается только несколько провайдеров (id, auth, chpass, access), а для других провайдеров подразумевается, что их имя совпадает с именем поставщика идентификационных данных (id_provider). Для удобства из соображений сокращения размера конфигурационного файла служба sssd руководствуется следующими правилами:

• Если параметр ipa_domain не указан, то используется полное имя домена из секции [domain/<fqdn домена>].

• Если параметр ipa_server не указан, то поиск активного контроллера домена будет выполняться автоматически через DNS, как будто параметр ipa_server = _srv_.

• Если провайдер не указан, то используется значение из парамтера id_provider. Исключением является access_provider. Если его значение не указано, то по умолчанию параметр принимает значение permit, что означает «всем пользователям разрешен доступ». Для управления доступом параметр access_provider должен быть задан явно.

Таким образом, стандартный файл конфигурации /etc/sssd/sssd.conf может быть упрощен до следующего вида:

. . .
[domain/ald.company.lan]
id_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
krb5_store_password_if_offline = True
. . .

Ответчики (Responders)

Ответчик служит посредником между пользовательским приложением (таким как id или getent), кэшем sssd и бэкендом. Когда приложение запрашивает данные, например, ищет пользователя по имени, Ответчик выполняет поиск в локальном кэше и, если данные не найдены или устарели, обращается к Бэкенду, чтобы тот совершил запрос к серверу службы каталога.

Клиентские библиотеки взаимодействуют с Ответчиком через UNIX-сокет (например, /var/lib/sss/pipes/nss), а внутри sssd между Ответчиками, Бэкендами и Монитором взаимодействие осуществляется через DBus.

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

• Ответчик NSS (sssd_nss) — обеспечивает данными диспетчер службы имен (англ. Name Service Switch, NSS).

• Ответчик PAM (sssd_pam) — предоставляет данные для работы подключаемых модулей аутентификации (англ. Pluggable Authentication Modules, PAM).

• Ответчик SUDO (sssd_sudo) — обеспечивает правилами утилиту sudo.

• И так далее.

Клиентские библиотеки и приложения

Для взаимодействия с Ответчиком приложению нужно обращаться к соответствующему UNIX-сокету по специфичному сетевому протоколу, поэтому для упрощения разработки клиентских приложений были созданы вспомогательные совместно используемые библиотеки, такие как libnss_sss.so.2, pam_sss.so и др., которые можно найти в каталоге /usr/lib/x86_64-linux-gnu.

Например, если в конфигурационном файле /etc/nsswitch.conf для базы sudoers источником данных будет указан sss, то утилита sudo для взаимодействия с Ответчиком sssd_sudo воспользуется функциями из библиотеки libsss_sudo.so. Аналогичным образом работает служба autofs.

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

Например, утилиты id, getent, ls вызывают стандартные функции NSS, которые извлекают информацию из нескольких баз данных имен (например, passwd, group, service, netgroup и так далее). На рис. 259 отражен поток данных, создаваемый клиентским приложением id, выполняющим NSS запрос через службу sssd:

• Клиентское приложение /usr/bin/id вызывает функцию getpwnam() из библиотеки glibc для получения информации о пользователе (1).

• Библиотека glibc загружает конфигурационный файл nsswitch.conf (2, 3), затем в соответствии с его настройками загружает совместно используемую библиотеку libnss_sss.so.2 и вызывает ее функцию _nss_sss_getpwnam_r() (4).

• Для получения данных от Ответчика /usr/lib/x86_64-linux-gnu/sssd/sssd_nss библиотека libnss_sss.so.2 отправляет запрос через UNIX-сокет /var/lib/sss/pipes/nss по специализированному протоколу обмена данными (5).

• Ответчик NSS проверяет наличие данных в кэше (6, 7) и в случае отсутствия данных или истекшего срока действия отправляет запрос getAccountInfo к Бэкенду, запрашивая необходимые данные (8).

• Бэкенд из-под учетной записи хоста /etc/krb5.ketyab направляет LDAP-запрос для получения данных от службы каталога (9). Если запрашиваемый пользователь принадлежит тому же домену, то это будет обычный LDAP-запрос на поиск информации, в противном случае sssd выполнит расширенную LDAP-операцию.

рис. 259 Диаграмма потока данных при вызове команды id

Ответчик PAM работает немного иначе. Локальный кэш будет использоваться только в том случае, если служба находится в режиме офлайн. А если связь с сервером есть, то при входе пользователя в систему Ответчик запросит проверку аутентичности у контроллера и обновит информацию об участии пользователя в группах, даже если срок действия кэша еще не истек. В качестве примеров клиентских приложений, использующих PAM, можно привести login, su и sshd.

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

Механизм кэширования службы sssd

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

Локальный кэш (local cache, cache)

Локальный кэш – это база данных, в которую Бэкенды записывают результаты, получаемые из службы каталога, чтобы Ответчики могли считывать их напрямую. При помещении объектов в кэш им назначается срок жизни, и до тех пор, пока он не истечет, все последующие запросы к этим данным обрабатываются без обращения к серверу. Устаревшие данные могут использоваться только в том случае, если служба находится в автономном режиме.

Файлы локального кэша находятся на диске в каталоге /var/lib/sss/db/. Для работы с этим кэшем служба sssd использует встроенную библиотеку баз данных облегченного доступа (англ. Light Weight Embedded Database Library, ldb), и это та же библиотека, с помощью которой реализована база данных службы каталога Samba AD, когда этот набор программного обеспечения используется как самостоятельная служба каталога.

Если установить пакет ldb-tools, то вам станет доступна утилита ldbsearch, с помощью которой можно заглянуть внутрь ldb-файлов. Структура этой базы данных подобна LDAP-каталогу, а параметры ldbsearch во многом повторяют параметры утилиты ldapsearch.

Установим пакет ldb-tools и выполним поиск:

sudo apt install ldb-tools

sudo ldbsearch -H /var/lib/sss/db/cache_ald.company.lan.ldb \
  -b  name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb \
  fullName uidNumber cachedPassword

asq: Unable to register control with rootdse!
# record 1
dn: name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb
fullName: Administrator
uidNumber: 491200000
cachedPassword: $6$u4YejIUZ9cxnfqeh$bxH/g8FNJ7gpz/...E/U/fotvnnimCKnjGWsueB/

 # returned 1 records
 # 1 entries
 # 0 referrals

В данном запросе ключ -b (--basedn) задет отличительное имя базовой записи для поиска. По результатам выполнения запроса можно заметить, информация в базе есть, и пароль закэширован, поэтому пользователь может успешно выполнить вход даже в автономном режиме.

Теперь зайдем в сессию супер-пользователя, выполним удаление кэша очисткой каталога /var/lib/sss/db/, перезапустим службу sssd и повторим поиск:

sudo rm -rf /var/lib/sss/db/*
sudo systemctl restart sssd
sudo ldbsearch -H /var/lib/sss/db/cache_ald.company.lan.ldb \
  -b name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb \
  fullName uidNumber cachedPassword

asq: Unable to register control with rootdse!
# returned 0 records
# 0 entries
# 0 referrals

Как видите, теперь в кэше пусто. Для прогрева кэша мы запросим информацию о пользователе admin с помощью утилиты id, после чего посмотрим в локальный кэш еще раз:

admin@dc-1:~$ id admin
uid=491200000(admin) gid=491200000(admins) группы=491200000(admins),1001(astra-admin),491200003(lpadmin),1005611117(ald trust admin)

admin@dc-1:~$ sudo ldbsearch -H /var/lib/sss/db/cache_ald.company.lan.ldb \
  -b name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb \
  fullName uidNumber cachedPassword

Результат поиска в кэше:

asq: Unable to register control with rootdse!
# record 1
dn: name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb
fullName: Administrator
uidNumber: 491200000
# returned 1 records
# 1 entries
# 0 referrals

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

На низком уровне ldb использует библиотеку Trivial DataBase, поэтому сырые данные в формате ключ-значение можно извлекать из этих файлов с помощью утилит из пакета tdb-tools:

admin@pc-1:~$ sudo apt install tdb-tools
...

admin@pc-1:~$ sudo tdbtool /var/lib/sss/db/config.ldb keys
key 18 bytes: DN=@INDEX:CN:SSSD
key 21 bytes: DN=CN=SSSD,CN=CONFIG
key 18 bytes: DN=@INDEX:CN:SUDO
key 17 bytes: DN=@INDEX:CN:PAC
key 13 bytes: DN=CN=CONFIG
. . .

В папке /var/lib/sss/db/ находятся следующие ldb-файлы локального кэша:

• Файл config.ldb — кэш для хранения настроек службы, загружаемых из конфигурационного файла /etc/sssd/sssd.conf.

• Файл sssd.ldb — база данных локального домена (local provider), который позволял использовать возможности вложенных групп без централизованной службы каталога. Для администрирования использовались команды sss_useradd, sss_groupadd и др. Поддержка функции прекращена в sssd с версии 2.0.0, но файл пока еще остался.

• Файл cache_ald.company.lan.ldb — кэш для хранения критически важной информации, получаемой из домена. Сохранение таких данных на диск требуется выполнять сразу при получении новых данных.

• Файл timestamps_ald.company.lan.ldb — кэш для хранения некритичной и часто обновляемой информации. Сохранение данных на диск выполняется в фоновом режиме по усмотрению операционной системы.

Кроме файлов локального кэша в этой же папке находятся файлы кэша учетных данных Kerberos, которые можно просматривать с помощью утилиты klist с ключом -c:

• Файл ccache_ALD.COMPANY.LAN — кэш для хранения Kerberos-билетов службы sssd, с помощью которых она выполняет LDAP-запросы к службе каталога.

• Файл fast_ccache_ALD.COMPANY.LAN — кэш для хранения еще одного TGT-билета, с помощью которого обеспечивается дополнительное шифрование запросов по технологии FAST (англ. Flexible Authentication Secure Tunneling – гибкая аутентификация через защищенное туннелирование), которая позволяет исключить передачу по сети посылок, зашифрованных только простыми паролями пользователей. В службе каталога MS AD эту технологию называют также Kerberos Armoring.

Удаление всех файлов из директории db является самым простым, но в то же время и самым полным способом очистки локального кэша службы sssd:

sudo systemctl stop sssd
sudo rm -rf /var/lib/sss/db/*
sudo systemctl start sssd

Того же эффекта (но явно безопаснее, чем удаление французского языка rm -fr) можно достичь с помощью команды cache-remove утилиты sssctl из состава пакета sssd-tools:

sudo apt install sssd-tools
sudo sssctl cache-remove

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

admin@pc-1:~$ sudo sssctl cache-remove
SSSD must not be running. Stop SSSD now? (yes/no) [yes]
Creating backup of local data...
Removing cache files...
SSSD needs to be running. Start SSSD now? (yes/no) [yes]

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

Вот так можно отметить недействительными все записи в кэше:

sudo sss_cache -E

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

sudo sss_cache -u admin

Быстрый кэш (in-memory cache, memcache)

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

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

Быстрый кэш представляет собой хеш-таблицы, которые находятся в каталоге /var/lib/sss/mc/ и отображаются на память (Memory-mapped). Ответчик NSS записывает информацию в быстрый кэш, и до тех пор, пока эти данные остаются актуальными, клиентской библиотеке не требуется связываться с sssd для их извлечения. Если нужная запись будет отсутствовать в кэше или срок ее жизни истек, запрос будет перенаправлен Ответчику NSS, который извлечет данные из локального кэша или обратится к контроллеру домена через Бэкенд.

По умолчанию время хранения записей в быстром кэше составляет 300 секунд, и это значение может быть изменено с помощью параметра memcache_timeout в файле /etc/sssd/sssd.conf. Для отключения быстрого кэша нужно установить memcache_timeout=0, а для очистки, как и в случае локального кэша, просто удалить файлы и перезапустить службу:

sudo systemctl stop sssd
sudo rm -rf /var/lib/sss/mc/*
sudo systemctl start sssd

Вам следует учитывать следующие два момента:

• Утилита sss_cache отмечает недействительными одновременно записи и локального и быстрого кэша.

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

Негативный или безрезультатный кэш (negative cache, ncache)

Для уменьшения нагрузки на сервер при обращении к несуществующим объектам каталога внутри Ответчика NSS и ряда других компонентов реализован так называемый негативный или безрезультатный кэш.

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

sudo systemctl restart sssd

Алгоритм использования кэша (cache lookup)

Служба sssd кэширует пользователей, группы, правила HBAC/SUDO, SSH-ключи, карты монтирования дисков и другую информацию, но вне зависимости от типов записей поиск в кэше выполняется очень похожим образом. В упрощенном виде алгоритм поиска показан на рис. 260.

рис. 260 Упрощенный алгоритм поиска в кэше sssd

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

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

• Клиентское приложение вызывает функцию getpwnam() из библиотеки glibc, которая в соответствии с настройками из nsswitch.conf загружает Клиентскую библиотеку libnss_sss.so.2 и вызывает ее функции, подробнее см. в разделе Клиентские библиотеки и приложения.

• Клиентская библиотека проверяет, есть ли информация о запрашиваемом объекте в быстром кэше (memcache), и только после этого обращается к Ответчику sssd_nss.

• Ответчик проверяет, есть ли информация о запрашиваемом объекте в локальном кэше, и только после этого обращается к Бэкенду sssd_be.

• Бэкенд выполняет запрос к LDAP-каталогу, сохраняет информацию в локальный кэш и сообщает Ответчику о готовности.

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

• Клиентская библиотека возвращает ответ в функцию библиотеки glibc, и на этом поиск завершается.

рис. 261 Поток данных при поиске информации о пользователе с использованием информации из кэша

Способы аутентификации в домене

Служба каталога ALD Pro построена на базе FreeIPA и поддерживает три вида аутентификации: LDAP Bind, Kerberos и NTLM.

Аутентификация по протоколу LDAP

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

Примечание

Когда вы подключаетесь к LDAP-каталогу, например, с помощью Apache Directory Studio, использовать аутентификацию по паролю вполне допустимо, и вам нужно позаботиться только о том, чтобы канал связи был зашифрован.

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

Чтобы выполнить подключение по LDAPS, этот протокол можно указать явно в способе подключения к серверу:

ldapwhoami -H ldaps://dc-1.ald.company.lan \
  -xD 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W -d 1

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

admin@dc-1:~$ ldapwhoami -H ldaps://dc-1.ald.company.lan \
>   -xD 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W -d 1
...
ldap_connect_to_host: TCP dc-1.ald.company.lan:636
...
ldap_parse_result
...
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
...

Чтобы активировать StartTLS, требуется добавить ключ -ZZ:

ldapwhoami -H ldap://dc-1.ald.company.lan \
  -xD 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W -d 1 -ZZ

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

admin@dc-1:~$ ldapwhoami -H ldap://dc-1.ald.company.lan \
>   -xD 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W -d 1 -ZZ
...
ldap_connect_to_host: TCP dc-1.ald.company.lan:389
...
res_errno: 0, res_error: <Start TLS request accepted.Server willing to negotiate SSL.>, res_matched: <>
...
ldap_parse_result
...
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
...

Напомним назначение ключей, используемых в утилитах из пакета ldap-utils:

• Ключ -H — позволяет задать адрес LDAP-сервера и протокол подключения LDAP, LDAPS или LDAPI. Если в качестве протокола указать LDAPS, то будет устанавливаться сразу шифрованное подключение на порт 636/TCP.

• Ключ -x— указывает на необходимость выполнить простую аутентификацию по логину/паролю вместо SASL.

• Ключ -D — задает отличительное имя DN пользовательской записи, которую нужно использовать для аутентификации.

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

• Ключ -d — устанавливает уровень отладки. Значение представляет собой битовую маску от 0 до 65535, в которой каждый бит соответствует определенной категории сообщений отладки. Мы используем значение 1 (LDAP_DEBUG_TRACE), которое соответствует трассировке входов и выходов из процедур.

• Ключ -ZZ — позволяет включить шифрование внутри небезопасного протокола LDAP. Устанавливает требование использовать только шифрованное соединение, поэтому если сервер не поддерживает TLS, то соединение будет разорвано.

Опасно

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

ldapsearch -H ldap://dc-1.ald.company.lan \
  -xD 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -w 'Pa$$w0rd'

С помощью программы Wireshark вы можете увидеть, что злоумышленник, у которого будет доступ к просмотру сетевых пакетов, может легко извлечь значение Pa$$w0rd из запроса, если канал связи не будет зашифрован:

рис. 262 Пароль пользователя открытым текстом в запросе bindRequest

Для проведения простой аутентификации LDAP-каталог хранит хеш пароля в атрибуте userPassword. Алгоритм проверки аутентичности работает следующим образом:

• Пользователь передает на сервер свое имя и пароль в открытом виде.

• Сервер извлекает из каталога хеш пароля для указанного пользователя.

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

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

ldapsearch -H ldaps://dc-1.ald.company.lan \
  -o ldif-wrap=no -D 'cn=Directory Manager' -W \
  -b 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' \
  | grep 'userPassword::' | cut -d" " -f 2 | base64  -d

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

Enter LDAP Password:
{PBKDF2_SHA512}10000$jx2z0Yf0Ak+uJafLT38yMfePgEc$aU6G9cQ/D...

Поясним ключи и используемые команды:

• Ключ -o ldif-wrap=no — требует выводить текст без переносов в одну строку, если она не помещается в 80 символов, что полезно в скриптах автоматизации.

• Командой grep мы делаем поиск строки, в которой содержится значение «userPassword::» с хешем пароля. Значение атрибута отделено от его названия двумя символами двоеточия, т.к. значение закодировано в base64.

• Командой cut мы разрезаем строку, используя символ пробела в качестве разделителя, и с помощью ключа -f2 извлекаем второй элемент из массива.

• Командой base64 -d мы декодируем текст из base64.

Результатом выполнения команды будет строка с паролем администратора, где в фигурных скобках указан способ хеширования, далее до символа $ идет соль пароля. Все остальное – это хеш, полученный с использованием указанной соли и способа хеширования.

{PBKDF2_SHA512}10000$jx2z0Yf0Ak+uJafLT38yMfePgEc$aU6G9cQ/D...

Если включить режим миграции пользователей, то при создании новых учетных записей в атрибут userPassword можно будет записать хеш пароля, при этом поддерживается довольно большой перечень алгоритмов: CRYPT, CRYPT-MD5, CRYPT-SHA256, CRYPT-SHA512, MD5, SHA, SHA256, SHA384, SHA512, SMD5, SSHA, SSHA256, SSHA384, SSHA512.

Включим режим миграции и создадим пользователя migrated_user с хешем пароля {MD5}PMMc0kYUmuxoB5JB5x6Y9g==, который соответствует значению Pa$$w0rd, и проверим возможность LDAP-аутентификации пользователя под этим паролем:

ipa config-mod --enable-migration=true

ipa user-add migrated_user \
   --first="migrated" --last="user" \
   --setattr userPassword='{MD5}PMMc0kYUmuxoB5JB5x6Y9g=='

ldapwhoami -H ldaps://dc-1.ald.company.lan \
   -xD 'uid=migrated_user,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -w 'Pa$$w0rd'

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

   admin@dc-1:~$ ipa config-mod --enable-migration=true
   Максимальная длина имени пользователя: 32
   Максимальная длина имени хоста: 64
   Основа домашних каталогов: /home
   Оболочка по умолчанию: /bin/bash
   Группа пользователей по умолчанию: ipausers
   Почтовый домен по умолчанию: ald.company.lan
   Ограничение времени поиска: 2
   Ограничение размера поиска: 100
   Поля поиска пользователей: uid,givenname,sn,telephonenumber,ou,title
   Поля поиска групп: cn,description
   Включить режим миграции: TRUE
   Основа субъекта сертификата: O=ALD.COMPANY.LAN
   Уведомление об окончании действия пароля (в днях): 4
   Возможности подключаемого модуля паролей: AllowNThash, KDC:Disable Last Success
   Порядок применения списка пользователей SELinux: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
   Пользователь SELinux по умолчанию: unconfined_u:s0-s0:c0.c1023
   Типы PAC по умолчанию: MS-PAC, nfs:NONE
   Главные IPA-серверы: dc-1.ald.company.lan
   Главный IPA-сервер с поддержкой PKINIT: dc-1.ald.company.lan
   DNS-серверы IPA: dc-1.ald.company.lan

   admin@dc-1:~$ ipa user-add migrated_user \
   >    --first="migrated" --last="user" \
   >    --setattr userPassword='{MD5}PMMc0kYUmuxoB5JB5x6Y9g=='
   -------------------------------------
   Добавлен пользователь "migrated_user"
   -------------------------------------
   Имя учётной записи пользователя: migrated_user
   Имя: migrated
   Фамилия: user
   Полное имя: migrated user
   Отображаемое имя: migrated user
   Инициалы: mu
   Домашний каталог: /home/migrated_user
   GECOS: migrated user
   Оболочка входа: /bin/bash
   Имя учётной записи: migrated_user@ALD.COMPANY.LAN
   Псевдоним учётной записи: migrated_user@ALD.COMPANY.LAN
   Адрес электронной почты: migrated_user@ald.company.lan
   UID: 491200009
   ID группы: 491200009
   Минимальный уровень конфиденциальности: 0
   Максимальный уровень конфиденциальности: 0
   Учётная запись отключена: FALSE
   nsuniqueid: dd687f07-2e5b11f0-81d3c33d-ecd7a769
   proxy addresses: SMTP:MIGRATED_USER@ALD.COMPANY.LAN
   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
   Участник групп: ipausers
   Роли: ALDPRO - Organization units
   Доступные ключи Kerberos: False

   admin@dc-1:~$ ldapwhoami -H ldaps://dc-1.ald.company.lan \
   >    -xD 'uid=migrated_user,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -w 'Pa$$w0rd'
   dn: uid=migrated_user,cn=users,cn=accounts,dc=ald,dc=company,dc=lan

Необходимое значение атрибута userPassword можно получить следующими командами на языке Python:

admin@dc-1:~$ python3
Python 3.7.3 (default, Apr  8 2024, 13:48:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> import binascii
>>> import base64
>>>
>>> password = 'Pa$$w0rd'
>>> md5_hash_string = hashlib.md5(password.encode()).hexdigest()
>>> md5_hash_bytes = binascii.unhexlify(md5_hash_string)
>>> md5_hash_base64_string = base64.b64encode(md5_hash_bytes).decode('utf-8')
>>>
>>> print(md5_hash_base64_string)
PMMc0kYUmuxoB5JB5x6Y9g==
>>> exit()

Для завершения миграции пользователю потребуется один раз выполнить простую LDAP-аутентификацию. Для этого на сервере существует даже специальная страница миграции, доступная по адресу https://dc-1.ald.company.lan/ipa/migration/, см. рис. 263. В случае успешной аутентификации серверу будет доступен пароль пользователя в открытом виде и он сможет сгенерировать недостающие ключи.

рис. 263 Страница для завершения миграции пользователей

Аутентификация по протоколу Kerberos

Общая информация

Основным протоколом аутентификации в домене является Kerberos V5, который был назван так по имени треглавой собаки, охраняющей по древнегреческой мифологии выход из царства мертвых. Каждая голова Цербера соответствует одному из трех участников процедуры аутентификации:

• Клиент (Client) — субъект, желающий получить доступ к ресурсу.

• Сервер приложения (Application Server, AP) — служба, к ресурсу которой клиент хочет получить доступ.

• Центр распространения ключей (Key Distribution Center, KDC) — доверенная сторона, отвечающая за аутентификацию пользователей и выдачу билетов для доступа к сетевым службам в домене.

  Мы уже отмечали, что в рамках KDC часто выделяют два отдельных компонента, отвечающих за каждую из операций (сервер аутентификации AS и сервер выдачи билетов TGS), но на практике такие детали можно считать несущественными.

Служба KDC работает по порту 88/TCP и отвечает только за выдачу билетов. Для управления учетными записями Kerberos на сервере устанавливается так же служба kadmin, которая использует порты 464/TCP и 749/TCP.

Поток данных при Kerberos-аутентификации

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

рис. 264 Запрос от клиента на получение TGT-билета

Шаг #1 Пользователь Алиса через приложение графического входа fly-dm_greet (англ. Fly Display Manager Greet - приложение для входа экранного менеджера Fly) передает логин и пароль в открытом виде стеку модулей аутентификации (Pluggable Authentication Modules, PAM). За аутентификацию в домене отвечает модуль pam_sss.so, который подключается библиотекой libpam в соответствии с настройками из файла common-auth:

admin@pc-1:~$ cat /etc/pam.d/common-auth
...
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
...

admin@pc-1:~$ file /usr/lib/x86_64-linux-gnu/security/pam_sss.so
/usr/lib/x86_64-linux-gnu/security/pam_sss.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=178d1f9af2fafaf8dd6e4d46bd6244804acf31b5, stripped

Шаг #2 Функции Клиентской библиотеки pam_sss.so обращаются к Ответчику sssd_pam. Ответчик обращается к Бэкенду, который порождает процесс krb5_child для аутентификации в домене по протоколу Kerberos V5.

admin@pc-1:~$ file /usr/lib/x86_64-linux-gnu/sssd/sssd_pam
/usr/lib/x86_64-linux-gnu/sssd/sssd_pam: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=102efb73ab48e0a7db70e62d76ab3451a2f8c1ba, stripped

admin@pc-1:~$ file /usr/lib/x86_64-linux-gnu/sssd/krb5_child
/usr/lib/x86_64-linux-gnu/sssd/krb5_child: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=0e99bfee28c8d22ef2507670610399a795ab7714, stripped

Клиент рассчитывает хеш пароля, который называют также долгосрочным ключом (UPN long-term key) или просто Kerberos-ключом. После этого Клиент может удалить пароль в открытом виде из памяти компьютера для повышения устойчивости системы к взлому.

Шаг #3 Клиент отправляет запрос к Центру распространения ключей (Key Distribution Center, KDC) для получения TGT-билета.

В четвертой версии протокола на этом шаге никакие учетные данные не требовались, т. к. ответ будет зашифрован долгосрочным ключом пользователя, и способность расшифровать ответ является подтверждением того, что пользователь является тем, за кого себя выдает. Но с пятой версии протокола сервер отклонит запрос и потребует предварительную аутентификацию, поэтому в журнале /var/log/auth.log на сервере можно увидеть строки с текстом «Additional pre-authentication required»:

Apr 4 07:27:11 dc-1 krb5kdc[1922]: AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.0.1.11: NEEDED_PREAUTH: admin@ALD.COMPANY.LAN for krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN, Additional pre-authentication required

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

Почему клиент не отправляет запрос сразу с аутентификатором

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

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

Вы можете увидеть значение соли при выполнении аутентификации с помощью утилиты kinit, если включить режим отладки:

admin@dc-1:~$ env KRB5_TRACE=/dev/stdout kinit admin <<< 'Pa$$w0rd' | grep salt
[76745] 1746980758.290401: Selected etype info: etype aes256-cts, salt "=r5h]%DQh@lr^W 1", params ""

В сетевых пакетах эта информация передается в открытом виде:

рис. 265 Создание и отправка TGT-билета на сторону клиента

Шаг #4 Служба KDC расшифровывает аутентификатор, используя долгосрочный ключ Алисы из LDAP-каталога. Ключи для аутентификации по протоколу Kerberos хранятся в атрибуте krbPrincipalKey, который представляет собой бинарный объект, зашифрованный мастер-ключом KDC (krbMKey). Если процедура расшифровки завершилась успешно и полученная метка времени расходится с временем сервера не более, чем на 5 минут, то считается, что предварительная аутентификация пройдена успешно. По указанной причине для корректной работы протокола Kerberos V5 важна синхронизация времени между всеми участниками домена.

Вы можете уменьшить допустимое отклонение времени, изменив значение параметра clockskew в секции libdefaults файла /etc/krb5.conf, но увеличивать его по соображениям безопасности лучше не стоит. Правильнее будет корректно настроить синхронизацию времени.

Шаг #5 Для повышения безопасности служба KDC генерирует временный сессионный ключ S1, чтобы использовать его в дальнейшем для шифрования сообщений между клиентом и контроллерами домена вместо долгосрочного ключа пользователя.

Обратите внимание, что в названии Центр распространения ключей под ключами подразумеваются как раз временные сессионные ключи S1 и S2, которые безопасно передаются между участниками домена внутри зашифрованных Kerberos-билетов, а не долгосрончые ключи, которые представляют собой хеши паролей.

Шаг #6 Сессионный ключ был сгенерирован конкретным сервером, но в домене может быть несколько контроллеров, и Клиент вправе обратиться с последующим запросом к любому из них. Учитывая случайный характер сессионного ключа, другой контроллер домена не сможет рассчитать его математически, поэтому сессионный ключ следует передать ему в явном виде. По протоколу Kerberos ответственность за передачу сессионного ключа возлагается на клиента, для чего ему выдается зашифрованный билет на выдачу билетов (Ticket-granting ticket, TGT), который он должен предъявлять в KDC при последующих обращениях.

Внутри TGT-билета содержится имя пользователя (User Principal Name, UPN), сессионный ключ (S1) и информация по сроку действия билета (Time to Live, TTL). Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа KDC (хеш пароля служебной учетной записи KRBTGT, Key Distribution Center Service Account), поэтому расшифровать его можно только на контроллере, и подделать билет на стороне Клиента невозможно.

Шаг #7 Для передачи сессионного ключа и TGT-билета на сторону клиента они шифруются симметричным алгоритмом с помощью долгосрочного ключа клиента, поэтому только клиент сможет расшифровать сообщение, подтверждая этим фактом, что является тем, за кого себя выдает. Данная проверка аутентичности считается основной.

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

рис. 266 Запрос от клиента на получение сервисного билета с помощью TGT-билета

Шаг #8 Клиент расшифровывает посылку, внутри которой находится сессионный ключ и TGT-билет, своим долгосрочным ключом. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает. Если результат расшифровки окажется недействительным, значит, ответ был получен от подставного Центра распределения ключей.

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

Шаг #9 Процесс krb5_child сохраняет TGT-билет в связке ключей Linux и передает результаты по цепочке «Бэкенд => Ответчик => Клиентская библиотека».

Получив подтверждение об успешной выдачи TGT-билета, Клиентская библиотека отправляет запрос на получение сервисного билета для доступа к серверу приложения. В запросе содержится имя пользователя (UPN), имя сервера приложения (Service Principal Name, SPN), билет на выдачу билетов (TGT) и аутентификатор. В качестве имени приложения выступает имя учетной записи хоста host/pc-1.ald.company.lan, аутентификатором является метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S1.

На этом шаге TGT-билет закодирован только долгосрочным ключом KDC, но этого достаточно, чтобы злоумышленник, перехвативший сообщение, не смог подделать запросы, т. к. он не располагает сессионным ключом S1.

рис. 267 Создание и отправка сервисного TGS-билета на сторону клиента

Шаг #10 Служба KDC расшифровывает информацию из TGT-билета, используя долгосрочный ключ KDC из LDAP-каталога, после чего ей становится доступна следующая информация: имя пользователя, сессионный ключ S1 и срок действия билета.

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

Шаг #11 Для повышения безопасности протокола аутентификации KDC генерирует новый сессионный ключ S2, чтобы его можно было использовать в дальнейшем для шифрования сообщений между клиентом и сервером приложения вместо ключа S1.

Шаг #12 Ключ S2 был сгенерирован сервером KDC, и его следует передать Серверу приложения. По протоколу Kerberos ответственность за передачу ключа возлагается на клиента, для чего ему выдается зашифрованный сервисный билет (Service ticket, ST), который он должен предъявлять Серверу приложения. Сервисный билет называют также ST-билетом или TGS-билетом.

Внутри TGS-билета содержится имя пользователя (UPN), сессионный ключ S2 и информация по сроку действия билета (TTL). Билет зашифрован симметричным алгоритмом с помощью долгосрочного ключа Сервера приложения, поэтому расшифровать его сможет только Сервер приложения, и подделать билет на стороне Клиента невозможно.

Сервером приложения в нашем случае является fly-dm_greet, поэтому для расшифровки TGS-билета используются ключи от учетной записи компьютера из файла /etc/krb5.keytab. Для повышения безопасности каждому керберизированному приложению обычно создается собственная учетная запись в домене.

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

рис. 268 Аутентификация клиента на сервере приложения с помощью TGS-билета

Шаг #14 Клиент расшифровывает сессионный ключ S2 и сервисный билет ST известным ему сессионным ключом S1. Возможность использования этих данных в последующих запросах означает, что Клиент является тем, за кого себя выдает.

Шаг #15 Клиент отправляет Серверу приложения запрос на аутентификацию, в котором содержится имя пользователя (UPN), сервисный билет (ST) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S2.

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

Шаг #16 Сервер приложения, в роли которого выступает служба sssd на пользовательском компьютере, извлекает долгосрочный ключ (хеш пароля) из файла /etc/krb5.keytab для расшифровки запроса. Используя этот ключ, служба sssd может расшифровать информацию из сервисного билета (ST), после чего ей становится доступна следующая информация: имя пользователя (UPN), сессионный ключ S2 и срок действия билета (TTL). Служба sssd расшифровывает аутентификатор, используя сессионный ключ S2 из сервисного билета, и, если полученное значение расходится со временем компьютера не более, чем на 5 минут, то считается, что аутентификация пройдена успешно.

Шаг #17-#18 Если бы в качестве керберизированного сервиса выступала не локальная служба sssd, а какое-нибудь приложение, расположенное на другом хосте, то Сервер приложения мог бы взаимно подтвердить Клиенту свою аутентичность, отправив в качестве аутентификатора метку времени, увеличенную на одну секунду и зашифрованную сессионным ключом S2.

В случае локальной службы sssd взаимная аутентификация не требуется, поэтому служба сразу отдает подтверждение, что Алиса успешно прошла аутентификацию, и приложение fly-dm_greet запускает рабочий стол fly-wm (Fly Windows Manager) от имени этого пользователя.

После проверки аутентичности пользователя TGS-билет на доступ к хосту более не требуется, поэтому компьютер не сохранит его в связке ключей и увидеть этот билет командой klist не получится. Но на контроллере домена в журнале /var/log/auth.log вы сможете найти подтверждение, что такой билет действительно запрашивался и был предоставлен рабочей станции.

Управление Kerberos-аутентификацией

Для работы с Kerberos-билетами на компьютере Linux используются утилиты из пакета krb5-user, такие как kinit, klist, kdestroy, kvno, kpasswd и другие.

Аутентификация

Для выполнения аутентификации по протоколу Kerberos (т.е. для получения TGT-билета) используется утилита kinit. Обратите внимание, что при выполнении повторной аутентификации тем же пользователем все ранее выданные билеты удаляются.

admin@dc-1:~$ kinit
Password for admin@ALD.COMPANY.LAN:

Имя конкретного пользователя можно указать с помощью параметра:

admin@dc-1:~$ kinit ivan.kuznetsov@ALD.COMPANY.LAN
Password for ivan.kuznetsov@ALD.COMPANY.LAN:

При этом вы можете использовать как полные имена пользователей, так и короткие, поскольку система будет автоматически дополнять короткие имена значением параметра default_realm из файла /etc/krb5.conf:

admin@dc-1:~$ cat /etc/krb5.conf | grep default_realm
 default_realm = ALD.COMPANY.LAN

admin@dc-1:~$ kinit ivan.kuznetsov
Password for ivan.kuznetsov@ALD.COMPANY.LAN:

Примечание

Как мы уже обсуждали ранее (см. примечание Дополнительная информация об алиасе root принципала admin, Модуль 2. Развертывание ALD Pro), если не указать имя пользователя, то утилита kinit попытается сначала взять его из связки ключей, а если кэш будет удален командой kdestroy, то переключится на имя текущего пользователя Linux из-за чего при выполнении команды sudo kinit мы иногда можем выполнить аутентификацию от имени принципала root@ALD.COMPANY.LAN, который является алиасом для учетной записи admin@ALD.COMPANY.LAN.

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

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

sudo kinit -kt /etc/krb5.keytab

Если путь к файлу не указывать с помощью ключа -t, то по умолчанию будет использован как раз системный файл /etc/krb5.keytab.

Просмотр билетов

Для просмотра полученных Kerberos-билетов используется утилита klist. При обращении к утилите без параметров она отобразит информацию о билетах из кэша по умолчанию.

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_8KcsvR7
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:33:10  03.04.2025 06:33:07  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

С помощью ключа -с можно прочитать билеты из кэша, который хранится в файле:

admin@dc-1:~$ sudo klist -c /var/lib/sss/db/ccache_ALD.COMPANY.LAN
Ticket cache: FILE:/var/lib/sss/db/ccache_ALD.COMPANY.LAN
Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:21:24  03.04.2025 06:21:24  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
02.04.2025 06:21:24  03.04.2025 06:21:24  ldap/dc-1.ald.company.lan@ALD.COMPANY.LAN

Утилита klist позволяет читать не только файлы кэшей учетных данных, но и keytab-файлы. Для того чтобы указать имя keytab-файла, нужно воспользоваться ключом -k (keytab). Полезно также использовать ключи -e (encryption) и -t (timestamp), чтобы увидеть дату выдачи и используемые алгоритмы шифрования.

admin@dc-1:~$ sudo klist -ket /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- -------------------------------------------------------------------------
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha256-128)
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha384-192)
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (camellia128-cts-cmac)
   2 28.03.2025 10:39:47 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (camellia256-cts-cmac)

Удаление билетов

Для того чтобы удалить билеты Kerberos из кэша, воспользуйтесь утилитой kdestroy без параметров. Проверим, что билеты есть в кэше:

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_8KcsvR7
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:33:10  03.04.2025 06:33:07  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Выполним удаление билетов и проверим кэше еще раз:

admin@dc-1:~$ kdestroy
admin@dc-1:~$ klist
klist: Credentials cache keyring 'persistent:491200000:krb_ccache_8KcsvR7' not found`

Получение сервисных билетов

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

Однако во время отладки, особенно при работе с доверительными отношениями, нам иногда требуется получить билет на какой-то конкретный сервис вручную. Сделать это можно, например, с помощью утилиты kvno (англ. key version number — номер версии ключа).

Основное назначение этой утилиты состоит в том, чтобы получить билет на указанный сервис и показать номер версии пароля, который хранится на сервере KDC. Это позволяет, например, быстро установить, что keytab-файл был взят из старой резервной копии и там хранятся неактуальные ключи. Но каким бы ни было изначальное назначение утилиты, она очень удобна для отладки.

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

admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:

admin@dc-1:~$ kvno HTTP/dc-1.ald.company.lan
HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN: kvno = 1

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_xOCrrRF
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 07:33:57  03.04.2025 07:33:52  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
02.04.2025 07:33:55  03.04.2025 07:33:52  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Примечание

Посмотреть названия сервисов можно в портале управления на странице Управление доменом ‣ Службы и параметры Kerberos.

Работа с коллекцией ключей

Выполняя Kerberos-аутентификацию под новым пользователем, вы не удаляете ранее полученные билеты, а просто переключаетесь на другое хранилище в рамках вашей коллекции ключей. Посмотреть все билеты в вашей коллекции можно командой klist с ключом -A (англ. all - все):

admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:

admin@dc-1:~$ kinit semenov.ii
Password for semenov.ii@ALD.COMPANY.LAN:

admin@dc-1:~$ klist -A
Ticket cache: KEYRING:persistent:491200000:krb_ccache_oR4OXE0
Default principal: semenov.ii@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
03.04.2025 06:54:06  03.04.2025 06:54:03  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Ticket cache: KEYRING:persistent:491200000:krb_ccache_8KcsvR7
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:53:58  03.04.2025 06:53:55  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Это позволяет вам быстро вернуться к нужному кэшу ключей без повторного ввода пароля. Для переключения между хранилищами используют команду kswitch, которой нужно передать имя пользователя ключом -p (principal). Вы можете использовать короткое имя пользователя без указания Kerberos-реалма.

admin@dc-1:~$ kswitch -p admin
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_8KcsvR7
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:53:58  03.04.2025 06:53:55  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

admin@dc-1:~$ kswitch -p semenov.ii
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_oR4OXE0
Default principal: semenov.ii@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 06:54:06  03.04.2025 06:54:03  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Если вам потребуется очистить все хранилища коллекции сразу, воспользуйтесь утилитой kdestroy с ключом -A (all). После этого klist с ключом -A не покажет никаких данных.

admin@dc-1:~$ kdestroy -A
admin@dc-1:~$ klist -A
admin@dc-1:~$

Администрирование учетных записей Kerberos

Сервер Kerberos может не только выдавать билеты, но и предоставляет интерфейс для управления учетными записями. За это отвечает служба kadmind, которая обрабатывает запросы на портах 464/TCP и 749/TCP.

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

Служба kadmind принимает удаленные запросы от таких программ, как kadmin, kpasswd, fly-passwd и даже Windows-компьютеры в составе домена ALD Pro (FreeIPA) могут с помощью этой службы предоставить доменному пользователю возможность сменить пароль штатными средствами через Ctrl + Alt + Del.

Например, если вам потребуется сменить пароль пользователя из командной строки, вы можете воспользоваться утилитой kpasswd. При вызове утилиты без параметров она использует текущее имя. Чтобы задать имя пользователя явным образом, передайте его в качестве параметра:

admin@dc-1:~$ kpasswd semenov.ii
Password for semenov.ii@ALD.COMPANY.LAN:
Enter new password:
Enter it again:
Password changed.

Но для смены пароля мы рекомендуем все-таки установить и использовать графическую утилиту fly-passwd, т.к. она позволяет не только изменить пароль в домене, но и обновить кэш службы sssd, что делает ее незаменимым инструментом для удаленных пользователей, которые подключаются к корпоративной сети через VPN.

рис. 269 Интерфейс приложения fly-passwd для смены пароля

Для выполнения расширенных задач администрирования вам нужно будет воспользоваться утилитами kadmin или kadmin.local. Но их работу лучше рассматривать в контексте этих задач.

Аутентификация по протоколу NTLM

Для интеграции с Active Directory служба каталога FreeIPA использует компоненты Samba, в которых реализована в том числе NTLM-аутентификация.

рис. 270 Поток данных при NTLM-аутентификации

На рисунке рис. 270. представлена диаграмма аутентификации по протоколу NTLM в упрощенном виде.

Шаг #1 Клиент обращается к Сервису с запросом на аутентификацию.

Шаг #2 Сервер отправляет в ответ случайное число длиной 8 байт (челлендж), которое Клиенту нужно будет подписать паролем, чтобы подтвердить свою аутентичность.

Шаг #3 Клиент подписывает челлендж (шифрует своим паролем) и отправляет Сервису в качестве подтверждения того, что ему известен пароль и он действительно является тем, за кого себя выдает.

Шаг #4 Сервис не может выполнить проверку подписи самостоятельно, т.к. не располагает хешем пользовательского пароля, поэтому пересылает на контроллер домена исходное значение челленджа и полученную подпись.

Шаг #5 Контроллер домена проверяет подпись, используя пароль пользователя из LDAP-каталога, и в случае успеха возвращает PAC-сертификат, в котором содержатся идентификаторы безопасности всех групп, участником которых является текущий пользователь.

Для возможности NTLM-аутентификации у пользователей в каталоге FreeIPA есть атрибут ipaNTHash, который обновляется плагином ipa_pwd_extop каждый раз при смене пароля. Служба Samba через плагин ipadb извлекает значение ipaNTHash из LDAP-каталога и выполняет все необходимые проверки аутентичности.

Для проверки работы NTLM-аутентификации на контроллере можно воспользоваться утилитой ntlm_auth. За обработку запросов NTLM-аутентификации отвечает Winbind.

root@dc-1:~# ntlm_auth --debuglevel=10 --domain=ALD --username=admin --password='Pa$$w0rd'
NT_STATUS_OK: The operation completed successfully. (0x0)

Текущие настройки службы Samba можно получить командой testparm. Роль ROLE_DOMAIN_PDC означает, что параметр security равен USER, т.е. Samba работает в режиме NT4-контроллера.

root@dc-1:~# testparm
Load smb config files from /etc/samba/smb.conf
lpcfg_do_global_parameter: WARNING: The "domain logons" option is deprecated
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_DOMAIN_PDC

Press enter to see a dump of your service definitions
...

Обращаем ваше внимание, что использовать NTLM для интеграции приложений в настоящее время считается даже менее безопасным, чем LDAP-коннекторы, потому что протокол NTLM подвержен MITM-атакам, таким как NTLM Relay, которые позволяют злоумышленникам получить авторизованный доступ к сервису, даже если им неизвестен пароль пользователя. Более того, Relay злоумышленников может направить Клиенту собственное значение челленджа, для которого у них построены радужные таблицы, что существенно упростит взлом пароля методом перебора.

Безопасный обмен данными с применением SSL/TLS

Доменный компьютер взаимодействует с подсистемами ALD Pro по разным протоколам, некоторые из которых используют шифрование:

• Доступ к каталогу по протоколам LDAP+StartTLS (389/TCP) и LDAPS (636/TCP) со стороны службы sssd и с помощью утилит из пакета ldap-utils.

• Доступ к веб-интерфейсам контроллера домена через браузер и REST API через утилиту ipa по протоколу HTTPS (443/TCP).

• Доступ к удаленному рабочему столу доменного компьютера с портала управления ALD Pro по протоколу VNC через HTTPS (6080/TCP - 608x/TCP).

• Доступ к принтерам по протоколу IPP (631/TCP), актуально для принтеров, зарегистрированных в подсистеме печати.

• Доступ к PostgreSQL (5432/TCP), актуально для подсистемы репозиториев при репликации базы данных с информацией о загруженных пакетах с главного сервера на подчиненные.

Обращаем внимание, что расширение Kerberos-аутентификации PKINIT использует асимметричное шифрование с применением сертификатов X.509, но шифрование в этом случае используется только для взаимной аутентификации клиента и сервера, а защищенного SSL-соединения между ними не устанавливается.

Механизм защиты данных по протоколу SSL

Протокол SSL (англ. Secure Sockets Layer, уровень защищенных сокетов) в его текущей реализации TLS (англ. Transport Layer Security, безопасность транспортного уровня) обеспечивает быстрый и безопасный обмен данными между клиентом и сервером за счет сочетания симметричных и асимметричных алгоритмов шифрования: медленные асимметричные алгоритмы используются только на фазе рукопожатия для того, чтобы договориться о параметрах шифрования и безопасно обменяться сессионным ключом, а непосредственно обмен данными происходит уже с применением быстрых симметричных алгоритмов.

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

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

рис. 271 Иллюстрация идеи асимметричного шифрования на примере использования сейфа с самозакрывающимся механизмом

Изначально протокол SSL разрабатывался для HTTP, но его универсальный TCP-подобный интерфейс позволил создать расширения и других протоколов прикладного уровня, например, LDAPS, FTPS, SMTPS, IMAPS и др.

рис. 272 Установление безопасного HTTPS-соединения

В качестве примера рассмотрим поток данных при открытии веб-страницы по протоколу HTTPS, см. рис. 272:

Шаг #1 Когда пользователь переходит по https-ссылке, браузер выполняет подключение к веб-серверу на 443/TCP порт и передает список поддерживаемых методов шифрования для установления безопасного соединения.

Шаг #2 Веб-сервер выбирает метод шифрования и передает клиенту свой SSL-сертификат, который содержит публичный ключ и цифровую подпись для этого ключа. Вернее, он передает не один сертификат, а всю цепочку до корневого сертификата включительно.

Шаг #3 Клиент проверяет валидность цифровой подписи сертификата по своей базе доверенных корневых сертификатов, используя алгоритмы асимметричного шифрования. Клиент также проверяет подлинность сервера, сопоставляя имя, по которому обращается к нему, с тем именем, которое указано внутри сертификата. Если сертификат сайта не пройдет проверку, то пользователь получит сообщение о небезопасности соединения ввиду возможности атак посредника (Man in the middle, MITM).

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

Шаг #5 Сервер извлекает общий ключ из сообщения, расшифровывая его своим закрытым ключом, и передает Клиенту в ответ сообщение, зашифрованное теперь уже общим ключом, подтверждая возможность начала безопасного обмена данными.

Шаг #6 Клиент и сервер начинают обмен данными по защищенному каналу связи.

Доступ к каталогу по протоколам LDAP+StartTLS и LDAPS

Служба sssd получает данные из каталога по протоколу LDAP (389/TCP) с использованием расширения StartTLS, которое позволяет инициировать шифрованный обмен данными внутри уже установленного TCP-соединения вместо открытия нового соединения на отдельном порту.

Администратор может проверить, что порт 389/TCP действительно защищен шифрованием, и получить цепочку сертификатов с помощью утилиты openssl. Первый сертификат выписан на конкретное полное имя FQDN контроллера домена, а второй соответствует корневому сертификату домена.

$ echo Q | openssl s_client -starttls ldap -showcerts dc-1.ald.company.lan:389
CONNECTED(00000003)
depth=1 CN = CA Signing Certificate
verify return:1
depth=0 CN = dc-1.ald.company.lan
verify return:1
---
Certificate chain
 0 s:CN = dc-1.ald.company.lan
   i:CN = CA Signing Certificate
 1 s:CN = CA Signing Certificate
   i:CN = CA Signing Certificate
---
Server certificate
-----BEGIN CERTIFICATE-----
aMIIDxjCCAq6gAwIBAgIUZ4JathCvRrV6v+Aoi4kUNScViBswDQYJKoZIhvcNAQEL
aBQAwITEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTAeFw0yMjExMTYx
NzM4MjVaFw0zMjExMTMxNzM4MjVaMCExHzAdBgNVBAMMFmRjLTEuYWxkLmNvbXBh
...
-----BEGIN CERTIFICATE-----
MIIDIzCCAgugAwIBAgIUULQd6OzgJ/ik7wJvV0gd6kUIFKAwDQYJKoZIhvcNAQEL
BQAwITEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTAeFw0yMjExMTYx
NzM4MjVaFw00MjExMTExNzM4MjVaMCExHzAdBgNVBAMMFkNBIFNpZ25pbmcgQ2Vy
...

Доверие к этой цепочке проверяется с помощью корневого сертификата из файла /etc/ipa/ca.crt, на который указывает параметр ldap_tls_cacert из секции domain конфигурационного файла /etc/sssd/sssd.conf. Данный сертификат загружается на компьютер автоматически при вводе компьютера в домен. Как можно заметить по первым трём строкам, содержимое этого файла соответствует последнему сертификату из цепочки, полученной от сервера.

admin@dc-1:~$ cat /etc/sssd/sssd.conf
[domain/ald.company.lan]
...
ldap_tls_cacert = /etc/ipa/ca.crt
...

admin@dc-1:~$ cat /etc/ipa/ca.crt
-----BEGIN CERTIFICATE-----
MIIDIzCCAgugAwIBAgIUULQd6OzgJ/ik7wJvV0gd6kUIFKAwDQYJKoZIhvcNAQEL
BQAwITEfMB0GA1UEAwwWQ0EgU2lnbmluZyBDZXJ0aWZpY2F0ZTAeFw0yMjExMTYx
NzM4MjVaFw00MjExMTExNzM4MjVaMCExHzAdBgNVBAMMFkNBIFNpZ25pbmcgQ2Vy
...

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

admin@dc-1:~$ openssl x509 -in /etc/ipa/ca.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            50:b4:1d:e8:ec:e0:27:f8:a4:ef:02:6f:57:48:1d:ea:45:08:14:a0
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = CA Signing Certificate
        Validity
            Not Before: Nov 16 17:38:25 2022 GMT
            Not After : Nov 11 17:38:25 2042 GMT
...

Для упрощения отладки работы компьютеров в домене на них автоматически устанавливается и настраивается пакет ldap-utils, в состав которого входят такие утилиты, как ldapsearch, ldapadd и др. Безопасность соединения проверяется с использованием корневого сертификата из файла /etc/ssl/certs/ca-certificates.crt, на который указывает параметр TLS_CACERT из конфигурационного файла /etc/ldap/ldap.conf.

admin@dc-1:~$ cat /etc/ldap/ldap.conf
...
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
URI ldaps://dc-1.ald.company.lan
BASE dc=ald,dc=company,dc=lan
SASL_MECH GSSAPI
...

Файл ca-certificates.crt является связкой сертификатов, в которой содержится более 100 корневых сертификатов удостоверяющих центров, которым доверяет операционная система Astra Linux. Корневой сертификат домена, который отображается в файле /etc/ipa/ca.crt, обычно находится в самом конце этого файла. Чтобы просмотреть информацию по всем сертификатам из файла, можно использовать следующую команду:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -text -noout | less

Учетная запись компьютера в домене

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

Учетные записи компьютеров хранятся в cn=computers,cn=accounts,dc=ald,dc=company,dc=lan, имя LDAP-записи включает значение атрибута fqdn, например, fqdn=pc-1.ald.company.lan, а для аутентификации по протоколу Kerberos используется имя принципала в формате host/pc-1.ald.company.lan@ALD.COMPANY.LAN.

Билеты службы sssd кэшируются в файле /var/lib/sss/db/ccache_ALD.COMPANY.LAN, прочитать который можно с помощью утилиты klist, используя параметр -c.

root@pc-1:~# klist -c /var/lib/sss/db/ccache_ALD.COMPANY.LAN
Ticket cache: FILE:/var/lib/sss/db/ccache_ALD.COMPANY.LAN
Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

Valid starting      Expires              Service principal
02.04.2025 16:32:19 03.04.2025 16:32:19  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
02.04.2025 16:32:19 03.04.2025 16:32:19  ldap/dc-1.ald.company.lan@ALD.COMPANY.LAN

Пароль учетной записи хоста хранится в файле /etc/krb5.keytab, поэтому пользователь может легко проходить аутентификацию и выполнять запросы от имени хоста. Проверка валидности keytab-файла является одной из рекомендаций по устранению неисправностей, если в журналах sssd появится информация о том, что служба не смогла пройти аутентификацию в домене. Такие ситуации могут возникать, например, если компьютер был удален из домена.

Содержимое keytab-файла можно посмотреть с помощью утилиты klist, используя параметр -k. Если добавить параметр -e, то можно будет увидеть, что для одной версии пароля в файле содержится сразу два ключа, полученные с помощью разных алгоритмов хеширования:

root@pc-1:~# klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

Как уже было сказано ранее, для того чтобы пройти аутентификацию от имени хоста, достаточно использовать команду sudo kinit -k. После выполнения команды ldapsearch можно увидеть, что в связке ключей появился билет на доступ к службе LDAP для учетной записи хоста:

admin@pc-1:~$ sudo kinit -k
admin@pc-1:~$ ldapsearch
...
admin@pc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_HXKunix
Default principal: host/pc-1.ald.company.lan@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 16:03:39  03.04.2025 16:03:32  ldap/dc-1.ald.company.lan@ALD.COMPANY.LAN
02.04.2025 16:03:32  03.04.2025 16:03:32  krbtgt/ALD.COMPANY.lan@ALD.COMPANY.LAN

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

Чтобы установить хосту новый пароль и выгрузить его в keytab-файл, можно воспользоваться утилитой ipa-getkeytab:

sudo ipa-getkeytab -p host/pc-1.ald.company.lan \
  -k /etc/krb5.keytab -s dc-1.ald.company.lan \
  -D uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan -W -P

Рассмотрим пример использования команды. Обратите внимание, что после смены пароля команда klist в колонке KVNO показывает новую (вторую) версию ключей.

admin@pc-1:~$ sudo rm -rf /etc/krb5.keytab

admin@pc-1:~$ sudo ipa-getkeytab -p host/pc-1.ald.company.lan \
> -k /etc/krb5.keytab -s dc-1.ald.company.lan \
> -D uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan -W -P
Введите пароль LDAP: ********
Новый пароль учётной записи: ********
Проверка пароля учётной записи: ********
Таблица ключей успешно получена и сохранена в: /etc/krb5.keytab

admin@pc-1:~$ sudo klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

Параметры вызова утилиты ipa-getkeytab:

• Ключ -p — задает имя учетной записи, для которой нужно сменить пароль.

• Ключ -k — указывает имя keytab-файла, в который требуется добавить ключи.

• Ключ -s — определяет адрес сервера (контроллера домена), через который должен быть выполнен запрос на изменение пароля.

• Ключ -D — задает отличительное имя (DN) привилегированной учетной записи, от которой можно выполнить изменения в каталоге. Если ключ -D не будет указан, то утилита ipa-getkeytab воспользуется учетными данными текущего Kerberos-пользователя.

• Ключ -W — указывает, что пароль привилегированной учетной записи будет предоставлен в интерактивном режиме.

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

• Ключ -P — определяет, что пароль хоста будет введен вручную. Если этот параметр не указывать, пароль будет сгенерирован автоматически.

Учитывая, что без указания привилегированного пользователя в явном виде утилита ipa-getkeytab использует учетные данные текущего Kerberos-пользователя, мы можем сменить пароль компьютера, используя учетные данные самого компьютера из его текущего keytab-файла:

admin@pc-1:~$ sudo kinit -kt /etc/krb5.keytab
admin@pc-1:~$ sudo ipa-getkeytab -p host/pc-1.ald.company.lan -k /etc/krb5.keytab
admin@pc-1:~$ sudo klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal

---- --------------------------------------------------------------------------
   2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)
   3 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   3 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

Регулярную смену пароля для учетной записи компьютера можно организовать с помощью дополнительного параметра групповой политики maximum_password_age.

Работа компьютера в автономном режиме

Для обеспечения комфортной работы пользователей в условиях нестабильного подключения к локальной сети по Wi-Fi или через VPN служба sssd может предоставлять часть сервисов автономно без подключения к серверу. Переход в автономный режим происходит автоматически в следующих случаях:

• пропало подключение к сети;

• нет возможности преобразовать полное имя сервера FQDN в IP-адрес;

• не удается подключиться к серверу.

Работая автономно, Монитор службы sssd предпринимает попытки возврата в режим онлайн по следующим триггерам:

• получено уведомление об изменении настроек сети, например, о подключении кабеля или изменении таблицы маршрутизации (см. информацию по библиотеке man netlink);

• получено уведомление об изменении конфигурационного файла /etc/resolv.conf (см. информацию по подсистеме man inotify);

• по расписанию каждые 30 секунд.

В ходе отладки администратор может переключать режимы вручную, отправляя процессу sssd сигналы SIGUSR1 (перейти в offline) и SIGUSR2 (перейти в online), но в большинстве случаев достаточно включить/выключить всю службу целиком.

root@pc-1:~# sssctl domain-status ald.company.lan | grep status
Online status: Online
root@pc-1:~# kill -SIGUSR1 $(pidof sssd)
root@pc-1:~# sssctl domain-status ald.company.lan | grep status
Online status: Offline
root@pc-1:~# kill -SIGUSR2 $(pidof sssd)
root@pc-1:~# sssctl domain-status ald.company.lan | grep status
Online status: Online

Автономный вход по кэшу пароля

Когда пользователь в первый раз входит в компьютер, его аутентификация возможна только через контроллер домена, но при получении успешного статуса PAM_SUCCESS служба sssd сохранит SHA512 хеш в локальной базе, что гарантирует возможность автономной аутентификации этого пользователя даже в условиях отсутствия связи с сервером. Извлечь хеш пользовательского пароля из ldb-файла и проверить его валидность можно с помощью утилит ldbsearch и openssl.

sudo ldbsearch -H /var/lib/sss/db/cache_ald.company.lan.ldb \
  -b name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb cachedPassword

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

admin@dc-1:~$ sudo ldbsearch -H /var/lib/sss/db/cache_ald.company.lan.ldb \
>   -b name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb cachedPassword
Can't load /etc/samba/smb.conf - run testparm to debug it
asq: Unable to register control with rootdse!
# record 1
dn: name=admin@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb
cachedPassword: $6$0auaUM4DmDNk0v9M$ZymggD9uTU1kRjgCVt5b2uWM3f/UHKXxC7u1DpgE87
t.WYDZl97x98PhRP/Ty.YjiSKzdGwSBlnHqX9HItV77.

# returned 1 records
# 1 entries
# 0 referrals

Проверить актуальность этого хэша можно с помощью утилиты openssl:

admin@pc-1:~$ openssl passwd -6 -salt '0auaUM4DmDNk0v9M' 'Pa$$w0rd'
$6$0auaUM4DmDNk0v9M$ZymggD9uTU1kRjgCVt5b2uWM3f/UHKXxC7u1DpgE87t.WYDZl97x98PhRP/Ty.YjiSKzdGwSBlnHqX9HItV77.

Функция хранения кэшей включена по умолчанию, за это отвечает параметр cache_credentials из файла sssd.conf. Срок хранения паролей не ограничен, так как параметр offline_credentials_expiration не задан.

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

Для решения этой проблемы в составе sssd-tools есть утилита sss_seed, которая позволяет имитировать первый вход, принудительно устанавливая ldb-кэш пароля:

root@pc-1:~# echo 'Pa$$w0rd' > /tmp/ssd-pwd.txt
root@pc-1:~# sss_seed --domain ALD.COMPANY.LAN \
--username ivan.kuznetsov --password-file /tmp/ssd-pwd.txt
Temporary password added to cache entry for admin@ald.company.lan

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

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

Автоматическая Kerberos-аутентификация при переходе в онлайн режим

Хеш SHA512 отлично подходит для долгосрочного хранения секретов на диске, но с его помощью не получится пройти Kerberos-аутентификацию в домене, поэтому при входе пользователя в систему в автономном режиме служба sssd помещает текст пользовательского пароля в связку ключей ядра Linux, чтобы иметь возможность выписать TGT-билет, когда связь с сервером будет восстановлена. За возможность автоматической Kerberos-аутентификации пользователя при переключении в онлайн режим отвечает параметр krb5_store_password_if_offline, который по умолчанию равен True.

Вы должны понимать, что этот механизм подойдет не всем организациям, поскольку, обладая привилегиями суперпользователя, вы теоретически можете извлечь это значение из связки ключей, например, с помощью утилиты keyctl. Следующие действия нужно выполнять в контексте процесса службы sssd, для чего к процессу нужно будет подключиться, например, отладчиком gdb (англ. GNU Debugger). Для возможности использования отладчика потребуется включить функцию ptrace, которая в Astra Linux по умолчанию отключена по соображениям безопасности.

admin@dc-1:~$ sudo apt install gdb
admin@dc-1:~$ sudo astra-ptrace-lock disable
admin@dc-1:~$ sudo reboot

После перезагрузки выполните вход в систему тем же пользователем и просмотрите: 1. номер pid службы sssd для подключения к процессу Монитора 2. номер текущего окна терминала для перенаправления стандартного вывода.

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

admin@dc-1:~$ sudo pidof sssd
487

admin@dc-1:~$ tty
/dev/pts/0

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

sudo gdb -p 487

GNU gdb (AstraLinuxSE 8.2.1-2) 8.2.1
...
(gdb) call system("keyctl show > /dev/pts/0")
[Detaching after fork from child process 7829]
Session Keyring
  84684334 --alswrv      0     0  keyring: _ses
 835659210 --alswrv      0     0   _ user: admin@ald.company.lan
$1 = 0
(gdb) call system("keyctl print 835659210 > /dev/pts/0")
[Detaching after fork from child process 7834]
Pa$$w0rd
$2 = 0

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

• пароль хранится в оперативной памяти и не сохраняется на диске при выключении компьютера;

• пароль хранится в системе ограниченное время и автоматически удаляется при появлении связи с контроллером домена;

• извлечь пароль может только суперпользователь при включенной функции ptrace.

Динамическое обновление DNS-записей в домене

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

Обновление DNS-записей возможно как по инициативе DHCP-сервера (Remote Name Daemon Control, RNDC), так и по инициативе рабочей станции (GSS-TSIG). У каждого из подходов есть свои сильные и слабые стороны, но второй способ видится наиболее простым и безопасным, так как в этом случае компьютеры отправляют запросы от своего имени с подтверждением аутентификации по протоколу Kerberos.

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

[domain/ad.example.com]
...
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
...

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

Централизованное управление параметрами динамического обновления DNS можно реализовать с помощью дополнительного параметра групповой политики dyndns.

Отладка sssd службы и Kerberos

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

getent passwd $USER

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

admin:*:491200000:491200000:Administrator:/home/admin:/bin/bash

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

id $USER

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

uid=491200000(admin) gid=491200000(admins) группы=491200000(admins),1001(astra-admin),491200003(lpadmin),1005611117(ald trust admin)

Журналы отладки sssd

Служба sssd состоит из множества компонентов, и для настройки каждого из них в конфигурационном файле предназначена отдельная секция (например, за настройки монитора отвечает секция [sssd], а бэкенд настраивается в секции [domain/...]), поэтому для включения отладки конкретного компонента в его секции следует задать параметр «debug_level=N», где N - это число от 1 до 10.

[domain/ald.company.lan]
debug_level = 10
...
[sssd]
debug_level = 10
...
[nss]
debug_level = 10
...
[pam]
debug_level = 10
...

Уровни отладки 1-3 регистрируют сбои, а уровни 8-10 обеспечивают излишнюю детализацию, которая затрудняет быстрый анализ журналов, поэтому для решения большинства проблем начать лучше с шестого уровня.

Уровень отладки можно менять не только через конфигурационный файл, но и «на лету» без перезагрузки службы sssd, отправляя ей команды через D-Bus с помощью утилиты sssctl из пакета sssd-tools.

Очистим логи, чтобы было удобно смотреть отладочную информацию:

admin@dc-1:~$ sudo sssctl logs-remove

Изменим уровень отладки и просмотрим в лог-файле изменение grep 'Debug level changed':

admin@dc-1:~$ sudo sssctl debug-level 6
admin@dc-1:~$ sudo cat /var/log/sssd/sssd.log | grep 'Debug level changed'

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

113 ... [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0

Повысим уровень логирования до 8:

sudo sssctl debug-level 8
sudo cat -n /var/log/sssd/sssd.log | grep 'Debug level changed'

Таким образом вы можете отметить начало и конец отладки:

113 ...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0
157 ...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x37f0

Вывести на экран диапазон строк можно с помощью утилиты sed:

sudo cat -n /var/log/sssd/sssd.log | sed '113,157!d'

В операционной системе Astra Linux журналы отладки хранятся в папке /var/log/sssd, по одному файлу журнала на каждый компонент. Ответчики пишут в файлы с именами sssd_<имя_сервиса>, например, Ответчик NSS пишет в файл /var/log/sssd/sssd_nss.log. Сообщения от Бэкенда пишутся в файл с именем sssd_<имя_домена>.log. Есть еще журналы вспомогательных процессов, таких как ldap_child.log и krb5_child.log.

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

Примечание

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

Общие рекомендации отладки sssd

Если команды getent или id не выводят вообще никакой информации о пользователе или группе:

• Проверьте работу службы разрешения имен командой ping dc-1, и указаны ли в /etc/resolv.conf правильные DNS-серверы.

• Проверьте, работает ли служба sssd с помощью команды systemctl status sssd.

• Проверьте конфигурацию /etc/nsswitch.conf, что модуль sss указан для всех нужных баз данных: passwd, group, shadow, services, netgroup, sudoers, automount.

• Проверьте поведение команды id на контроллере домена ALD Pro.

• Проверьте, доходит ли запрос до Ответчика. Для этого в разделе [nss] установите debug_level = 6 и перезапустите службу sssd.

Приведем пример успешного запроса информации по пользователю:

[sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[10327] egid[10327] pid[18144].
[sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x13c9960][22]
[sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
[sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1].
[sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1].
[sssd[nss]] [nss_getby_name] (0x0400): Input name: admin

Если команда достигает Ответчика NSS, проверьте что она передается Поставщику данных (Data Provider). Неудачный запрос может выглядеть так:

[sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
[sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for
[ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
[sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request:
[0x41e51c:1:admin@win.trust.test@win.trust.test]
[sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error
[org.freedesktop.sssd.Error.DataProvider.Offline]
[sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #3: Data Provider Error: 3, 5, Failed to get reply
from Data Provider
[sssd[nss]] [cache_req_common_dp_recv] (0x0400): CR #3: Due to an error we will return cached data

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

[sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
[sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
[sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for
[ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
[sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error
message: Success
[sssd[nss]] [cache_req_search_cache] (0x0400): CR #3: Looking up [admin@ipa.test] in cache

Если запрос к Поставщику данных успешно завершен, но вы по-прежнему не видите никаких результатов, следует переходить к журналам Бэкенда.

Отладка Бэкенда sssd

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

• Бэкенд получает запрос от клиентской библиотеки и решает, к какому серверу следует подключиться для его обработки. Этот шаг может включать в себя поиск по SRV-записям.

• Бэкенд устанавливает соединение с сервером и проходит аутентификацию, используя учетные данные из keytab-файла хоста, если это требуется.

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

• После того, как поиск завершится, соответствующие записи будут сохранены в кэше. Код состояния возвращается собеседнику.

  Установите debug_level=6 в разделе [domain/], перезапустите службу и выполните еще раз неудачный поиск информации о пользователе. При отладке работы Бэкенда в первую очередь убедитесь, что бэкенд находится в режиме онлайн. Сделать это можно с помощью утилиты sssctl:

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

Проверьте, можно ли установить соединение с теми же параметрами безопасности, которые использует sssd:

admin@dc-1:~$ kinit -k && klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_pMxi5Bu
Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.04.2025 23:15:25  03.04.2025 23:15:25  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Проверим запрос в LDAP, где Ключи -H и -ZZ делают запрос ближе к тому, как служба sssd взаимодействует с каталогом:

ldapsearch -ZZ -H ldap://dc-1.ald.company.lan \
  -b uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan cn

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

...
# admin, users, accounts, ald.company.lan
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
cn: Administrator

Если вы установите для Бэкенда десятый уровень отладки, то информация о трассировке Kerberos-аутентификации будет отражаться в файле ldap_child.log, но проще ее получить напрямую от утилиты kinit, если определить значение переменной окружения KRB5_TRACE:

set +o history
env KRB5_TRACE=/dev/stdout kinit <<< 'Pa$$w0rd'
set -o history

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

[23001] 1696515238.426608: Getting initial credentials for admin@ALD.COMPANY.LAN
[23001] 1696515238.426610: Sending unauthenticated request
[23001] 1696515238.426611: Sending request (191 bytes) to ALD.COMPANY.LAN
[23001] 1696515238.426612: Initiating TCP connection to stream 10.0.1.11:88
[23001] 1696515238.426613: Sending TCP request to stream 10.0.1.11:88
[23001] 1696515238.426614: Received answer (514 bytes) from stream 10.0.1.11:88
[23001] 1696515238.426615: Terminating TCP connection to stream 10.0.1.11:88
[23001] 1696515238.426616: Response was from master KDC
...
[23001] 1696515238.426651: Storing admin@ALD.COMPANY.LAN ->
krb5_ccache_conf_data/pa_type/krbtgt\/ALD.COMPANY.LAN\@ALD.COMPANY.LAN@X-CACHECONF: in KEYRING:persistent:491200000:krb_ccache_kFlzpn6``

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

Устранение неисправностей аутентификации, изменения пароля и контроля доступа

Если информация о пользователе может быть успешно получена, но аутентификация не проходит, то в первую очередь нужно смотреть журнал /var/log/auth.log на предмет сообщений от pam_sss.

Аутентификация начинается в PAM-стеке на фазе auth и выполняется с помощью провайдера аутентификации (auth_provider) службы sssd. Однако не все запросы на аутентификацию проходят через sssd, например, аутентификация по SSH происходит непосредственно в SSHD, а sssd взаимодействует с PAM-стеком только на фазе account.

Контроль доступа начинается в PAM-стеке на фазе account и выполняется с помощью провайдера доступа (access_provider) службы sssd.

И, наконец, смена пароля начинается на стороне PAM-стека на фазе password и выполняется с помощью провайдера смены пароля (chpass_provider) службы sssd.

Аутентификация через PAM-стек происходит по следующему шаблону:

• Приложение с поддержкой PAM-аутентификации начинает диалог. В зависимости от настроек PAM-стека в диалог может быть вовлечен модуль pam_sss. Для отладки процесса аутентификации сначала проверьте журнал /var/log/auth.log на предмет того, есть ли вообще обращения к pam_sss. Если вы не видите упоминания pam_sss, скорее всего, ваш PAM-стек настроен неправильно. Если вы видите, что есть обращения к pam_sss, включите отладку для Ответчика PAM.

• Ответчик PAM-службы sssd получает запрос на аутентификацию и в большинстве случаев пересылает его Бэкенду. Обратите внимание, что в отличие от запросов на идентификацию, запросы на аутентификацию и контроль доступа обычно не кэшируется и всегда завершаются обращением к серверу. В некоторых случаях это может приводить к задержкам, но это достаточно важно, потому что дополнительные группы в GNU/Linux устанавливаются только в момент входа в систему.

  Журналы Ответчика PAM должны показывать запросы, которые пришли от PAM-стека и были перенаправлены на бэкенд. Если вы видите запрос на аутентификацию к Ответчику PAM, но получаете ошибку от бэкенда, проверьте журналы бэкенда. Пример ошибки может выглядеть как:

[sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x411d44:3:admin@ipa.example.com]
[sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.example.com][3][1][name=admin]
[sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x411d44:3:admin@ipa.example.com]
[sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error
message: Offline
[sssd[pam]] [pam_check_user_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1,
11, Offline

• Бэкенд обрабатывает запрос. Это может включать эквивалент выполнения команды kinit в процессе krb5_child, аутентификацию по LDAP или проверку по списку контроля доступа. После того как запрос к бэкенду завершится, результат отправляется обратно собеседнику PAM.

  Посмотрите также файл krb5_child.log. Если установить уровень отладки debug_level = 10, то в этот файл будет включаться также низкоуровневая информация для трассировки работы протокола Kerberos. Вы также можете имитировать аутентификацию вручную с помощью утилиты kinit.

• Ответчик PAM получает результат и пересылает его обратно в модуль pam_sss. Сообщения об ошибке или статусе отображаются в /var/log/auth.log.

Расположение значимых файлов

В следующей таблице представлена сводная информация по наиболее полезным файлам для отладки компонентов системы.

табл. 19 Расположение файлов журналов

Компонент системы	Конфигурация	Файл журнала
sssd
SSSD	/etc/sssd/sssd.conf	/var/log/sssd/
PAM	/etc/pam.d/system-auth	/var/log/sssd/sssd_pam.log
NSS	/etc/nsswitch.conf	/var/log/sssd/sssd_nss.log
krb5_child	/etc/sssd/sssd.conf	/var/log/sssd/krb5_child.log
ldap_child	/etc/sssd/sssd.conf	/var/log/sssd/ldap_child.log
Data Provider (Backend)	/etc/sssd/sssd.conf	/var/log/sssd/sssd_<domainFQDN>.log
DNS
OS	/etc/resolv.conf	Журнала нет, но в качестве альтернативы можно использовать команду sudo tcpdump port 53
BIND9	/etc/bind/named.conf	journalctl -u bind9-pkcs11.service
SAMBA
Samba	/etc/samba/smb.conf	/var/log/samba/*.log
Winbind	/etc/security/pam_winbind.conf	/var/log/samba/log.*
Kerberos
Kerberos	/etc/krb5.conf	/var/log/sssd/krb5_child.log
SaltStack
Salt-master	/etc/salt/	/var/log/salt/master
Salt-minion	/etc/salt/	/var/log/salt/minion

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

• Практическая работа: Модуль 5. Работа Linux-компьютера в домене
• Тест: Модуль 5. Работа Linux-компьютера в домене

Заключение

В этом модуле мы рассмотрели архитектуру службы sssd и подробно разобрали протокол Kerberos, поэтому у нас теперь есть целостное представление о том, как именно работает Linux-компьютер в составе домена, что поможет в отладке любых нештатных ситуаций.

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

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

• Статья на Хабре Windows-компьютеры в составе домена ALD Pro.

• Рекомендуем ознакомиться также с видеороликами нашего хорошего товарища на канале «ИТ-Проповедник». Учитывайте, что ролики записаны для версии 2.2.1.

  • Служба sssd в ALD Pro, отладка службы sssd и Kerberos

  • Виды аутентификации в ALD Pro - LDAP, Kerberos, NTLM

Обратная связь

Если остались вопросы, то их всегда можно задать в специальной теме.