Computerprogeek
У цій статті ми розглянемо, як налаштувати базову автентифікацію в Nginx через Ldap каталог. Як сервер LDAP ми будемо використовувати Windows Active Directory. Оскільки NGINX не має офіційного модуля авторизації в побудованому шляху через LDAP (на відміну від Apache або Tomcat), розробники пропонують використовувати третю службу Nginx-ldap-auth, який звернеться до LDAP і виконає своєрідний проксі між NGINX та сервером каталогів LDAP LDAP. По -перше, давайте почнемо послугу і подивимось, як вона працює.
Зміст:
- Встановлення та запуск служби аутентифікації NGINX-LDAP-AUTH
- Конфігурація контейнера Nginx для Active Directory (LDAP)
- Ми перевіряємо автентифікацію користувача доменного оголошення користувача в NGINX
Встановлення та запуск служби аутентифікації NGINX-LDAP-AUTH
Щоб запустити послугу Nginx-ldap-auth, ми будемо використовувати Docker. Спочатку вам потрібно клонувати сховище за допомогою послуги з Github:
# Sudo git клон https: // github.Com/nginxinc/nginx-ldap-auth
# CD NGINX-LDAP-AUTH
Якщо у вас немає утиліт Git, ви можете просто завантажити архів з джерелом і розпакувати його в каталог Nginx-ldap-auth.
Каталог вже готовий -Made DockerFile. Щоб зібрати контейнер, вам потрібно виконати:
# Sudo docker build -t nginx-ldap-auth-daemon .
Висновок під час складання буде таким:
Надсилання контексту збірки Docker Daemon 208.9 кб Крок 1/7: arg python_version = 2 Крок 2/7: Від Python: $ python_version -alpine ---> 8579e446340f Крок 3/7: Скопіюйте Nginx-ldap-auth-daemon.Py/usr/src/app/---> Використання кешу ---> a0b2c58fd4af Крок 4/7: Workdir/usr/src/app/---> Використання кеш- —Но-кеш admenldap-dev && apk-no-cache add-virtual build-endences base та pip install python-ldap && apk deld-depenenences ---> Використання кешу ---> Страх 6/7: Експозиція 8888 ---> Використання кеш-.Py "," -host "," 0.0.0.0 "," -Sort "," 8888 "] ---> Використовуючи кеш ---> 3EB60DDA0847 Успішно побудований 3EB60DDA0847 SuccessFollly Tagged NINX-LDAP-Auth-Daemon: Latet:
Зображення Docker готове, ви можете запустити контейнер. Для цього виконайте команду:
# Sudo Docker Run -P 8888: 8888-Назва ldap-auth nginx-ldap-auth-daemon
Висновок цієї команди буде таким:
Почніть слухати на 0.0.0.0: 8888 ..
Ця команда запустить контейнер із зображення Nginx-ldap-auth-daemon, З назвою контейнера Ldap-auth і киньте порт 8888 з контейнера до хоста -автомобіля. Для перевірки роботи та налагодження автентифікації в Active Director. В майбутньому цей параметр можна виключити. Крім того, для налагодження ми не додали ключ -D, який запустить контейнер і розв'язав його з консолі, але тоді журнал роботи, який був корисним під час налагодження, не був видно.
Давайте тепер розберемося, як працює послуга Nginx-ldap-auth. Цей демон - це невелика веб -сервіс, до якої ви можете надіслати HTTP -запит методом GET з певними заголовками, він, у свою чергу, звернеться до Active Directory та перевірить дані авторизації. Якщо вони правдиві, він відповість на код HTTP 200 ОК, якщо ні, то поверне 401 код (не уповноважений).
Для перевірки вам потрібен налаштований Active Directory або Server OpenDAP. Ця стаття розгляне контролер домену на Windows Server 2008 R2, але Readme сховища демонів також підтримувався іншими серверами LDAP.
- Доменне ім'я: Корпус.до.Високий
- Контролер домену IP: 192.168.0.шістнадцять
Давайте створимо гостя з користувачем. Давайте назвемо це ldap_reader. Цей користувач потрібен таким чином, щоб від його імені демон звертався до оголошення та перевіряти перенесений вхід та пароль при уповноваженні.
Дані користувача такі
- Вхід: ldap_reader@corp.до.Високий
- Пароль: R05-2020
- Група оголошень: Гості домену.
Заборонити користувачеві змінити пароль і встановлювати необмежений період дійсності пароля (ніколи не закінчується), оскільки це послуга.
Для тестування ви можете завантажити утиліту для LDAP, наприклад Ldapsearch.
Він встановлений командою:
# Sudo apt встановити ldap-utils
Щоб перевірити наявність контролера домену та правильного налаштування користувача, ви можете виконати команду:
# ldapsearch -v -d "ldap_reader@corp.до.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 Search Base - AD контейнера (OU), в якому потрібно шукати користувача (ви можете звузити область пошуку, щоб швидше отримати відповідь),
- -Ч Адреса сервера LDAP;
- Потім вказано Фільтр LDAP, на якому потрібно шукати.
Висновок для нашого домену буде таким:
ldap_initialize (ldap: // 192.168.0.16: 389/??база) фільтр: (samaccountname = ldap_reader) Запит: Усі атрибути Application # Розширений LDIF # # ldapv3 # база з піддереженням області # фільтр: (samaccountname = ldap_reader) # запит: усі # # ldap_reader, користувачі, corp corp.до.High DN: CN = LDAP_READER, CN = Користувачі, DC = Corp, DC = to, DC = High ObjectClass: Top ObjectClass: Person ObjectClass: OrganisationPerson ComboitClass: Користувач CN: LDAP_READER ДЕНЬНА: LDAP_READER ENSIGRANGEADYNAME: CN = LDAP_READER, CN = Користувачі, kinsiors,, cn = ldap_reader, cn = користувачі,, cn -user Dc = corp, dc = to, dc = високий екземпляр: 4 при оцінці: 20210308212600.0Z, коли змінився: 20210308212700.0Z DisplayName: LDAP_READER ... # Довідка про пошук: ldap: // forestnszones.Корпус.до.High/DC = Forestdnszones, DC = CORP, DC = to, DC = Висока # Довідка пошуку: ldap: // domainnszones.Корпус.до.High/DC = Domaindnszones, DC = Corp, DC = to, DC = Висока # Довідка пошуку: ldap: // corp.до.High/CN = Конфігурація, DC = Corp, DC = to, DC = Високий # пошук пошуку: 2 Результат: 0 Успіх # NumRespons: 5 # Numentries: 1 # numrefeences: 3
Цей журнал показує, що користувач знайдений, а користувач LDAP_READER має доступ до читання доменного дерева. Тепер ми перевіримо роботу демона авторизації. Для цього ми завершимо команду в консолі:
# Curl -Локса -Request get 'http: // localhost: 8888' \
--Заголовок 'x-ldap-url: ldap: // 192.168.0.Шістнадцять '\
--Заголовок 'x-LDAP на основі: cn = користувачі, dc = corp, dc = to, dc = high' \
--Заголовок 'x-ldap-binddn: ldap_reader@corp.до.Високий '\
--Заголовок 'x-ldap-bindpass: r05-2020' \
--Заголовок 'x-ldap-template: (samaccountname =%(ім'я користувача) s)' -vv -u ldap_reader: r05-2020
Висновок буде таким:
Примітка: непотрібне використання -x або -request, отримувати вже висновки. * Перебудована URL -адреса: http: // localhost: 8888/ * спроба 127.0.0.1 ... * tcp_nodelay set * підключений до localhost (127.0.0.1) Порт 8888 (#0) * Сервер Auth з використанням базового з користувачем 'ldap_reader'> get / http / 1.1> хост: localhost: 8888> Авторизація: Основний bgrhcf9yzwfkzi6cja1ltiwmja => user-agent: curl/7.58.0> Прийняти: */ *> x-ldap-url: ldap: // 192.168.0.16> x-ldap-basdn: cn = користувачі, dc = corp, dc = to, dc = high> x-ldap-bindndn: ldap_reader@corp.до.Високий> x-ldap-bindpass: r05-2020> x-ldap-template: (samaccountname =%(ім'я користувача) s)> * http 1.0, припустимо близько за тілом < HTTP/1.0 200 OK < Server: BaseHTTP/0.3 Python/2.7.18 < Date: Sun, 14 Mar 2021 19:07:48 GMT < * Closing connection 0
Заголовки, що використовуються у запиті:
- X-ldap-url - Адреса сервера LDAP така ж, як при тестуванні за допомогою утиліти Ldapsearch;
- X-ldap-basdn - Початковий DN для пошуку;
- X-ldap-binddn - Облікуйте права на читання доменного дерева.
- X-ldap-bindpass - Пароль користувача для доступу до AD;
- X-ldap-template - У цьому заголовку фільтр LDAP передається пошуком. У заголовку можна поєднувати різні фільтри. Більш детальну інформацію можна побачити в документації для демона Nginx-ldap-auth.
- Опція -u: Потрібно передати позики користувача, які потрібно перевірити в домені
Якщо ви передаєте неправильні дані про бухгалтерський облік, помилка 401 буде повернута (не уповноважена). Спробуємо пройти неправильний пароль, висновок буде таким:
* Перебудована URL -адреса: http: // localhost: 8888/ * спроба 127.0.0.1 ... * tcp_nodelay set * підключений до localhost (127.0.0.1) Порт 8888 (#0) * Сервер Auth з використанням базового з користувачем 'ldap_reader'> get / http / 1.1> хост: localhost: 8888> Авторизація: Основний bgrhcf9yzwfkzi6cja1ltiwmjax> user-agent: curl/7.58.0> Прийняти: */ *> x-ldap-url: ldap: // 192.168.0.16> x-ldap-basdn: cn = користувачі, dc = corp, dc = to, dc = high> x-ldap-bindndn: ldap_reader@corp.до.Високий> x-ldap-bindpass: r05-2020> x-ldap-template: (samaccountname =%(ім'я користувача) s)> * http 1.0, припустимо близько за тілом < HTTP/1.0 401 Unauthorized < Server: BaseHTTP/0.3 Python/2.7.18 < Date: Sun, 14 Mar 2021 19:16:40 GMT * Authentication problem. Ignoring this. < WWW-Authenticate: Basic realm="Restricted" < Cache-Control: no-cache < * Closing connection 0
Ви також можете побачити висновок у журналах демона:
172.17.0.1 - [14/березня/2021 19:17:45] Використання імені користувача/пароля із заголовка авторизації 172.17.0.1 - LDAP_READER [14/MAR/2021 19:17:45] Пошук на сервері "Ldap: // 192.168.0.16 "з базовим DN" CN = користувачі, DC = Corp, DC = to, DC = High "з фільтром" (SamaccountName = LDAP_READER) "172.17.0.1 - LDAP_READER [14/MAR/2021 19:17:45] Намагання зв’язати за допомогою DN "CN = LDAP_READER, CN = Користувачі, DC = Corp, DC = to, DC = HIIH" 172.17.0.1 - LDAP_READER [14/MAR/2021 19:17:45] Помилка під час прив’язки як існуючого користувача "CN = LDAP_READER, CN = Користувачі, DC = Corp, DC = to, DC = HIIH": 'info': u '80090308: Ldaperr: DSID-0C0903AA, Коментар: Приймається помилка SecurityContext, Data 52e, V1772', 'msgid': 3, 'msgtype': 97, 'результат': 49, 'desc': u'invalid Redientials, '' ': [], server = "ldap: // 192.168.0.16 ", login =" ldap_reader "172.17.0.1 - LDAP_READER [14/MAR/2021 19:17:46] "GET/HTTP/1.1 "401 -
Конфігурація контейнера Nginx для Active Directory (LDAP)
Ми перевірили роботу офісного демона NGINX-LDAP-AUTH, тепер ви можете перейти до налаштування NGINX. У цій статті я покажу, як налаштувати авторизацію для реєстру Docker за допомогою облікового запису Active Directory. Nginx з’явиться в контейнер Docker. Створити dockerfile:
Від nginx скопіювати nginx-ldap-auth.Conf/etc/nginx/confr.D/NGINX-LDAP-AUTH.Конфігурація
У каталозі DockerFile Створіть файл конфігурації Nginx-ldap-auth.Конфігурація.
Вміст файлу:
proxy_cache_path кеш/ keys_zone = auth_cache: 10m; Вгору за течією Реєстр сервера: 5000; Сервер Слухати 8081; # Захищене розташування програми / auth_request / auth-proxy; Proxy_pass http: // backend/; location = /auth-proxy внутрішній; proxy_cache auth_cache; proxy_cache_valid 200 10 м; # Наступна директива додає файл cookie до кешу proxy_cache_key "$ http_authorization $ cookie_nginxaut"; proxy_pass_request_body off; Proxy_set_header-довжина вмісту "" ""; Proxy_pass http: // ldap-round: 8888; # URL-адреса та порт для підключення до сервера LDAP Proxy_set_header X-LDAP-URL "LDAP: // 192.168.0.16 "; # база dn proxy_set_header x-ldap-basdn" cn = користувачі, dc = corp, dc = to, dc = hig.до.Високий "; # прив’язати пароль proxy_set_header x-ldap-bindpass" r05-2020 "; proxy_set_header x-ldap-templenatnam (samaccountname =%(ім'я користувача) s)";
Ця конфігурація вказує на розташування з опцією auth_request, що дозволяє надсилати запит HTTP для перевірки авторизації. Ми вказали внутрішню адресу /автор-проксі, до якої буде перенаправлений запит на авторизацію. У цьому місці вказується параметри, які налаштовують параметри кешування та заголовків, які будуть надіслані в Nginx-ldap-auth.
- Proxy_pass_request_body - забороняє передачу полів заголовка початкового запиту на близький сервер;
- Proxy_set_header - Встановлює заголовок Вміст;
- proxy_cache_valid 200 10 м - кешування відповіді з кодом 200 протягом 10 хвилин (для того, щоб не надсилати запит на сервер авторизації на кожній ручці);
- proxy_cache_path - шлях та інші параметри кешу;
- proxy_cache_key - кешування кеша;
- Proxy_pass - Позначає контейнер демона авторизації Nginx-ldap-auth. Решта варіантів схожі на те, що вони використовувались для перевірки демона. Файл Configa та DockerFile можна взяти на сховищі Github.
Після створення конфігурації потрібно зібрати контейнер:
# Sudo docker build . -T nginx-ldap
Запустіть контейнер з Nginx з висновком консолі:
# Sudo Docker Run -P: 8081: 8081-Лінк LDAP-AUTH-Лінк Реєстр-Назва NGINX-LDAP NGINX-LDAP
- Запустіть nginx-ldap зображення з іменем -Назва nginx-ldap;
- -Зв'язок - Параметр дозволяє зав’язати контейнери в одну мережу, оскільки ми звертаємось до них за іменами в конфігурації Nginx. Без цих варіантів реєстр імен та LDAP-AUTH не будуть вирішені з контейнера NGINX;
- -P: 8081: 8081 - Ми кидаємо порт назовні.
Висновок команди буде таким:
/Docker-entrypoint.Sh: /docker-entrypoint.D / не порожній, спробує виконати конфігурацію / docker-entrypoint.SH: Шукаю сценарії оболонки в /docker-entrypoint.D / / docker -entrypoint.SH: Запуск /Docker-entrypoint.D/10-Listen-on-ipv6-by-default.Sh 10-Listen-on-ipv6-by-default.SH: Інформація: отримання контрольної суми/etc/nginx/conf.D/за замовчуванням.Конф 10-лист-он-на-ipv6-by-default.SH: Інформація: Увімкнено прослуховувати на ipv6 in/etc/nginx/contront.D/за замовчуванням.Conf /docker-entrypoint.SH: Запуск /Docker-entrypoint.D/20-ONVSUBST-ON-TEMPLATES.Sh /docker-entrypoint.SH: Конфігурація завершена; Готовий до запуску
Ми перевіряємо аутентифікацію користувача доменного оголошення користувача в NGINX
Тепер відкрийте браузер і перейдіть на адресу: http: // localhost: 8081/v2/_catalog. Після успішного дозволу NGINX повинен перенаправити приватне сховище Докера, описаний у статті про реєстр Докера.
У журналах веб -сервера лінія привабливості до /v2/_catalog. Т.до. Поточний користувач не уповноважений, сервер повернув код коду відповіді 401 і пропонує ввійти. Після успішного дозволу код відповіді повинен повернутися 200.
172.17.0.1 - - [21/березня/2021: 19: 19: 09 +0000] "get/v2/_catalog http/1.1 "401 179"-"" Mozilla/5.0 (x11; ubuntu; linux x86_64; rv: 82.0) Gecko/20100101 Firefox/82.0 ""-"172.17.0.1 - ldap_reader [21/mar/2021: 19: 19: 20 +0000] "get/v2/_catalog http/1.1 "200 20"-"" Mozilla/5.0 (x11; ubuntu; linux x86_64; rv: 82.0) Gecko/20100101 Firefox/82.0 ""-"
Введіть вхід та пароль користувача домену. Для тесту ви можете використовувати користувача служби, який був створений для пошуку домену деревини.
Після успішного авторизації слід відкрити сторінку зі списком зображень у сховищі Докера.
У моєму сховищі, на даний момент одне зображення, створене у статті про створення простої мікросервісу в Docker.
У журналах служби служби, що звертається до сервера LDAP, ви можете побачити наступне:
172.17.0.4 - [21/березня/2021 19:18:18] Використання імені користувача/пароля із заголовка авторизації 172.17.0.4 - LDAP_READER [21/MAR/2021 19:18:18] Пошук на сервері "Ldap: // 192.168.0.16 "з базовим DN" CN = користувачі, DC = Corp, DC = to, DC = High "з фільтром" (SamaccountName = LDAP_READER) "172.17.0.4 - LDAP_READER [21/MAR/2021 19:18:18] Спроба зв’язати за допомогою DN "CN = LDAP_READER, CN = користувачі, DC = Corp, DC = to, DC = HIIH" 172.17.0.4 - LDAP_READER [21/MAR/2021 19:18:18] Auth OK для користувача "LDAP_READER" 172.17.0.4 - LDAP_READER [21/MAR/2021 19:18:18] "Get/Auth -Proxy HTTP/1.0 "200
Журнал показує, що було зроблено підключення до сервера LDAP, облікові записи користувачів були уповноважені та перевірені.
Після перевірки ви можете зупинити контейнери та почати знову на задньому плані:
Ми видаляємо контейнери:
# Sudo docker rm ldap-auth
# Sudo docker rm nginx-ldap
Тепер ви можете запустити на задньому плані Nginx та nginx-ldap-auth. Ми також видалили прохід портів назовні у контейнері авторизації, це більше не потрібно.
# Sudo docker run -d-ім'я ldap-auth nginx-ldap-auth-daemon
# Sudo docker run -p: 8081: 8081 -d-link ldap-auth-link Registr
У цій статті ми вивчили загальний принцип налаштування авторизації за допомогою облікових даних LDAP в Nginx. Заключний бекенд може не обов'язково діяти Реєстр Docker, Таким чином, ви можете налаштувати автентифікацію в Active Directory у будь -якому з ваших додатків, опублікованих через Nginx.
