ActiveDirectory/SSSD&Winbind

Материал из ALT Linux Wiki

В операционных системах на базе Linux два ключевых инструмента обеспечивают взаимодействие с Active Directory: Winbind и SSSD.

  • Winbind (часть пакета Samba) — демон, обеспечивающий взаимодействие с AD и решающий проблему единого входа в систему. Winbind использует вызовы Microsoft RPC. Он поддерживает как Kerberos, так и NTLM, предоставляя системам механизмы аутентификации и авторизации, аналогичные тем, что используются в Windows.
  • SSSD (System Security Services Daemon) — клиентский компонент централизованных служб каталогов (таких как FreeIPA, 389 Directory Server, Microsoft Active Directory, OpenLDAP и другие). Он запрашивает и кэширует информацию, а также предоставляет услуги идентификации, аутентификации и авторизации для локальной машины.
Winbind SSSD
Аутентификация Kerberos Поддерживает (начиная с версии 4.19.9-alt4) Поддерживает
NTLM Поддерживает. Используется, если Kerberos недоступен или не используется. Не поддерживает
LDAP Не поддерживает Поддерживает (не в AD-домене)
Авторизация LDAP Поддерживает Поддерживает
вызовы Microsoft RPC Поддерживает Не поддерживает
Автономный вход в систему Поддерживает Поддерживает
Поддержка доверительных отношений External Поддерживает Поддерживает
Forest Поддерживает Поддерживает в пределах одного леса
Сross-forest Поддерживает Не поддерживает
Поддержка групповых политик Групповые политики Samba Теоретически поддерживает, не реализовано в Альт домен Не поддерживает
Групповые политики ALT Linux с помощью gpupdate Поддерживает Поддерживает
GPO-Based Access Control Не поддерживает Поддерживает
Сопоставление идентификаторов
Подробнее в IDMapping
 Уникальные (в пределах одного домена) Поддерживает
 Поддерживает
Локальные (в пределах одной машины) Поддерживает
 Не поддерживает
RFC 2307 Поддерживает
 Поддерживает
Обновление DNS Встроенное Не поддерживает Поддерживает
Сторонние решения Поддерживает
Подробнее Dynamic dns update 		Не поддерживает
Автоматическая интеграция с sudo Не поддерживает
 Поддерживает
Аутентификация с помощью электронных ключей, смарт-карт и сертификатов Не поддерживает
 Поддерживает
Производительность при обработке большого числа групп и пользователей Высокая

 Низкая

Аутентификация (PAM)

В Linux аутентификация пользователей управляется системой PAM (Pluggable Authentication Modules), которая позволяет использовать различные модули для проверки учетных данных. Winbind и SSSD реализуют собственные PAM-модули:

  • Winbind: pam_winbind.so
  • SSSD: pam_sss.so

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

  • Winbind использует NTLM или Kerberos.
  • SSSD использует Kerberos.

Конфигурация PAM обычно прописывается в файле /etc/pam.d/system-auth, где подключается преднастроенный стек: 

system-auth-winbind-only

или

system-auth-sss-only

SSSD

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

  • Поставщик данных Kerberos - для аутентификации через билеты Kerberos. Требует настройки auth_provider = krb5. Для корректной работы его необходимо использовать совместно с поставщиком данных идентификации (например, id_provider = ldap). Некоторые данные, которые требуются внутреннему серверу проверки подлинности Kerberos 5, должны предоставляться поставщиком данных идентификации (например, имя участника Kerberos пользователя (UPN)).
  • Поставщик данных LDAP - Требует настройки auth_provider = ldap. Чтобы аутентифицироваться на сервере LDAP, требуется TLS/SSL или LDAPS. SSSD не поддерживает аутентификацию через незащищенный канал. Даже если сервер LDAP используется только как провайдер идентификации, использование зашифрованного канала настоятельно рекомендуется.
  • Поставщик данных Active Directory — это внутренний сервер, который используется для подключения к серверу Active Directory. Обмен данными с внутренним сервером выполняется по каналу с шифрованием GSSAPI. С поставщиком данных AD не следует использовать параметры SSL/TLS, поскольку использование Kerberos будет иметь приоритет над ними. Поставщик данных AD позволяет SSSD использовать поставщика данных идентификации sssd-ldap и поставщика данных проверки подлинности sssd-krb5 с оптимизацией для сред Active Directory. Поставщик данных AD принимает те же параметры, которые используются поставщиками sssd-ldap и sssd-krb5, за некоторыми исключениями.
  • Поставщик IPA — это серверная часть, используемая для подключения к серверу IPA. Этот поставщик требует, чтобы компьютер был подключен к домену IPA; конфигурация почти полностью определяется автоматически и получается непосредственно с сервера. Поставщик IPA позволяет SSSD использовать поставщика идентификационных данных sssd-ldap и sssd-krb5.

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

