Проблемы проверки подлинности ASP.NET на IIS7 - User.Identity.Name пуст для проверки подлинности Windows

Question

У нас есть приложение ASP.NET в ASP.NET 4.0, использующее MVC 3, в котором используется проверка подлинности Windows.

При запуске из Visual Studio 2010 все работает как положено, но при развертывании в IIS7 Windows, вошедший в систему пользовательникогда не заполняется (проверка User.Identity.Name).Также не появляется диалоговое окно для ввода учетных данных пользователя.

Параметр web.config:

<authentication mode="Windows" />

В IIS я вижу, что включена проверка подлинности Windows, как и Anonymous (отключение Anonymous приводит к403 Запрещено и контент не отображается).

Я пробовал включить и отключить «Аутентификацию в режиме ядра» (useKernelMode = «true»), но, похоже, это не имеет значения.Хотя я помню, что нам пришлось отключить этот параметр на другом сайте на другом сервере, чтобы заставить аутентификацию работать должным образом (может указывать на потенциальную проблему в стеке?).

В случае, если это полезно,из приложения IISHost.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.config для 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 запрещено».

Answer 1

В данном случае это была проблема Microsoft ISA Server. Похоже, что запрос направлялся изнутри через ISA для сайта, прошедшего проверку подлинности Windows, после удаления ISA проблема исчезла.

Я не знаю много об ISA и о том, как он маршрутизирует запросы, но я предполагаю, что он, должно быть, удалял некоторую важную информацию из запроса из-за какого-то правила, которое кто-то настроил.

В качестве дополнительного примечания на случай, если он помогает диагностировать аналогичные установки: сотрудники сетевого администратора сказали мне, что внутренний трафик не маршрутизируется через ISA, но пинг веб-сайта изнутри показал, что ISA действительно работает.

Answer 2

Вы упомянули, что отключение анонимного доступа работает на другом сервере, но на вашем главном сервере вы получаете 403 ошибки.Поэтому я бы проверил разрешения на основе файлов для папки, из которой работает ваш сайт.В прошлом мне требовалось предоставить полный контроль учетной записи \ Network Serivce папке сайта и всем подпапкам, иначе я столкнулся бы с 403 ошибками.Проверьте права доступа к файлам на сервере, который работает, и посмотрите, есть ли различия с сервером, который не работает.

Кроме того, если это не проблема, я бы порекомендовал сравнить все остальные параметры IIS между двумя серверами, поскольку вы знаете, что он работает на одном, а не на другом.Найди разницу.