ActiveDirectory/SSSD&Winbind

Материал из ALT Linux Wiki
< ActiveDirectory
Версия от 18:03, 12 марта 2025; Olga kmv (обсуждение | вклад) (Новая страница: «В операционных системах на базе Linux два ключевых инструмента обеспечивают взаимодействие с Active Directory: '''Winbind''' и '''SSSD'''. * '''Winbind''' (часть пакета Samba) — демон, обеспечивающий взаимодействие с AD и решающий проблему единого входа в систему. Winbind использует вы...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)

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

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.