Пример настройки аутентификации для Active Directory:

[domain/EXAMPLE.ALT]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
debug_level = 0
; cache_credentials = false
ad_gpo_ignore_unreadable = true
ad_gpo_access_control = permissive
ad_update_samba_machine_account_password = true

Winbind

В Winbind за аутентификацию отвечает параметр security, который определяет модель безопасности Samba:

  • ads – настраивает Samba как участника домена в домене Active Directory. Для аутентификации в этом режиме используется Kerberos.
  • domain – Samba выступает как член старого NT-домена (не Active Directory) и передает учетные данные на контроллер домена Windows.
  • server – более устаревший вариант, при котором Samba делегирует аутентификацию другому серверу, но, если тот откажет, пробует локальную проверку.
  • user – стандартный режим, когда учетные данные проверяются на самом сервере Samba, без обращения к домену.

Основными методами аутентификации являются:

  • Kerberos — используется для безопасной аутентификации через билеты Kerberos. Это основной механизм при работе с доменами Active Directory (security = ads). Winbind автоматически получает и управляет Kerberos-билетами для пользователей.
  • NTLM — в случае, если Kerberos недоступен или не используется, Winbind может прибегать к аутентификации через NTLM (NT LAN Manager), который является устаревшим, но все еще поддерживаемым методом аутентификации в Windows-средах.

Для настройки Winbind используется конфигурация в файле /etc/samba/smb.conf.

Пример настройки аутентификации Winbind для AD:

[global]
security = ads
workgroup = EXAMPLE
realm = EXAMPLE.ALT
idmap config * : backend = tdb
idmap config EXAMPLE : backend = rid
idmap config EXAMPLE : range = 10000-999999
winbind use default domain = yes
winbind offline logon = yes
winbind refresh tickets = yes
winbind enum users = no
winbind enum groups = no
kerberos method = secrets and keytab
log file = /var/log/samba/log.%m
log level = 3

Авторизация (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.

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).

Если в access_provider не задана проверка (например, access_provider = permit), то авторизация не будет выполняться, и система пустит всех пользователей.

Механизм ID Mapping

  1. Использование атрибутов uidNumber и gidNumber
    Если в AD настроены Unix-атрибуты и не требуется динамическое сопоставление, можно использовать атрибуты напрямую. SSSD берет uidNumber, gidNumber, homeDirectory, loginShell из AD.
  2. ID Mapping через ldap_id_mapping = True
    Возможность сопоставления идентификаторов позволяет SSSD выступать в роли клиента Active Directory, при этом администраторам не требуется расширять атрибуты пользователя с целью поддержки атрибутов POSIX для идентификаторов пользователей и групп. Когда сопоставление идентификаторов включено, атрибуты uidNumber и gidNumber игнорируются. Это позволяет избежать возможных конфликтов между значениями, назначенными автоматически, и значениями, назначенными вручную.
    Минимальная конфигурация (в разделе “[domain/DOMAINNAME]”):
    ldap_id_mapping = True
