Как включить проверку подлинности Windows через обратный прокси-сервер?

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

Я работаю над приложением для перехвата и изменения HTTP-запросов и ответов между веб-браузером и веб-сервером (см. как перехватывать и изменять HTTP-ответы на стороне сервера? для фона). Я решил реализовать обратный прокси-сервер в ASP.Net который пересылает клиентские запросы на сервер HTTP, переводит ссылки и заголовки из ответа на правильно "проксированный" URL-адрес и отправляет ответ клиенту после извлечения соответствующей информации из ответа.

он работает так, как ожидалось, за исключением части аутентификации: веб-сервер использует аутентификацию NTLM по умолчанию, и просто пересылка запросов и ответов через обратный прокси-сервер не позволяет пользователю проходить аутентификацию в удаленном приложении. Как обратный прокси, так и веб-приложение находится на той же физической машине и выполняется на том же сервере IIS (Windows server 2008/IIS 7, Если это имеет значение). Я попытался включить и отключить аутентификацию в приложении обратного прокси-сервера без успеха.

Я искал информацию об этом, и, похоже, это связано с "проблемой двойного прыжка", которую я не понимаю. Мой вопрос: есть ли способ аутентификации пользователя в удаленном приложении через обратный прокси-сервер с помощью NTLM? Если есть нет, есть ли альтернативные методы аутентификации, которые я мог бы использовать?

даже если у вас нет решения моей проблемы, просто указав мне на соответствующую информацию об этом, чтобы помочь мне выйти из путаницы было бы здорово!

7
authentication iis ntlm reverse-proxy

4 ответов

Я нашел, в чем проблема (и это NTLM): для того, чтобы браузер запрашивал у пользователя его учетные данные, ответ должен иметь код состояния 401. Мой обратный прокси-сервер переадресовывал ответ в браузер, поэтому IIS добавлял стандартный HTML-код, чтобы объяснить, что запрошенная страница не может быть доступна, поэтому браузер не запрашивает учетные данные. Проблема была решена путем удаления содержимого ответа, когда код состояния 401.

С при всем моем уважении к тому, кто ответил, что несколько лет назад, я должен признать, что это явная ложь. Проблема была действительно решен после удаления содержимого ответа, когда код состояния 401, но он не имел никакого отношения к первоначальной проблеме.. Правда в том, что проверка подлинности windows была сделана для проверки подлинности людей в локальных сетях windows, где нет прокси-сервера или даже не требуется. Основная проблема с аутентификацией NTLM заключается в том, что этот протокол не аутентифицируйте сеанс HTTP, но базовое TCP-соединение, и, насколько я знаю, нет способа получить доступ к нему из кода asp. Каждый прокси-сервер, который я пробовал, нарушал аутентификацию NTLM. Аутентификация Windows удобна для пользователя, потому что ему никогда не нужно будет вводить пароль к любому приложению, которое может находиться в вашей интрасети, пугая парня безопасности, потому что есть автоматический вход без даже подсказки, если домен сайта доверяет IE, шокирующий для сетевого администратора потому что он плавит приложение, Транспорт и сетевой уровень в какой-то "шар кружки windows" вместо простого http-трафика.

9

NTLM не будет работать, если пакеты TCP не пересылаются точно так же, как обратный прокси-сервер получил > их. И именно поэтому многие обратные прокси не работают с аутентификацией NTLM. (например, nginx) > они пересылают HTTP-запросы корректно, но не TCP-пакеты.

Nginx имеет функциональность для работы с аутентификацией NTLM. Keepalive должен быть включен, который доступен только через http_upstream_module. Дополнительно в блоке location необходимо указать что вы будете использовать HTTP / 1.1 и что поле заголовка "соединение" должно быть очищено для каждого проксированного запроса. Конфигурация Nginx должна выглядеть примерно так:

upstream http_backend {
    server 1.1.1.1:80;

    keepalive 16;
}

server {
...

location / {
       proxy_pass http://http_backend/;
       proxy_http_version 1.1;
       proxy_set_header Connection "";
    ...
    }
 }

Я довольно долго чесал голову с этой проблемой, но выше работает для меня. Обратите внимание, что если вам нужно прокси-трафик HTTPS, отдельный восходящий блок считается необходимым. Чтобы уточнить немного больше, "keepalive 16;" указывает количество одновременных подключений к восходящему прокси-серверу. Отрегулируйте количество в соответствии с ожидаемым количеством одновременных посетителей на сайте.

6

хотя это старый пост, я просто хочу сообщить, что он работает для меня довольно хорошо с Apache2.2 обратный прокси-сервер и опция keepalive=on. Очевидно, что это сохраняет соединение между прокси-сервером и узлом SharePoint открытым и" прикрепленным " к клиентскомупрокси-соединению. Я не совсем знаю механизмы этого, но он работает довольно хорошо.

но: иногда мои пользователи сталкиваются с проблемой, что они вошли в систему как другой пользователь. Кажется, здесь какая-то путаница. через сеансы. Мне придется провести еще кое-какие испытания.

решение для всего (если у вас есть действительный, подписанный сертификат SSL): переключите IIS на базовую аутентификацию. Это работает абсолютно нормально, и даже Windows(т. е. Office с подключением SharePoint, все процессы на основе WebClient и т. д.) не будет жаловаться вообще. Но они будут, когда вы просто используете http без SSL / TLS, а также с самозаверяющими сертификатами.

4

Я подтверждаю, что он работает с "keep-alive=on" на apache2.2

Я проверил кадры с wireshark, и я знаю, почему это не работает. NTLM не будет работать, если пакеты TCP не пересылаются точно так же, как обратный прокси-сервер получил их. И именно поэтому многие обратные прокси не работают с аутентификацией NTLM. (такой как nginx) Они пересылают HTTP-запросы корректно, но не TCP-пакеты.

для NTLM требуется обратный прокси TCP.

3