Настройка SSSD

SSSD (System Security Services Daemon) — системный демон, позволяющий обращаться к удаленным механизмам авторизации. Информацию о пользователях предоставляет база данных, называемая доменом, которая может служить источником данных для удаленной авторизации. Допускается использование нескольких механизмов, что разрешает нескольким серверам реализовать различные пространства имен. Полученная информация потом предоставляется внешним приложениям с помощью стандартных интерфейсов PAM и NSS.

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

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

Установка SSSD

Для установки SSSD и всех зависимостей, включая клиента SSSD, выполните следующую команду:

# yum install sssd

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

Обновление предыдущей версии

Описание конфигурационного файла SSSD приводится в секции Настройка SSSD.

Обновление с использованием RPM

Если вы делаете обновление с использованием пакетов RPM, скрипт выполнится автоматически во время обновления системы. Он обновит формат файла /etc/sssd/sssd.conf и сохранит его предыдущую резервную копию в файле /etc/sssd/sssd.conf.bak.

Ручное обновление

В некоторых случаях бывает необходимо выполнить скрипт обновления вручную, например, если вы строите SSSD из исходных файлов, или используете платформу, не поддерживающую RPM. Строка запуска скрипта имеет следующий формат:

upgrade_config.py [ -f INFILE ] [ -o OUTFILE ] [ -verbose ] [ --no-backup ]

• -f INFILE — задаётся имя нового конфигурационного файла. Если параметр не задан, по умолчанию берётся файл /etc/sssd/sssd.conf;
• -o OUTFILE — задаётся имя обновляемого конфигурационного файл. Если параметр не задан, по умолчанию берётся файл /etc/sssd/sssd.conf;
• -verbose — выводить более подробную информацию о процессе обновления;
• --no-backup — не создавать резервную копию исходного конфигурационного файла. Если параметр не задан, по умолчанию исходный файл копируется в INFILE.bak

Запуск и остановка сервиса

Перед тем, как запустить SSSD в первый раз, необходимо настроить хотя бы один домен. Обратитесь к соответствующей документации, чтобы узнать больше о настройке доменов. Для запуска используйте либо команду service, либо скрипт /etc/init.d/sssd. Например, для запуска сервиса sssd выполните следующую команду:

# service sssd start

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

# chkconfig sssd on

Настройка SSSD

Глобальные настройки SSSD сохраняются в файле /etc/sssd/sssd.conf . Этот файл состоит из нескольких секций, каждая из которых содержит пару ключ/значение. Некоторые ключи могут принимать несколько значений, разделяемых запятой. Данный конфигурационный файл использует строковые (кавычки не требуются), целые и булевы (TRUE или FALSE) переменные. Комментарии отделяются знаками «#» или «;». Следующий пример иллюстрирует описываемый синтаксис:

[section]
# Keys with single values
key1 = value
key2 = val2

# Keys with multiple values
key10 = val10,val11

Используйте параметр командной строки -c (или --config), чтобы задать имя используемого конфигурационного файла. Обратитесь к документации на sssd.conf(5), чтобы получить больше информации о глобальных конфигурационных параметрах SSSD.

Настройка NSS

SSSD предоставляет новый модуль nss_sss, с помощью которого вы можете настроить вашу систему на получение информации о пользователе с помощью SSSD. Для того, чтобы ваша система использовала базу имён sss, отредактируйте файл /etc/nsswitch.conf так, чтобы в нём была прописана необходимая информация об sss. Например:

passwd: files sss
group: files sss

Настройка PAM

Будьте предельно осторожны, когда меняете свою конфигурацию PAM! Ошибка в конфигурационном файле может полностью заблокировать вас в системе. Всегда сохраняйте резервную копию своего конфигурационного файла перед внесением в него любых изменений. Оставляйте сессию открытой, чтобы всегда можно было всё вернуть к первоначальному состоянию. Для того, чтобы включить использование SSSD для PAM в системе, нужно отредактировать конфигурационный файл PAM по умолчанию. В системах, основанных на Fedora, это файл /etc/pam.d/system-auth. Впишите следующий текст в этот файл и перезапустите сервис sssd:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel/
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_sss.so
session     required      pam_unix.so

Конструкция include в конфигурационных файлах PAM

