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

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

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

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

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

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

• ModuleName WindowsAuthentication
• Уведомление 2
• HttpStatus 500
• HttpReason Внутренняя ошибка сервера
• HttpSubStatus 0
• ErrorCode 0
• ConfigExceptionInfo
• Уведомление AUTHENTICATE_REQUEST
• ErrorCode Операция успешно завершена. (0x0)

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

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

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

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

• Модуль IIS Web Core
• Уведомление 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

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

Я думаю, это то, что произошло бы, если бы веб-сервер был членом домена, а локальному пользователю было необходимо получить доступ к некоторым локальным ресурсам (config?) Для сопоставления виртуального.

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