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. Это необязательно. Если имя не указано, используется имя домена в конфигурации.

    Для корректной работы этот параметр следует указывать в формате записи полной версии имени домена Active Directory в нижнем регистре.

    Краткое имя домена (также называется именем NetBIOS или плоским именем) автоматически определяется SSSD.

ad_enabled_domains (строка)
    Разделённый запятыми список включённых доменов Active Directory. Если он предоставлен, SSSD будет игнорировать все домены, отсутствующие в этом списке. Если параметр не задан, будут доступны все обнаруженные домены из леса AD.

    Во время обнаружения доменов SSSD отфильтрует некоторые домены, флаги или атрибуты которых указывают на то, что они не принадлежат локальному лесу или не являются доверенными. Если установлено значение ad_enabled_domains, SSSD попытается включить все перечисленные домены.

    Для корректной работы этот параметр должен быть указан полностью в нижнем регистре и как полное доменное имя домена Active Directory. Например:

        ad_enabled_domains = sales.example.com, eng.example.com

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

    По умолчанию: не задано

ad_server, ad_backup_server (строка)
    Разделённый запятыми список имён узлов серверов AD, к которым SSSD следует подключаться в порядке приоритета. Дополнительные сведения об отработке отказа и избыточности сервера доступны в разделе “ОТРАБОТКА ОТКАЗА”.

    Этот параметр является необязательным, если включено автоматическое обнаружение служб. Дополнительные сведения об обнаружении служб доступны в разделе “ОБНАРУЖЕНИЕ СЛУЖБ”.

    Примечание: доверенные домены всегда автоматически обнаруживают серверы, даже если в параметре ad_server явно определён основной сервер.

ad_hostname (строка)
    Необязательный параметр. На компьютерах, где hostname(5) не содержит полное имя, sssd будет пытаться расширить краткое имя. Если это невозможно или если следует использовать именно краткое имя, необходимо явно указать этот параметр.

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

ad_enable_dns_sites (логическое значение)
    Включить сайты DNS — обнаружение служб по расположению.

    Если этот параметр установлен в значение «true» и включено обнаружение служб (смотрите абзац об обнаружении служб в нижней части справочной страницы), SSSD сначала попытается обнаружить сервер Active Directory, к которому следует подключиться, с помощью возможности обнаружения сайтов Active Directory, а затем, если сайт AD не удастся найти, будет использовать записи SRV DNS. Конфигурация SRV DNS, включая домен обнаружения, используется также и при обнаружении сайтов.

    По умолчанию: true

ad_access_filter (строка)
    Определяет фильтр контроля доступа LDAP, которому должен соответствовать пользователь для получения доступа. Чтобы этот параметр вступил в силу, для параметра “access_provider” должно быть явно установлено значение “ad”. Если вы хотите использовать “ad_access_filter” как единственную схему контроля доступа, необходимо отключить контроль доступа на основе GPO (дополнительные сведения доступны в описании параметра “ad_gpo_access_control”).

    Этот параметр также поддерживает указание разных фильтров для отдельных доменов или лесов. Такой расширенный фильтр имеет следующий формат: “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, к которому клиенту следует попытаться подключиться. Если этот параметр не указан, обнаружение сайта AD будет выполнено автоматически.

    По умолчанию: не задано

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

    Обратите внимание, что отключение глобального каталога не отключает получение данных пользователей из доверенных доменов. SSSD просто будет подключаться к порту LDAP доверенных доменов. Тем не менее, для разрешения данных о междоменном участии в группах необходимо использовать глобальный каталог.

    По умолчанию: true

