LDAP

[править на GitHub]

Авторизация с помощью существующих систем управления идентификацией

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

Chef Automate поддерживает использование как локальных пользователей, так и пользователей, управляемых внешним поставщиком идентификации (IdP). Можно использовать одну службу LDAP (или MSAD для упрощенной конфигурации установок Active Directory) и одного поставщика SAML IdP. Вам не нужно настраивать внешний IdP, если вы просто хотите создать пользователей и команды, локальных для Chef Automate. См. документацию Пользователи для получения дополнительной информации.

Chef Automate использует Dex для поддержки интеграций LDAP. Для настройки аутентификации для вашей установки Chef Automate создайте файл TOML, содержащий частичную конфигурацию LDAP. Затем выполните chef-automate config patch </path/to/your-file.toml> для развертывания изменений.

Переключение между конфигурацией Microsoft AD и общей конфигурацией LDAP не повлияет на ваши политики, поскольку обе являются конфигурациями LDAP. Однако переключение между любой из этих конфигураций и конфигурацией SAML потребует корректировки членства в политике IAM.

Поддерживаемые системы управления идентификацией

• Azure Active Directory
• Microsoft Active Directory (MSAD)

Обзор

В данном документе описывается настройка интеграций Chef Automate с протоколом Lightweight Directory Access Protocol (LDAP) и Microsoft Active Directory (MSAD). LDAP — это устоявшийся и открытый стандартный протокол для взаимодействия с серверами каталогов. Сервер каталогов хранит информацию — в данном случае информацию для аутентификации и авторизации пользователей — в иерархии записей. (Это не реляционная база данных.)

Microsoft Active Directory

Microsoft Active Directory (MSAD) — это тип сервера каталогов, поддерживающий LDAP. Chef Automate поставляется с конфигурацией LDAP по умолчанию для MSAD. Конфигурация MSAD по умолчанию в Chef Automate — это минимальная конфигурация для стандартных систем MSAD, которую можно расширить, переопределяя значения по умолчанию и используя дополнительные параметры конфигурации. Конфигурация Chef Automate по умолчанию для Microsoft AD специфична для LDAP. Для настройки Microsoft AD с использованием SAML см. документацию SAML.

Изменение конфигурации Chef Automate

Если вам нужно изменить настройки внешнего поставщика идентификации, выполните следующие действия:

1. Выполните chef-automate config show config.toml.
2. Отредактируйте config.toml, чтобы заменить раздел dex.sys.connectors значениями конфигурации для нового поставщика идентификации.
3. Выполните chef-automate config set config.toml для установки обновленной конфигурации.

Минимальная конфигурация MSAD

base_user_search_dn

“ваш базовый DN для поиска пользователей”

base_group_search_dn

“ваш базовый DN для поиска групп”

bind_dn

“ваш bind_dn”

bind_password

“ваш bind_password”

ca_contents

Содержание сертификата вашей доверенной третьей стороны (CA). Вы можете указать несколько сертификатов CA в формате PEM. Необязательно.

# Example ca_contents setting:
ca_contents = """-----BEGIN CERTIFICATE-----
MIICsDCCAhmgAwIBAgIJAJxMopMJbhPkMA0GCSqGSIb
...
X0uRzUPlpTtd5tYFs43nKqxJT6s=
-----END CERTIFICATE-----"""

host

Имя домена вашего сервера каталогов, например "ldap.corp.com". Порт по умолчанию: 636. Переопределите порт, добавив его к параметру хоста, например, "ldap.corp.com:10636"

Минимальная конфигурация MSAD config.toml

[dex.v1.sys.connectors.msad_ldap]
host = "<your host>"
bind_dn = "<your bind_dn>"
bind_password = "<your bind_password>"
base_user_search_dn = "<your base user search DN>"
base_group_search_dn = "<your base group search DN>"
ca_contents = "<your ca contents>" # optional, but recommended

Полная конфигурация MSAD

Конфигурация MSAD — это конфигурация LDAP с дополнительными значениями по умолчанию, которые часто подходят для Active Directory. Переопределите любое значение по умолчанию, раскомментировав его в конфигурации и установив его значение:

...

...

