Вопрос или проблема
У меня есть пользователи на сервере OpenLDAP. Они управляются вручную.
dn: cn=alice,ou=contoso,dc=combined,dc=internal
mail: [email protected]
dn: cn=bob,ou=fabrikam,dc=combined,dc=internal
mail: [email protected]
DN указывает, что пользователь принадлежит компании fabrikam или contoso.
Когда пользователь выполняет простое связывание с сервером OpenLDAP, я хочу, чтобы OpenLDAP
- выбирал сервер backend для этого пользователя на основе его DN:
-
ou=contoso,...=> сервер backend ldap: 192.168.1.11
-
ou=fabrikam,...=> сервер backend ldap: 192.168.1.12
- искал пользователя на сервере
backendпо атрибутуmail:(&(mail={orig.mail})(objectClass=user)), чтобы получить DN этого пользователя от сервера backend (back_dn) - пытался связаться как
back_dnс сервером backend, используя пароль, предоставленный пользователем, и возвращал успех или ошибку
Я не могу найти ни одного работающего примера этого или чего-то подобного, пожалуйста, помогите мне…
Этот руководитель кажется, описывает настройку OpenLDAP для работы в качестве LDAP-прокси, который проксирует запросы аутентификации на разные серверы LDAP. Я не изучал это руководство детально и сам не разворачивал такую прокси-службу, поэтому не знаю наверняка, может ли OpenLDAP выбрать нужный сервер backend на основе конкретных атрибутов, которые вам нужны.
Существуют и другие решения для LDAP-прокси, которые можно найти, если поискать “LDAP proxy”. Если OpenLDAP не может удовлетворить вашим требованиям, возможно, одно из других решений сможет.
Я не знаю о существующей конфигурации, которая бы здесь сработала, но мой подход заключался бы в использовании ‘saslauthd’ из Cyrus libsasl.
OpenLDAP поддерживает аутсорсинг аутентификации Simple Bind демону ‘saslauthd’, имея записи пользователей с атрибутом userPassword: {SASL}foo. Когда клиент пытается связаться с такой записью, slapd будет обращаться к демону saslauthd через Unix-сокет, запрашивая его проверить имя пользователя foo с паролем клиента.
(То же самое будет сделано для связей SASL ‘PLAIN’, хотя никто их и не использует.)
Реальный saslauthd имеет backend для LDAP, хотя он поддерживает только один сервер LDAP. Однако, поскольку протокол очень простой (слушает на /run/saslauthd/mux и получает строки с префиксом длины), возможно написать собственный saslauthd – например, на python – который бы понимал имена пользователей в каком-то произвольном формате, таком как user@realm или realm/email@addr (или любым другим форматом, который вы предпочитаете), и проверял бы пароль через соответствующий сервер LDAP backend. Тогда вам останется только выяснить, как синхронизировать атрибут mail с новым гипотетическим атрибутом userPassword: {SASL}contoso/[email protected].
(Также возможно хранить только уникальный идентификатор в userPassword (например, userPassword: {SASL}0183658373ea), и самописный saslauthd будет запрашивать оригинальный OU и адрес ‘mail:’ из вашего фронтенд-каталога, выполняя поиск (userPassword={SASL}$username). Насколько мне известно, slapd многопоточен, так что этот подход не должен привести к взаимной блокировке… до тех пор, пока не закончатся рабочие потоки, по крайней мере, и тогда может произойти взаимная блокировка.)
.
Ответ или решение
Для решения задачи аутентификации пользователей из серверов OpenLDAP на основе их отличительных имен (DN), с использованием промежуточного прокси-сервера LDAP, необходимо сосредоточиться на нескольких ключевых моментах, включая настройку прокси-решения, интеграцию с внешними серверами LDAP, и настройку аутентификации с параметрами, описанными в вашей ситуации.
Теория
OpenLDAP может быть настроен как прокси-сервер, который сможет перенаправлять запросы аутентификации на различные конечные серверы LDAP, в зависимости от параметров запроса, таких как определенный организационный юнит (ou) в DN пользователя. Как было указано в вашем описании, необходимо использовать различные backend-серверы для пользователей из компаний "fabrikam" и "contoso". Это может быть достигнуто с использованием модуля slapd-ldap/proxy в OpenLDAP и несколько специфичной конфигурации, основанной на маршрутизации запросов.
Пример
Для настройки OpenLDAP как прокси-сервера сперва необходимо убедиться, что OpenLDAP поддерживает необходимые модули. Далее потребуется конфигурация, которая позволит использовать различные backend-серверы на основе DN пользователя. Следующий пример может послужить стартовой точкой:
-
Настройка
slapd.conf:-
Откройте ваш slapd.conf файл для редактирования.
-
Для dn: cn=alice,ou=contoso,dc=combined,dc=internal:
database ldap suffix "ou=contoso,dc=combined,dc=internal" uri "ldap://192.168.1.11" chase-referrals yes -
Для dn: cn=bob,ou=fabrikam,dc=combined,dc=internal:
database ldap suffix "ou=fabrikam,dc=combined,dc=internal" uri "ldap://192.168.1.12" chase-referrals yes
-
-
Распределение аутентификации:
Конфигурация должна поддерживать поиск по mail-атрибуту. Это возможно, определив правила для того, как должны обрабатываться запросы bind. Может потребоваться настройкаauthz-regexpдля преобразования DNs. -
Дополнительное ПО:
Вам может потребоваться внешний скрипт или программа для точной проверки паролей через saslauthd или подобную систему, особенно если вы ищете более сложное поведение, чем простая аутентификация по DN.
Применение
После того как OpenLDAP настроен, динамическая маршрутизация запросов на backend-серверы позволит вам управлять аутентификацией без необходимости изменения конфигурации при добавлении новых пользователей. Это масштабируемый путь для обработки аутентификаций в распределенных системах, учитывая особенности структуры больших компаний.
Совет
Несмотря на то, что OpenLDAP может быть настроен для выполнения нужных функций, может возникнуть необходимость в более специализированных решениях в сложных сценариях, которые проще реализовать с помощью дополнительных инструментов, например, механизма proxy, реализующего сложные правила маршрутизации. Это достигается путем создания пользовательских решений на базе скриптов, которые интегрируются с существующей инфраструктурой, например, с использованием Python для взаимодействия с API LDAP.
Таким образом, вашему проекту аутентификации можно придать гибкость, необходимую для масштабирования и поддержки сложных моделей аутентификации через OpenLDAP, прокси-серверы и saslauthd, что будет гарантировать легкость и простоту интеграции в различные доменные структуры.