Под какой учетной записью работает ASP (классический) при включенной встроенной проверке подлинности Windows?

Question

У меня есть файл 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 под учетной записью домена?

Answer 1

Классический 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.

Answer 2

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

Если что-либо из вышеперечисленного неверно (и сервер не может согласовать учетную запись пользователя с клиентским браузером), то IUSR_<machine>по умолчанию используется то, что вы установили в качестве пользователя для анонимного просмотра, или, если анонимный просмотр отключен, пользователь получит ошибку 401.*.

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

Вы можете увидеть пользователя, которого веб-сервер в данный момент использует для запросов к определенной области, добавив скрипт, который запрашивает коллекцию reqeust.servervariables и выводит соответствующие значения — имя пользователя там есть.

Answer 3

Похоже, вы пытаетесь выполнить аутентификацию "double-hop". Обычно это происходит в контексте бэкэнд-службы SQL, но, как мне кажется, это может относиться и к отдельной службе, работающей на том же сервере (хотя я не уверен на 100%). Поищите в MSKB этот термин, "double hop", и вы получите несколько документов, которые объясняют, как настроить делегирование, чтобы это работало. Вот один для начала:http://support.microsoft.com/kb/326985

Вам нужно, чтобы сервер IIS был настроен на «Делегирование разрешено». Когда пользователь проходит аутентификацию с помощью встроенной аутентификации Windows, он должен получить билет Kerberos (это НЕ БУДЕТ работать, если вы получаете аутентификацию NTLM).

Для делегирования вам нужно будет добавить SPN на сервер. Убедитесь, что пользователи попадают на веб-страницу с фактическим FQDN, для которого сервер имеет SPN в AD. Имя участника службы (SPN) — это то, что агент Kerberos пользователя будет использовать для создания правильного билета Kerberos, который позволит серверу IIS выдавать себя за пользователя, когда он передает запрос следующей службе.

Answer 4

Важно ли, чтобы веб-сервис использовал учетные данные вошедшего в систему пользователя? Если вы используете что-то вроде MSXML2.ServerXMLHTTPRequest для вызова веб-сервиса, можете ли вы просто предоставить учетные данные в методе .Open, чтобы предоставить фиксированный набор учетных данных веб-сервису?