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

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

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

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

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

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

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

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

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

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

Включение Offline режима можно командой:

sudo kill -SIGUSR1 $(pidof sssd) && sudo sssctl domain-status ald.company.lan | grep status

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

Online status: Offline

Включение Online режима можно командой:

sudo kill -SIGUSR2 $(pidof sssd) && sudo sssctl domain-status ald.company.lan | grep status

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

Online status: Online

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

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

Получить кэшированный пароль пользователя admin:

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

В результате отображается атрибут 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$o.zJdi5M.yDDUi5j$5YHQgKLFhRzt78sSx5R8AXqLYTo9fgkgzGflHI1SYG
rshTqIGPwEv7G1WUvgd8vW3LoCSYPt88KV7SeN2N6A.0
...

Проверить генерацию хэша пароля можно с помощью утилиты openssl, где: o.zJdi5M.yDDUi5j — соль, которая получается из кэша пароля между символами $:

sudo i
set +o history
openssl passwd -6 -salt 'o.zJdi5M.yDDUi5j' 'AstraLinux_176'
set -o history
exit

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

$6$o.zJdi5M.yDDUi5j$5YHQgKLFhRzt78sSx5R8AXqLYTo9fgkgzGflHI1SYGrshTqIGPwEv7G1WUvgd8vW3LoCSYPt88KV7SeN2N6A.0

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

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

Установить кэш пароля для тестовой учетной записи olegovo:

sudo i
set +o history
echo 'AstraLinux_176' > /tmp/ssd-pwd.txt
sss_seed --domain ALD.COMPANY.LAN --username olegovo --password-file /tmp/ssd-pwd.txt
rm /tmp/ssd-pwd.txt
set -o history
exit

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

Temporary password added to cache entry for olegovo@ald.company.lan

Проверить результат кэша командой:

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

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

...
dn: name=olegovo@ald.company.lan,cn=users,cn=ald.company.lan,cn=sysdb cachedPassword:
$6$0Xa5CIrB1WRICTmM$eJ0bVItqEQeSfx6/B3.bodGHdn//uMuAYk.9fCnvcL.7iGdka/Uhrn5TrV4HxKznikXeXc82LQcT/d1CYvWig.
...

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

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

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

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

sudo apt install gdb
sudo astra-ptrace-lock disable
sudo reboot

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

Найти идентификатор процесса можно командой:

pidof sssd

Результат выполнения потребуется для подключения к процессу sssd:

487

Вычисляется устройство текущего терминала для вывода:

tty

Результат вывода:

/dev/pts/0

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

sudo gdb -p 487

В результате подключиться к процессу через отладчик gdb:

GNU gdb (AstraLinuxSE 8.2.1-2) 8.2.1
...
(gdb) _

Для выхода из отладчика ввести команду q.

Выполнить команду gdb для получения связки ключей:

call system("keyctl show > /dev/pts/0")

Результат выполнения, где важен идентификатор ключа 835659210:

Session Keyring
 84684334 --alswrv      0     0  keyring: _ses
835659210 --alswrv      0     0   \_ user: admin@ald.company.lan
...

Выполнить запрос данных по идентификатору 835659210 на терминал /dev/pts/0:

call system("keyctl print 835659210 > /dev/pts/0")

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

[Detaching after fork from child process 7834]
AstraLinux_172
$2 = 0

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

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

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

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