Комментарии 19
Спасибо. Устойчиво работает? Credentials не теряются?
make install, сколько можно… На debian/ubuntu есть checkinstall.
Если не ошибаюсь на web сервере не обязательно ставить samba keytab можно сгенерить на домен контроллере и перенести его на web сервер, для дальнейшего использования.
Что будет если зайти на test.intranet.com c ПК который не в домене?
У вас написано:
location / {
proxy_pass
…
то ест nginx используется как frontend, почему про это ни слова? куда все проксируется, в какое web-приложение, оно ведь тоже должно быть настроено соответствующим образом?
Пробовали собрать модуль spnego-http-auth-nginx-module как динамический?
У вас написано:
location / {
proxy_pass
…
то ест nginx используется как frontend, почему про это ни слова? куда все проксируется, в какое web-приложение, оно ведь тоже должно быть настроено соответствующим образом?
Пробовали собрать модуль spnego-http-auth-nginx-module как динамический?
Как я и написал в статье, если не использовать параметр
то при попытке входа не с доменного ПК будет вылезать запрос basic auth, который примет доменную учетку.
А по поводу проксирования, конечно, nginx просто проксирует соеденение на web приложение, в моем случае CRM, приложение же конечно должно быть доработано разработчиками, дабы авторизовывать пользователя прозрачно. С nginx приходят специальные пакеты идентификации пользователя, наш программист их ловит в таком виде:
Собственно красивый вариант — внутри сети офиса на локальном DNS делаем запись внешнего ULR CRM с указанием на nginx, а на самом nginx делаем rewrite на локальный доменный URL, получится, что когда юзеры в офисе, они будут ходить прозрачно в приложение, когда не в офисе — по старинке, с запросом логина пароля.
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, получится, что когда юзеры в офисе, они будут ходить прозрачно в приложение, когда не в офисе — по старинке, с запросом логина пароля.
Рекомендую посмотреть haproxy также
Сделал, как описано. Админа контроллера домена nginx пускает корректно, а для простого пользователя выдается ошибка 500, в логе nginx пишется
Как исправить?
Kerberos error: Credentials failed, client: 127.0.0.1, server: myweb.mydomain.local, request: "GET / HTTP/1.1", host: "localhost:81"Как исправить?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб авторизация доменного пользователя через nginx и HTTP Negotiate