Как 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, известна либо как раздел или база данных.
Мы будем использовать термин база данных.
Убедитесь, что OpenLDAP поднят и запущен
Процесс сервера OpenLDAP называется slapd, что означает «stand-alone LDAP daemon».
Он обеспечивает практически все функции сервера OpenLDAP, включая возможность принимать соединения с LDAP-клиентов, обрабатывать запросы и обновления и реализовывать списки ACL, которые ограничивают доступ к конфиденциальной информации в каталоге.
Давайте рассмотрим, что вы уже установили и настроили OpenLDAP.
В соответствии с приведенной выше конфигурацией slapd управляет базой данных для дерева каталогов dc = example, dc = com.
Убедитесь, что служба slapd запущена.
# service slapd status
Теперь мы проверим, что наши записи загружаются должным образом с помощью команды ldapsearch.
# ldapsearch -LLL -x -h localhost -b 'dc=example,dc=com'
Параметр -x указывает, что ldapsearch должен использовать простую аутентификацию вместо простой проверки подлинности и уровня безопасности (SASL).
При простой аутентификации клиент LDAP отправляет учетные данные в виде открытого текста.
Даже если вы используете LDAP через SSL (LDAPS) или LDAP StartTLS, вы все равно используете простую аутентификацию, но туннель, используемый для связи, зашифрован (и гораздо безопаснее).
Вернемся к команде ldapsearch.
Он выполняет запрос, чтобы найти все записи под деревом root.
Как и ожидалось, ldapsearch возвращает все записи, которые мы первоначально импортировали через ldapadd, как в приведенном примере.
Интеграция с Active Directory
Мы легко просматриваем записи из OpenLDAP с помощью простой команды ldapsearch на нашем локальном клиенте, но как насчет просмотра записей, управляемых в Active Directory?
Чтобы это произошло, вам нужно направить OpenLDAP в Active Directory.
Убедитесь, что все необходимые модули включены в файл slapd.conf:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema
Следующий шаг – включить прокси-сервер openLDAP в качестве Active Directory, перейдите к концу slapd.conf и добавьте следующие строки:
database ldap subordinate rebind-as-user yes uri "ldaps://ad-dc.example.com" suffix "DC=corp,DC=ad,DC=com" chase-referrals yes idassert-bind bindmethod=simple binddn="CN=ad-username,DC=corp,DC=ad,DC=com" credentials="password" tls_cacert=/etc/openldap/certs/certificate_file
Итак, теперь клиенты будут авторизованы как «CN = ad-username, DC = corp, DC = ad, DC = com», даже если они фактически подключены анонимно к прокси.
Теперь перезапустите службу slapd и снова запустите ldapsearch.