ad_gpo_access_control (строка)
    Этот параметр позволяет указать режим работы функциональной возможности управления доступом на основе GPO: отключённый, принудительный или разрешительный. Обратите внимание, что для работы этого параметра необходимо явно установить параметр “access_provider” в значение “ad”.

    Функциональная возможность управления доступом на основе 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:

        • Read: пользователь или одна из его групп должна обладать правом чтения свойств GPO (RIGHT_DS_READ_PROPERTY)

        • Apply Group Policy: пользователю или хотя бы одной из его групп должно быть разрешено применять GPO (RIGHT_DS_CONTROL_ACCESS).

    По умолчанию в GPO присутствует группа Authenticated Users. Она обладает как правом доступа Read, так и правом доступа Apply Group Policy. Так как проверка подлинности пользователя должна успешно завершиться до того, как будет применён фильтр безопасности и начато управление доступом на основе GPO, этот пользователю всегда будет обладать правами группы Authenticated Users GPO.

    ПРИМЕЧАНИЕ: если в качестве режим работы выбран принудительный режим, возможно, что пользователям, которым был ранее разрешён доступ для входа, теперь будет отказано в доступе для входа (согласно параметрам политики GPO). Чтобы облегчить переход на новую систему, для администраторов предусмотрен разрешительный режим: правила управления доступом не применяются в принудительном порядке. Программа просто проверяет соответствие этим правилам и выводит в системный журнал сообщение в случае отказа в доступе. Просмотрев этот журнал, администраторы смогут внести необходимые изменения, а затем включить принудительный режим. Для ведения журнала управления доступом на основе GPO необходимо включить уровень отладки «трассировка функций» (см. справочную страницу sssctl(8)).

    Для этого параметра поддерживаются три значения:

        • disabled: не осуществляется ни проверка соответствия правилам управления доступом на основе GPO, ни их принудительное применение.

        • enforcing: осуществляется проверка соответствия правилам управления доступом на основе GPO и их принудительное применение.

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

    По умолчанию: enforcing

ad_gpo_implicit_deny (логическое значение)
    Обычно пользователям разрешается доступ, если применимые GPO не найдены. Когда этот параметр установлен в значение «True», пользователям будет разрешён доступ только в том случае, если это явно разрешено правилом GPO. В ином случае пользователям будет отказано в доступе. Это можно сделать для усиления защиты, но следует использовать этот параметр с осторожностью: возможен отказ в доступе даже тем пользователям, которые состоят во встроенной группе Administrators, если к ним не применяются правила GPO.

    По умолчанию: false

    В следующих двух таблицах показано, когда пользователю будет разрешён или запрещён доступ на основе прав разрешения или запрета входа, которые определены на стороне сервера, и установленного значения ad_gpo_implicit_deny.
    ad_gpo_implicit_deny = False (по умолчанию)
    правила разрешения | правила запрета | результат
    отсутствуют | отсутствуют | доступ разрешён всем пользователям
    отсутствуют | присутствуют | доступ разрешён только пользователям, отсутствующим в правилах запрета
    присутствуют | отсутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения
    присутствуют | присутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения и отсутствующим в правилах запрета

    ad_gpo_implicit_deny = True
    правила разрешения | правила запрета | результат
    отсутствуют | отсутствуют | доступ запрещён всем пользователям
    отсутствуют | присутствуют | доступ запрещён всем пользователям
    присутствуют | отсутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения
    присутствуют | присутствуют | доступ разрешён только пользователям, присутствующим в правилах разрешения и отсутствующим в правилах запрета

ad_gpo_ignore_unreadable (логическое значение)
    Обычно пользователям запрещён доступ, когда некоторые контейнеры групповой политики (объекта AD) соответствующих объектов групповой политики недоступны для чтения SSSD. Этот параметр позволяет игнорировать контейнеры групповой политики, а также связанные с ними политики, если их атрибуты в контейнерах групповой политики недоступны для чтения SSSD.

    По умолчанию: false

ad_gpo_cache_timeout (целое число)
    Временной интервал между сеансами поиска файлов политики GPO на сервере AD. Это сократит задержки и нагрузку на сервер AD, когда за короткое время поступает много запросов на управление доступом.

    По умолчанию: 5 (секунд)