ldap_schema = ad
    По умолчанию пул UID/GID для сопоставления SID в SSSD имеет ограниченный размер. Для больших доменов с количеством пользователей более 200 тысяч этот пул необходимо расширять вручную.
    • При стандартной конфигурации настраивается 10000 срезов, каждый из которых может содержать до 200000 идентификаторов, начиная от 200000 и до 2000200000.
    • Из всего общего диапазона, размером 2 миллиарда под каждый домен выделяется срез id размером 200000, каждому домену может соответствовать только один единственный срез.
    • Для увеличения размера среза в конфигурации SSSD используются параметры:
      • ldap_idmap_range_min - нижняя (включительно) граница диапазона идентификаторов.
      • ldap_idmap_range_max - верхняя (не включительно) граница диапазона идентификаторов.
      • ldap_idmap_range_size - количество идентификаторов, доступных для каждого среза.
      Значение должно быть не меньше значения максимального RID пользователя, запланированного для использования на сервере AD.
      Эти параметры позволяют адаптировать пул UID/GID под нужды вашего домена. Однако, увеличивая размер среза, необходимо уменьшать количество срезов, что увеличивает вероятность коллизий (по умолчанию вероятность коллизии одного конкретного домена с другим составляет 1/10000).

Управление правами через 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 = EXAMPLE

[domain/EXAMPLE]
id_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com

Важно учитывать, что на платформах, где поддерживается systemd, не требуется добавлять поставщика данных «sudo» в список служб, так как он стал необязательным. Однако вместо этого следует включить sssd-sudo.socket.

Подробнее см. Правила SUDO.

Winbind

Winbind работает как клиент Active Directory и получает данные учетных записей пользователей и групп через вызовы Microsoft RPC и LDAP.

Механизм ID Mapping

Домены Windows различают пользователей и группы по уникальным идентификаторам безопасности (SID). Однако в Linux для каждого пользователя и группы требуются уникальные идентификаторы UID и GID. Служба winbindd отвечает за предоставление информации о пользователях и группах домена.

Чтобы служба winbindd могла предоставлять уникальные идентификаторы для пользователей и групп в Linux, необходимо на клиенте домена настроить сопоставление идентификаторов в файле /etc/samba/smb.conf для:

  • Локальная база данных (домен * по умолчанию)
  • Домен AD
  • Каждый доверенный домен, из которого пользователи должны иметь доступ к ресурсам

Подробности в статье IDMapping.

Кеширование и управление сессией

SSSD

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

Чтобы пользователи могли входить в систему, даже если провайдер идентификации недоступен, можно включить кэширование учетных данных, установив параметр cache_credentials = true в файле /etc/sssd/sssd.conf.

  • cache_credentials — определяет, должны ли учетные данные пользователя также сохраняться в локальном кэше LDB. Кэшированные учетные данные относятся к паролям, включая первый (долгосрочный) фактор двухфакторной аутентификации, но не другие механизмы аутентификации (пароли хранятся в виде хеша формата SHA-512). По умолчанию: FALSE.

В SSSD информация о пользователях и группах кэшируется в следующих файлах:

  • cache_<домен>.ldb
    • Тип: Авторизационный кэш
    • Функция: Основной кэш данных о пользователях и группах.
  • ccache_<домен>
    • Тип: Аутентификационный кэш
    • Функция: Кэширование учетных данных, используемое для Kerberos.
  • timestamps_<домен>.ldb
    • Функция: Управляет сроками действия кэшированных данных.

Winbind

Winbind использует TDB (Trivial Database) файлы, которые расположены в /var/lib/samba/.

  • winbindd_cache.tdb:
    • Тип: Авторизационный кэш
    • Функция: Хранит информацию об идентификации, полученной от домена Active Directory.
  • winbindd_idmap.tdb:
    • Тип: Авторизационный кэш
    • Функция: Локальная база данных IDMAP, используемая winbindd для сопоставления SID и UID/GID при бэкенде tdb.
  • gencache.tdb:
    • Тип: Общий кэш
    • Функция: Хранит кэшированную информацию о недоступных серверах и доверенных доменах.

