SSSD-AD(5) | Форматы файлов и рекомендации | SSSD-AD(5) |
NAME¶
sssd-ad - Поставщик Active Directory SSSD
ОПИСАНИЕ¶
На этой справочной странице представлено описание настройки поставщика данных AD для sssd(8). Подробные сведения о синтаксисе доступны в разделе “ФОРМАТ ФАЙЛА” справочной страницы sssd.conf(5).
Поставщик данных AD — это внутренний сервер, который используется для подключения к серверу Active Directory. Для работы этого поставщика необходимо, чтобы компьютер был присоединён к домену AD и чтобы была доступна таблица ключей. Обмен данными с внутренним сервером выполняется по каналу с шифрованием GSSAPI. С поставщиком данных AD не следует использовать параметры SSL/TLS, поскольку использование Kerberos будет иметь приоритет над ними.
Поставщик данных AD поддерживает подключение к Active Directory 2008 R2 или выше. Работа с предшествующими версиями возможна, но не поддерживается.
Поставщик данных AD может использоваться для получения данных пользователей и проверки подлинности пользователей из доверенных доменов. В настоящее время распознаются только домены, находящиеся в одном и том же лесу. Кроме того, серверы из доверенных доменов всегда обнаруживаются автоматически.
Поставщик данных AD позволяет SSSD использовать поставщика данных идентификации sssd-ldap(5) и поставщика данных проверки подлинности sssd-krb5(5) с оптимизацией для сред Active Directory. Поставщик данных AD принимает те же параметры, которые используются поставщиками sssd-ldap и sssd-krb5 providers, за некоторыми исключениями. Но установка этих параметров не является ни необходимой, ни рекомендуемой.
Поставщик данных AD в основном копирует стандартные параметры традиционных поставщиков данных ldap и krb5, за некоторыми исключениями. Список различий доступен в разделе “ИЗМЕНЁННЫЕ СТАНДАРТНЫЕ ПАРАМЕТРЫ”.
Поставщик данных AD также может использоваться в качестве поставщика данных управления доступом, chpass, sudo и autofs. Конфигурация поставщика доступа на стороне клиента не требуется.
Если в sssd.conf указано “auth_provider=ad” или “access_provider=ad”, параметр id_provider тоже необходимо установить в значение “ad”.
По умолчанию поставщик данных AD сопоставляет значения UID и GID из параметра objectSID в Active Directory. Подробные сведения об этом доступны в разделе “СОПОСТАВЛЕНИЕ ИДЕНТИФИКАТОРОВ” ниже. Если требуется отключить сопоставление идентификаторов и полагаться на атрибуты POSIX, определённые в Active Directory, следует указать
ldap_id_mapping = False
Если должны быть использованы атрибуты POSIX, в целях повышения производительности рекомендуется также реплицировать эти атрибуты в глобальный каталог. Если атрибуты POSIX реплицируются, SSSD попытается найти домен по числовому идентификатору из запроса с помощью глобального каталога и выполнит поиск в этом домене. Если же атрибуты POSIX не реплицируются в глобальный каталог, SSSD придётся последовательно выполнить поиск во всех доменах в лесу. Обратите внимание, что для ускорения поиска без доменов также может быть полезным использование параметра “cache_first”. Учтите, что если в глобальном каталоге присутствует только подмножество атрибутов POSIX, из порта LDAP не будет выполняться чтение нереплицированных атрибутов.
Регистр записей пользователей, групп и других сущностей, обслуживаемых SSSD, никогда не учитывается поставщиком данных AD в целях обеспечения совместимости с реализацией LDAP Active Directory.
SSSD разрешает только группы безопасности Active Directory. Дополнительные сведения о типах групп AD см. в разделе Группы безопасности Active Directory[1]
SSSD отфильтровывает локальные для домена группы от удалённых доменов в лесу AD. По умолчанию группы будут отфильтрованы (например, при следовании по иерархии вложенных групп в удалённых доменах), так не являются действительными в локальном домене. Это сделано для обеспечения согласованности с назначением групп и участия в них Active Directory, которое можно увидеть в PAC билете Kerberos пользователя, выданного Active Directory.
ПАРАМЕТРЫ КОНФИГУРАЦИИ¶
Сведения о конфигурации домена SSSD доступны в разделе “РАЗДЕЛЫ ДОМЕНА” справочной страницы sssd.conf(5).
ad_domain (строка)
Для корректной работы этот параметр следует указывать в формате записи полной версии имени домена Active Directory в нижнем регистре.
Краткое имя домена (также называется именем NetBIOS или плоским именем) автоматически определяется SSSD.
ad_enabled_domains (строка)
During the discovery of the domains SSSD will filter out some domains where flags or attributes indicate that they do not belong to the local forest or are not trusted. If ad_enabled_domains is set, SSSD will try to enable all listed domains.
Для корректной работы этот параметр должен быть указан полностью в нижнем регистре и как полное доменное имя домена Active Directory. Например:
ad_enabled_domains = sales.example.com, eng.example.com
Краткое имя домена (также называется именем NetBIOS или плоским именем) будет автоматически определено SSSD.
По умолчанию: не задано
ad_server, ad_backup_server (строка)
Этот параметр является необязательным, если включено автоматическое обнаружение служб. Дополнительные сведения об обнаружении служб доступны в разделе “ОБНАРУЖЕНИЕ СЛУЖБ”.
Примечание: доверенные домены всегда автоматически обнаруживают серверы, даже если в параметре ad_server явно определён основной сервер.
ad_hostname (строка)
Это поле используется для определения используемого участника-узла в таблице ключей и выполнения динамических обновлений DNS. Его значение должно соответствовать имени узла, для которого была выпущена таблица ключей.
ad_enable_dns_sites (логическое значение)
Если этот параметр установлен в значение «true» и включено обнаружение служб (смотрите абзац об обнаружении служб в нижней части справочной страницы), SSSD сначала попытается обнаружить сервер Active Directory, к которому следует подключиться, с помощью возможности обнаружения сайтов Active Directory, а затем, если сайт AD не удастся найти, будет использовать записи SRV DNS. Конфигурация SRV DNS, включая домен обнаружения, используется также и при обнаружении сайтов.
По умолчанию: true
ad_access_filter (строка)
Этот параметр также поддерживает указание разных фильтров для отдельных доменов или лесов. Такой расширенный фильтр имеет следующий формат: “KEYWORD:NAME:FILTER”. Ключевым словом может быть “DOM” или “FOREST”, а также оно может отсутствовать.
Если в качестве ключевого слова используется “DOM” или если ключевое слово не указано, “NAME” указывает домен или поддомен, к которому применяется фильтр. Если в качестве ключевого слова используется “FOREST”, фильтр применяется ко всем доменам из леса, указанного значением “NAME”.
Несколько фильтров можно разделить с помощью символа “?”, аналогично работе баз поиска.
Поиск участия во вложенных группах выполняется с помощью специального OID “:1.2.840.113556.1.4.1941:” в дополнение к полной синтаксической конструкции DOM:domain.example.org:, чтобы средство обработки не пыталось интерпретировать символы двоеточия, связанные с OID. Без использования этого OID разрешение участия во вложенных группах не будет выполняться. Пример использования приводится ниже, а дополнительные сведения о OID доступны в разделе технической спецификации Active Directory MS, посвящённом расширениям LDAP[2]
Всегда используется совпадение с наивысшим уровнем соответствия. Например, если с помощью параметра задан фильтр для домена, участником которого является пользователь, и глобальный фильтр, будет применяться фильтр для домена. Если имеется несколько совпадений с одинаковым уровнем соответствия, будет использоваться первое из них.
Примеры:
# применить фильтр только для домена с именем dom1: dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com) # применить фильтр только для домена с именем dom2: DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com) # применить фильтр только для леса с именем EXAMPLE.COM: FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com) # применить фильтр для участника вложенной группы в dom1: DOM:dom1:(memberOf:1.2.840.113556.1.4.1941:=cn=nestedgroup,ou=groups,dc=example,dc=com)
По умолчанию: не задано
ad_site (строка)
По умолчанию: не задано
ad_enable_gc (логическое значение)
Обратите внимание, что отключение глобального каталога не отключает получение данных пользователей из доверенных доменов. SSSD просто будет подключаться к порту LDAP доверенных доменов. Тем не менее, для разрешения данных о междоменном участии в группах необходимо использовать глобальный каталог.
По умолчанию: true
ad_gpo_access_control (строка)
Функциональная возможность управления доступом на основе GPO использует параметры политики GPO для определения того, разрешён ли конкретному пользователю вход на узел. Дополнительные сведения о поддерживаемых параметрах политики доступны в описании параметров “ad_gpo_map”.
Обратите внимание, что текущая версия SSSD не поддерживает встроенные группы Active Directory. Встроенные группы (например, Administrators с SID S-1-5-32-544) в правилах управления доступом GPO будут проигнорированы SSSD. Подробные сведения доступны в системе отслеживания ошибок: https://github.com/SSSD/sssd/issues/5063 .
Перед осуществлением управления доступом SSSD применяет к GPO фильтр безопасности групповой политики. Для входа каждого пользователя проверяется применимость GPO, связанных с узлом. Чтобы GPO применялся к пользователю, пользователь или хотя бы одна из групп, участником которых он является, должна обладать следующими правами GPO:
По умолчанию в GPO присутствует группа Authenticated Users. Она обладает как правом доступа Read, так и правом доступа Apply Group Policy. Так как проверка подлинности пользователя должна успешно завершиться до того, как будет применён фильтр безопасности и начато управление доступом на основе GPO, этот пользователю всегда будет обладать правами группы Authenticated Users GPO.
ПРИМЕЧАНИЕ: если в качестве режим работы выбран принудительный режим, возможно, что пользователям, которым был ранее разрешён доступ для входа, теперь будет отказано в доступе для входа (согласно параметрам политики GPO). Чтобы облегчить переход на новую систему, для администраторов предусмотрен разрешительный режим: правила управления доступом не применяются в принудительном порядке. Программа просто проверяет соответствие этим правилам и выводит в системный журнал сообщение в случае отказа в доступе. Просмотрев этот журнал, администраторы смогут внести необходимые изменения, а затем включить принудительный режим. Для ведения журнала управления доступом на основе GPO необходимо включить уровень отладки «трассировка функций» (см. справочную страницу sssctl(8)).
Для этого параметра поддерживаются три значения:
По умолчанию: enforcing
ad_gpo_implicit_deny (логическое значение)
По умолчанию: false
В следующих двух таблицах показано, когда пользователю будет разрешён или запрещён доступ на основе прав разрешения или запрета входа, которые определены на стороне сервера, и установленного значения ad_gpo_implicit_deny.
ad_gpo_implicit_deny = False (по умолчанию) | ||
правила разрешения | правила запрета | результат |
отсутствуют | отсутствуют | доступ разрешён всем пользователям |
отсутствуют | присутствуют | доступ разрешён только пользователям, отсутствующим в правилах запрета |
присутствуют | отсутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения |
присутствуют | присутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения и отсутствующим в правилах запрета |
ad_gpo_implicit_deny = True | ||
правила разрешения | правила запрета | результат |
отсутствуют | отсутствуют | доступ запрещён всем пользователям |
отсутствуют | присутствуют | доступ запрещён всем пользователям |
присутствуют | отсутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения |
присутствуют | присутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения и отсутствующим в правилах запрета |
ad_gpo_ignore_unreadable (логическое значение)
По умолчанию: false
ad_gpo_cache_timeout (целое число)
По умолчанию: 5 (секунд)
ad_gpo_map_interactive (строка)
Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить локальный вход» («Allow log on locally») и «Запретить локальный вход» («Deny log on locally»).
Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для этого права входа (например, “login”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_interactive = +my_pam_service, -login
По умолчанию: стандартный набор имён служб PAM включает:
ad_gpo_map_remote_interactive (строка)
Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход через службы удалённых рабочих столов» («Allow log on through Remote Desktop Services») и «Запретить вход через службы удалённых рабочих столов» («Deny log on through Remote Desktop Services»).
Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для этого права входа (например, “sshd”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_remote_interactive = +my_pam_service, -sshd
По умолчанию: стандартный набор имён служб PAM включает:
ad_gpo_map_network (строка)
Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить доступ к компьютеру из сети» («Access this computer from the network») и «Запретить доступ к компьютеру из сети» («Deny access to this computer from the network»).
Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для этого права входа (например, “ftp”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_network = +my_pam_service, -ftp
По умолчанию: стандартный набор имён служб PAM включает:
ad_gpo_map_batch (строка)
Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход в качестве пакетного задания» («Allow log on as a batch job») и «Запретить вход в качестве пакетного задания» («Deny log on as a batch job»).
Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для этого права входа (например, “crond”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_batch = +my_pam_service, -crond
Примечание: имя службы cron может различаться в зависимости от используемого дистрибутива Linux.
По умолчанию: стандартный набор имён служб PAM включает:
ad_gpo_map_service (строка)
Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход в качестве службы» («Allow log on as a service») и «Запретить вход в качестве службы» («Deny log on as a service»).
Можно добавить имя службы PAM в стандартный набор с помощью “+service_name”. Так как стандартный набор является пустым, из него невозможно удалить имя службы PAM. Например, чтобы добавить пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_service = +my_pam_service
По умолчанию: не задано
ad_gpo_map_permit (строка)
Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для безусловно разрешённого доступа (например, “sudo”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_permit = +my_pam_service, -sudo
По умолчанию: стандартный набор имён служб PAM включает:
ad_gpo_map_deny (строка)
Можно добавить имя службы PAM в стандартный набор с помощью “+service_name”. Так как стандартный набор является пустым, из него невозможно удалить имя службы PAM. Например, чтобы добавить пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:
ad_gpo_map_deny = +my_pam_service
По умолчанию: не задано
ad_gpo_default_right (строка)
Для этого параметра поддерживаются следующие значения:
По умолчанию: deny
ad_maximum_machine_account_password_age (целое число)
По умолчанию: 30 дней
ad_machine_account_password_renewal_opts (строка)
По умолчанию: 86400:750 (24 часа и 15 минут)
ad_update_samba_machine_account_password (логическое значение)
По умолчанию: false
ad_use_ldaps (логическое значение)
По умолчанию: false
ad_allow_remote_domain_local_groups (логическое значение)
Обратите внимание, что установка этого параметра в значение “true” идёт вразрез со смыслом локальной группы домена в Active Directory и ДОЛЖНА ВЫПОЛНЯТЬСЯ ТОЛЬКО ДЛЯ ОБЛЕГЧЕНИЯ ПЕРЕХОДА С ДРУГИХ РЕШЕНИЙ. Хотя эта группа существует и пользователь может быть её участником, смысл состоит в том, что группа должна использоваться только в том домене, где она определена, и ни в каких других. Так как существует только один тип групп POSIX, единственный способ добиться этого на стороне Linux — игнорировать эти группы. Active Directory делает то же самое: в PAC билета Kerberos для локальной службы и в запросах tokenGroups тоже отсутствуют удалённые группы, локальные в домене.
Учитывая вышесказанное, при установке этого параметра в значение “true” необходимо отключить запрос tokenGroups путём установки параметра “ldap_use_tokengroups” в значение “false” для получения согласованных данных об участии пользователей в группах. Кроме того, также следует отключить поиск в глобальном каталоге путём установки параметра “ad_enable_gc” в значение “false”. И, наконец, может потребоваться изменить значение параметра “ldap_group_nesting_level”, если удалённые группы, локальные в домене, могут быть найдены только на более глубоком уровне вложенности.
По умолчанию: false
dyndns_update (логическое значение)
ПРИМЕЧАНИЕ: на устаревших системах (например, RHEL 5) для корректной работы в этом режиме необходимо надлежащим образом задать стандартную область Kerberos в /etc/krb5.conf
По умолчанию: true
dyndns_ttl (целое число)
По умолчанию: 3600 (секунд)
dyndns_iface (строка)
По умолчанию: использовать IP-адреса интерфейса, который используется для подключения LDAP AD
Пример: dyndns_iface = em1, vnet1, vnet2
dyndns_refresh_interval (целое число)
По умолчанию: 86400 (24 часа)
dyndns_update_ptr (логическое значение)
Note that dyndns_update_per_family parameter does not apply for PTR record updates. Those updates are always sent separately.
По умолчанию: true
dyndns_force_tcp (логическое значение)
По умолчанию: false (разрешить nsupdate выбрать протокол)
dyndns_auth (строка)
По умолчанию: GSS-TSIG
dyndns_auth_ptr (строка)
По умолчанию: то же, что и dyndns_auth
dyndns_server (строка)
Установка этого параметра имеет смысл для сред, в которых сервер DNS отличается от сервера данных идентификации.
Обратите внимание, что этот параметр используется только для резервной попытки, которая выполняется тогда, когда предыдущая попытка с использованием автоматически определённых параметров завершилась неудачей.
По умолчанию: none (разрешить nsupdate выбрать сервер)
dyndns_update_per_family (логическое значение)
По умолчанию: true
override_homedir (строка)
%u
%U
%d
%f
%l
%P
%o
%h
%H
%%
Этот параметр также можно задать для каждого домена отдельно.
пример:
override_homedir = /home/%u
По умолчанию: не задано (SSSD будет использовать значение, полученное от LDAP)
Обратите внимание, что домашний каталог из конкретного переопределения для пользователя, локально (см. sss_override(8)) или централизованно управляемых переопределений идентификаторов IPA, обладает более высоким приоритетом и будет использоваться вместо значения, указанного с помощью override_homedir.
homedir_substring (строка)
По умолчанию: /home
krb5_confd_path (строка)
Чтобы отключить создание фрагментов конфигурации, установите этот параметр в значение «none».
По умолчанию: не задано (подкаталог krb5.include.d каталога pubconf SSSD)
ИЗМЕНЁННЫЕ СТАНДАРТНЫЕ ПАРАМЕТРЫ¶
Некоторые стандартные значения параметров не соответствуют стандартным значениям параметров соответствующего внутреннего поставщика данных. Имена этих параметров и специфичные для поставщика данных AD стандартные значения параметров перечислены ниже:
Поставщик данных KRB5¶
Поставщик данных LDAP¶
Поставщик данных AD по умолчанию выполняет поиск других записей участников, чем поставщик LDAP, потому что в окружении Active Directory участники делятся на две группы: участники-пользователи и участники-службы. Для получения TGT может использоваться только запись участника-пользователя, и по умолчанию записи участников — объектов компьютеров создаются из их sAMAccountName и области AD. Известный участник host/hostname@REALM является участником-службой и, следовательно, не может использоваться для получения TGT.
Настройка NSS¶
Поставщик данных AD автоматически устанавливает «fallback_homedir = /home/%d/%u», чтобы предоставить личные домашние каталоги для пользователей без атрибута homeDirectory. Если домен AD надлежащим образом заполнен атрибутами POSIX и требуется предотвратить такое поведение в качестве резервного, можно явно указать «fallback_homedir = %o».
Обратите внимание: система обычно ожидает, что домашний каталог будет в папке /home/%u. Если принято решение использовать другую структуру каталога, может потребоваться настроить некоторые другие части системы.
Например, автоматическое создание домашних каталогов в сочетании с SELinux потребует настройки параметров SELinux; в ином случае домашний каталог будет создан с неверным контекстом SELinux.
ОТРАБОТКА ОТКАЗА¶
Функция обработки отказа позволяет внутренним серверам автоматически переключаться на другой сервер в случае сбоя текущего сервера.
Синтаксис обработки отказа¶
Список серверов разделяется запятыми; рядом с запятыми допускается любое количество пробелов. Серверы перечислены в порядке приоритета. Список может содержать любое количество серверов.
Для каждого параметра конфигурации с поддержкой отработки отказа существуют два варианта: основной (primary) и резервный (backup). Смысл в том, что приоритет получают серверы из списка основных, а поиск резервных серверов выполняется только в том случае, если не удалось связаться с основными серверами. Если выбран резервный сервер, устанавливается 31-секундный тайм-аут. По его истечении SSSD будет периодически пытаться восстановить подключение к одному из основных серверов. Если попытка будет успешной, текущий активный (резервный) сервер будет заменён на основной.
Механизм отработки отказа¶
Механизм отработки отказа различает компьютеры и службы. Внутренний сервер сначала пытается разрешить имя узла указанного компьютера; если попытка разрешения завершается неудачей, компьютер считается работающим в автономном режиме. Дальнейшие попытки подключиться к этому компьютеру для доступа к другим службам не выполняются. Если попытка разрешения успешна, внутренний сервер пытается подключиться к службе на этом компьютере. Если попытка подключения к службе завершается неудачей, работающей в автономном режиме будет считаться только эта служба, и внутренний сервер автоматически переключится на следующую службу. Компьютер продолжает считаться находящимся в сети, возможны дальнейшие попытки подключения к другим службам на нём.
Дальнейшие попытки подключения к компьютерам или службам, обозначенным, как работающие в автономном режиме, выполняются по истечении определённого периода времени; в настоящее время это значения является жёстко заданным и составляет 30 секунд.
Если список компьютеров исчерпан, внутренний сервер целиком переключается на автономный режим и затем пытается восстановить подключение каждые 30 секунд.
Тайм-ауты и тонкая настройка отработки отказа¶
Разрешение имени сервера, к которому следует подключиться, может быть выполнено как за один запрос DNS, так и за несколько шагов, например, при поиске корректного сайта или переборе нескольких имён узлов, если некоторые из настроенных серверов недоступны. Для более сложных сценариев требуется больше времени, и SSSD требуется соблюсти баланс между предоставлением достаточного количества времени для завершения процесса разрешения и не слишком долгим ожиданием перед переходом в автономный режим. Если в журнале отладки SSSD есть данные о том, что время на разрешение сервера истекло до обращения к реальному серверу, рекомендуется изменить значения тайм-аутов.
В этом разделе перечислены доступные настраиваемые параметры. Их описание содержится на справочной странице sssd.conf(5).
dns_resolver_server_timeout
По умолчанию: 1000
dns_resolver_op_timeout
По умолчанию: 3
dns_resolver_timeout
По умолчанию: 6
Для поставщиков данных на основе LDAP операция разрешения выполняется как часть операции установления LDAP-соединения. Следовательно, тайм-аут “ldap_opt_timeout” также следует установить в большее значение, чем “dns_resolver_timeout”, который, в свою очередь, следует установить в большее значение, чем “dns_resolver_op_timeout”, который должен быть больше “dns_resolver_server_timeout”.
ОБНАРУЖЕНИЕ СЛУЖБ¶
Функция обнаружения служб позволяет внутренним серверам автоматически находить серверы, к которым следует подключиться, с помощью специального запроса DNS. Эта возможность не поддерживается для резервных серверов.
Конфигурация¶
Если серверы не указаны, внутренний сервер будет автоматически использовать обнаружение служб, чтобы попытаться найти сервер. Пользователь может (необязательно) задать использование сразу и фиксированных адресов серверов, и обнаружения служб, вставив в список серверов специальное ключевое слово “_srv_”. Обработка выполняется в порядке приоритета. Эта возможность полезна, например, если пользователь предпочитает использовать обнаружение служб всегда, когда это возможно, и подключаться к определённому серверу только в тех случаях, когда серверы не удалось обнаружить с помощью DNS.
Имя домена¶
Дополнительные сведения доступны в описании параметра “dns_discovery_domain” на справочной странице sssd.conf(5).
Протокол¶
В запросах обычно указан протокол _tcp. Исключения задокументированы в описаниях соответствующих параметров.
См. также¶
Дополнительные сведения о механизме обнаружения служб доступны в RFC 2782.
СОПОСТАВЛЕНИЕ ИДЕНТИФИКАТОРОВ¶
Возможность сопоставления идентификаторов позволяет SSSD выступать в роли клиента Active Directory, при этом администраторам не требуется расширять атрибуты пользователя с целью поддержки атрибутов POSIX для идентификаторов пользователей и групп.
ПРИМЕЧАНИЕ: когда сопоставление идентификаторов включено, атрибуты uidNumber и gidNumber игнорируются. Это позволяет избежать возможных конфликтов между значениями, назначенными автоматически, и значениями, назначенными вручную. Если требуется использовать значения, назначенные вручную, следует назначить вручную ВСЕ значения.
Обратите внимание, что изменение параметров конфигурации, связанных с сопоставлением идентификаторов, приведёт к изменению идентификаторов пользователей и групп. В настоящее время SSSD не поддерживает изменение идентификаторов, поэтому базу данных SSSD необходимо удалить. Так как кэшированные пароли также хранятся в в этой базе данных, её удаление должно выполняться только тогда, когда серверы проверки подлинности доступны; в ином случае пользователи могут быть заблокированы. Для кэширования пароля необходимо выполнить проверку подлинности. Для удаления базы данных недостаточно использовать sss_cache(8), на самом деле требуются следующие шаги:
Более того, поскольку смена идентификаторов может сделать необходимым изменение других свойств системы, таких как параметры владения файлами и каталогами, рекомендуется спланировать всё заранее и тщательно протестировать конфигурацию сопоставления идентификаторов.
Алгоритм сопоставления¶
Active Directory предоставляет objectSID для всех объектов пользователей и групп в каталоге. Этот objectSID можно разбить на компоненты, которые соответствуют идентификатору домена Active Directory и относительному идентификатору (RID) объекта пользователя или группы.
Алгоритм сопоставления идентификаторов SSSD берёт диапазон доступных UID и делит его на разделы равного размера — «срезы». Каждый срез представляет собой пространство, доступное домену Active Directory.
Когда запись пользователя или группы определённого домена встречается SSSD в первый раз, SSSD выделяет один из доступных срезов для этого домена. Чтобы такое назначение срезов воспроизводилось на разных клиентских компьютерах, предусмотрен следующий алгоритм выбора среза:
Строка SID передаётся через алгоритм murmurhash3 для её преобразования в 32-битное хэшированное значение. Затем для выбора среза это значение с общим количеством срезов берётся по модулю.
ПРИМЕЧАНИЕ: между хэшем и полученным далее модулем возможны конфликты. В таких случаях будет выбран следующий доступный срез, но на других компьютерах может быть невозможно воспроизвести точно такой же набор срезов (так как порядок, в котором они встречаются, определяет срез). В такой ситуации рекомендуется либо переключиться на использование явных атрибутов POSIX в Active Directory (отключить сопоставление идентификаторов), либо настроить стандартный домен, чтобы гарантировать согласованность хотя бы для одного. См. “Конфигурация”.
Конфигурация¶
Минимальная конфигурация (в разделе “[domain/DOMAINNAME]”):
ldap_id_mapping = True ldap_schema = ad
При стандартной конфигурации настраивается 10000 срезов, каждый из которых может содержать до 200000 идентификаторов, начиная от 200000 и до 2000200000. Этого должно быть достаточно для большинства вариантов развёртывания.
Дополнительная
конфигурация
ldap_idmap_range_min (целое число)
ПРИМЕЧАНИЕ: этот параметр отличается от “min_id”: “min_id” работает как фильтр ответов на запросы к этому домену, в то время как этот параметр управляет диапазоном назначения идентификаторов. Это тонкое различие, но рекомендуется устанавливать значение “min_id” меньшим или равным значению “ldap_idmap_range_min”
По умолчанию: 200000
ldap_idmap_range_max (целое число)
ПРИМЕЧАНИЕ: этот параметр отличается от “max_id”: “max_id” работает как фильтр ответов на запросы к этому домену, в то время как этот параметр управляет диапазоном назначения идентификаторов. Это тонкое различие, но рекомендуется устанавливать значение “max_id” большим или равным значению “ldap_idmap_range_max”
По умолчанию: 2000200000
ldap_idmap_range_size (целое число)
ПРИМЕЧАНИЕ: значение этого параметра должно быть не меньше значения максимального RID пользователя, запланированного для использования на сервере Active Directory. Поиск записи пользователя и вход завершатся неудачей для всех пользователей, RID которых превышает значение этого параметра.
Например, если у последнего добавленного пользователя Active Directory objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, значение“ldap_idmap_range_size” должно равняться минимум 1108, так как размер диапазона рассчитывается как максимальный SID минус минимальный SID плюс один (т.е. 1108 = 1107 - 0 + 1).
Для будущего расширения важно всё спланировать заранее,поскольку изменение этого значения приведёт к изменению всех сопоставлений идентификаторов в системе и, следовательно, изменению локальных идентификаторов пользователей.
По умолчанию: 200000
ldap_idmap_default_domain_sid (строка)
По умолчанию: не задано
ldap_idmap_default_domain (строка)
По умолчанию: не задано
ldap_idmap_autorid_compat (логическое значение)
When this option is configured, domains will be allocated starting with slice zero and increasing monotonically with each additional domain.
ПРИМЕЧАНИЕ: этот алгоритм является недетерминированным (он зависит от порядка, в котором запрашиваются пользователи и группы). Если этот режим требуется для обеспечения совместимости с компьютерами, где работает winbind, рекомендуется также использовать параметр “ldap_idmap_default_domain_sid”, чтобы гарантировать постоянное выделение хотя бы одного домена для нулевого среза.
По умолчанию: false
ldap_idmap_helper_table_size (целое число)
Примечание: дополнительные вторичные срезы могут быть созданы, когда выполняется сопоставление SID с идентификатором UNIX и часть RID SID находится за пределами диапазона для уже созданных вторичных срезов. Если значение параметра ldap_idmap_helper_table_size равно нулю, дополнительные вторичные срезы не будут созданы.
По умолчанию: 10
Известные SID¶
SSSD поддерживает поиск имён известных SID, то есть SID со специальным жёстко заданным значением. Так как типичные пользователи и группы, связанные с этими известными SID, не имеют аналогов в среде Linux/UNIX, для этих объектов недоступны идентификаторы POSIX.
Пространство имён SID организовано по центрам, которые можно рассматривать как разные домены. Для известных SID используются следующие центры
Записанные прописными буквами варианты этих имён используются в качестве имён доменов при возврате полных имён известных SID.
Так как некоторые утилиты позволяют изменять данные управления доступом на основе SID с помощью имени, а не непосредственного использования SID, SSSD также поддерживает поиск SID по имени. Чтобы избежать конфликтов, для поиска известных SID разрешается использовать только полные имена. Следовательно, нельзя использовать в качестве имён доменов в sssd.conf следующие названия: “NULL AUTHORITY”, “WORLD AUTHORITY”, “ LOCAL AUTHORITY”, “CREATOR AUTHORITY”, “MANDATORY LABEL AUTHORITY”, “AUTHENTICATION AUTHORITY”, “NT AUTHORITY” и “BUILTIN”.
ПРИМЕР¶
В следующем примере предполагается, что конфигурация SSSD корректна и что example.com — один из доменов в разделе [sssd]. В примере показаны только параметры, относящиеся к поставщику данных AD.
[domain/EXAMPLE] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ad_server = dc1.example.com ad_hostname = client.example.com ad_domain = example.com
ПРИМЕЧАНИЯ¶
Поставщик данных управления доступом AD проверяет, не истёк ли срок действия учётной записи. Работает так же, как и следующая конфигурация поставщика данных LDAP:
access_provider = ldap ldap_access_order = expire ldap_account_expire_policy = ad
Тем не менее, если поставщик данных управления доступом “ad” не настроен явным образом, поставщиком доступа по умолчанию является “permit”. Обратите внимание, что при настройке поставщика доступа, отличного “ad”, потребуется вручную указать все параметры подключения, такие как URI LDAP и параметры шифрования.
Когда поставщик данных autofs установлен в значение “ad”, используется схема сопоставления атрибутов RFC2307 (nisMap, nisObject, ...), так как эти атрибуты включены в стандартную схему Active Directory.
СМ. ТАКЖЕ¶
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
AUTHORS¶
Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/
NOTES¶
- 1.
- Группы безопасности Active Directory
- 2.
- в разделе технической спецификации Active Directory MS, посвящённом расширениям LDAP
05/24/2024 | SSSD |