Пример полной конфигурации MSAD config.toml

[dex.v1.sys.connectors.msad_ldap]
host = "<your host>"
bind_dn = "<your bind_dn>"
bind_password = "<your bind_password>"
base_user_search_dn = "<your base user search DN>"
base_group_search_dn = "<your base group search DN>"
ca_contents = "<your ca contents>" # optional

# MSAD default values (uncomment to override a specific one)
# insecure_no_ssl = false
# user_query_filter = "(objectClass=person)"
# user_id_attr = "sAMAccountName"
# username_attr = "sAMAccountName"
# email_attr = "mail"
# user_display_name_attr = "displayName"
# group_query_filter = "(objectClass=group)"
# filter_groups_by_user_value = "DN"
# filter_groups_by_user_attr = "member"
# group_display_name_attr = "displayName"

Расширенные настройки LDAP

Для тех, кто не использует Microsoft AD или требует большего контроля над конфигурацией, Chef Automate предоставляет следующие настраиваемые параметры конфигурации LDAP:

...

insecure_no_ssl :true или false

...

Пример расширенной конфигурации LDAP config.toml

[dex.v1.sys.connectors.ldap]
# authentication options
ca_contents = "<your ca contents>"
host = "<your host>"
bind_dn = "<your bind_dn>"
bind_password = "<your bind_password>"
insecure_no_ssl = true or false

# ldapsearch options
base_user_search_dn = "<your base user search DN>"
user_query_filter = "<your user query filter>"
username_attr = "<your username attribute>"
user_id_attr = "<your userid attribute>"
email_attr = "<your email attribute>"
user_display_name_attr = "<your user display name attribute>"
base_group_search_dn = "<your base group search DN>"
group_query_filter = "<your group query filter>"
filter_groups_by_user_attr = "<groups to filter by user attribute>"
filter_groups_by_user_value = "<groups to filter by user value>"
group_display_name_attr = "<group display name attribute>"

Дополнительную информацию о параметрах конфигурации см. в разделе LDAP. Для объявления параметров конфигурации доступен весь функционал TOML.

Однако, если вы хотите интегрироваться с сервером LDAP с отключенным TLS:

insecure_no_ssl = true

Вход с использованием LDAP

После ввода имени пользователя и пароля на экране входа Chef Automate выполняет ряд операций для завершения входа:

1. Подключение
2. Связывание
3. Поиск пользователя
4. Связывание для входа
5. Поиск группы

Авторизация с помощью LDAP

Chef Automate поддерживает определение разрешений для пользователей LDAP и их групп. См. Члены и политики IAM.

Подключение

Сначала Chef Automate необходимо установить TCP-соединение с вашей службой LDAP, защищенное TLS. Оно будет подключено к хосту, настроенному в вашей конфигурации TOML, например:

host = "ldap.corp.com"

По умолчанию Automate использует порт 636. Чтобы переопределить порт, добавьте его к параметру хоста, например:

host = "ldap.corp.com:10636"

Проверка подлинности TLS-сертификата сервера зависит от настройки TLS: если вы предоставляете сертификат(ы) доверенной третьей стороны (CA), Chef Automate будет взаимодействовать с LDAP-службой только в том случае, если предоставленный хостом сертификат может быть проверен с помощью сертификата(ов) CA.

Однако, если вы хотите интегрироваться с сервером LDAP с отключенным TLS:

insecure_no_ssl = true

См. Устранение неполадок подключения для распространенных проблем, связанных с этапом Подключения.

Связывание

Затем Chef Automate выполняет аутентификацию со службой LDAP (или «связывается» с ней) с использованием учетных данных для связывания. В вашем файле конфигурации TOML они будут (например):

bind_dn = "cn=service_account,dc=corp,dc=com"
bind_password = "i<3ldap"

Если ваш LDAP-сервер поддерживает анонимное связывание, и вы хотите использовать его, снимите флажки bind DN и пароля:

bind_dn = ""
bind_password = ""

Оберните специальные символы в bind_password в тройные одинарные кавычки.

bind_password = '''$p3c"i'@l ! %#'''

См. Устранение неполадок связывания для распространенных проблем, связанных с Связыванием.

