Как настроить аутентификацию AD с помощью LDAP через прокси с помощью TLS / SSL

Как 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.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

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 в вашей сети, если они уже не являются частью более крупного леса.

cryptoparty

Cryptography is typically bypassed, not penetrated.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *