ASP.NET проблемы аутентификации на IIS7-User.Личность.Имя пусто для проверки подлинности Windows
У нас есть ASP.NET применение на ASP.NET 4.0 использование MVC 3, который использует проверку подлинности Windows.
при запуске из Visual Studio 2010 все работает так, как ожидалось, но при развертывании в IIS7 вошедший в систему пользователь Windows никогда не заполняется (проверка пользователя.Личность.Имя). Также не появляется диалоговое окно для учетных данных пользователя.
веб.config параметр:
<authentication mode="Windows" />
в IIS я вижу, что аутентификация Windows включена, как и анонимная (отключение Анонимные результаты в 403 запрещено и содержание не отображается).
Я пробовал как включить, так и отключить "аутентификацию в режиме ядра" (useKernelMode="true"), но это, похоже, не имеет никакого значения. Хотя я помню, что нам пришлось отключить этот параметр на другом сайте на другом сервере, чтобы аутентификация работала правильно (может указывать на потенциальную проблему дальше по стеку?).
в случае, если это полезно, из IIS файл applicationhost.config:
<security>
<authentication>
<anonymousAuthentication enabled="true" />
<digestAuthentication enabled="false" />
<basicAuthentication enabled="false" />
<windowsAuthentication enabled="true" useKernelMode="false">
<providers>
<clear />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
</security>
есть идеи, что проблема может быть?
заранее спасибо за любые предложения.
обновление 1
мне удалось найти другой сервер IIS7 для тестирования, и я обнаружил, что если я отключил анонимный доступ, все работало по желанию. Однако у меня все еще есть проблемы на исходном сервере IIS7, даже когда я отключаю анонимный доступ (теперь я отключаю анонимный доступ). Так что должна быть какая-то проблема. думаю, дальше по стопке. Есть идеи? Что-то, что мне нужно исправить, так как это будет продолжать появляться и кусать нас, я думаю.
обновление 2
Если я включаю дайджест-аутентификацию в поле проблема IIS7, то мне бросают вызов диалоговым окном приглашения для входа, и все работает так, как ожидалось, если я предоставлю подходящие учетные данные. Но будучи внутренним веб-приложением с пользователями, уже вошедшими в домен, мы не хотим бросать им вызов таким образом. Полномочия должны пройти прозрачно, как это работает на втором поле и IIS7.
обновление 3
некоторый прогресс... Я обнаружил, что если веб-приложение находится в корне, а не на суб-сайте, то непосредственно редактирует applicationHost.файл конфигурации для IIS7, чтобы дать следующие параметры аутентификации, позволяет сайту работать так, как ожидалось:
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true">
<providers>
<clear />
<add value="NTLM" />
</providers>
</windowsAuthentication>
<digestAuthentication enabled="false" />
</authentication>
использование пользовательского интерфейса IIS7 для настройки аутентификации не дает правильных результатов. элементы аутентификации либо отсутствуют после подопечных (как я предполагаю, IIS7 предполагает, что они наследуются), либо у них неправильные настройки (windowsAuthentication, похоже, нужна конфигурация поставщиков выше, чтобы работать правильно).
к сожалению, веб-приложение, о котором идет речь, на самом деле является вложенным приложением, поскольку есть внутренняя версия (с использованием проверки подлинности windows > www.site.com/internal) и внешней версии (с использованием проверки подлинности форм > www.site.com/external). Я все еще не могу понять ... аутентификация для работы в качестве суб-приложения. Я просто получаю "код ошибки: 403 Forbidden".
2 ответов
в этом случае это была проблема Microsoft ISA Server. Кажется, запрос был перенаправлен внутренне через ISA для аутентифицированного сайта Windows, как только ISA была удалена, проблема исчезла.
Я не знаю много об ISA и о том, как он маршрутизирует запросы, но я предполагаю, что он должен был удалить некоторую важную информацию из запроса из-за какого-то правила, которое кто-то настроил.
в качестве примечания в случае, если это помогает диагностировать аналогичные настройки: мне сказали сотрудниками администратора сети, что внутренний трафик не был направлен через ISA, но пингинг веб-сайта внутри показал, что ISA на самом деле в игре.
вы упомянули, что отключение анонимного доступа работало на другом сервере, но на вашем основном сервере вы испытываете 403 ошибки. Поэтому я бы проверил разрешения на основе файлов в папке, из которой запущен ваш сайт. В прошлом мне нужно было предоставить учетной записи \Network Serivce полный контроль над папкой сайта и всеми вложенными папками, или у меня возникнут ошибки 403. Проверьте права доступа к файлам на работающем сервере и проверьте, есть ли различия с сервером, который не работающий.
кроме того, если это не проблема, я бы рекомендовал сравнить все другие настройки IIS между двумя серверами, так как вы знаете, что он работает на одном, а не на другом. Найдите разницу.