Поиск пользователя

После успешного связывания Chef Automate попытается получить имя каталога пользователя, пытающегося войти в систему.

Для этого он будет искать, используя настроенный базовый base_user_search_dn, запись, в которой username_attr равно имени пользователя, пытающегося войти в систему.

Если настроено, он получит дополнительные атрибуты, используя настроенные имена (user_id_attr, email_attr и user_display_name_attr). См. Конфигурация: LDAP для обзора.

ldapsearch -h $host -D $bind_dn -w $bind_password \
  -s sub \
  -b $base_user_search_dn \
  "($username_attr=$username)" \
  $user_id_attr $user_display_name_attr $email_attr

См. Устранение неполадок поиска пользователя для распространенных проблем, связанных с Поиском пользователя.

Фильтрация пользователей, которые могут войти

Вы можете дополнительно ограничить поиск пользователей, предоставив допустимый фильтр LDAP для user_query_filter. Например,

user_query_filter = "(objectClass=person)"

который будет конкатенирован с фильтром поиска, сконструированным из предоставленного имени пользователя на экране входа в систему. Содержимое user_query_filter расширяется до (&<user_query_filter_value>), так что вы можете передавать несколько фильтров.

Например, если вы хотите разрешить вход в Chef Automate только пользователям, являющимся членами определенной группы Active Directory, вы можете определить user_query_filter с несколькими фильтрами, например:

user_query_filter = "(objectClass=person)(memberof=CN=YourGroupToFilterOn,OU=Users,DC=YourDomain,DC=com)"

Этот фильтр означает «разрешить вход только тем пользователям, которые являются членами группы YourGroupToFilterOn в Chef Automate». Когда пользователь пытается войти в систему, он будет авторизован только в том случае, если он будет найден после применения фильтра:

(&(objectClass=person)(memberof=CN=YourGroupToFilterOn,OU=Users,DC=YourDomain,DC=com))

ldapsearch -h $host -D $bind_dn -w $bind_password \
  -s sub \
  -b $base_user_search_dn \
  "(&$user_query_filter($username_attr=$username))"

См. ldapsearch Примеры запросов для примера использования ldapsearch и различных схем каталогов.

Вход с привязкой

После успешного поиска записи пользователя в каталоге LDAP-соединитель попытается выполнить привязку как запись пользователя, используя предоставленный пароль.

Например, если вход с использованием jane:janespassword привел к успешному поиску пользователя, вернувшему cn=jane,ou=People,dc=corp,dc=com, следующим шагом будет повторная привязка с использованием этого DN и пароля janespassword.

ldapsearch -h $host -D $user_dn -w $password

ldap_bind: Invalid credentials (49)
        additional info: INVALID_CREDENTIALS: Bind failed: Cannot authenticate user uid=test2,ou=users,ou=system

См. Устранение неполадок входа с привязкой для распространенных проблем, связанных с входом_с_привязкой.

Поиск групп

Наконец, после аутентификации пользователя его внутренняя запись обогащается группами, предоставляемыми LDAP. Это происходит путем выполнения другого поиска с использованием того же DN привязки и пароля, которые использовались для поиска пользователя.

Аналогично поиску пользователя, необходимо предоставить базовый DN; результат может быть ограничен путем предоставления дополнительного фильтра:

base_group_search_dn = "ou=Groups,dc=corp,dc=com"
group_query_filter = "(objectClass=group)"

Правильные параметры конфигурации снова зависят от схемы вашего сервера каталогов; см. примеры конфигураций ниже.

ldapsearch -h $host -D $bind_dn -w $bind_password \
  -s sub \
  -b $base_group_search_dn \
  "($filter_groups_by_user_attr=$user_attr)" \
  $group_display_name_attr

См. Устранение неполадок поиска групп для распространенных проблем, связанных с поиском_групп.

Обзор конфигурации

Ниже представлена полная конфигурация и дополнительные сведения обо всех параметрах конфигурации LDAP.

