Как Active Directory (AD), так и OpenLDAP играют важную роль на предприятии.
Фактически, в той же компании вы найдете группу UNIX с использованием OpenLDAP и администраторов локальной сети и Windows, использующих AD.
Однако большинство людей не могут полностью получить доступ к схеме AD через OpenLDAP.
В этой статье мы рассмотрим, как настроить проверку подлинности Active Directory с помощью LDAP через прокси с защитой транспортного уровня/SSL.
OpenLDAP и AD могут мирно сосуществовать — ключ находит лучший способ разрешить операции LDAP пересекать границы между AD и развертываниями OpenLDAP.
Один из способов сделать это — настроить проверку подлинности Active Directory с помощью LDAP через TLS/SSL. Наша основная цель — интегрировать наш LDAP с Active Directory.
Мы включим некоторую схему в основной файл конфигурации и добавим требуемые параметры.
Прежде чем мы начнем
режде чем двигаться дальше, давайте определим терминологию.
Во-первых, сервер LDAP на самом деле известен как агент службы каталогов (DSA).
Во-вторых, DSA управляет любой частью или всем деревом информации каталога (DIT).
Несколько DSA могут быть развернуты для управления всем DIT, а также для обеспечения репликации и высокой доступности.
Часть DIT, которую управляет DSA, известна либо как раздел или база данных.
Мы будем использовать термин database.
Убедитесь, что OpenLDAP запущен и поднят
Процесс сервера OpenLDAP называется slapd, что означает «автономный демон LDAP».
Он обеспечивает практически все функции сервера OpenLDAP, включая возможность принимать соединения с LDAP-клиентов, обрабатывать запросы и обновления и реализовывать списки ACL, которые ограничивают доступ к конфиденциальной информации в каталоге.
# service slapd status
Теперь мы проверим, что наши записи (из той же конфигурации примера, приведенной в этой статье) загружаются должным образом с помощью команды ldapsearch.
# ldapsearch -LLL -x -h localhost -b 'dc=example,dc=com'
Параметр -x указывает, что ldapsearch должен использовать простую аутентификацию вместо простой проверки подлинности и уровня безопасности (SASL).
При простой аутентификации клиент LDAP отправляет учетные данные в виде открытого текста.
Даже если вы используете LDAP через SSL (LDAPS) или LDAP StartTLS, вы все равно используете простую аутентификацию, но туннель, используемый для связи, зашифрован (и гораздо безопаснее).
Вернемся к команде ldapsearch.
Он выполняет запрос, чтобы найти все записи под корнем дерева.
Как и ожидалось, ldapsearch возвращает все записи, которые мы первоначально импортировали через ldapadd, как в приведенном примере.
Интеграция с Active Directory
Мы легко просматриваем записи из OpenLDAP с помощью простой команды ldapsearch на нашем локальном клиенте, но как насчет просмотра записей, управляемых в Active Directory? Чтобы это произошло, вам нужно направить OpenLDAP в Active Directory.
Убедитесь, что все необходимые модули включены в файл slapd.conf:
include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/nis.schema
Следующий шаг — включить прокси-сервер openLDAP в качестве Active Directory, перейдите к концу slapd.conf и добавьте следующие строки:
database ldapsubordinaterebind-as-user yesuri "ldaps://ad-dc.example.com"suffix "DC=corp,DC=ad,DC=com"chase-referrals yesidassert-bind bindmethod=simplebinddn="CN=ad-username,DC=corp,DC=ad,DC=com"credentials="password"tls_cacert=/etc/openldap/certs/certificate_file
database ldap — определяет новый задний конец с помощью slapd-ldap, который будет нашим прокси-сервисом.
subordinate — без этого ключевого слова slapd ищет только базу данных, указанную базой поиска (например, если dc = example, dc = com были указанной базой поиска, тогда cn = users, dc = example, dc = com никогда не будет проверяться, потому что это другая slapd-база данных).
rebind-as-user — эта опция сообщает slapd привязываться к удаленному агенту службы каталогов с учетными данными, предоставленными клиентом. Обратите внимание, что учетные данные должны быть действительными в AD.
URI — указывает удаленный LDAP-сервер, который в этом случае является контроллером домена AD.
chase-referrals — этот параметр указывает, что slapd будет автоматически преследовать любых рефералов.
idassert-bind — этот параметр используется для привязки к удаленному серверу и, при необходимости, авторизации другого идентификатора.
bindmethod — этот оператор используется для определения того, какой метод используется прокси для привязки к удаленному серверу с данным административным идентификатором.
В этом случае мы используем простые, так как настоятельно рекомендуется использовать TLS вместе с простым связыванием. Для простого связывания требуются дополнительные параметры:
binddn = «CN = ad-username, DC = corp, DC = ad, DC = com» используется для указания DN связывания;
credentials = «password» используется для указания учетных данных привязки;
tls_cacert — сертификат сертификата сертификатов безопасности транспортного уровня определяет путь и имя файла сертификата, который позволяет клиенту проверить сертификат LDAP-сервера. Этот файл может быть получен от поставщика сертификата X.509 или в случае самоподписывания — скопирован с сервера LDAP.
Итак, теперь клиенты будут авторизованы как «CN = ad-username, DC = corp, DC = ad, DC = com», даже если они фактически подключены анонимно к прокси.
Теперь перезапустите службу slapd и снова запустите ldapsearch.
# ldapsearch -v -H "ldaps: //ad-dc.example.com: 636 /" -b "DC = corp, DC = ad, DC = com" -s sub -D "CN = ad-username, DC = corp, DC = ad, DC = com "-w" password "
Если команда не работает, убедитесь, что:
1. Вы можете достигнуть ldaps: //ad-dc.example.com: 636
2. Свяжите с учетными данными, предоставленными клиентом (сторона Active Directory)
Вывод
Теперь вы можете подключить Active Directory к любой части вашего каталога OpenLDAP.
Вы можете аутентифицировать своих пользователей AD в приложениях LDAP, которые используют OpenLDAP, или даже предоставить доступ к нескольким AD в вашей сети, если они уже не являются частью более крупного леса.
0 Комментарии