Последние версии PAM позволяют использовать конструкцию include. Например:

...
session     include      system-auth
session     optional     pam_console.so
...

В этом примере, если достаточное (sufficient) условие из system-auth возвращает PAM_SUCCESS, pam_console.so не будет исполняться.

Настройка контроля доступа

SSSD предоставляет рудиментарный механизм контроля доступа, основанный на списках имён пользователей, для которых доступ разрешён или запрещён. Этот так называемый «Простой провайдер доступа» (Simple Access Provider), он настраивается в секции [domain/<NAME>] файла /etc/sssd/sssd.conf. Чтобы включить контроль доступа, нужно установить опцию access_provider в simple, и добавить имена пользователей, разделённые запятыми, в списки simple_allow_users или simple_deny_users.

Использование простого провайдера доступа

С помощью простого провайдера доступа, вы можете продолжать поддерживать ряд сетевых логинов для поддержания общих сетевых учетных записей компании. Но в каком-то случае вы, возможно, захотите ограничить использование конкретного ноутбука одним или двумя пользователями. Это значит, что даже если другой другой пользователь успешно пройдёт проверку подлинности у того же провайдера авторизации, простой провайдер доступа не позволит этому пользователю получить доступ именно на данном устройстве. В примере ниже демонстрируется использование простого провайдера доступа для назначений прав двум пользователям. Предполагается, что SSSD правильно сконфигурирован, example.com - один из доменов, заданных в секции [sssd], и показаны только настройки, специфичные для простого провайдера доступа.

[domain/example.com]
access_provider = simple
simple_allow_users = user1, user2

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

Простой провайдер доступа придерживается следующих правил для определения, какому пользователю дать права, а какому не давать:

• Если оба листа пусты, доступ разрешается;
• Если список simple_allow_users задан, доступ разрешается только пользователям из этого списка. Этот список приоритетнее списка simple_deny_users (и в данном случае simple_deny_users избыточен);
• Если список simple_allow_users пуст, доступ получат пользователи, не перечисленные в списке simple_deny_userslist.

Важно! Одновременное определение списков simple_allow_users и simple_deny_users — ошибка в конфигурации. Если такое происходит, SSSD выводит сообщение об ошибке во время своей загрузки и не может стартовать.

Настройка аварийного переключения

Функция аварийного переключения позволяет автоматически переключиться на другой сервер в случае, если на работающем сервере произошла ошибка. Такие резервные сервера в порядке приоритета заносятся в список, разделённый запятыми и учитывающий регистр, в секцию [domain/<NAME>] в файле /etc/sssd/sssd.conf. Этот список может содержать любое количество серверов. Например, для настроенного домена LDAP, вы можете задать следующие величины ldap_uri:

ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org

В этой конфигурации ldap://ldap0.mydomain.org работает как первичный сервер. Если на нём возникли какие-то проблемы, система аварийного переключения SSSD пытается присоединиться к ldap1.mydomain.org, а если он недоступен, к ldap2.mydomain.org. Если параметр, устанавливающий соответствие серверов и доменов (например, ldap_uri, krb5_kdcip, …), не установлен, по умолчанию используется Use service discovery.

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

Использование служебных записей для аварийного подключения

SSSD также позволяет использовать служебные (SRV) записи в своих конфигурациях. То есть, можно задать имя, которое позже при необходимости преобразуется в список серверов с помощью специального служебного запроса. Атрибуты запроса priority и weight позволяют указать, какие сервера должны быть присоединены в первую очередь в случае возникновения проблем с первым сервером. Для каждого такого сервера нужно прописать специальную запись DNS на первом сервере в следующей форме:

_service._protocol._domain TTL priority weight port hostname

Типичная конфигурация содержит несколько таких записей, каждая с разным приоритетом (для аварийного подключения) и весом (для балансировки нагрузки). Клиент делает служебный запрос для получения списка имён, приоритетов и весов серверов в форме _service._protocol._domain, например, _ldap._tcp._redhat.com. После этого клиент сортирует полученный список соответственно приоритетам и весам, и пытается присоединиться к первому серверу из упорядоченного списка. Формат служебных запросов описан в стандарте IETF RFC 2782.

Как работает механизм аварийного переключения

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