[dex.v1.sys.connectors.ldap]
  ###
   # Configuration for querying your LDAP server
   ###
   ca_contents = "<your ca contents>"
   host = "<your host>"

   # The DN and password you wish to bind to your LDAP server to search for
   # users to authenticate for Chef Automate (and also to search for their group membership).
   # Example: "uid=seviceaccount,cn=users,dc=example,dc=com"
   bind_dn = "<your bind_dn>"
   bind_password = "<your bind_password>"

   ###
   # User Query (search for LDAP users to authenticate for Chef Automate)
   ###
   # The base DN to start the user query.
   # Chef Automate will use this as the base DN on which to search for users to authenticate against your LDAP server.
   # Example: "cn=users,dc=example,dc=com"
   base_user_search_dn = "<your base user search DN>"

   # The LDAP field used to filter the query for users to authenticate for Chef Automate.
   # Example: Setting this to "uid" would result in a filter of "(uid=<username_for_user_trying_to_authenticate>)".
   username_attr = "<your username attribute>"

   # Optional: LDAP query filter to apply when searching for users to authenticate.
   # This will be combined with username_attr filter above.
   # Example: Setting this to "(objectClass=person)" will filter on human actors only.
   user_query_filter = "<your user query filter>"

   ###
   # Populating the Chef Automate User via LDAP
   ###
   # Determines which LDAP field populates the username in a user's Chef Automate session on successful authentication.
   user_id_attr = "<your userid attribute>"

   # Optional: determines which LDAP field populates the email in a user's Chef Automate session on successful authentication.
   # Defaults to "user_id_attr" if not specified.
   email_attr = "<your email attribute>"

   # Optional: determines which LDAP field populates the display name in a user's Chef Automate session on successful authentication.
   # Defaults to "name" if not specified.
   user_display_name_attr = "<your user display name attribute>"

   ###
   # Group Query (search for LDAP group membership for an authenticated user)
   ###
   # The base DN to start the group membership query.
   # Chef Automate will use this as the base DN on which to search for LDAP group membership for a specific LDAP user.
   # Example: "cn=groups,dc=freeipa,dc=example,dc=com"
   base_group_search_dn = "<your base group search DN>"

   # The following two fields are used to match a user to a group.
   # If the defaults are used, then you end up with a group membership
   # filter of "(&(objectClass=group)(member=<user's DN>))".
   # Optional: The LDAP field by which you wish to filter group membership.
   # Defaults to "member".
   filter_groups_by_user_attr = "<groups to filter by user attribute>"
   # Optional: The LDAP field from the authenticated user you wish to use as input to the above filter.
   # Defaults to "DN".
   filter_groups_by_user_value = "<groups to filter by user value>"

   # Optional: Additional LDAP filter you can define to further filter group membership results.
   group_query_filter = "<your group query filter>"

   # The LDAP field on the group you wish to use as the Chef Automate Team name for the group.
   # Defaults to "name".
   group_display_name_attr = "<group display name attribute>"

Примеры конфигураций

В зависимости от схемы вашего каталога требуются различные параметры поиска групп:

Если ваш каталог выглядит так

dn: dc=corp,dc=com
objectClass: dcObject
objectClass: organization
o: Example Company
dc: corp

dn: ou=People,dc=corp,dc=com
objectClass: organizationalUnit
ou: People

dn: cn=jane,ou=People,dc=corp,dc=com
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane

dn: cn=john,ou=People,dc=corp,dc=com
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john

# Groups
dn: ou=Groups,dc=corp,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=admins,ou=Groups,dc=corp,dc=com
objectClass: groupOfNames
cn: admins
member: cn=john,ou=People,dc=corp,dc=com
member: cn=jane,ou=People,dc=corp,dc=com

dn: cn=developers,ou=Groups,dc=corp,dc=com
objectClass: groupOfNames
cn: developers
member: cn=jane,ou=People,dc=corp,dc=com

то необходимо следующее:

base_user_search = "ou=People,dc=corp,dc=com"
username_attr = "cn"
user_id_attr = "cn"
user_display_name_attr = "cn"

base_group_search = "ou=Groups,dc=corp,dc=com"
filter_groups_by_user_value = "DN"
filter_groups_by_user_attr = "member" # default
group_display_name_attr = "cn"

Однако, если ваша схема выглядит так — без списка членов в записях вашей группы:

