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

Введение

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

Служба SSSD

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

За работу компьютера в домене отвечает служба SSSD, которая была создана в рамках проекта FreeIPA и является на сегодняшний день лучшим решением для обеспечения работы компьютера Linux в составе домена. Установка службы SSSD происходит вместе с пакетом aldpro-client, а настройка выполняется при вводе компьютера в домен с помощью утилиты aldpro-client-installer.

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

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

root@pc-1:~# systemctl stop sssd
root@pc-1:~# systemctl start sssd
root@pc-1:~# systemctl restart sssd
root@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 Mon 2023-07-31 22:38:35 MSK; 5s 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

июл 31 22:38:35 pc-1.ald.company.lan systemd[1]: Starting System Security Services Daemon...
июл 31 22:38:35 pc-1.ald.company.lan sssd[3740]: Starting up
июл 31 22:38:35 pc-1.ald.company.lan be[ald.company.lan][3741]: Starting up
июл 31 22:38:35 pc-1.ald.company.lan ifp[3742]: Starting up
июл 31 22:38:35 pc-1.ald.company.lan pac[3743]: Starting up
июл 31 22:38:35 pc-1.ald.company.lan ifp[3742]: List item [ipaapi] is neither ...
июл 31 22:38:35 pc-1.ald.company.lan systemd[1]: Started System Security Services Daemon.

Основная задача службы SSSD заключается в предоставлении доступа информации удаленной службы каталога и механизмам централизованной аутентификации. В качестве поставщика данных для SSSD может выступать FreeIPA, Active Directory, сервер Kerberos и даже простой LDAP-каталог. Продукт ALD Pro построен на базе службы каталога FreeIPA, поэтому в конфигурационных файлах /etc/sssd/sssd.conf на доменных компьютерах будет указан поставщик «ipa»:

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

Для обработки запросов на аутентификацию служба 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
...

Модули службы 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 состоит из множества компонентов, которые взаимодействуют друг с другом при помощи различных методов межпроцессного взаимодействия, см. рис. 227.

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

• Монитор (англ. Monitor). В английском языке слово «monitor» имеет еще значение «наставник» что точнее отражает роль этого компонента, но мы не станем создавать путаницу и будем называть его просто монитором.

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

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

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

рис. 227 Архитектура службы SSSD

Монитор (Monitor)

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

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

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

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

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

рис. 228 Диаграмма загрузки службы 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 head /etc/sssd/sssd.conf -n 12

