Веб авторизация доменного пользователя через nginx и HTTP Negotiate

[kolu4iy]

Спасибо. Устойчиво работает? Credentials не теряются?

[AbyssMoon]

В данный момент в процессе тестирования, в боевой режим для всех еще не внедрено, пока проблем не было.

[kolu4iy]

У меня (был момент) схема обновление KVNO не отрабатывала, например. А KVNO раз в неделю увеличивается принудительно. Потому, если не сложно, оставьте попозже более подробный отчёт — как оно там, если без нас…

[grossws]

make install, сколько можно… На debian/ubuntu есть checkinstall.

[AbyssMoon]

Привычка сильная штука, но спасибо за заметку.

[symbix]

В вашем случае можно было бы просто вручную заменить /usr/sbin/nginx.

А если уж совсем по-хорошему — лучше собрать свой пакет, ничего сложного в этом нет.

[brestows]

Если не ошибаюсь на web сервере не обязательно ставить samba keytab можно сгенерить на домен контроллере и перенести его на web сервер, для дальнейшего использования.

[AbyssMoon]

Все верно, в моем случае контроллер домена и веб сервер это одна машина.

[Sleuthhound]

Что будет если зайти на test.intranet.com c ПК который не в домене?

У вас написано:
location / {
proxy_pass
…

то ест nginx используется как frontend, почему про это ни слова? куда все проксируется, в какое web-приложение, оно ведь тоже должно быть настроено соответствующим образом?

Пробовали собрать модуль spnego-http-auth-nginx-module как динамический?

[AbyssMoon]

Как я и написал в статье, если не использовать параметр

auth_gss_allow_basic_fallback off;

то при попытке входа не с доменного ПК будет вылезать запрос basic auth, который примет доменную учетку.

А по поводу проксирования, конечно, nginx просто проксирует соеденение на web приложение, в моем случае CRM, приложение же конечно должно быть доработано разработчиками, дабы авторизовывать пользователя прозрачно. С nginx приходят специальные пакеты идентификации пользователя, наш программист их ловит в таком виде:

[PHP_AUTH_USER] => Administrator [PHP_AUTH_PW] => bogus_auth_gss_passwd

Собственно красивый вариант — внутри сети офиса на локальном DNS делаем запись внешнего ULR CRM с указанием на nginx, а на самом nginx делаем rewrite на локальный доменный URL, получится, что когда юзеры в офисе, они будут ходить прозрачно в приложение, когда не в офисе — по старинке, с запросом логина пароля.

[Sleuthhound]

А какую CRM используете? Там из коробки есть прозрачная авторизация или Вы допиливали?

[AbyssMoon]

Самописную, соответственно допилили…

[Balek]

Поясните, пожалуйста, а что будет не так, если auth_gss включить для внешнего сайта?

[AbyssMoon]

Если сайт не входит в домен, то работать по-идее нет будет, во всяком случае так пишут на гитхабе.

[Balek]

Не совсем понял. Если AD домен — example.loc, то аутентификация будет работать только на crm.example.loc, а на crm.example.com не будет?

[AbyssMoon]

Все верно.

[Botkin]

Рекомендую посмотреть haproxy также

[DarkGenius]

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

Kerberos error: Credentials failed, client: 127.0.0.1, server: myweb.mydomain.local, request: "GET / HTTP/1.1", host: "localhost:81"

Как исправить?

[DarkGenius]

Оказалось, это моя ошибка — пользователь просто не был в домене.