dn: dc=corp,dc=com
objectClass: dcObject
objectClass: organization
o: Example Company
dc: corp

dn: ou=People,dc=corp,dc=com
objectClass: organizationalUnit
ou: People

dn: cn=jane,ou=People,dc=corp,dc=com
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane
departmentNumber: 1000
departmentNumber: 1001

dn: cn=john,ou=People,dc=corp,dc=com
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: john
departmentNumber: 1000
departmentNumber: 1002

dn: ou=Groups,dc=corp,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=admins,ou=Groups,dc=corp,dc=com
objectClass: posixGroup
cn: admins
gidNumber: 1000

dn: cn=developers,ou=Groups,dc=corp,dc=com
objectClass: posixGroup
cn: developers
gidNumber: 1001

dn: cn=designers,ou=Groups,dc=corp,dc=com
objectClass: posixGroup
cn: designers
gidNumber: 1002

Вам потребуются другие параметры для связывания пользователей и групп:

base_user_search = "ou=People,dc=corp,dc=com"
username_attr = "cn"
user_id_attr = "cn"
user_display_name_attr = "cn"

base_group_search = "ou=Groups,dc=corp,dc=com"
filter_groups_by_user_value = "departmentNumber"
filter_groups_by_user_attr = "gidNumber"
group_display_name_attr = "cn"

Устранение неполадок

В этом разделе будут указаны некоторые индикаторы, чтобы определить, на каком этапе процесса входа в систему произошел сбой.

Устранение неполадок подключения

Если хост или порт были неверными или Chef Automate не смог подключиться к службе LDAP, на экране входа будет отображаться

Внутренняя ошибка сервера

Ошибка входа.

В журналах (journalctl -u chef-automate) вы найдете строку из automate-dex.default, подобную этой — обратите внимание, что для читабельности из этого примера лога были удалены метка времени и имя службы:

level=error msg="Failed to login user: failed to connect: LDAP Result Code 200 \"\": dial tcp 192.168.33.223:10637: getsockopt: connection refused"

Обратите внимание, что журнал содержит IP-адрес даже тогда, когда сервер LDAP был настроен с помощью имени хоста. Проверка этого может помочь исключить проблемы с разрешением доменных имен.

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

level=error msg="Failed to login user: failed to connect: LDAP Result Code 200 \"\": x509: certificate is valid for localhost, not dex-dev.test"

Устранение неполадок привязки

Проблемы с привязкой проявляются аналогичным образом («Внутренняя ошибка сервера») как проблемы с подключением. Однако они отличаются тем, что записывается:

level=error msg="Failed to login user: ldap: initial bind for user \"cn=service_account,dc=corp,dc=com\" failed: LDAP Result Code 49 \"Invalid Credentials\": "

Устранение неполадок поиска пользователя

Существует два основных способа, которыми поиск пользователя может завершиться неудачно, и они приводят к различным ошибкам входа: один — запросы, которые вообще не могут быть выполнены, что приводит к

Внутренняя ошибка сервера

Ошибка входа.

в браузере и строке, подобной

level=info msg="performing ldap search ou=Peoples,dc=example,dc=org sub (cn=jane)"
level=error msg="Failed to login user: ldap: search with filter \"(cn=jane)\" failed: LDAP Result Code 32 \"No Such Object\": "

в журналах.

Возможной причиной (журналы которой вы видите здесь) является неправильная настройка base_user_search_dn.

Когда поиск пользователя выполняется успешно, но не удается вернуть полезную запись пользователя, браузер покажет запрос входа с баннером об ошибке, гласящим

Имя пользователя или пароль неверны.

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

level=info msg="performing ldap search ou=People,dc=corp,dc=com sub (cnn=jane)"

вместе с записью о том, что запрошенный запрос не вернул ничего:

level=error msg="ldap: no results returned for filter: \"(cnn=jane)\""

В этом примере вывода username_attr было установлено на cnn (а не на cn).

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

Обратите внимание, что неверные записи для user_query_filter также приведут к запросам, которые не возвращают записей.

Установка

user_query_filter = "(objectClass=person)"

приведет к следующим журналам:

level=info msg="performing ldap search ou=People,dc=example,dc=org sub (&(objectClass=person(cn=jane))" connector=LDAP
level=error msg="ldap: no results returned for filter: \"(&(objectClass=person(cn=jane))\"" connector=LDAP

Убедитесь, что поиск username_attr с заданным базой поиска может вернуть только одного пользователя. Что-то вроде этого могло произойти (упрощено для демонстрации):

dn: cn=jane,ou=Denver,ou=People,dc=corp,dc=com
sn: doe
cn: jane
username: jdoe

dn: cn=john,ou=Boston,ou=People,dc=corp,dc=com
sn: doe
cn: john
username: jdoe

с

base_user_search_dn = "ou=People,dc=corp,dc=com"
username_attr = "username"

ни Джейн Доу, ни её брат не смогли войти в Chef Automate. Был бы журнал, указывающий на то, что возвращено несколько пользователей.

Эта ситуация могла бы быть предотвращена путем установки username_attr = "cn"; или путем ограничения base_user_search_dn, если вы хотите разрешить доступ только людям из одного из этих городов для использования Chef Automate.

Наконец, успешный поиск пользователя записывает строку, подобную следующей:

level=info msg="username \"jane\" mapped to entry cn=jane,ou=People,dc=corp,dc=com"

Устранение неполадок привязки входа

Ошибки входа с привязкой, которые не вызваны неверными учетными данными, приведут к

Внутренняя ошибка сервера

Ошибка входа.

сопровождаемой строкой журнала с более подробной информацией, начиная с Failed to sign in user.

Устранение неполадок поиска групп

Ошибки при получении групп пользователя приведут к запрету входа с

Внутренняя ошибка сервера

Ошибка входа.

и журналами, похожими на

level=info msg="performing ldap search ou=Groups,dc=example,dc=org sub (member=cn=jane,ou=People,dc=example,dc=org)"
level=error msg="Failed to login user: ldap: failed to query groups: ldap: search failed: LDAP Result Code 32 \"No Such Object\": "

Например, это то, что вы видите, когда base_group_search_dn не существует ("ou=Groups,dc=...").

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

Успешный вход вызывает записи в журнале, подобные следующим:

level=info msg="performing ldap search ou=People,dc=corp,dc=com sub (cn=jane)"
level=info msg="username \"jane\" mapped to entry cn=jane,ou=People,dc=corp,dc=com"
level=info msg="performing ldap search ou=Groups,dc=corp,dc=com sub (member=cn=jane,ou=People,dc=corp,dc=com)"
level=info msg="login successful: connector \"ldap\", username=\"jane\", email=\"janedoe@example.com\", groups=[\"admins\" \"developers\"]"

и последующие журналы запросов API, содержащие предметы пользователя:

level=info msg="Authorization Query" action=search resource="compliance:profiles" result=true subject="[team:ldap:admins team:ldap:developers user:ldap:jane]"

ldapsearch Примеры запросов

Для отладки может быть полезно выполнить запросы LDAP вручную с помощью утилиты ldapsearch. В Ubuntu она предоставляется через ldap-utils (т.е. sudo apt-get install ldap-utils). Далее мы опишем пример схемы каталога и соответствующие запросы ldapsearch для различных фаз.

Запрос Поиск пользователя выглядит следующим образом, с комментариями, ссылающимися на настраиваемые параметры для интеграции LDAP:

ldapsearch -H ldap://ldap-server:636/ \  # host
  -D cn=service_account,dc=corp,dc=com \ # bind_dn
  -w admin \                             # bind_password
  -b ou=People,dc=corp,dc=com \          # base_user_search_dn
  -s sub \
  '(cn=jane)'                            # (username_attr=what-was-provided-via-sign-in-form)

При использовании анонимной привязки:

ldapsearch -H ldap://ldap-server:636/ \ # host
  -b ou=People,dc=corp,dc=com \         # base_user_search_dn
  -s sub \
  '(cn=jane)'                           # (username_attr=what-was-provided-via-sign-in-form)

Если вы настроили user_query_filter, он заключён в аргумент фильтра:

  '(&(objectClass=person)(cn=jane))'    # (&user_query_filter(username_attr=what-was-provided-via-sign-in-form))

