ASP MVC Preview 5 и IIS 6 для проверки подлинности Windows

Question

Я только что создал базовый веб-сайт ASP MVC для развертывания в нашей внутренней сети. Ожидается, что пользователи будут в том же домене, что и окно IIS, и если вы не являетесь аутентифицированным пользователем Windows, вы не должны получать доступ.

Я только что развернул это на IIS6, работающем на Server 2003 R2 SP2. Веб-приложение настроено со своим собственным пулом с собственной учетной записью пользователя пула. Параметры безопасности каталогов IIS для веб-приложения установлены только на «Интегрированную безопасность Windows», а файл web.config имеет:

<authentication mode="Windows" />

В сеансе удаленного рабочего стола на самом сервере IIS6 окно браузера IE7 может успешно аутентифицироваться и перемещаться по веб-приложению при доступе через http://localhost/myapp.

Однако также с сервера, если доступ осуществляется через имя сервера (т. Е. http://myserver/myapp), то IE7 открывает диалоговое окно учетных данных, которое после трех попыток ввода правильных учетных данных в конечном итоге возвращает «Ошибка HTTP 401.1 - Несанкционированный: доступ запрещен» из-за неверных учетных данных ".

Та же проблема возникает, когда рабочая станция просматривает URL веб-приложения (естественно, используя имя сервера, а не «localhost»).

Сервер IIS6 является членом единственного домена, который у нас есть, и у которого не включен брандмауэр.

Есть ли что-то, что мне не удалось правильно настроить, чтобы это работало?

Спасибо

---

Я попробовал предложения Мэтта Райана, Графэйна и Майка Диммика на сегодняшний день безуспешно. Я только что создал тестовую лабораторию виртуальной машины с DC Server 2003 и отдельным сервером IIS6 Server 2003, и я могу воспроизвести проблему.

Я вижу запись в системном журнале событий сервера IIS6 при первой попытке доступа к сайту через нелокальный URL-адрес (т. Е. http://iis/myapp). URL-адреса FQDN тоже не работают.

Источник: Kerberos, Код события: 4
Клиент kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера host / iis.test.local. В качестве целевого имени использовался HTTP / iis.test.local. Это означает, что пароль, используемый для шифрования билета службы Kerberos, отличается от пароля на целевом сервере. Обычно это происходит из-за идентичных имен учетных записей компьютеров в целевой области (TEST.LOCAL) и клиентской области.

Answer 1

После интенсивного поиска в Google мне удалось найти решение в следующей статье MSDN:
Как: создать учетную запись службы для приложения ASP.NET 2.0

В частности, раздел «Дополнительные соображения», в котором описывается «Создание имен участников службы (SPN) для учетных записей домена» с использованием инструмента setspn из средств поддержки Windows:

setspn -A HTTP / myserver MYDOMAIN \ MyPoolUser
setspn -A HTTP / myserver.fqdn.com MYDOMAIN \ MyPoolUser

Это решило мою проблему как в моей виртуальной тестовой лаборатории, так и на моем исходном сервере проблем.

В статье также есть важное замечание, что использование проверки подлинности Windows с пользователями настраиваемого пула ограничивает связанное DNS-имя, которое будет использоваться только этим пулом. То есть другой пул с другим идентификатором должен быть связан с другим DNS-именем.

Answer 2

Похоже на новую функцию безопасности проверки петли в Windows Server 2003 SP1. Насколько я понимаю, предназначен для предотвращения перехвата определенного типа атаки.

С http://support.microsoft.com/kb/896861

ПРИЗНАКИ

Когда вы используете полное доменное имя (FQDN) или настраиваемый заголовок узла для просмотра локального веб-сайта, размещенного на компьютере под управлением Microsoft Internet Information Services (IIS) 5.1 или IIS 6, вы можете получить сообщение об ошибке, похожее на следующее: HTTP 401.1 - не авторизован: ошибка входа Эта проблема возникает, когда веб-сайт использует встроенную проверку подлинности и имеет имя, сопоставленное с локальным адресом обратной связи.

Примечание. Это сообщение об ошибке появляется только в том случае, если вы пытаетесь просматривать веб-сайт непосредственно на сервере. Если вы просматриваете веб-сайт с клиентского компьютера, веб-сайт работает должным образом.

ПРИЧИНА

Эта проблема возникает при установке Microsoft Windows XP с пакетом обновления 2 (SP2) или Microsoft Windows Server 2003 с пакетом обновления 1 (SP1). Windows XP с пакетом обновления 2 и Windows Server 2003 с пакетом обновления 1 (SP1) включают функцию безопасности проверки петли, которая предназначена для предотвращения атак отражений на вашем компьютере. Поэтому проверка подлинности не выполняется, если полное доменное имя или пользовательский заголовок узла, который вы используете, не совпадает с именем локального компьютера.

Обход

• Способ 1: отключить проверку петли
• Способ 2. Укажите имена хостов

Подробнее см. http://support.microsoft.com/kb/896861.

---

Edit - только что заметил, что вы сказали, что видели это и на клиентских ПК ... это более необычно. Но я все еще хотел бы протестировать один из этих обходных путей, чтобы увидеть, исправит ли он проблему (и если да, может ли это указывать на проблему с вашей конфигурацией DNS).

Answer 3

Я только что столкнулся с противоположной проблемой - мой сайт аутентифицируется внешне, но не локально.

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

Однако другие сайты, с которыми я работаю (это сервер разработки), как правило, имеют базовую аутентификацию.

Не уверен, почему именно, но это исправило это.

Однако в то же время я заметил настройки «Домен по умолчанию» и «Область».

Я знаю, что это очень маловероятно, но может ли это вообще помочь?

Answer 4

IE7 отправляет учетные данные Windows (NTLM, Kerberos) только в том случае, если он идентифицирует сервер как находящийся в интрасети. В IE7 также добавлена ​​функция блокировки зоны интрасети - если вы не находитесь в домене, по умолчанию серверы не находятся в зоне интрасети. Это было сделано для предотвращения атак зонной миграции.

Чтобы изменить это, перейдите в Сервис / Свойства обозревателя, вкладка Безопасность, затем нажмите Локальная интрасеть. Затем вы можете вручную добавить серверы, которые должны рассматриваться как интрасеть, нажав кнопку «Сайты», затем «Дополнительно» или указав IE не определять автоматически вашу интрасеть и устанавливая другие флажки соответствующим образом.

Answer 5

Мне кажется, что вы все сделали правильно.

Я уверен, что вы уверены, но вы убедились, что используете DOMAIN \ user в качестве учетной записи пользователя, а не просто «user»?