[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, с которым требуется поддерживать соединение.

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

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

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

• Если провайдер не указан, то используется значение id_provider (например, ipa). Исключением является 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 socket (например, /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 и так далее). На рис. 229 отражен поток данных, создаваемый клиентским приложением 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-операцию.

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

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

Несмотря на то, что клиентские приложения и библиотеки не являются синонимами, в рабочей документации и программном коде службы SSSD под словосочетанием SSSD Client (суффикс sss_cli) часто подразумеваются именно клиентские библиотеки, а не сами приложения. Например, идентификатором sss_cli обозначается сетевой протокол, с помощью которого клиентские библиотеки общаются с Ответчиками службы 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:

admin@dc-1:~$ sudo apt install ldb-tools
...

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: 310400000
cachedPassword: $6$u4YejIUZ9cxnfqeh$bxH/g8FNJ7gpz/...E/U/fotvnnimCKnjGWsueB/

 # returned 1 records
 # 1 entries
 # 0 referrals

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

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

admin@dc-1:~$ sudo -i
root@dc-1:~# rm -rf /var/lib/sss/db/*; systemctl restart sssd
root@dc-1:~# 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, после чего посмотрим в локальный кэш еще раз:

root@dc-1:~# id admin
uid=310400000(admin) gid=310400000(admins) группы=310400000(admins),1001(astra-admin),1005611117(ald trust admin),113(lpadmin)

root@dc-1:~# 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: 310400000
# 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 (Kerberos Armoring).

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

localadmin@pc-1:~$ sudo systemctl stop sssd
localadmin@pc-1:~$ sudo rm -rf /var/lib/sss/db/*
localadmin@pc-1:~$ sudo systemctl start sssd

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

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

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. С ее помощью можно не удалять записи из кэша, а отметить их недействительными, что сильно повышает производительность службы, т.к. обновление информации о записях происходит значительно быстрее, чем их создание.

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

admin@pc-1:~$ sudo sss_cache -E

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

admin@pc-1:~$ 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, а для очистки, как и в случае локального кэша, просто удалить файлы и перезапустить службу:

localadmin@pc-1:~$ sudo systemctl stop sssd
localadmin@pc-1:~$ sudo rm -rf /var/lib/sss/mc/*
localadmin@pc-1:~$ sudo systemctl start sssd

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

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

admin@pc-1:~$ sudo sss_cache –u admin

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

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

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

admin@pc-1:~$ sudo systemctl restart sssd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

admin@pc-1:~$ ldapsearch -H ldaps://dc-1.ald.company.lan \
-D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W | head -1

Enter LDAP Password:
# extended LDIF
...

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

admin@pc-1:~$ ldapsearch -ZZ -H ldap://dc-1.ald.company.lan \
–D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W | head -1

Напомним назначение ключей утилиты ldapsearch:

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

• Ключ -D — задает имя пользователя для подключения.

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

• Ключ -ZZ — первый ключ Z указывает на то, что после установления соединения необходимо попробовать включить шифрование командой STARTTLS, а второй требует прервать соединение, если сервер не поддерживает TLS. Использовать один ключ Z при выполнении авторизованных запросов не рекомендуется.

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

admin@dc-1:~$ ldapsearch -H ldap://dc-1.ald.company.lan \
-D 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' -W

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

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

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

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

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

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

Хеширование паролей выполняется автоматически при изменении пароля, по умолчанию используется устойчивый к взлому алгоритм PBKDF2_SHA256:

admin@pc-1:~$ 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::». В строке 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.

$ sudo ipa config-mod --enable-migration=true
$ sudo ipa user-add userName --setattr userPassword='{TYPE}HASH'

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

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

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

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

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

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

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

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

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

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

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

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

рис. 234 Начало аутентификации пользователя «Алиса»

Шаг (1) Пользователь Алиса через приложение графического входа (Fly Display Manager Greet) передает стеку модулей аутентификации (Pluggable Authentication Modules, PAM) логин и пароль в открытом виде. За аутентификацию в домене отвечает модуль /usr/lib/x86_64-linux-gnu/security/pam_sss.so, см. файл /etc/pam.d/common-auth:

#
# /etc/pam.d/common-auth - authentication settings common to all services
...
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
...

Шаг (2) Библиотека libpam загружает Клиентскую библиотеку pam_sss.so, через функции которой обращается к Ответчику /usr/lib/x86_64-linux-gnu/sssd/sssd_pam. Ответчик обращается к Бэкенду, который порождает процесс krb5_child для аутентификации в домене по протоколу Kerberos V5.

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

Шаг (3) Клиент отправляет запрос службе аутентификации Центра распространения ключей (Key Distribution Center, KDC). В четвертой версии протокола на этом шаге никакие учетные данные не требовались, т. к. ответ будет зашифрован долгосрочным ключом пользователя, и способность расшифровать ответ является подтверждением того, что пользователь является тем, за кого себя выдает. Но с пятой версии протокола сервер отклонит запрос и потребует предварительную аутентификацию. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью долгосрочного ключа клиента. Указанная проверка существенно затрудняет кибератаки, так как лишает злоумышленника возможности запросить TGT-билет на любого пользователя в системе.

рис. 235 Обработка запроса на стороне KDC, создание и отправка билета TGT

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

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

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

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

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

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

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

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

Шаг (9) Процесс krb5_child сохраняет TGT-билет в связке ключей Linux и передает результаты по цепочке «Бэкенд => Ответчик => Клиентская библиотека». После чего Клиентская библиотека отправляет запрос на получение сервисного билета на доступ к серверу приложения, в котором содержится имя пользователя (user principal name), имя сервера приложения (service principal name), билет на выдачу билетов (TGT) и аутентификатор. В качестве аутентификатора выступает метка времени, зашифрованная симметричным алгоритмом с помощью сессионного ключа S1. В качестве имени сервиса при входе в компьютер выступает host/pc-fqdn.

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

рис. 237 Обработка запроса на сессионный ключ и выдача сессионного ключа по запросу клиента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для выполнения аутентификации по протоколу Kerberos, т.е. для получения TGT-билета используется утилита kinit. Если обратиться к утилите без параметров, то она будет использовать имя пользователя по умолчанию (англ. Default principal) из текущего кэша учетных данных системы (см. klist), а если в кэше ничего нет, то воспользуется именем текущего пользователя Linux (см. whoami).

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

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

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

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

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

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

sudo kinit -kt /etc/krb5.keytab

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

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

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

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

Valid starting       Expires              Service principal
15.06.2024 06:33:10  16.06.2024 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
15.06.2024 06:21:24  16.06.2024 06:21:24  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
15.06.2024 06:21:24  16.06.2024 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 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   2 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)
   2 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha256-128)
   2 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha384-192)
   2 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (camellia128-cts-cmac)
   2 17.09.2023 10:52:49 host/dc-1.ald.company.lan@ALD.COMPANY.LAN (camellia256-cts-cmac)

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

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

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

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

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

admin@dc-1:~$ kdestroy
admin@dc-1:~$ klist
klist: Credentials cache keyring 'persistent:310400000: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:310400000:krb_ccache_xOCrrRF
Default principal: admin@ALD.COMPANY.LAN

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

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

Выполняя 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:310400000:krb_ccache_oR4OXE0
Default principal: semenov.ii@ALD.COMPANY.LAN

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

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

Valid starting       Expires              Service principal
15.06.2024 06:53:58  16.06.2024 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:310400000:krb_ccache_8KcsvR7
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
28.06.2024 06:53:58  29.06.2024 06:53:55  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
admin@dc-1:~$
admin@dc-1:~$ kswitch -p semenov.ii
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:310400000:krb_ccache_oR4OXE0
Default principal: semenov.ii@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
28.06.2024 06:54:06  29.06.2024 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.

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

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

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

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

• Клиент обращается к Сервису с запросом на аутентификацию (1) и получает в ответ случайное число длиной 8 байт, которое ему нужно подписать, используя свой пароль, для подтверждения аутентичности (2).

• Клиент подписывает сообщение и передает его Сервису (3), который пересылает подпись вместе с исходным сообщением на контроллер домена (4).

• Контроллер проверяет подпись и возвращает PAC сертификат, если проверка аутентичности пройдена успешно (5).

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

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

Текущие настройки службы 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-аутентификации на контроллере можно воспользоваться утилитой ntlm_auth. За обработку запросов NTLM-аутентификации отвечает Winbind.

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

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

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

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

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

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

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

• Аутентификация с использованием расширения PKINIT по протоколу Kerberos (TCP/88) использует X.509 сертификаты для взаимной аутентификации центра распределения ключей и клиента, но не является примером SSL-протокола.

Сертификаты применяются также для доступа к PostgreSQL (TCP/5432), взаимодействия со службой печати по протоколу IPP (TCP/631), а до версии 2.0.0 использовалось REST API системы конфигурирования SaltStack (TCP/8000), но все эти примеры не представляют интереса ввиду локального характера сетевого взаимодействия.

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

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

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

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

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

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

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

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

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

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

• [5] Сервер передает клиенту сообщение, зашифрованное общим ключом, подтверждающее возможность начала безопасного обмена данными.

• [6] Клиент и сервер выполняют обмен данными по защищенному каналу связи.

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

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

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

Администратор может проверить, что порт TCP/389 действительно защищен шифрованием, и получить цепочку сертификатов с помощью утилиты 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, обычно находится в самом конце этого файла. Чтобы просмотреть информацию по всем сертификатам из файла, можно использовать следующую команду:

admin@dc-1:~$ 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
17.08.2023 16:32:19 18.08.2023 16:32:19  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN
17.08.2023 16:32:19 18.08.2023 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)

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

root@pc-1:~# kinit -kt /etc/krb5.keytab
root@pc-1:~# ldapsearch
...
root@pc-1:~# klist
Ticket cache: KEYRING:persistent:959800000:krb_ccache_HXKunix
Default principal: host/pc-1.ald.company.lan@ALD.COMPANY.LAN

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

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

Чтобы установить хосту новый пароль и выгрузить его в keytab-файл, можно воспользоваться утилитой ipa-getkeytab. Обратите внимание, что после смены пароля команда klist в колонке KVNO показывает новую версию ключей.

root@pc-1:~# rm -rf /etc/krb5.keytab
root@pc-1:~# 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

root@pc-1:~# 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-файла:

root@pc-1:~# kinit -kt /etc/krb5.keytab
root@pc-1:~# ipa-getkeytab -p host/pc-1.ald.company.lan -k /etc/krb5.keytab
root@pc-1:~# 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)

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

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

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

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

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

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

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

• получено уведомление об изменении конфигурационного файла /etc/resolv.conf (см. информацию по подсистеме 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.

root@pc-1:~# 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

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$CGpJigrgfCjFleyN$ZJA....zzPp6Lwx0W5NxIy5nm1

# returned 1 records
# 1 entries
# 0 referrals

root@pc-1:~# openssl passwd -6 -salt 'CGpJigrgfCjFleyN' 'AstraLinux_174'
$6$CGpJigrgfCjFleyN$ZJAYEysnOtFNIhbDqgs2idg...nm1

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

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

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

root@pc-1:~# echo 'AstraLinux_174' > /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

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

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

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

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

root@pc-1:~# apt install gdb
root@pc-1:~# astra-ptrace-lock disable
root@pc-1:~# reboot

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

root@pc-1:~# pidof sssd
487

root@pc-1:~# tty
/dev/pts/0

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

root@pc-1:~# 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]
AstraLinux_172
$2 = 0

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

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

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

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

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

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

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

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

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

admin@dc-1:~$ getent passwd "$USER"

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

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

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

admin@dc-1:~$ id $USER

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

uid=959800000(admin) gid=959800000(admins) группы=959800000(admins),1001(astra-admin),113(lpadmin)

Журналы отладки 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'

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

(2023-08-20 22:17:00): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0

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

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

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

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

Выбрать строки между кодами смены уровня отладки 0x07f0 и 0x37f0 можно с помощью regex:

admin@dc-1:~$ cat /var/log/sssd/sssd.log | grep -zoP '(?<=0x07f0)(?s).*(?=0x37f0)'

В операционной системе 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-серверы.

• Работает ли служба с помощью команды 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:

admin@dc-1:~$ 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:959800000:krb_ccache_pMxi5Bu
Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

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

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

admin@dc-1:~$ 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

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

admin@dc-1:~$ set +o history
admin@dc-1:~$ env KRB5_TRACE=/dev/stdout kinit <<< AstraLinux_174
admin@dc-1:~$ 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:1421600000: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
BIND9	/etc/resolv.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. Работа компьютера в домене
• Тест: Модуль 5. Работа компьютера в домене

Заключение

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

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

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

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