С остальными файлами и их описанием можно ознакомиться в SambaWiki.

Параметр, отвечающий за кэширование:

[global]
winbind offline logon = yes

Этот параметр включается в smb.conf, чтобы позволить Winbind использовать кешированные учетные данные для аутентификации, когда сервер Active Directory недоступен.

Также есть параметр время кэширования Winbind: 

winbind cache time

Этот параметр указывает количество секунд, в течение которых демон winbindd будет кэшировать информацию о пользователях и группах перед повторным запросом к серверу Windows NT.

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

Групповые политики

Групповая политика — это механизм централизованного управления настройками рабочей среды.

Поддержка групповых политик ALT Linux

В дистрибутивах ALT Linux реализована поддержка групповых политик (Group Policy Objects, GPO), что позволяет централизованно управлять настройками и конфигурациями систем, аналогично средам Windows. Для применения групповых политик используется утилита gpupdate, предназначенная для работы на машинах, введённых в домен Samba, как с помощью SSSD, так и с помощью Winbind.

При аутентификации пользователя модуль PAM system-policy-gpupdate.so запускает pam_oddjobd_gpupdate.so, который инициирует выполнение системной службы oddjob.service для выполнения привилегированных задач. oddjob.service вызывает утилиту /usr/sbin/gpoa, которая отвечает за репликацию и применение групповых политик (GPO). В зависимости от переданного параметра утилита gpoa обновляет либо настройки пользователя, если передано его имя, либо настройки всей машины, если параметр отсутствует. Этот процесс гарантирует автоматическое применение актуальных групповых политик при каждом входе пользователя в систему.

SSSD

Интеграция с GPO-Based Access Control для входа в систему

Один из распространенных сценариев управления доступом к компьютерам в среде Active Directory — использование параметров групповой политики (GPO), связанных с правами входа на машину.

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

Групповая политика Параметр конфигурации SSSD
Allow log on locally ad_gpo_map_interactive
Allow log on through Remote Desktop Services ad_gpo_map_remote_interactive
Log on as a batch job ad_gpo_map_batch
Log on as a service ad_gpo_map_service

Настройки политики GPO можно использовать для централизованной настройки нескольких наборов прав входа (Logon Rights) на клиентскую машину, каждый из которых классифицируется по способу входа (interactive, remote interactive) и состоит из белого и чёрного списка пользователей и групп, которым разрешён или запрещён доступ к компьютеру с использованием способа входа. Для этого сопоставляются имена pam-служб с определёнными правами входа. Предоставляются сопоставления по умолчанию для всех часто используемых имён pam-служб, также администратор может добавлять/удалять сопоставления по мере необходимости. Делается это с помощью параметров конфигурации вида «gpo_map_<logon_right>» (например, gpo_map_interactive, gpo_map_network и т. д.), каждый из которых состоит из списка записей, разделённых запятыми, начинающихся либо с «+» (для добавления в набор по умолчанию), либо с «-» (для удаления из набора по умолчанию). Подробнее прочитать в man sssd-ad.

Значение белого и черного списка:

  • Белый список (“allow”):
    Если этот параметр не задан, любой пользователь может войти в систему. Если он задан, только указанные пользователи и группы получают доступ. Другими словами, при включении этого параметра поведение изменяется с "доступ разрешен всем" на "доступ запрещен всем, кроме перечисленных в белом списке".
  • Черный список (“deny”):
    Если этот параметр не задан, он не оказывает влияния. Если он определен, указанные пользователи и группы не могут входить в систему. Если пользователь или группа присутствует одновременно в белом и черном списках, приоритет отдается черному списку.

Процесс применения GPO:

Если пользователь пытается войти в систему, то:

  • Определяется, какое право входа (Logon Rights) связано с сервисом PAM.
  • Получаются соответствующие политики GPO из файла GptTmpl.inf, который содержит настройки политики из расширения "Security Settings".
  • Например, для права интерактивного входа (Interactive Logon Right) используются параметры SeInteractiveLogonRight (разрешенные пользователи) и SeDenyInteractiveLogonRight (запрещенные пользователи) из файла GptTmpl.inf.

