У меня есть сайт ASP.Net, размещенный в IIS 10 на Windows Server 2019 DataCenter в Azure. На этом сайте включена только проверка подлинности Windows.
Когда я захожу на сайт напрямую (http://mysite-backend.example.com) Мне предлагают ввести учетные данные, после чего все работает как и ожидалось. Когда я захожу на сайт через App Gateway (настроенный с частным IP) (https://mysite.example.com) Мне предлагают ввести учетные данные, после чего мне снова предлагают запросить дополнительные ресурсы (размещенные на том же сайте, без специальных правил для подпапок). Мне предлагают повторно, пока я не нажимаю «Отмена», после чего я вижу 401 для запроса ресурса в сетевом журнале Chrome.
Один из ресурсов, с которым у меня возникает эта проблема, — это запрос GET для favicon.png. Если я обращаюсь к ресурсу напрямую (https://mysite.example.com/favicon.png) все работает, но когда я захожу на страницу сайта, вызывая запрос на этот ресурс, отправляемый браузером как часть ресурсов страницы, я вижу ошибку. Это подразумевает, что ресурс доступен; но что-то в том, как он обрабатывается в рамках "транзакции", вызывает проблемы.
Я пробовал с разными браузерами, включая новую установку / с другого клиентского устройства, чтобы убедиться, что нет ничего кэшированного, вызывающего проблемы. Кроме того, я проверил Disable Cacheнастройки сети F12, чтобы убедиться, что я делаю полные запросы / честные сравнения между двумя сайтами.
В бэкенд-пуле только 1 узел. Настройки бэкенда говорят использовать имя хоста бэкенд-пула вместо имени фронтенда, поэтому с точки зрения веб-сервера запросы выглядят одинаково.
В журнале событий безопасности веб-сервера я вижу неудачные попытки входа (идентификатор события 4625) с моим тестовым именем пользователя; подтверждая, что запрос поступает на внутренний сервер с правильным именем пользователя (и я был очень осторожен, чтобы убедиться, что я постоянно ввожу правильный пароль / делал это много раз, чтобы исключить вероятность человеческой ошибки / пробовал как использовать, так и перезаписывать сохраненный пароль). Если я пытаюсь слишком много раз, моя тестовая учетная запись блокируется (т. е. в AD атрибут lockedoutустанавливается на true); после чего все запросы получают ответы 401 (что понятно).
Я проверил журналы App Gateway, чтобы убедиться, что он ничего не блокирует. Я также установил пользовательское правило WAF для этого сайта и установил его в detection onlyрежим, гарантирующий, что он не сможет блокировать запросы; на всякий случай, если что-то блокировалось, но не регистрировалось.
Я включил трассировку неудачных запросов для статуса 401 на внутреннем сервере; это показывает, что 401 приходит от:
-MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName: IIS Web Core
Notification: AUTHENTICATE_REQUEST
HttpStatus: 401
HttpReason: Unauthorized
HttpSubStatus: 2
ErrorCode: Access is denied. (0x80070005)
ConfigExceptionInfo
Примечание: Ресурсы, которые блокируются (т. е. получают ответы 401), обычно совпадают, когда я тестирую на одном и том же устройстве в течение определенного периода времени; но если я тестирую в другой день или на другом устройстве, я могу увидеть, что другие ресурсы блокируются. В первый раз, когда я тестирую на любом устройстве (в основном), я вижу, что два POSTзапроса xhr к /subfolder###/Searchстраницам терпят неудачу, затем после нескольких тестов на этом устройстве другие ресурсы, похоже, становятся испорченными. Кажется, что они являются основной причиной, но затем что-то вызывает проблему с сеансом.
Я пытаюсь получить доступ к исходному коду бэкэнд-сайта, чтобы лучше понять, что закодировано в этих конечных точках поиска, и выяснить, может ли это быть причиной проблемы.
В то же время любые идеи, которые могут возникнуть у кого-либо здесь, будут очень признательны... Заранее спасибо.
Обновление: прямой вызов конечной точки поиска также приводит к ответу HTTP 200 / допустимому:
$resp = Invoke-RestMethod -Method Post -Uri 'https://mySite.example.com/subfolder###/Search' -Form @{recordsToTake=25;recordsToSkip=0;sortColumn='CategorieName';sortDirection='Ascending'} -Credential $cred -StatusCodeVariable sc;"Status $sc";$resp
решение1
NTLM («Аутентификация Windows») не поддерживается App Gateway (Документы MS).
Похоже, что обратные прокси-серверы обычно не поддерживают NTLM из-за проблем безопасности (Обсуждение MS YARP NTML).
Существуют некоторые альтернативные обратные прокси-серверы, которые могут справиться с этой задачей, например:nginx плюс(коммерческое предложение nginx).