Я знаю, что есть тысячи сообщений о людях, испытывающих затруднения при использовании встроенной аутентификации Windows для работы с IIS, но все они, похоже, приводят к веб-страницам, которые не применяются, или решениям, которые я уже пробовал. Ранее я развернул десятки таких сайтов, поэтому либо с сервером / конфигурацией происходит что-то странное, либо я слишком долго смотрел на это и не видел очевидного.
Проще говоря, все отлично работает на моей локальной машине, но разваливается на рабочем сервере, который, насколько я могу судить, имеет точно такую же конфигурацию .
На локальной машине:
- Машина работает под управлением Windows 7 Ultimate, Service Pack 1, IIS 7.5.
- Сайт был успешно протестирован с использованием IIS и сервера веб-разработки VS.
- В конфигурации сайта IIS отключены все методы проверки подлинности, кроме проверки подлинности Windows.
- Локальная машина не находится ни в одном домене.
- Поставщики настроены: согласование и NTLM (не согласование: Kerberos).
- Расширенная защита отключена.
- Все протестированные браузеры (IE, Firefox, Chrome) показывают запрос вызова и позволяют мне входить в домен localhost с моей (локальной) учетной записью Windows.
- Все протестированные браузеры также работают с использованием непрозрачного локального IP-адреса, поэтому сами браузеры, похоже, не заботятся о том, является ли сайт «локальным» или «удаленным».
- Я добавил строку отображения на веб-страницу, которая показывает пользователя, вошедшего в систему в данный момент, и показывает, что именно я ожидал (с каким локальным пользователем я вошел в систему).
На удаленной машине:
- Сервер работает под управлением Windows Server 2008 R2, IIS 7.5.
- Загрузка веб-страницы приводит к немедленной ошибке 401.2: вы не авторизованы для просмотра этой страницы из-за неверных заголовков аутентификации. Никакой подсказки никогда не появляется.
- В конфигурации сайта IIS отключены все методы проверки подлинности, кроме проверки подлинности Windows.
- Удаленная машина не находится ни в одном домене.
- Поставщики настроены: согласование и NTLM (не согласование: Kerberos).
- Расширенная защита отключена.
- На удаленном компьютере (сеанс удаленного рабочего стола) такая же ошибка появляется в Internet Explorer независимо от того, является ли домен локальным или внешним IP-адресом.
- Если я пытаюсь просмотреть удаленный веб-сайт с моего локального компьютера, ошибка все равно 401, но немного отличается от 401. Никакого субкода с текстом: Доступ запрещен из-за неверных учетных данных.
- Проверка подлинности Windows функция роли IIS будет установлена.
- WindowsAuthentication модуль будет добавлен (на уровне сервера).
- Точно такая же ошибка возникает, если я отключаю проверку подлинности Windows и включаю обычную проверку подлинности.
- Сайт действительно загружается, если я отключаю аутентификацию Windows и включаю анонимный доступ (очевидно).
- Я уже выполнил все шаги по устранению неполадок поддержки Microsoft: Устранение ошибок HTTP 401 в IIS
- Я уже попробовал обходной путь, показанный на другой странице поддержки Microsoft (предположительно, чтобы заставить NTLM использовать как единственный метод).
И последнее, но не менее важное: я попытался включить FREB для ошибок 401.2, и результаты, похоже, не говорят мне ничего полезного, все, что я вижу, это следующее предупреждение:
MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName IIS Web Core
Уведомление 2
HttpStatus 401
HttpReason Несанкционированный
HttpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Уведомление AUTHENTICATE_REQUEST
ErrorCode Доступ запрещен. (0x80070005)
... это, кажется, просто говорит мне то, что я уже знаю (это просто отклоняет запрос вместо согласования учетных данных).
Трассировка действительно указывает на то, что модуль WindowsAuthentication правильно загружен, потому что есть NOTIFY_MODULE_START
строка с ModuleName
= WindowsAuthentication
(и различными другими последующими событиями ASP.NET - к счастью, здесь нет интересных ошибок или предупреждений).
Может кто-нибудь сказать мне, что я мог бы упустить здесь?
Быстрое обновление:
Мне немного неудобно отправлять весь дамп Wireshark, так как он показывает IP-адреса, URL-адреса и другие вещи, но я провел параллельное сравнение HTTP-ответов от localhost и удаленного сервера в Fiddler, и это кажется довольно самостоятельным -видно в чем проблема:
Localhost:
HTTP / 1.1 401 Несанкционированный Cache-Control: приватный Content-Type: text / html; кодировка = UTF-8 Сервер: Microsoft-IIS / 7.5 WWW-Аутентификация: переговоры WWW-Аутентификация: NTLM X-Powered-By: ASP.NET Дата: сб, 17 дек 2011 23:42:34 GMT Контент-длина: 6399 Proxy-Support: Session-Based-Authentication
Удаленный:
HTTP / 1.1 401 Несанкционированный Тип контента: текст / HTML Сервер: Microsoft-IIS / 7.5 X-Powered-By: ASP.NET Дата: сб, 17 дек 2011 23:43:13 GMT Длина контента: 1293
Помимо нескольких, казалось бы, несущественных различий, таких как управление кэшем, основное отличие состоит в том, что удаленный сервер не отправляет заголовки WWW-Authenticate обратно клиенту.
Итак, я предполагаю, что это сужает вопрос до: Почему IIS не отправляет заголовки WWW-Authenticate, когда аутентификация Windows установлена, загружена и включена исключительно?
источник
Ответы:
Проблема решена. Я наконец решил сравнить список модулей бок о бок, и на самом деле одного из них не было. Оказывается, есть два модуля аутентификации Windows:
На сервере был управляемый
WindowsAuthentication
модуль, но неWindowsAuthenticationModule
выделенный выше. Почему он был настроен таким образом, можно только догадываться, но, очевидно, если родной модуль не загружен, управляемый модуль будет загружаться и молча давать сбой.Поэтому для любых будущих читателей, которые столкнутся с этой проблемой, убедитесь, что у вас загружены оба модуля , потому что IIS не предупредит вас, если один из них отсутствует.
источник
Мы обнаружили, что это не обязательно решает проблему для разработчиков, работающих локально на сайтах ASP.NET, работающих под аутентификацией Windows. Мы нашли взлом реестра, который отключает проверку петли; это исправило это: -
раздел реестра - HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa
Создайте DWORD со значением 1 с именем «DisableLoopbackCheck»
Вам нужно будет перезагрузить машину, чтобы настройки вступили в силу
источник