Клиентская реализация:

Когда клиент пытается получить доступ к серверу, SSSD (System Security Services Daemon) выполняет несколько шагов для обработки групповых политик:

  • Скачивание файлов политики: Файлы GPT.INI и GptTmpl.inf скачиваются с сервера и сохраняются в кэше GPO на клиентской машине (в директории /var/lib/sss/gpo_cache/), чтобы ускорить доступ и избежать повторных запросов к серверу при каждом входе пользователя в систему.
  • Анализ содержимого файлов: После того как файлы были получены и сохранены в кэше, процесс gpo_child начинает их обработку.
  • Применение политики:После того как политика была загружена и ее содержание проанализировано, механизм принудительного применения GPO обеспечивает контроль доступа, проверяя политику против белого или черного списка, который может содержать разрешения или запреты для определенных групп.

Детали реализации:

Так как функция контроля доступа на основе GPO используется только провайдером AD, она включена в пакет sssd-ad. Исходные файлы для этой функции включены в libsss_ad.so. Эта функция не включена по умолчанию. Предоставлена конфигурационная опция ad_gpo_access_control, которая может быть установлена в одно из следующих значений:

  • disabled (не осуществляется ни проверка соответствия правилам управления доступом на основе GPO, ни их принудительное применение)
  • enforcing (осуществляется проверка соответствия правилам управления доступом на основе GPO и их принудительное применение)
  • permissive (осуществляется проверка соответствия правилам управления доступом на основе GPO, но не их принудительное применение. Вместо этого создаётся сообщение системного журнала, означающее, что пользователю было бы отказано в доступе, если бы в качестве значения этого параметра был задан принудительный режим)

С остальными конфигурационными параметрами, относящимися к GPO, можно ознакомиться в man sssd-ad.

Winbind

В Альт Домене поддержка групповых политик Samba не реализована, но теоретически Winbind их поддерживает. Ознакомиться можно в статье.

Обновление DNS

Когда машина вводится в домен, в DNS-записи на DNS-сервере прописывается текущий IP-адрес машины. В случае изменения IP-адреса для взаимодействия с Active Directory используются службы Winbind и SSSD для обновления DNS-записей.

SSSD

Для включения обновления IP-адресов службой sssd существует несколько способов:

  • с помощью центра управления ALT Linux (ALT Linux Control Center)
  • редактирование файла /etc/sssd/sssd.conf
  • групповыми политиками
  • применением control

Подробности в статье.

Winbind

Samba Winbind не поддерживает возможность динамического обновления DNS-записей. Для обхода этой проблемы была разработана программа, реализующая динамическое обновление адресов на DNS-сервере при использовании winbind в качестве клиента домена — winbind-dnsupdate. 

# apt-get install samba-winbind-dnsupdate

Подробности в статье.

Поддержка работы с несколькими доменами и доверительные отношения

SSSD

Работа с несколькими доменами: SSSD с поставщиком данных AD (id_provider = ad) может использоваться для получения данных пользователей и проверки подлинности пользователей из доверенных доменов. В настоящее время распознаются только домены, находящиеся в одном и том же лесу. Кроме того, контроллеры доменов из доверенных доменов всегда обнаруживаются автоматически.

Поддержка кросс-лесных доверий: SSSD не поддерживает трасты уровня леса (Forest Trusts), что ограничивает его возможности при работе с многоуровневыми лесами доменов.

Winbind

Работа с несколькими доменами: Winbind на клиентских машинах не распознаёт доверенные домены. Чтобы устранить эту проблему, необходимо внести изменения в конфигурационный файл smb.conf на Linux-клиентах, подключенных через Winbind. В секции [global] этого файла следует добавить соответствующую опцию:

winbind scan trusted domains = yes