После получения записи пользователя из каталога можно проверить пароль и сконструировать запрос на поиск групп из неё:

Предположим, что мы получили запись пользователя jane:

# jane, People, corp.com
dn: cn=jane,ou=People,dc=corp,dc=com
objectClass: person
objectClass: inetOrgPerson
sn: doe
cn: jane

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

ldapsearch -H ldap://ldap-server:636/ \ # host
  -b cn=jane,ou=People,dc=corp,dc=com \ # always the entry's DN
  -w janespassword                      # as provided via sign in from

где любой результат, отличный от ошибки (например, 32 No such object), указывает на правильные учетные данные.

Наконец, запрос поиска групп для этой записи пользователя выглядит так

ldapsearch -H ldap://ldapserver:636/ \        # host
  -D cn=service_account,dc=corp,dc=com \      # bind_dn
  -w admin \                                  # bind_password
  -b ou=Groups,dc=corp,dc=com \               # base_group_search_dn
  -s sub \
  '(member=cn=jane,ou=People,dc=corp,dc=com)' # (filter_groups_by_user_attr=[that attr of user entry])

С дополнительным group_query_filter, окончательный фильтр:

  '(&(objectClass=group)(member=cn=jane,ou=People,dc=corp,dc=com))' # (&group_query_filter(filter_groups_by_user_attr=[...])

Примечание: если запись пользователя содержит более одного атрибута filter_groups_by_user_attr, будут выполнены несколько запросов, и их результаты будут объединены.

Другие распространенные проблемы

Если пользователь, выполнивший вход через LDAP или SAML, видит страницу ошибки

502 Bad Gateway

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

Это может иметь две причины: у пользователя слишком много групп или ссылки на группы LDAP по их отличительным именам (DN). Последнее может привести к тому, что небольшая информация (например, имя группы «admins») станет чрезмерно большой (например, «cn=admins,ou=DeptA,ou=CityB,ou=StateWA,dc=subcorp,dc=corp,dc=com»). Это можно смягчить, изменив group_display_name_attr из DN в cn (общее имя). Обратите внимание, что для целей авторизации это также желательно. Группы, предоставленные LDAP, ссылаются в политиках с помощью team:ldap:<group-name>. Таким образом, team:ldap:admins удобнее, чем team:ldap:cn=admins,ou=DeptA,ou=CityB,ou=StateWA,dc=subcorp,dc=corp,dc=com.

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

cn=group1,ou=Groups,dc=corp,dc=com
cn=group2,ou=Groups,dc=corp,dc=com
cn=group3,ou=Groups,dc=corp,dc=com
cn=group4,ou=Groups,dc=corp,dc=com
cn=group5,ou=Groups,dc=corp,dc=com

group_query_filter из (|(cn=group1)(cn=group2)) будет ограничивать результаты поиска по группам одним из этих групп. Обратите внимание, что это не влияет на то, какие пользователи проходят аутентификацию; это влияет только на группы, распознаваемые Chef Automate. Например, учитывая пользователей Джейн и Джека, где Джейн является членом group1 и group3, а Джек — group3 и group4: группы Джейн будут сведены к group1 только, а у Джека не будет групп — но он всё равно сможет получить доступ к Chef Automate. Аналогичным образом, определённые группы могут быть исключены из результатов явно, используя фильтр, такой как (!cn=group2)

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

cn=group1,ou=AGroups,dc=corp,dc=com
cn=group2,ou=AGroups,dc=corp,dc=com
cn=group3,ou=BGroups,dc=corp,dc=com
cn=group4,ou=BGroups,dc=corp,dc=com
cn=group5,ou=CGroups,dc=corp,dc=com

вы можете использовать возможности запросов вашего сервера каталогов для ограничения результатов поддеревом. Конкретные детали зависят от используемого продукта; например, на серверах, поддерживающих расширенное соответствие, все записи групп ниже AGroups и BGroups можно получить, используя group_query_filter из (|(ou:dn:=AGroups)(ou:dn:=BGroups)).

Для получения подробностей см. LDAP Wiki Расширенный поиск по фильтру соответствия.