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

13

У меня есть виртуальный каталог на моем сайте (тестовая среда). Это общий ресурс 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 и того же пользователя, что он работает. Просто на тестовом сервере его нет.

Что я делаю неправильно?

iis permissions unc virtual-directory Роб Стивенсон-Леггетт
источник

Ответы:

10

Тот факт, что это приложение 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
mfinni
источник
7

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

IT Action
источник
3
Потратив 5 часов на поиски решения, наконец, решение IT Action сработало для меня. Итак, я создал абсолютно одинаковых пользователей на обеих машинах, а затем настроил пул приложений для запуска с использованием этой учетной записи. Я как раз собирался сходить с ума по этому поводу. Наконец-то решено. Надеюсь, что это помогает всем иметь ту же проблему
Массив +1. Я в той же лодке, что и @ user249232 - создание зеркальной учетной записи на IIS-машине сразу решило проблему после долгих поисков. Однако я установил для пользователя значение «Подключиться как» в основных настройках сайта, а не путем изменения идентификатора пула приложений.
Скраффи
1
Престижность, для которой работает это решение, но это ужасное решение для меня, так как я не хочу пытаться имитировать настройку имени пользователя моего домена corp в собственной настройке vbox linux, в которой я использую другое соглашение об имени пользователя. Синхронизация паролей представляет собой дополнительную сложность, которая для меня является чрезмерной, поскольку я уже использую разделенные серверы (iis на моем хосте и php56 на linux, чтобы иметь доступ для композитора)
Брайан Томас
потратив 2 дня. Это сработало для меня. Даже я попробовал те же самые полномочия, и это не работало. Наконец это работает после перемещения этого общего пользователя в группу администраторов
Ketan Kotak
2

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

Эмре Гулдоган
источник
1

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

user48838
источник
3
Если бы это было не приложение ASP.net, вы были бы на деньги. Поскольку он работает в пуле приложений, ему нужен доступ, а не учетная запись пользователя IIS.
mfinni
1

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

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

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

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

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

jprmsn
источник