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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Nginx обладает функциональностью для работы с аутентификацией NTLM. Keepalive должен быть включен, который доступен только через http_upstream_module. Кроме того, в блоке местоположения необходимо указать, что вы будете использовать 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;" указывает количество одновременных подключений к восходящему каналу, которому ваш прокси разрешено хранить. Отрегулируйте количество согласно ожидаемому количеству одновременных посетителей на сайте.

Answer 3

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

Но: иногда мои пользователи сталкиваются с проблемой, что они вошли в систему как другой пользователь. Таким образом, похоже, что некоторые сессии путаются. Я должен буду провести это дополнительное тестирование.

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

Answer 4

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

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

NTLM требует обратного прокси-сервера TCP.