Интегрированная аутентификация Windows завершается неудачно ТОЛЬКО, если клиент web svcs находится на той же машине, что и сервер IIS

Question

У меня есть веб-служба, работающая под IIS7 на сервере с установленным заголовком узла, так что он получает запросы, отправленные на http://myserver1.mydomain.com/.
Я установил Windows INtegrated Authentication на "Включено", а все остальное (базовое, анонимное и т. Д.) На "Отключено".

Я тестирую веб-сервис с использованием скрипта powershell, и он отлично работает, когда я запускаю его со своей рабочей станции на http://myserver1.mydomain.com/

Однако, когда я запускаю тот же самый точный сценарий на самом сервере IIS, я получаю сообщение 401-Unauthorized.

Кроме того, я попытался установить веб-сервис на втором сервере, myserver2.mydomain.com. Опять же, я могу нормально назвать мой тестовый скрипт с ОБА моей рабочей станции и с myserver1.

Таким образом, кажется, единственная проблема заключается в том, что клиент находится в том же окне, что и сам веб-сервер - почему-то учетные данные Windows не передаются или не распознаются.

Я попытался поиграть с настройками IE на myserver1 (проверил и снял флажок "Включить встроенную аутентификацию Windows" и добавил URL-адрес для локальных сайтов). Это, казалось, не имело эффекта.

Когда я просматриваю журналы IIS, я вижу несанкционированную линию 401, но очень мало другой информации.

Я вижу в основном то же самое поведение при тестировании с IE (v9) - работает с моей рабочей станции, но не когда IE работает на сервере IIS.

Буду признателен за любые подсказки или отправную точку для устранения этой проблемы.

Answer 1

Я нашел ответ через несколько часов:

По умолчанию существует нечто, называемое LoopbackCheck, которое отклоняет проверку подлинности Windows, если заголовок узла, используемый для сайта, не совпадает с именем локального узла. Такое поведение будет видно только когда клиент находится на локальном хосте. Проверка здесь, чтобы победить возможные атаки отражения.

Подробнее здесь:

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

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

Спасибо тем, кто оказал помощь.

Answer 2

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

Например, на вашем ящике ваши учетные данные работают как...

MYDOMAIN\MYNAME

и сервер будет что-то вроде...

SYSTEM\SYSTEM_ACCOUNT

и поэтому это не удастся, потому что "SYSTEM\SYSTEM_ACCOUNT" не имеет учетных данных.

Если это так, вы можете решить проблему одним из двух способов.

1. Предоставьте доступ "SYSTEM\SYSTEM_ACCOUNT" к рассматриваемому ресурсу. Большинство людей избегают этой стратегии из-за проблем безопасности (именно поэтому учетная запись не имеет доступа в первую очередь).

2. Олицетворение или изменение учетных данных клиента вручную на что-то, что имеет доступ к ресурсу, например, MYDOMAIN\MYNAME. Это то, с чем, вероятно, пойдет большинство людей, включая меня.