Демон ldap auth это что

Nginx + LDAP Auth ( Наладка аутентификации пользователей сайта под управлением Nginx через внешний LDAP-сервис. )

OS: «Linux Debian 8/9/10», «Linux Ubuntu 16/18 LTS».
Application: Nginx, Python, LDAP.

Задача: обеспечить аутентификацию пользователей сайта через внешний LDAP-сервис, средствами web-сервера «Nginx».

С точки зрения эксплуатационщика на предприятии удобно проводить аутентификацию пользователей внутренних сервисов через некий централизованный каталог с учётными данными. Чаще всего для этого применяется сервис «Microsoft Active Directory», но технически почти всегда в этой роли можно использовать иные реализации LDAP, вроде «OpenLDAP» или «389-DS».

В сложносочинённых сайтах задачи аутентификации и авторизации обычно возлагаются на специально для этого предназначенные компоненты внутри информационной системы, для реализации которых во всех распространённых языках программирования имеются библиотеки функций взаимодействия с LDAP. С мелкими сайтами, возможно даже полностью статическими, сложнее — у них нет подкапотных механизмов, посредством которых можно было бы проверять право доступа пользователя к запрашиваемым данным. В таком случае на роль привратника остаётся один кандидат — web-браузер. И вот на этом этапе выясняется, что любимый нами «Nginx» не имеет модуля аутентификации через LDAP.

Как вариант решения поставленной задачи, можно воспользоваться системных модулем «auth_pam», указав «Nginx» проводить аутентификацию через PAM несущей операционной системы («Linux» или xBSD), в которой настроена связка с LDAP. Лет пять назад разрабатывалась реализация в виде модуля «nginx-auth-ldap», но он устарел сейчас разработчики «Nginx» официально предлагают использовать другой подход, с промежуточным сервисом «nginx-ldap-auth-daemon».

Предлагаемая схема взаимодействий проста и прозрачна. Когда пользователь обращается к защищённому разделу сайта, web-сервер «Nginx» запрашивает посредством протокола «HTTP Basic authentication» логин и пароль. Полученные аутентификационные данные встроенным модулем «http_auth_request» сразу отправляются по протоколу проксирования фоновому web-сервису «LDAP Auth Daemon», который в свою очередь обращается к указанному в его настройках LDAP-серверу за подтверждением существования пользователя с предъявленными логином и паролем. Положительный или отрицательный ответ доставляется обратно по цепочке web-серверу «Nginx», который допускает или нет пользователя до запрашиваемого контента. Этот процесс красиво расписан в официальной документации.

Перейдём же к практике.

Установка «Nginx LDAP Auth Daemon».

Простенькое приложение-посредник написано на «Python», который почти всегда уже установлен:

Загружаем дистрибутив «Nginx LDAP Auth Daemon»:

Копируем единственный нужный исполняемый файл в наиболее подходящее ему место в файловой системе:

Заготавливаем место для журналов событий (аутентификация дело ответственное):

Пробуем запустить приложение:

По умолчанию «Nginx LDAP Auth Daemon» прослушивает запросы только на «локальной сетевой петле», на обычно свободном порту, что меня полностью устраивает и освобождает от необходимости что-то настраивать:

Оставим пока приложение запущенным и перейдём к настройке web-сервера.

Настройка аутентификации через LDAP в «Nginx».

Принимая за данность, что web-сервер «Nginx» уже корректно настроен, дополним настройки конкретного сайта блоком параметров проксирования запросов аутентификации к «Nginx LDAP Auth Daemon»:

# Перечисляем требования, которым должны удовлетворять пользователи сайта
satisfy all;
#
# (пользователи из локальных сетей)
allow 10.0.0.0/8;
allow 172.16.0.0/12;
allow 192.168.0.0/16;
deny all;
#
# (прошедшие аутентификацию)
auth_request /auth-proxy;

# Блок параметров запроса к "Nginx LDAP Auth Daemon"
location = /auth-proxy {
internal;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_pass http://127.0.0.1:8888;
proxy_set_header X-Ldap-URL "ldaps://ldap.example.net:636";
proxy_set_header X-Ldap-Template "(&(uid=%(username)s)(objectclass=person)(memberOf=cn=web-service-users,ou=groups,dc=example,dc=net))";
proxy_set_header X-Ldap-BaseDN "ou=People,dc=example,dc=net";
proxy_set_header X-Ldap-BindDN "uid=nginx-web-service,ou=Accounts,ou=Services,dc=example,dc=net";
proxy_set_header X-Ldap-BindPass "***";
}

Проверяем синтаксическую корректность конфигурации «Nginx» и применяем её:

Сразу после запуска можно пробовать обращаться к закрытой части сайта и проверять, работает ли связка «Nginx», «Nginx LDAP Auth Daemon» и LDAP в соответствии с ожиданиями. Если что-то пошло не так, смотрим предусмотрительно заготовленный журнал событий.

