Active Directory/LDAP

LDAP (Lightweight Directory Access Protocol) – это протокол, реализующий службу каталогов Microsoft (Active Directory) для операционных систем Windows. Основное предназначение Active Directory — хранение в централизованной базе данных информации о пользователях. Протокол LDAP обеспечивает доступ к этой базе данных, а также авторизует пользователей в локальной сети для предоставления ресурсов.

Aсtive Directory состоит из объектов, которые делятся на три категории:

• Категория Люди включает в себя группы пользователей, а также их учётные записи.
• Категория Службы может включать электронную почту.
• Категория Ресурсы – различное оборудование (сканер, принтер и т. д.).

Основной задачей Active Directory является контроль и управление всеми этими объектами, а также предоставление информации о них внешним системам. Lightweight Directory Access Protocol включает несколько операций с каталогами. Для того, чтобы получить к ним доступ, необходимо подключиться. Подключение к каталогу осуществляется за счёт аутентификации пользователя.

Следующей операцией работы с Каталогом является Поиск. Эта операция включает в себя несколько параметров: база поиска – с неё начинается поиск информации, глубина поиска – охватываемая область и фильтр поиска – отбор тех объектов Каталога, которые попали в область поиска. Изменять данные возможно с помощью операции модификации. Она включает в себя добавление, копирование, перемещение и удаление учетных записей.

Преимущества Active Directory/LDAP в ВКС?

Во время сеанса видеоконференции участники могут быть «разбросаны» по разным местам (разные города, страны и даже континенты). Число пользователей может варьироваться от единиц до нескольких сотен. Active Directory/LDAP значительно облегчает работу администратора, который занимается обслуживанием каталога корпоративных пользователей. Подключение протокола LDAP к серверу избавляет администратора от повторного заведения записей, что значительно экономит его время. Пользователи, в свою очередь, избавляются от сеанса повторной авторизации. Active Directory/LDAP даёт возможность использовать на ВКС терминале существующий механизм авторизации, без необходимости повторного ввода своего логина и пароля вначале работы. Если протокол LDAP будет использоваться в локальной сети, пользователь сможет подключаться и аутентифицироваться на любом компьютере, который входит в корпоративную сеть.

Отслеживание LDAP запросов к Active Directory с помощью perfmon

После внедрения в компании Active Directory на базе Windows 2008 R2 остро ощутили нехватку подробного лога соединений по протоколу LDAP. Необходимость в подобном логе часто возникает при решении задач интеграции в Active Directory различных Linux сервисов.
Под катом — описание метода, позволяющего получить лог содержащий: ip-адрес и порт источника запроса, фильтр поиска, глубина (scope) поиска, запрошенный набор атрибутов, количество записей в результате поиска и т.д.

Предварительно необходимо настроить сеанс отслеживания событий:

1. Запустить «Системный монитор»: Пуск → Выполнить… → perfmon.
2. Открыть Производительность → Группы сборщиков данных → Сеансы отслеживания событий.
3. В контекстном меню Создать → Группа сборщиков данных.
4. Задать понятное имя группы. Выбрать «Создать вручную (для опытных)». Нажать «Далее».
5. Нажать «Добавить» и выбрать поставщика данных «ActiveDirectory Domain Services: Core». Нажать «Далее».
6. Задать папку для сохранения отчёта. Нажать «Далее».
7. Выбрать «Сохранить и закрыть». Нажать «Готово».
8. Будет создан остановленный сеанс отслеживания событий. Для начала сбора информации следует его запустить. ВАЖНО. Запущенный сбор информации неизбежно увеличит нагрузку на ваш сервер — учитывайте это при запуске сбора на высоко нагруженном сервере.
9. По завершению сбора событий следует остановить сеанс.

Результатом сбора событий будет .etl файл в заданной папке.

Для анализа содержимого этого файла:

1. Запустить командную строку Пуск → Выполнить… → cmd
2. Перейти в папку с .elt файлом
3. Сконвертировать дамп в .csv для последующего анализа:

обратите внимание — tracerpt умеет выгружать данные не только в csv, но и в xml и evtx.

На выходе будет два файла:
summary.txt — сводка о захваченных событиях
dumpfile.csv — собственно собранный дамп. Наиболее интересны события типа «DsDirSearch» — в ним будут зарегистрированы: ip и порт источника запроса, фильтр поиска, глубина (scope) поиска, запрошенный набор аттрибутов, количество записей в результате поиска.

P.S. Есть ещё как минимум один способ получить сведения о том, какие запросы поступили в Active Directory и что по ним нашлось: перехват трафика (Wireshark или Network Monitor). Но при использовании ssl перехват трафика становится более трудоёмким (и более ресурсоёмким).

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Настройка аутентификации в Nginx через Active Directory (LDAP)

