Назад | Перейти на главную страницу

Ошибка 500 виртуального каталога IIS6 на удаленном общем ресурсе

У нас есть серверы на ферме серверов в домене. Назовем это ЖИВОЙ.

Наши компьютеры для разработчиков находятся в совершенно отдельном корпоративном домене, за многие мили от нас. Назовем это CORP.

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

Проблема в разработке.

На моей машине разработки. Я вхожу в систему как CORP \ MyName. Мой пул приложений IIS 6 работает как сетевая служба. Я не могу запустить его как пользователь из LIVE-домена, потому что моя машина не (и не может быть) присоединена к этому домену.

Я пытаюсь создать виртуальный каталог, указываю его на тот же сетевой каталог, нажимаю «Подключить как», снимаю флажок «Всегда использовать учетные данные аутентифицированного пользователя при проверке доступа к сетевому каталогу», чтобы я мог ввести данные для входа, ввести учетные данные для LIVE \ MediaUser нажмите OK, проверьте пароль и т. д.

Это не работает. Я получаю сообщение «Ошибка HTTP 500 - Внутренняя ошибка сервера» от IIS.

В файле журнала IIS указано sc-status = 500, sc-substatus = 16 и sc-win32-status = 1326.

В документации говорится, что это означает, что «учетные данные авторизации UNC неверны», а статус Win32 означает «Ошибка входа в систему: неизвестное имя пользователя или неверный пароль».

Это было бы все и хорошо, если бы оно было где-то близко к точному. Я перепроверил и проверил. Пробовал несколько известных хороших логинов. Диспетчер IIS позволяет мне просматривать дерево файлов в своем окне, меня выгоняет только браузер.

Я даже попытался перейти на вкладку «Безопасность каталога» виртуального каталога, а в разделе «Аутентификация и контроль доступа» попытался использовать то же имя пользователя домена LIVE для учетных данных анонимного доступа. Не повезло.

Я не пытаюсь запускать какие-либо ASP, ASP.NET или другие динамические объекты из виртуального каталога. Я просто хочу, чтобы IIS мог загружать статические изображения, файлы css и js.

Если у кого-то есть блестящие идеи, я буду очень признателен!

Я согласен не присоединять компьютер CORP к домену LIVE, но есть ли причина, по которой вы не можете установить одностороннее доверие между ними? По сути, либо LIVE должен иметь возможность проверять CORP \ user, либо CORP должен иметь возможность успешно передавать учетные данные LIVE \ user (чего нельзя, если он не знает этого домена, даже если консоль управления IIS 6 не сделайте это слишком ясным).

По сути, домены должны знать друг о друге, чтобы AD могла делать свое дело. Общий ресурс UNC не сообщает вам, что он не проверен (это будет ошибкой класса HTTP 400). Сервер DEV сообщает вам (через 500.16), что он не может создать токен для кредитов, которые вы ему дали, b / c он не знает, что такое LIVE домен, поэтому kerberos не может создать токен для него.

TechNet на HTTP 500.16: ...

Для этого IIS использует API входа в Windows для получения маркера безопасности, который он может использовать для олицетворения удостоверения безопасности при доступе к удаленно сохраненному содержимому.

У меня была эта проблема раньше. Вот два предложения, оба не идеальны и могут быть даже невозможны в вашей среде:

  1. Храните файлы в общей папке на сервере, не являющемся доменом. Таким образом, доступ к ним будет иметь как рабочий сервер, так и сервер разработки.

  2. Выполняйте ежедневное задание по копированию необходимых файлов с живого сервера для разработки (через FTP, FTPS или каким-либо другим способом).

Убедитесь, что учетная запись пользователя, которую вы используете для доступа к общей папке (например, LIVE \ MediaUser), имеет разрешение «Войти в качестве службы» и «Доступ к этому компьютеру из сети».

Вы настраиваете это на сервере, на котором размещена общая папка, в:

Администрирование -> Управление компьютером -> Параметры локальной безопасности -> Локальные политики -> Назначение прав пользователя

Я решил эту проблему, используя пользователя домена для анонимного пользователя, которому разрешен доступ к удаленному общему ресурсу на контроллере домена. Он отлично работает.

Искренне