Подключение к LDAP с «самоподписанным» SSL-сертификатом.

Почти наверняка LDAP-сервер, работающий только в локальной сети, для шифрования соединений будет предлагать «self-signed» SSL-сертификат. Типовое python-приложение доверяет сертификатам, размещённым в соответствующем хранилище несущей операционной системы, так что самым простым способом наладить связь будет добавление публичной части самодельного сертификата LDAP-сервиса в перечень «доверенных»:

Последующая проверка (с несущего «Nginx LDAP Auth Daemon» сервера) не должна демонстрировать предупреждений о проблемах распознавания подписи SSL-сертификата целевого сервера:

О кешировании запросов аутентификации.

Аутентификация через «auth_request» в «Nginx» работает так, что на каждый запрос любого ресурса (даже мелкой картинки в составе страницы) генерируется внутреннее событие требования аутентификации, по которому отправляется запрос в промежуточную подсистему «ldap‑auth», которая в свою очередь обращается за подтверждением подлинности пользователя в LDAP. Таким образом на каждый запрос web-страницы создаётся от десятка до нескольких сотен подзапросов, в которых совершенно нет необходимости. Для снижения затрат ресурсов на такую непродуктивную деятельность в «Nginx» применяется кеширование.

Вначале на уровне глобальной конфигурации «Nginx» указываем желаемое месторасположение директории для файлов данных кешируемых запросов и максимальное время хранения таковых, а после в конфигурации сайта, для доступа к которому требуется аутентификация через LDAP, добавляем указание кешировать успешно завершённые запросы к подсистеме «ldap-auth» на срок до десяти минут:

proxy_cache_path /var/lib/nginx/cache/ keys_zone=auth_cache:10m;
.
server {
.

location = /auth-proxy {
internal;
proxy_cache auth_cache;
proxy_cache_valid 200 10m;
.

Настройка автозапуска «Nginx LDAP Auth Daemon» посредством «Systemd».

Ранее мы запустили приложение-прослойку вручную. Автоматизируем эту процедуру, описав подсистему аутентификации как постоянно работающий простой сервис:

[Unit]
Description=LDAP authentication helper for Nginx
After=network.target network-online.target

Указываем «Systemd» перечитать и принять новую конфигурацию, а также явно активируем и запускаем новый сервис:

Журналы событий нам в помощь, если что-то работает не так, как задумывалось:

Наладка ротации журналов событий.

Выше упоминалось, что реализация аутентификации в «Nginx» склонна генерировать массу запросов, которые записываются в журнал событий. Если забыть об этом, то через полгода в файловой системе вырастет огромный ненужный файл. Заранее натравим на него подсистему усечения и оборота журналов:

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

[ уже посетило: 7402 / +4 ] [ интересно! / нет ]

Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )

Docker и аутентификация через Nginx

Одна из досадных проблем, которые встают при создании NAS, заключается в том, что не всякое программное обеспечение может работать с LDAP, а некоторое вообще не содержит механизмов аутентификации.

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

Поскольку данная статья является частью NAS цикла,
здесь я остановлюсь на том, как приспособить данное решение к сервисам в Docker-контейнерах.

Решение основывается на примере реализации аутентификации через внешнего агента Nginx LDAP Auth, но я использую контейнеризованный вариант от LinuxServer.io потому, что это готовый образ, соответствующий определённым стандартам.

Единственная проблема заключалась в том, что патчи LinuxServer.io сломали базовую HTTP аутентификацию, но после того, как влили багфикс, пользоваться этим стало опять возможно.

Аутентификация в общем случае

Как показано в статьях, аутентификация производится по следующей схеме:

• Клиент обращается к сервису.
• Обратный прокси делает перенаправление, если установлен cookie.
• Если cookie нет, делается запрос к сервису аутентификации.
• Сервис аутентификации запрашивает логин и пароль, которые проверяет через обращение к LDAP серверу.
• Если проверка успешна, он устанавливает cookie и выполняет перенаправление на сервис.

Альтернативным вариантом может являться использование компилируемого модуля для nginx, но я данный вариант здесь не рассматриваю с силу некоторых проблем с данным модулем и меньшей его гибкости.

Доработанный образ для OpenLDAP сервера есть здесь.

Аутентификация контейнеров

В рамках NAS, сервисы работают в контейнерах, поэтому есть желание сделать так, чтобы возможно было переключать режимы аутентификации, просто установив переменные внутри контейнера.

Такой механизм уже есть в используемом образе ngingx-proxy и реализован он через шаблоны, которые обрабатывает docker-gen.

Он подставляет в шаблон метаданные, которые содержат описание запущенных в данный момент контейнеров Docker.

Таким образом, всё что надо сделать — это доработать шаблон конфигурации обратного прокси так, чтобы при наличии условной переменной в контейнере, было включено перенаправление на сервис сквозной аутентификации, который также работает в контейнере.

Затем, внести соответствующие коррективы в конфигурацию docker-compose.

Реализация аутентификации

Модификация шаблона конфигурации nginx-proxy

В первую очередь добавляется новый upstream, который позволяет обращаться к сервису аутентификации в конфиге:

Видно, что сервис аутентификации работает на хосте $ и порту $ , по умолчанию 9000.
Значения переменных будут подставлены docker-gen так, что данная часть конфига будет выглядеть следующим образом в /etc/nginx/conf.d/default.conf внутри контейнера:

Следующее дополнение устанавливает переменную ext_ldap_auth , если в контейнере некоего сервиса была взведена переменная LDAP_EXT_AUTH .
Также, устанавливаются ещё несколько переменных для настройки аутентификации.

Основной блок дополнений приведён ниже. Он активируется, только если установлена переменная ext_ldap_auth .
Если ldap_use_login_page установлена, то будет включено перенаправление на страницу аутентификации, иначе будет использовано окно базовой аутентификации HTTP.

Путь /auth-proxy — это и есть перенаправление на сервис аутентификации.
Параметры будут переданы через заголовки HTTP.
Какие параметры и для чего нужны, вполне подробно описано в комментариях.

И последнее, когда LDAP аутентификация для сервиса включена, добавляется auth_request в его location:

Ниже приведён полный листинг шаблона.

Модификация конфигурации docker-compose

В docker-compose.yml были добавлены:

• Новый сервис «ldap-auth», который отвечает за авторизацию.
• Блок переменных, настраивающих взаимодействия с LDAP сервером.

То что записано в переменных, nginx передаст сервису аутентификации через HTTP заголовки.
Назначение параметров ясно из названий переменных, так что останавливаться я на них не буду.
Полный конфиг смотрите ниже.

Использование сервисом

Сквозная аутентификация по умолчанию выключена.
Для её включения достаточно установить в окружении нужного контейнера переменные:

• LDAP_EXT_AUTH=true — включение аутентификации.
• LDAP_EXT_ADD_GROUPS=(memberOf=cn=users_cloud,ou=groups,dc=nas,dc=nas) — необязательный фильтр, список групп, в которые обязательно должен входить пользователь, чтобы быть аутентифицированным. Таким образом обеспечивается поддержка авторизации.

Заключение

В целом, решение уже длительное время работает и обеспечивает не только аутентификацию, но и авторизацию.
Что позволяет использовать в NAS любые сервисы в контейнерах, независимо от того поддерживают ли они аутентификацию через LDAP.

Name already in use

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

PLEASE note that this project is not designed or hardened for production. It is intended as a model for such connector daemons

The nginx-ldap-auth project

This project provides a reference model implementation of a method for authenticating users on behalf of servers proxied by NGINX or NGINX Plus.

For ease of reading, this document refers to NGINX Plus, but it also applies to open source NGINX. The prerequisite ngx_http_auth_request_module module is included both in NGINX Plus packages and prebuilt open source NGINX binaries.

The nginx-ldap-auth software is a reference model implementation of a method for authenticating users who request protected resources from servers proxied by NGINX Plus. It includes a daemon (ldap-auth) that communicates with an authentication server, and a sample daemon that stands in for an actual back-end server during testing, by generating an authentication cookie based on the user’s credentials. The daemons are written in Python for use with a Lightweight Directory Access Protocol (LDAP) authentication server (OpenLDAP or Microsoft Windows Active Directory 2003 and 2012).

The ldap-auth daemon, which mediates between NGINX Plus and the LDAP server, is intended to serve as a model for «connector» daemons written in other languages, for different authentication systems, or both. NGINX, Inc. Professional Services is available to assist with such adaptations.

For a step-by-step description of the authentication process in the reference implementation, see How Authentication Works in the Reference Implementation in NGINX Plus and NGINX Can Authenticate Application Users.

Installation and Configuration

The NGINX Plus configuration file that is provided with the reference implementation configures all components other than the LDAP server (that is, NGINX Plus, the client, the ldap-auth daemon, and the back-end daemon) to run on the same host, which is adequate for testing purposes. The LDAP server can also run on that host during testing.

In an actual deployment, the back-end application and authentication server typically each run on a separate host, with NGINX Plus on a third host. The ldap-auth daemon does not consume many resources in most situations, so it can run on the NGINX Plus host or another host of your choice.

To install and configure the reference implementation, perform the following steps.

Create a clone of the GitHub repository (nginx-ldap-auth).

If NGINX Plus is not already running, install it according to the instructions for your operating system.

If an LDAP authentication server is not already running, install and configure one. By default the ldap-auth daemon communicates with OpenLDAP, but can be configured to work with Active Directory.

If you are using the LDAP server only to test the reference implementation, you can use the OpenLDAP server Docker image that is available on GitHub, or you can set up a server in a virtual environment using instructions such as How To Install and Configure a Basic LDAP Server on an Ubuntu 12.04 VPS.

On the host where the ldap-auth daemon is to run, install the following additional software. We recommend using the versions that are distributed with the operating system, instead of downloading the software from an open source repository.

• Python versions 2 and 3 are supported.
• The Python LDAP module, python-ldap (created by the python-ldap.org open source project).

Copy the following files from your repository clone to the indicated hosts:

nginx-ldap-auth.conf – NGINX Plus configuration file, which contains the minimal set of directives for testing the reference implementation. Install on the NGINX Plus host (in the /etc/nginx/conf.d directory if using the conventional configuration scheme). To avoid configuration conflicts, remember to move or rename any default configuration files installed with NGINX Plus.

nginx-ldap-auth-daemon.py – Python code for the ldap-auth daemon. Install on the host of your choice.

Alternatively, use provided Dockerfile to build Docker image:

If you desire to use a container with Python3, you can supply an appropriate build argument:

nginx-ldap-auth-daemon-ctl.sh – Sample shell script for starting and stopping the daemon. Install on the same host as the ldap-auth daemon.

backend-sample-app.py – Python code for the daemon that during testing stands in for a real back-end application server. Install on the host of your choice.

Modify the NGINX Plus configuration file as described in Required Modifications to the NGINX Plus Configuration File below. For information about customizing your deployment, see Customization below. We recommend running the nginx -t command after making your changes to verify that the file is syntactically valid.

Start NGINX Plus. If it is already running, run the following command to reload the configuration file:

Run the following commands to start the ldap-auth daemon and the back-end daemon.

To test the reference implementation, use a web browser to access http://nginx-server-address:8081. Verify that the browser presents a login form. After you fill out the form and submit it, verify that the server returns the expected response to valid credentials. The sample back-end daemon returns this:

Required Modifications to the NGINX Plus Configuration File

Modify the nginx-ldap-auth.conf file, by changing values as appropriate for your deployment for the terms shown in bold font in the following configuration.

For detailed instructions, see Configuring the Reference Implementation in the NGINX Plus and NGINX Can Authenticate Application Users blog post. The nginx-ldap-auth.conf file includes detailed instructions (in comments not shown here) for setting the proxy-set-header directives; for information about other directives, see the NGINX reference documentation.

If the authentication server runs Active Directory rather than OpenLDAP, uncomment the following directive as shown:

In addition, the X-Ldap-Template header can be used to create complex LDAP searches. The code in ldap-auth-daemon creates a search filter that is based on this template header. By default, template is empty, and does not make any effect on LDAP search. However, you may decide for instance to authenticate only users from a specific user group (see LDAP documentation for more information regarding filters).

Suppose, your web resource should only be available for users from group1 group. In such a case you can define X-Ldap-Template template as follows:

The search filters can be combined from less complex filters using boolean operations and can be rather complex.

The reference implementation uses cookie-based authentication. If you are using HTTP basic authentication instead, comment out the following directives, and enable the Authorization header as shown:

The nginx-ldap-auth.conf file enables caching of both data and credentials. To disable caching, comment out the four proxy_cache* directives as shown:

Optional LDAP Parameters

If you want to change the value for the template parameter that the ldap-auth daemon passes to the OpenLDAP server by default, uncomment the following directive as shown, and change the value:

If you want to change the realm name from the default value (Restricted), uncomment and change the following directive:

To modify the ldap-auth daemon to communicate with a different (non-LDAP) type of authentication server, write a new authentication-handler class to replace LDAPAuthHandler in the nginx-ldap-auth-daemon.py script.

The auth daemon was tested against default configurations of the following LDAP servers:

The back-end daemon uses Base64 encoding on the username and password in the cookie. Base64 is a very weak form of scrambling, rendering the credentials vulnerable to extraction and misuse. We strongly recommend using a more sophisticated algorithm in your actual back-end application.

The reference implementation is subject to the same 2-clause BSD license as the open source NGINX software.

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

22.03.2021
Ivan
Active Directory, DevOps, Docker, Linux, Ubuntu
комментариев 10

В данной статье мы рассмотрим, как настроить 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 и проверял переданную при авторизации связку логин и пароль.

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

• Логин:[email protected]
• Пароль: r05-2020
• Группа AD: Гости домена.

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

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

# sudo apt install ldap-utils

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

# ldapsearch -v -D «[email protected]» -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: [email protected]’ \
—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 <login>:<password> нужно передать креденшелы пользователя, которые нужно проверить в домене

Если передать неверные учетные данные, будет возвращена ошибка 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.

Предыдущая статья Следующая статья