В данной статье мы рассмотрим, как настроить basic аутентификацию в Nginx через LDAP каталог. В качестве сервера LDAP будем использовать Windows Active Directory. Так как у Nginx нет официального встроенного модуля авторизации через LDAP (в отличии от Apache или Tomcat), разработчики предлагают использовать сторонний сервис nginx-ldap-auth, который будет обращаться к LDAP и выступать своего рода прокси между Nginx и сервером каталога LDAP ldap сервером. Для начала давайте запустим сервис и посмотрим, как он работает.

Настройка и запуск сервиса аутентификации nginx-ldap-auth

Для запуска сервиса nginx-ldap-auth будем использовать docker. Для начала нужно клонировать репозиторий с сервисом с github:

# sudo git clone https://github.com/nginxinc/nginx-ldap-auth

Если у вас не установлен утилиты git, можно просто скачать архив с исходниками и распаковать его в директорию nginx-ldap-auth.

В директории уже имеется готовый Dockerfile. Для сборки контейнера нужно выполнить:

# sudo docker build -t nginx-ldap-auth-daemon .

Вывод при сборке будет таким:

Docker image готов, можно запустить контейнер. Для этого выполните команду:

# sudo docker run -p 8888:8888 —name ldap-auth nginx-ldap-auth-daemon

Вывод данной команды будет таким:

Эта команда запустит контейнер из образа nginx-ldap-auth-daemon, c названием контейнера ldap-auth и пробросит порт 8888 из контейнера на host машину. Проброс портов нужен, чтобы проверить работу и выполнить отладку аутентификации в Active Directory. В дальнейшем, можно исключить этот параметр. Также для отладки мы не добавили ключ -d, который запустил бы контейнер и отвязал бы его от консоли, но тогда не было видно лога работы, который полезен при отладке.

Давайте теперь разберем, как работает сервис nginx-ldap-auth. Данный демон является небольшим web сервисом, к которому можно отправить HTTP запрос методом get с определенными заголовками, он в свою очередь обратится в Active Directory и проверит авторизационные данные. Если они верны, он ответит HTTP кодом 200 ОК, если нет, то вернет 401 код (не авторизован).

Для проверки нужен настроенный сервер Active Directory либо OpenLDAP. В данной статье будет рассмотрен контроллер домена на Windows Server 2008 R2, но в README репозитория демона заявлена поддержка и других LDAP серверов.

• Имя домена: corp.to.high
• IP контроллера домена: 192.168.0.16

Создадим пользователя с правами гость. Назовем его ldap_reader. Данный пользователь нужен, чтобы от его имени демон обращался в AD и проверял переданную при авторизации связку логин и пароль.

Данные пользователя следующие

• Логин: ldap_reader@corp.to.high
• Пароль: r05-2020
• Группа AD: Гости домена.

Запретите пользователю менять пароль и установите неограниченный срок действия пароля (Never Expires), так как это сервисная УЗ.

Для тестирования можно скачать утилиту для поиска в дереве LDAP, например ldapsearch.

# sudo apt install ldap-utils

Для проверки доступности контроллера домена и правильной настройки пользователя можно выполнить команду:

# ldapsearch -v -D «ldap_reader@corp.to.high» -w «r05-2020» -b «DC=corp,DC=to,DC=high» -H «ldap://192.168.0.16» «(sAMAccountName=ldap_reader)»

• -D binddn учетная запись, для доступа к домену,
• -w bindpassword пароль учетной записи,
• -b searchbase – контейнер (OU) AD, в котором нужно искать пользователя (можно сузить область поиска для получения ответа более быстро),
• -H адрес ldap сервера;
• Затем указывается LDAP фильтр, по которому нужно выполнить поиск.

Вывод для нашего домена будет такой:

Данный лог показывает, что пользователь найден и у пользователя ldap_reader есть доступ на чтение дерева домена. Проверим теперь работу демона авторизации. Для этого, выполним в консоли команду:

# curl —location —request GET ‘http://localhost:8888’ \
—header ‘X-Ldap-URL: ldap://192.168.0.16’ \
—header ‘X-Ldap-BaseDN: CN=Users,DC=corp,DC=to,DC=high’ \
—header ‘X-Ldap-BindDN: ldap_reader@corp.to.high’ \
—header ‘X-Ldap-BindPass: r05-2020’ \
—header ‘X-Ldap-Template: (sAMAccountName=%(username)s)’ -vv -u ldap_reader:r05-2020

Вывод будет таким:

Заголовки, используемые в запросе:

• X-Ldap-URL — адрес ldap сервера, такой же, как при тестировании с помощью утилиты ldapsearch;
• X-Ldap-BaseDN — начальный DN для поиска;
• X-Ldap-BindDN — учетная запись с правами на чтение дерева домена.
• X-Ldap-BindPass – пароль пользователя для доступа к AD;
• X-Ldap-Template — в данном заголовке передается LDAP фильтр, по которому будет происходить поиск. В заголовке можно комбинировать разные фильтры. Подробнее можно посмотреть в документации к демону nginx-ldap-auth.
• Опцией -u :

нужно передать креденшелы пользователя, которые нужно проверить в домене

Если передать неверные учетные данные, будет возвращена ошибка 401 ( не авторизован). Попробуем передать неверный пароль, вывод будет такой:

Также в логах демона можно увидеть вывод:

Настройка контейнера Nginx для авторизации в Active Directory (LDAP)

Мы проверили работу демона аутентфикации nginx-ldap-auth, теперь можно перейти к настройке Nginx. В данной статье, покажу, как настроить авторизацию для docker registry с учетной записью Active Directory. Nginx будем запускать в docker контейнере. Создадйте Dockerfile:

В директории с Dockerfile создадйте файл конфигурации nginx-ldap-auth.conf.
Содержание файла:

В данном конфиге указывается location, с опцией auth_request, которая позволяет отправить HTTP запрос для проверки авторизации. Мы указали внутренний адрес /auth-proxy, на который будет переадресован запрос авторизации. В данном location указаны опций, которые настраивают параметры кэширования и заголовки, которые будут отправлены в nginx-ldap-auth.

• proxy_pass_request_body — запрещает передачу полей заголовка исходного запроса на проксируемый сервер;
• proxy_set_header — устанавливает заголовок Content-Length;
• proxy_cache_valid 200 10m — кешировать ответ с кодом 200 на 10 минут (чтобы не отправлять запрос к серверу авторизации при каждом обращении);
• proxy_cache_path — путь и другие параметры кэша;
• proxy_cache_key — ключ кэширования;
• proxy_pass – указывает на контейнера демона авторизации nginx-ldap-auth. Остальные опции аналогичны тем, что использовались при проверке демона. Файл конфига и dockerfile можно взять в github репозитории.

После создания конфига, нужно собрать контейнер:

# sudo docker build . -t nginx-ldap

Запустите контейнер с nginx с выводом в консоль:

# sudo docker run -p:8081:8081 —link ldap-auth —link registry —name nginx-ldap nginx-ldap

• Запускаем nginx-ldap образ с именем —name nginx-ldap;
• —link — опция позволяет связать в одну сеть контейнеры, так как мы к ним обращаемся по именам в конфиге nginx. Без этих опций из контейнера nginx не будет резолвиться имя registry и ldap-auth;
• -p:8081:8081 — прокидываем порт наружу.

Вывод команды будет такой:

Тестируем аутентификацию пользователя доменного пользователя AD в Nginx

Теперь откройте браузер и перейдите по адресу: http://localhost:8081/v2/_catalog. После успешной авторизации nginx должен переадрессовать на приватный репозиторий docker, описанный в статье про Docker Registry Нам будет предложено окно базовой авторизации следующего вида.

В логах веб сервера должна появится строку обращения к /v2/_catalog. Т.к. текущий пользователь не авторизирован, сервер вернул код ответа 401 код и предлагает авторизоваться. После успешной авторизации должен вернуться код ответа 200.

Введите логин и пароль пользователя домена. Для теста можно использовать сервисного пользователя, которого создали для поиска по дереву домена.

После успешной авторизации должна открыться страница со списком образов в Docker репозитории.

У меня в репозитории в данный момент один образ, созданного в статье про создание простого микросервиса в docker.

В логах сервиса, который обращается к серверу ldap можно увидеть следующее:

По логу видно, что выполнено подключение к LDAP серверу, выполнена авторизация и проверены учетные данные пользователя.

После проверки, можно остановить контейнеры, и запустить заново в фоновом режиме:

# sudo docker rm ldap-auth
# sudo docker rm nginx-ldap

Теперь можно запуститьконтейнеру nginx и nginx-ldap-auth в фоновом режиме. Также мы убрали в контейнере авторизации проброс портов наружу, это больше не нужно.

# sudo docker run -d —name ldap-auth nginx-ldap-auth-daemon
# sudo docker run -p:8081:8081 -d —link ldap-auth —link registry —name nginx-ldap nginx-ldap

В данной статье мы рассмотрели общий принцип настройки авторизации с учетными данными LDAP в nginx. В качестве конечного backend может выступать не обязательно docker registry, таким образом можно настроить аутентификацию в Active Directory в в любом вашем приложении, опубликованном через nginx.

Читайте также:  Windows 10 как удалить беспроводную сеть