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

Question

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

Я тестирую веб-сервис с использованием скрипта 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.Это то, с чем, вероятно, пойдет большинство людей, включая меня.