ad_gpo_map_interactive (строка)
    Разделённый запятыми список имён служб PAM, для которых проверка соответствия правилам управления доступом на основе GPO осуществляется на основе параметров политики InteractiveLogonRight и DenyInteractiveLogonRight. Обрабатываются только те GPO, на доступ к которым у пользователя есть права Read и Apply Group Policy (смотрите описание параметра “ad_gpo_access_control”). Если обработанный GPO содержит параметр запрета интерактивного входа для пользователя или одной из его групп, пользователю будет отказано в локальном доступе. Если ни в одном из обработанных GPO нет определённого права интерактивного входа, пользователю будет разрешён локальный доступ. Если хотя бы один обработанный GPO содержит параметры права интерактивного входа, пользователю будет разрешён только локальный доступ, если он или хотя бы одна из его групп являются частью параметров политики.

    Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить локальный вход» («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 включает:

        • login

        • su

        • su-l

        • gdm-fingerprint

        • gdm-password

        • gdm-smartcard

        • kdm

        • lightdm

        • lxdm

        • sddm

        • unity

        • xdm

ad_gpo_map_remote_interactive (строка)
    Разделённый запятыми список имён служб PAM, для которых проверка соответствия правилам управления доступом на основе GPO осуществляется на основе параметров политики RemoteInteractiveLogonRight и DenyRemoteInteractiveLogonRight. Обрабатываются только те GPO, на доступ к которым у пользователя есть права Read и Apply Group Policy (смотрите описание параметра “ad_gpo_access_control”). Если обработанный GPO содержит параметр запрета удалённого входа для пользователя или одной из его групп, пользователю будет отказано в удалённом интерактивном доступе. Если ни в одном из обработанных GPO нет определённого права удалённого интерактивного входа, пользователю будет разрешён удалённый доступ. Если хотя бы один обработанный GPO содержит параметры права удалённого интерактивного входа, пользователю будет разрешён только удалённый доступ, если он или хотя бы одна из его групп являются частью параметров политики.

    Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход через службы удалённых рабочих столов» («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 включает:

        • sshd

        • cockpit

ad_gpo_map_network (строка)
    Разделённый запятыми список имён служб PAM, для которых проверка соответствия правилам управления доступом на основе GPO осуществляется на основе параметров политики NetworkLogonRight и DenyNetworkLogonRight. Обрабатываются только те GPO, на доступ к которым у пользователя есть права Read и Apply Group Policy (смотрите описание параметра “ad_gpo_access_control”). Если обработанный GPO содержит параметр запрета входа в сеть для пользователя или одной из его групп, пользователю будет отказано в доступе для входа в сеть. Если ни в одном из обработанных GPO нет определённого права входа в сеть, пользователю будет разрешён доступ для входа. Если хотя бы один обработанный GPO содержит параметры права входа в сеть, пользователю будет разрешён только доступ для входа, если он или хотя бы одна из его групп являются частью параметров политики.

    Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить доступ к компьютеру из сети» («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 включает:

        • ftp

        • samba

ad_gpo_map_batch (строка)
    Разделённый запятыми список имён служб PAM, для которых проверка соответствия правилам управления доступом на основе GPO осуществляется на основе параметров политики BatchLogonRight и DenyBatchLogonRight. Обрабатываются только те GPO, на доступ к которым у пользователя есть права Read и Apply Group Policy (смотрите описание параметра “ad_gpo_access_control”). Если обработанный GPO содержит параметр запрета пакетного входа для пользователя или одной из его групп, пользователю будет отказано в доступе для пакетного входа. Если ни в одном из обработанных GPO нет определённого права пакетного входа, пользователю будет разрешён доступ для входа. Если хотя бы один обработанный GPO содержит параметры права пакетного входа, пользователю будет разрешён только доступ для входа, если он или хотя бы одна из его групп являются частью параметров политики.

    Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход в качестве пакетного задания» («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 включает:

        • crond

ad_gpo_map_service (строка)
    Разделённый запятыми список имён служб PAM, для которых проверка соответствия правилам управления доступом на основе GPO осуществляется на основе параметров политики ServiceLogonRight и DenyServiceLogonRight. Обрабатываются только те GPO, на доступ к которым у пользователя есть права Read и Apply Group Policy (смотрите описание параметра “ad_gpo_access_control”). Если обработанный GPO содержит параметр запрета входа службы для пользователя или одной из его групп, пользователю будет отказано в доступе для входа службы. Если ни в одном из обработанных GPO нет определённого права входа службы, пользователю будет разрешён доступ для входа. Если хотя бы один обработанный GPO содержит параметры права входа службы, пользователю будет разрешён только доступ для входа, если он или хотя бы одна из его групп являются частью параметров политики.

    Примечание: в редакторе управления групповыми политиками это значение называется «Разрешить вход в качестве службы» («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, которым всегда предоставляется доступ на основе GPO, независимо от прав входа GPO.

    Можно добавить имя ещё одной службы PAM в стандартный набор с помощью “+service_name”. Также можно явно удалить имя службы PAM из стандартного набора с помощью “-service_name”. Например, чтобы заменить стандартное имя службы PAM для безусловно разрешённого доступа (например, “sudo”) на пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:

        ad_gpo_map_permit = +my_pam_service, -sudo

    По умолчанию: стандартный набор имён служб PAM включает:

        • polkit-1

        • sudo

        • sudo-i

        • systemd-user

ad_gpo_map_deny (строка)
    Разделённый запятыми список имён служб PAM, которым всегда запрещается доступ на основе GPO, независимо от прав входа GPO.

    Можно добавить имя службы PAM в стандартный набор с помощью “+service_name”. Так как стандартный набор является пустым, из него невозможно удалить имя службы PAM. Например, чтобы добавить пользовательское имя службы PAM (например, “my_pam_service”), необходимо использовать следующую конфигурацию:

        ad_gpo_map_deny = +my_pam_service

    По умолчанию: не задано

ad_gpo_default_right (строка)
    Этот параметр определяет, как обрабатываются правила управления доступом для имён служб PAM, которые явно не указаны в одном из параметров ad_gpo_map_*. Этот параметр можно установить двумя разными способами. Первый: с помощью этого параметра можно задать использование стандартного права входа. Например, установка этого параметра в значение «interactive» означает, что несопоставленные имена служб PAM будут обрабатываться на основе параметров политики InteractiveLogonRight и DenyInteractiveLogonRight. Второй: с помощью этого параметра можно указать всегда разрешать или всегда запрещать доступ для несопоставленных имён служб PAM.

    Для этого параметра поддерживаются следующие значения:

        • interactive

        • remote_interactive

        • network

        • batch

        • service

        • permit

        • deny

    По умолчанию: deny

ad_maximum_machine_account_password_age (целое число)
    SSSD будет раз в день проверять, не превышен ли указанный возраст (в днях) пароля учётной записи компьютера, и в случае превышения попытается обновить его. Значение «0» отключает попытку обновления.

    По умолчанию: 30 дней

ad_machine_account_password_renewal_opts (строка)
    Этот параметр следует использовать только для тестирования задания по обновлению пароля учётной записи компьютера. Параметр ожидает 3 целых числа и строку, разделённых двоеточием («:»). Первое целое число определяет интервал (в секундах) между последовательными запусками задания. Второе целое число указывает начальный тайм-аут (в секундах) перед первым запуском задания после перезапуска. Необязательное третье число указывает максимальное случайное смещение к первым двум значениям, чтобы избежать одновременного обновления большого количества узлов (проблема «громового стада»). Если это значение отсутствует или пустое, будет использоваться значение «0».

    Необязательное четвёртое строковое значение указывает вспомогательную утилиту, которая должна использоваться для обновления. В настоящее время поддерживаются adcli и realm. Если это значение отсутствует или пустое, будет использоваться realm. Поскольку вспомогательная утилита запускается от имени пользователя, под которым работает SSSD, существует вероятность, что обновление завершится неудачей, если у этого пользователя нет прав на изменение файла keytab, в котором хранятся учётные данные учётной записи машины. Обычно это относится adcli.

    realm не обновляет keytab напрямую, а вызывает процесс realmd, который для этой задачи запускается от имени пользователя root . realmd может разрешить доступ непривилегированным пользователям с помощью PolicyKit, по умолчанию SSSD предоставляет подходящие правила для пользователя, от имени которого работает SSSD.

    По умолчанию: 86400:750:300:realm (24 часа, 12 минут 30 секунд и 5 минут)

ad_update_samba_machine_account_password (логическое значение)
    Если этот параметр включён, когда SSSD обновляет пароль учётной записи компьютера, он обновляется также в базе данных Samba. Это позволяет предотвратить устаревание копии пароля учётной записи компьютера в Samba, когда программа настроена на использование AD для проверки подлинности.

    По умолчанию: false

ad_use_ldaps (логическое значение)
    По умолчанию SSSD использует простой порт LDAP 389 и порт глобального каталога 3628. Если этот параметр установлен в значение «True», SSSD будет использовать порт LDAPS 636 и порт глобального каталога 3629 с защитой LDAPS. Так как AD не разрешает использование нескольких слоёв шифрования для одного подключения и всё ещё требуется использовать SASL/GSSAPI или SASL/GSS-SPNEGO для проверки подлинности, свойство безопасности SASL maxssf для таких подключений будет установлено в значение «0» (ноль).

    По умолчанию: false

dyndns_update (логическое значение)
    Необязательный параметр. Этот параметр указывает SSSD автоматически обновлять на сервере DNS Active Directory IP-адрес клиента. Защита обновления обеспечивается с помощью GSS-TSIG. Соответственно, администратору Active Directory требуется только разрешить защищённые обновления для зоны DNS. Для обновления будет использован IP-адрес LDAP-соединения AD, если с помощью параметра “dyndns_iface” не указано иное.

    ПРИМЕЧАНИЕ: на устаревших системах (например, RHEL 5) для корректной работы в этом режиме необходимо надлежащим образом задать стандартную область Kerberos в /etc/krb5.conf

    По умолчанию: true

dyndns_ttl (целое число)
    Значение TTL, которое применяется при обновлении записи DNS клиента. Если параметр dyndns_update установлен в значение «false», этот параметр ни на что не влияет. Если администратором установлено значение TTL на стороне сервера, оно будет переопределено этим параметром.

    По умолчанию: 3600 (секунд)

dyndns_iface (строка)
    Optional. Applicable only when dyndns_update is true. Choose the interface or a list of interfaces whose IP addresses should be used for dynamic DNS updates. The name of interface can be a wildcard pattern prefixed with ! for interface excluding. First match stops the evaluation. For example list !eth1, * instruct SSSD to use all interfaces except eth1. See man 7 glob for details about patterns.

    ПРИМЕЧАНИЕ: прежнее имя параметра, ipa_dyndns_iface, всё ещё можно использовать, но пользователям рекомендуется перейти на использование нового имени, dyndns_iface, в файле конфигурации.

    По умолчанию: использовать IP-адреса интерфейса, который используется для подключения LDAP AD

    Example: dyndns_iface = em[12], !vnet1, vnet*

dyndns_address (string)
    Optional. Applicable only when dyndns_update is true. A list of IP addresses or IP networks to be used for dynamic DNS updates. Network addresses must be in CIDR format. An entry can be prefixed with ! to indicate exclusion. The best match is used to determine whether an address is included or excluded (i.e., a longer prefix takes precedence).

    Default: No filtering of IP addresses.

    Example: dyndns_address = 10.0.0.0/16, !10.0.1.0/24

dyndns_refresh_interval (целое число)
    Как часто внутреннему серверу следует выполнять периодическое обновление DNS в дополнение к автоматическому обновлению, которое выполняется при переходе внутреннего сервера в сетевой режим. Этот параметр является необязательным и применяется только тогда, когда параметр dyndns_update установлен в значение «true». Обратите внимание, что наименьшее допустимое значение составляет 60 секунд: если будет указано меньшее значение, параметр примет наименьшее допустимое значение (60 секунд).

    По умолчанию: 86400 (24 часа)

dyndns_update_ptr (логическое значение)
    Следует ли также явно обновлять запись PTR при обновлении записей DNS клиента. Применимо только тогда, когда параметр dyndns_update установлен в значение «true».

    Обратите внимание, что параметр dyndns_update_per_family не применяется для обновлений записей PTR. Эти обновления всегда отправляются отдельно.

    По умолчанию: true

dyndns_force_tcp (логическое значение)
    Должна ли утилита nsupdate по умолчанию использовать TCP для обмена данными с сервером DNS.

    По умолчанию: false (разрешить nsupdate выбрать протокол)

dyndns_auth (строка)
    Следует ли утилите nsupdate использовать проверку подлинности GSS-TSIG для защищённых обновлений сервера DNS. Незащищённые отправления можно отправлять, установив этот параметр в значение «none».

    По умолчанию: GSS-TSIG

dyndns_auth_ptr (строка)
    Следует ли утилите nsupdate использовать проверку подлинности GSS-TSIG для защищённых обновлений PTR сервера DNS. Незащищённые отправления можно отправлять, установив этот параметр в значение «none».

    По умолчанию: то же, что и dyndns_auth

dyndns_server (строка)
    Сервер DNS, который следует использовать для выполнения обновления DNS. В большинстве конфигураций рекомендуется не устанавливать значение для этого параметра.

    Установка этого параметра имеет смысл для сред, в которых сервер DNS отличается от сервера данных идентификации или если мы используем зашифрованный DNS.

    Параметр может быть простой строкой, содержащей DNS-имя или IP-адрес. Это также может быть URI. URI может выглядеть как dns://servername/ или dns+tls://1.2.3.4:853#servername/.

    Второй пример включает протокол DNS-over-TLS для обновлений DNS. Утилита nsupdate должна поддерживать DoT — проверьте man nsupdate перед её включением в SSSD.

    Обратите внимание, что этот параметр используется только для резервной попытки, которая выполняется тогда, когда предыдущая попытка с использованием автоматически определённых параметров завершилась неудачей или когда включен DNS-over-TLS.

    По умолчанию: none (разрешить nsupdate выбрать сервер)

dyndns_update_per_family (логическое значение)
    По умолчанию обновление DNS выполняется за два шага: обновление IPv4, а затем обновление IPv4. В некоторых случаях может быть желательно выполнить обновление IPv4 и IPv6 за один шаг.

    По умолчанию: true

dyndns_dot_cacert (строка)
    Этот параметр указывает файл сертификатов удостоверяющих центров (в формате PEM) для проверки TLS-сертификата удаленного сервера при использовании DoT.

    По умолчанию: none (использовать глобальное хранилище сертификатов)

dyndns_dot_cert (строка)
    Эта опция задаёт файл сертификата(ов) для аутентификации при использовании транспорта DoT с удалённым сервером. Ожидается, что файл цепочки сертификатов будет в формате PEM.

    Для достижения взаимной аутентификации TLS необходимо установить оба параметра dyndns_dot_cert и dyndns_dot_key.

    По умолчанию: none (не использовать TLS-аутентификацию)

dyndns_dot_key (строка)
    Этот параметр устанавливает файл ключа для аутентифицированного шифрования при использовании транспорта DoT с удалённым сервером. Ожидается, что файл закрытого ключа будет в формате PEM.

    По умолчанию: none (не использовать TLS-аутентификацию)

override_homedir (строка)
    Переопределить домашний каталог пользователя. Можно указать либо абсолютное значение, либо шаблон. В шаблоне заменяются следующие последовательности:

    %u
        имя для входа

    %U
        номер UID

    %d
        имя домена

    %f
        полное имя пользователя (user@domain)

    %l
        Первая буква имени для входа.

    %P
        UPN — имя участника-пользователя (name@REALM)

    %o
        Значение homedir, определенное в каталоге поставщика данных идентификации.

        Эта подстановка предназначена для использования в сценарии доверия между IPA и AD. Если эта подстановка используется в параметре subdomain_homedir, значение домашнего каталога из домена AD передаётся клиентам IPA. В этом сценарии параметр должен быть задан в конфигурации SSSD на сервере IPA, где SSSD работает в серверном режиме.

    %h
        Путь, определенный для атрибута каталога homedir поставщика данных идентификации, но в нижнем регистре. Подробнее см. в %o.

    %H
        Значение параметра конфигурации homedir_substring.

    %%
        литерал «%»

    Этот параметр также можно задать для каждого домена отдельно.

    пример:

        override_homedir = /home/%u

    По умолчанию: не задано (SSSD будет использовать значение, полученное от LDAP)

    Обратите внимание, что домашний каталог из конкретного переопределения для пользователя, локально (см. sss_override(8)) или централизованно управляемых переопределений идентификаторов IPA, обладает более высоким приоритетом и будет использоваться вместо значения, указанного с помощью override_homedir.

homedir_substring (строка)
    Значение этого параметра будет использоваться в расширении параметра override_homedir, если шаблон содержит строку формата %H. Запись каталога LDAP может непосредственно содержать этот шаблон, поэтому этот параметр можно использовать для расширения пути домашнего каталога для каждого клиентского компьютера (или операционной системы). Его можно задать для отдельного домена или глобально в разделе [nss]. Значение, указанное в разделе домена, переопределит то значение, которое задано в разделе [nss].

    По умолчанию: /home

krb5_confd_path (строка)
    Абсолютный путь к каталогу, в котором SSSD следует размещать фрагменты конфигурации Kerberos.

    Чтобы отключить создание фрагментов конфигурации, установите этот параметр в значение «none».

    По умолчанию: не задано (подкаталог krb5.include.d каталога pubconf SSSD)

ИЗМЕНЁННЫЕ СТАНДАРТНЫЕ ПАРАМЕТРЫ

Некоторые стандартные значения параметров не соответствуют стандартным значениям параметров соответствующего внутреннего поставщика данных. Имена этих параметров и специфичные для поставщика данных AD стандартные значения параметров перечислены ниже:

  Поставщик данных KRB5

    • krb5_validate = true

    • krb5_use_enterprise_principal = true

  Поставщик данных LDAP

    • ldap_schema = ad

    • ldap_force_upper_case_realm = true

    • ldap_id_mapping = true

    • ldap_sasl_mech = GSS-SPNEGO

    • ldap_referrals = false

    • ldap_account_expire_policy = ad

    • ldap_use_tokengroups = true

    • ldap_sasl_authid = sAMAccountName@REALM (обычно SHORTNAME$@REALM)

    Поставщик данных AD по умолчанию выполняет поиск других записей участников, чем поставщик LDAP, потому что в окружении Active Directory участники делятся на две группы: участники-пользователи и участники-службы. Для получения TGT может использоваться только запись участника-пользователя, и по умолчанию записи участников — объектов компьютеров создаются из их sAMAccountName и области AD. Известный участник host/hostname@REALM является участником-службой и, следовательно, не может использоваться для получения TGT.

  Настройка NSS

    • fallback_homedir = /home/%d/%u

    Поставщик данных 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
    Время (в миллисекундах), в течение которого SSSD будет обращаться к одному серверу DNS перед переходом к следующему.

    По умолчанию: 1000

dns_resolver_op_timeout
    Время (в секундах), в течение которого SSSD будет пытаться разрешить один запрос DNS (например, разрешение имени узла или записи SRV) перед переходом к следующему имени узла или домену обнаружения.

    По умолчанию: 3

dns_resolver_timeout
    Как долго SSSD будет пытаться разрешить резервную службу. Это разрешение службы может включать несколько внутренних шагов, например, при разрешении запросов SRV DNS или определении расположения сайта.

    По умолчанию: 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), на самом деле требуются следующие шаги:

    • Проверка доступности удалённых серверов

    • Остановка службы SSSD

    • Удаление базы данных

    • Запуск службы SSSD

Более того, поскольку смена идентификаторов может сделать необходимым изменение других свойств системы, таких как параметры владения файлами и каталогами, рекомендуется спланировать всё заранее и тщательно протестировать конфигурацию сопоставления идентификаторов.

  Алгоритм сопоставления

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 (целое число)
        Указывает нижнюю (включительно) границу диапазона идентификаторов POSIX, которые следует использовать для сопоставления SID пользователей и групп Active Directory. Это первый идентификатор POSIX, который можно использовать для сопоставления.

        ПРИМЕЧАНИЕ: этот параметр отличается от “min_id”: “min_id” работает как фильтр ответов на запросы к этому домену, в то время как этот параметр управляет диапазоном назначения идентификаторов. Это тонкое различие, но рекомендуется устанавливать значение “min_id” меньшим или равным значению “ldap_idmap_range_min”

        По умолчанию: 200000

    ldap_idmap_range_max (целое число)
        Указывает верхнюю (не включительно) границу диапазона идентификаторов POSIX, которые следует использовать для сопоставления идентификаторов SID пользователей и групп Active Directory. Это первый идентификатор POSIX, который нельзя использовать для сопоставления, т.е. данный идентификатор на единицу больше последнего, которым можно воспользоваться для сопоставления.

        ПРИМЕЧАНИЕ: этот параметр отличается от “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, так как размер диапазона рассчитывается как максимальный RID минус минимальный RID плюс один (т.е. 1108 = 1107 - 0 + 1).

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

        По умолчанию: 200000

    ldap_idmap_default_domain_sid (строка)
        Позволяет указать SID стандартного домена. Это гарантирует, что этот домен всегда будет назначаться нулевому срезу в карте идентификаторов, в обход описанного выше алгоритма murmurhash.

        По умолчанию: не задано

    ldap_idmap_default_domain (строка)
        Позволяет указать имена домена по умолчанию.

        По умолчанию: не задано

    ldap_idmap_autorid_compat (логическое значение)
        Изменяет поведения алгоритма сопоставления идентификаторов, делая его более похожим на алгоритм “idmap_autorid” winbind.

        Когда настроен этот параметр, домены будут выделяться, начиная с нулевого среза, с постепенным увеличением для каждого дополнительного домена.

        ПРИМЕЧАНИЕ: этот алгоритм является недетерминированным (он зависит от порядка, в котором запрашиваются пользователи и группы). Если этот режим требуется для обеспечения совместимости с компьютерами, где работает winbind, рекомендуется также использовать параметр “ldap_idmap_default_domain_sid”, чтобы гарантировать постоянное выделение хотя бы одного домена для нулевого среза.

        По умолчанию: false

    ldap_idmap_helper_table_size (целое число)
        Максимальное количество вторичных срезов, которое можно использовать при сопоставлении идентификатору UNIX номера SID.

        Примечание: дополнительные вторичные срезы могут быть созданы, когда выполняется сопоставление SID с идентификатором UNIX и часть RID SID находится за пределами диапазона для уже созданных вторичных срезов. Если значение параметра ldap_idmap_helper_table_size равно нулю, дополнительные вторичные срезы не будут созданы.

        По умолчанию: 10

  Известные SID

SSSD поддерживает поиск имён известных SID, то есть SID со специальным жёстко заданным значением. Так как типичные пользователи и группы, связанные с этими известными SID, не имеют аналогов в среде Linux/UNIX, для этих объектов недоступны идентификаторы POSIX.

Пространство имён SID организовано по центрам, которые можно рассматривать как разные домены. Для известных SID используются следующие центры

    • Null Authority

    • World Authority

    • Local Authority

    • Creator Authority

    • Mandatory Label Authority

    • Authentication Authority

    • NT Authority

    • Built-in

Записанные прописными буквами варианты этих имён используются в качестве имён доменов при возврате полных имён известных SID.

Так как некоторые утилиты позволяют изменять данные управления доступом на основе SID с помощью имени, а не непосредственного использования SID, SSSD также поддерживает поиск SID по имени. Чтобы избежать конфликтов, для поиска известных (Well-Known) SID разрешается использовать только полные имена. Следовательно, нельзя использовать следующие названия: “NULL AUTHORITY”, “WORLD AUTHORITY”, “ LOCAL AUTHORITY”, “CREATOR AUTHORITY”, “MANDATORY LABEL AUTHORITY”, “AUTHENTICATION AUTHORITY”, “NT AUTHORITY” и “BUILTIN” в качестве имён доменов в sssd.conf.

ПРИМЕР

В следующем примере предполагается, что конфигурация 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-idp(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(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

AUTHORS

Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/

NOTES

1.  Группы безопасности Active Directory
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups

2.  в разделе технической спецификации Active Directory MS, посвящённом расширениям LDAP
    https://msdn.microsoft.com/en-us/library/cc223367.aspx