Под какой учетной записью работает ASP (classic), когда включена встроенная проверка подлинности Windows?
У меня есть файл ASP, который пытается сделать запрос веб-службы к веб-службе ASP.NET, работающему на том же сервере в том же виртуальном каталоге. В IIS виртуальный каталог настроен на отключение анонимного доступа и включена "встроенная проверка подлинности Windows".
Таким образом, проблема заключается в том, что, когда компьютер пользователя запрашивает запуск страницы ASP или даже вручную запускать файл WebService.asmx .NET, он работает, потому что передаются учетные данные пользователя, однако, когда файл ASP пытается вызвать веб-сервис, мы получаем 401.2 - Несанкционированный: доступ запрещен из-за конфигурации сервера.
Например:
- "DIRECTORY \ user1" из браузера на машине пользователя запрашивает Service.asmx, который работает нормально.
- "DIRECTORY \ user1" из браузера на пользовательском компьютере запрашивает File1.asp, который работает нормально.
- _________ изнутри File1.asp на сервере запрашивает Service.asmx, который возвращает 401.2
Поэтому я предположил, что мне нужно установить разрешения NTFS для WebService.asmx, чтобы разрешить учетной записи ASP разрешения "Чтение и выполнение", но я не знаю, под какой учетной записью он работает, и после дальнейших раздумий после прочтения некоторых ответов, кажется, что мы не достигают уровня NTFS, IIS полностью отклоняет запрос, потому что анонимный доступ отключен.
Означает ли это, что нам нужно запустить процесс ASP под учетной записью домена?
4 ответа
Классический 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 на сервер. Убедитесь, что пользователи переходят на веб-страницу с фактическим полным доменным именем, для которого у сервера есть имя участника-службы в AD. Имя участника службы (SPN) - это то, что пользовательский агент Kerberos будет использовать для создания правильного билета Kerberos, который позволит серверу IIS выдавать себя за пользователя, когда он передает запрос следующей службе.
Если включена встроенная проверка подлинности, и пользователь использует браузер, который будет выполнять встроенную проверку подлинности Windows, и пользователь вошел в систему как учетная запись, которая транслируется на один веб-сервер (например, клиентский компьютер находится в том же домене, что и веб-сервер).) ваш скрипт будет работать от имени этого пользователя.
Если любое из вышеперечисленного является ложным (поэтому сервер не может согласовать учетную запись пользователя с клиентским браузером), то используется то, что вы указали в качестве пользователя для анонимного, IUSR_<machine> по умолчанию, или если анонимный просмотр отключен, пользователь получит ошибку 401.*.
Это предполагает, что другие мнения аутентификации отключены. Я не уверен, что имеет преимущественную силу, если у вас одновременно включены интегрированные и базовые схемы проверки подлинности Windows.
Вы можете увидеть пользователя, которого веб-сервер в настоящее время использует для запросов к определенной области, добавив скрипт, который запрашивает коллекцию reqeust.servervariables и выводит соответствующие значения, в которых находится имя пользователя.
Важно ли, чтобы веб-сервис использовал учетные данные вошедшего в систему пользователя? Если вы используете что-то вроде MSXML2.ServerXMLHTTPRequest для выполнения вызова веб-службы, не могли бы вы просто предоставить учетные данные в методе.Open, чтобы предоставить фиксированный набор учетных данных для веб-службы?