Мы используем собственный модуль HTTP в IIS в качестве обратного прокси-сервера для веб-приложений. Как правило, это работает хорошо и уже в течение некоторого времени, но мы столкнулись с проблемой аутентификации Windows (WA). Мы используем IE 11, IIS 10 и Server 2016.
При прямом доступе к целевому сайту WA работает нормально - мы получаем диалоговое окно входа в браузер при запросе начальной страницы HTML и последующей запросы (CSS, JS, et c) go через штраф.
При доступе через наш прокси-сервер то же самое (правильное поведение) происходит на начальной странице html, первой Запрос CSS / JS тоже аутентифицируется, но последующие вызывают появление логина в браузере.
Что, похоже, происходит при «плохих» запросах (то есть тех, которые вызывают диалог входа в систему) is:
1) Браузер решает, что ему необходимо пройти аутентификацию, поэтому отправляет заголовок авторизации (согласование, с маркером NTLM)
2) Сервер отвечает (401) с помощью WWW-Authenticate: согласование ответ с полным токеном NTLM
3) Браузер повторно запрашивает заголовок авторизации (согласование с полным токеном NTLM)
4) Сервер отвечает (401) с WWW-Authenticate: Согласовать (без токена), что вызывает браузер чтобы отобразить диалоговое окно входа в систему
5) После ввода учетных данных для входа браузер отправляет тот же запрос, что и в (1) - идентичный токен NTLM, сервер отвечает, как в (2), повторные запросы браузера как в (3) , но на этот раз это работает!
Мы создали тестовый веб-сайт с одной html страницей, запрашивая 3 JS и 2 CSS файлов для репликации этого. На нашем тестовом сервере у нас есть два сайта, один из которых использует наш обратный прокси-сервер, а другой - ARR. Сайт ARR работает нормально. Кроме того, поскольку вышеприведенный шаг (5) работает, мы считаем, что сквозной прокси-сервер работает в основном, то есть токены NTLM не портятся из-за хитрого кодирования, и т. Д. c.
Одна вещь, которая работает является то, что если мы используем Fiddler и ставим точки останова для каждого запроса, мы можем удерживать 5 подзапросов (JS & CSS файлов), пропуская по одному go за раз. Если мы разрешим каждую последовательность (т. Е. Обмен токенов NTLM для каждого URL / файла, до ответа 200), то это сработает. Это заставило нас думать, что в нашем прокси есть некоторый промежуточный эффект (например, повреждение общей памяти), это все еще возможно.
Итак, мы помещаем код в начало BeginRequest и конец EndRequest с помощью Синхронизация и общая переменная для хранения пути (AppRelativeCurrentExecutionFilePath). Это было для нашего кода, чтобы 'Единственная Поток' каждый из этих запросов / обменов. Это делает то, что мы ожидали, т. Е. Разрешается только один обмен аутентификацией и получается 200, прежде чем разрешить следующий. Тем не менее, у нас все еще остается та же проблема, когда сервер отклоняет первый обмен. Итак, означает ли это, что что-то происходит в / перед BeginRequest, где, если мы удерживаем запросы обратно в Fiddler, они работают, но не если мы делаем это в нашем модуле http?
Или есть какая-то проблема синхронизации где ручные контрольные точки в Fiddler также означают, что мы делаем это на «человеческой» скорости и поэтому позволяем вещам работать лучше?
Одно из различий, которое мы видим, это «Связь: Keep-Alive». Этот заголовок находится в запросе от браузера к нашему прокси-сайту, но не передается с нашего прокси на базовый сайт, но сайт ARR действительно проходит через ... Все это использует HTTP 1.1. и поэтому мы не можем найти способ установить Keep-Alive на наш исходящий запрос - может ли это быть так?
Что касается «попробовать», мы считаем, что мы исключили такие вещи, как наличие сайта в Введите anet Зону для IE, чтобы сайт ARR работал нормально и имел те же настройки IE для этого сайта. Ясно, что что-то не так, поэтому мы могли бы что-то здесь упустить!
Короче говоря, мы работали над этим в течение нескольких дней и перепробовали большую часть того, что мы можем найти на SO и в других местах, но можем Не понимаю, что, черт возьми, происходит.
Любые предложения - дайте мне знать, если вам нужна дополнительная информация. Вся помощь будет с благодарностью получена!