У меня есть файл ASP, который пытается сделать запрос веб-службы к веб-службе ASP.NET, работающей на том же сервере в том же виртуальном каталоге. В IIS виртуальный каталог настроен на отключение анонимного доступа и включена «встроенная проверка подлинности Windows».
Таким образом, проблема в том, что когда компьютер пользователя запрашивает запуск страницы ASP или даже вручную запускает файл WebService.asmx .NET, он работает, потому что учетные данные пользователя передаются, однако, когда файл ASP пытается вызвать веб-службу, мы получаем 401.2 - Неавторизованный: доступ запрещен из-за конфигурации сервера.
Например:
Поэтому я предположил, что мне нужно установить разрешения NTFS для WebService.asmx, чтобы разрешить учетной записи ASP разрешения на чтение и выполнение, но я не знаю, под какой учетной записью он работает, и после дополнительных размышлений после прочтения некоторых ответов кажется, что мы не переходят на уровень NTFS, IIS полностью отклоняет запрос, потому что анонимный доступ отключен.
Означает ли это, что нам нужно запустить процесс ASP под учетной записью домена?
Классический ASP выполняет олицетворение пользователя, прошедшего аутентификацию на сервере в сеансе HTTP. Вам необходимо предоставить пользователям, которые проходят аутентификацию, разрешение на запуск классического приложения ASP или разрешить анонимный доступ.
Если вы уже пробовали «Прошедшие проверку пользователи» и он не работает, я бы сказал, что у вас нет проблемы с правами доступа к файлу.
Что вы имеете в виду, когда говорите «... файл ASP пытается вызвать веб-службу ...»? Вы говорите, что сценарий ASP отправляет HTTP-запрос обратно на сервер? Если это так, учетные данные пользователя не будут переданы в этом запросе, потому что «встроенная проверка подлинности Windows» не дает серверу пароль в виде открытого текста для использования при проверке подлинности на других серверах (или на самом себе).
Редактировать:
В соответствии с вашим комментарием, как указано выше, у сервера не будет учетных данных для аутентификации пользователя, поскольку встроенная проверка подлинности Windows не дает серверу пароля в виде открытого текста для передачи другим серверам (или самому себе, который в данном случае является другим сервером) ).
Вы можете попробовать три вещи:
Если вы можете получить WebService.asmx для разрешения анонимного доступа, ваш HTTP-вызов между сервером должен работать (вам необходимо явно разрешить анонимный доступ, разрешив IUSR_xxx читать файл и путем изменения параметра «Анонимный доступ и контроль проверки подлинности» для «Анонимный доступ» в самом файле через оснастку консоли управления IIS, поскольку этот файл будет наследовать включенные параметры «Встроенная проверка подлинности Windows» и отключенные параметры «Анонимный доступ» из каталог, в котором он находится).
Если элемент управления, который вы используете для отправления HTTP-запроса, поддерживает прозрачное предоставление учетных данных вошедшего в систему пользователя на удаленный сервер, вы можете включить «Обычную проверку подлинности» в классическом сценарии ASP (который дает серверу пароль в виде открытого текста для передачи на другие серверы), чтобы ваш элемент управления HTTP-запросом мог передать этот пароль в виде открытого текста во время запроса WebService.asmx. На этом этапе вы захотите потребовать SSL для доступа к классическому сценарию ASP, чтобы не передавать пароли в виде открытого текста.
Наконец, вы можете просто жестко запрограммировать некоторые учетные данные базовой аутентификации в классическом сценарии ASP и включить базовую аутентификацию в файле WebService.asmx. Это означает, что WebService.asmx всегда будет видеть доступ от одного и того же пользователя.
Ни одно из этих решений не является хорошим. Вы сталкиваетесь с «классической» проблемой, которую мы видели с «классическим ASP» при попытке аутентификации на внутреннем уровне (базе данных и т. Д.) В качестве пользователя, который аутентифицировался для запуска классического сценария ASP.
Похоже, вы пытаетесь выполнить двухэтапную аутентификацию. Обычно это происходит в контексте серверной службы SQL, но я думаю, это может применяться к отдельной службе, работающей на том же сервере (хотя я не уверен на 100%). Найдите в MSKB термин «двойной переход», и вы получите несколько документов, в которых объясняется, как настроить делегирование, чтобы это работало. Вот один для начала, http://support.microsoft.com/kb/326985
Вам нужно, чтобы сервер IIS был настроен на «Делегирование разрешено». Когда пользователь аутентифицируется с помощью встроенной аутентификации Windows, он должен получить билет Kerberos (это НЕ БУДЕТ работать, если вы получаете аутентификацию NTLM).
Для делегирования вам нужно будет добавить SPN на сервер. Убедитесь, что пользователи переходят на веб-страницу с фактическим полным доменным именем, для которого сервер имеет SPN в AD. Имя участника службы (SPN) - это то, что пользовательский агент Kerberos будет использовать для создания правильного билета Kerberos, который позволит серверу IIS олицетворять пользователя, когда он передает запрос следующей службе.
Если встроенная проверка подлинности включена, и пользователь использует браузер, который выполняет встроенную проверку подлинности Windows и пользователь входит в систему как учетная запись, которая переводит на один веб-сервер (например, клиентский компьютер находится в том же домене, что и веб-сервер), и ваш сценарий будет запускаться как учетная запись этого пользователя.
Если что-либо из вышеперечисленного неверно (поэтому сервер не может согласовать учетную запись пользователя с клиентским браузером), то используется все, что вы установили как анонимный пользователь, IUSR_<machine> по умолчанию или если анонимный просмотр отключен, пользователь получит ошибку 401. *.
Это предполагает, что другие мнения об аутентификации отключены. Я не уверен, что имеет приоритет, если у вас одновременно включены схемы проверки подлинности Windows Integrated и Basic.
Вы можете увидеть пользователя, которого веб-сервер в настоящее время использует для запросов к определенной области, добавив сценарий, который запрашивает коллекцию reqeust.servervariables и выводит соответствующие значения - имя пользователя находится там.
Важно ли, чтобы веб-сервис использовал учетные данные вошедшего в систему пользователя? Если вы используете что-то вроде MSXML2.ServerXMLHTTPRequest для вызова веб-службы, не могли бы вы просто указать учетные данные в методе .Open для предоставления фиксированного набора учетных данных веб-службе?