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 между двумя серверами, так как вы знаете, что он работает на одном, а не на другом. Найдите разницу.