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

Проблема с разрешениями с виртуальным каталогом для пути UNC

У меня на сайте есть виртуальный каталог (тестовая среда). Это общий ресурс UNC, который также используется как общедоступный FTP.

Он настроен для подключения как учетная запись администратора домена, и в «Тестовых настройках» указано, что все работает. Однако когда я пытаюсь подключиться к нему, я получаю:

500 - «Не удалось начать мониторинг изменений на \ INTRANET \ FTP \ test \ web.config, поскольку доступ был запрещен»

Это ASP.NET YSOD. Я не уверен, почему ASP.NET вообще участвует, поскольку я запрашиваю статический файл .jpg.

Я попытался включить отслеживание неудачных запросов, и это конкретная ошибка:

Если я изменю «Тип входа физического пути» с ClearText на Network. Я получаю следующую ошибку IIS:

Ошибка HTTP 500.19 - Внутренний сервер

ошибка Запрошенная страница недоступна, поскольку соответствующие данные конфигурации для страницы недействительны.

Подробная информация об ошибках

  • Модуль Веб-ядро IIS
  • Уведомление BeginRequest
  • Обработчик Еще не определено
  • Код ошибки 0x80070005
  • Ошибка конфигурации Не удается прочитать файл конфигурации из-за недостаточных разрешений
  • Файл конфигурации \\?\UNC\INTRANET\FTP\test\web.config

  • Запрошенный URL http://test.mydowmain.com:80/uploads/images/ca49acf6-6174-412e-8abd-59fab983e931.jpg

  • Физический путь \\INTRANET\FTP\test\images\ca49acf6-6174-412e-8abd-59fab983e931.jpg

  • Метод входа в систему Еще не определено

  • Войти в систему Еще не определено
  • Каталог журнала отслеживания неудачных запросов C:\inetpub\logs\FailedReqLogFiles

Как ни странно, при этом не создается журнал неудачных запросов - я установил трассировку неудачных запросов для отслеживания ошибок с кодами 400-999.

Также стоит отметить, что если я открываю функцию конфигурации из IIS, я вижу ошибку отказа в доступе.

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

Что я делаю не так?

Вероятно, проблема именно в том, что это приложение ASP.net. У удостоверения пула приложений должны быть права (не обязательно удостоверение IIS; по умолчанию удостоверение пула приложений - это учетная запись локальной сетевой службы). Вам также, вероятно, потребуется запустить caspol.exe на вашем компьютере IIS.

http://msdn.microsoft.com/en-us/library/cb6t8dtz%28v=vs.80%29.aspx

http://learn.iis.net/page.aspx/50/aspnet-20-35-shared-hosting-configuration/

%windir%\Microsoft.NET\Framework\v2.0.50727\caspol -m -ag 1.  -url "file://\\remotefileserver\content$\*" FullTrust

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

Если этот общий источник не является приложением (например, папкой изображений), попробуйте настроить виртуальный каталог, который будет игнорироваться корневым приложением, которое включает виртуальный каталог (в моем случае я выполнил это, изменив тип пула корневых приложений как Классический вместо интегрированного режима). Но если в общей точке есть приложение, вы можете следовать указаниям @mfinni.

Вы можете проверить, имеет ли учетная запись, под которой работает IIS, надлежащие / необходимые права на проблемный UNC.

У меня была такая же проблема в IIS 7.5, я нашел решение:

  1. Создайте локального пользователя на сервере с общим ресурсом
  2. Создайте сетевой ресурс, предоставив пользователю, созданному на шаге 1, требуемые разрешения. Windows установит разрешения для указанного вами пользователя.
  3. Зайдите в виртуальный каталог на IIS и откройте «дополнительные настройки»
  4. Введите URL-адрес в физическом пути для общего сетевого ресурса как \\<servername>\<sharename>
  5. щелкните Учетные данные физического пути; добавьте учетные данные для пользователя, созданного на шаге 1

Просто была такая же проблема с веб-сервером, не являющимся доменом, доступ к некоторым ресурсам домена с использованием учетной записи домена. Мы наблюдали странное поведение («тестовые учетные данные» не выполнялись, хотя мы знали, что учетные данные верны, мы могли видеть папки и файлы в представлении содержимого, но не могли «просматривать» их). Решением было создать локального пользователя на машине с тем же именем, что и у пользователя домена.

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

Надеюсь, это кому-то поможет.