Product SiteDocumentation Site

⁠14.2. Авторизация (NSS)

После успешной аутентификации системе необходимо определить, какие пользователи и группы существуют, какие у них UID/GID и какие права им назначены. Для этого используется подсистема NSS (Name Service Switch), которая позволяет системе получать информацию о пользователях и группах из различных источников.
Winbind и SSSD предоставляют свои модули для интеграции с NSS:
  • Winbind: nss_winbind.so
  • SSSD: nss_sss.so
Эти модули настраиваются в файле /etc/nsswitch.conf, например: 
passwd: files winbind
shadow: tcb files winbind
group:  files winbind
или: 
passwd: files sss
shadow: tcb files sss
group:  files sss
Здесь winbind или sss определяют, что информация о пользователях и группах запрашивается у соответствующей службы:
  • Winbind — запрашивает SID пользователей и групп через RPC и LDAP и маппирует их в локальные UID/GID;
  • SSSD — запрашивает данные пользователей и групп через LDAP.

⁠14.2.1. SSSD

SSSD позволяет управлять авторизацией пользователей и групп, используя разные механизмы, которые определяются параметром access_provider.
Доступные значения access_provider:
  • permit — разрешает доступ всем пользователям (по умолчанию);
  • deny — блокирует доступ всем пользователям;
  • ldap — проверяет доступ через LDAP-фильтр (например, членство в группе);
  • ad — использует Group Policy Objects (GPO) для авторизации (при id_provider = ad);
  • hbac — применяет Host-Based Access Control (HBAC) (только для FreeIPA).

⁠14.2.1.1. Механизм ID Mapping

Информацию о механизме ID Mapping в SSSD см. Настройка SSSD.

⁠14.2.1.2. Управление правами через SUDO

Помимо контроля входа, SSSD может управлять sudo-правилами. Конфигурация sudo традиционно хранится в файле sudoers, который нужно вручную копировать и обновлять на каждой машине в системе (чтобы включить SSSD как источник правил sudo, необходимо добавить sss в запись sudoers в файле nsswitch.conf). Однако в больших инфраструктурах это может быть неудобно и трудоемко, поэтому часто для упрощения управления правами доступа используют LDAP (Lightweight Directory Access Protocol), централизованный каталог для хранения конфигураций. В этом случае локальные системы просто обращаются к центральному серверу LDAP для получения актуальной информации о правилах доступа.
На стороне SSSD достаточно расширить список служб добавлением sudo в раздел [sssd] sssd.conf. Чтобы ускорить поиск LDAP, также можно указать базу поиска для правил sudo с помощью параметра ldap_sudo_search_base.
В следующем примере показано, как настроить SSSD на загрузку правил sudo с сервера LDAP: 
[sssd]
config_file_version = 2
services = nss, pam, sudo
domains = TEST

[domain/TEST]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://test.alt
ldap_sudo_search_base = ou=sudoers,dc=test,dc=alt
Важно учитывать, что на платформах, где поддерживается systemd, не требуется добавлять поставщика данных «sudo» в список служб, так как он стал необязательным. Однако вместо этого следует включить sssd-sudo.socket.