Ошибка 500.19 - Сайт IIS 7.5 на основе UNC - проблема с правами доступа к файлам - PullRequest
1 голос
/ 23 мая 2011

Я пытаюсь заставить веб-сайт в моем IIS 7.5 (машина с Win 7 Pro) работать по UNC-пути к коду для одного из веб-сайтов по умолчанию и базового приложения.Это первый раз, когда я пытался настроить сайт / приложение в IIS 7.5 на основе пути UNC: папка на другом сервере в том же домене.

Я пробовал разные вещи, чтобы попробоватьчтобы решить это.Пул приложений работает под ApplicationPoolIdentity на моем компьютере с Win 7 Pro, где у меня настроен этот сайт.

Ошибка времени выполнения, возникающая при попытке запустить приложение в браузере с помощью http://localhost/TheAppNameis:

Модуль: IIS Web Core
Уведомление: Неизвестно
Обработчик: Еще не определено
Код ошибки: 0x800700005
Ошибка конфигурации: Невозможно прочитать файл конфигурации из-за недостаточных прав доступа
Файл конфигурации: \\?\UNC\theServerName\www\TheAppName
Запрошенный URL: http://localhost:80/TheAppName
Физический путь: (здесь ничего не отображается)
Метод входа в систему: Пока не определено
Пользователь входа в систему: Еще не определено

Я ввел поддельные имена для сервера и имя приложения выше для конфиденциальности этого сообщения.

Так что возникают проблемы при чтенииweb.config обнаружил в этом пути UNC для этого сайта.

Я попытался добавить локального пользователя на целевой сервер, а затем дал этому пользователю разрешения наb.config, а затем использовал этого пользователя RemoteServerName\LocalUserICreated в качестве удостоверения пула приложений на моем компьютере, но это не имело никакого эффекта.

Не знаю, что здесь делать и как это делать.

Ответы [ 4 ]

2 голосов
/ 23 мая 2011

Я предполагаю, что путь UNC - к другому серверу?

Если да, оба сервера находятся в одном домене?Если это так, то IIS должен запустить веб-сайт под учетной записью пользователя, которая имеет права на чтение файлов.

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

Надеюсь, это поможет / работает.

1 голос
/ 18 июля 2012

Мне потребовалось несколько часов, чтобы наконец решить эту проблему для себя. Оказалось, я использовал неправильные косые черты на моем физическом пути. Должно быть \ это, а не // это.

1 голос
/ 23 мая 2011

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

В диалоговом окне «Добавить приложение» под разделом «Физический путь» находится кнопка «Подключиться как ...» - затем вы можете выбрать «Пользователь приложения (сквозная аутентификация)» или «Определенный пользователь».

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

Когда нам нужно было сделать это в прошлом, мы создавали учетную запись в домене, под которой будет запускаться локальный AppPools, а затем это можно было бы использовать и в этих ситуациях.

Если вы уже создали приложение, доступ к диалоговому окну можно получить по ссылке действия «Основные настройки ...».

0 голосов
/ 27 сентября 2018

Zhaph и Alan оба определяют обходной путь, предложенный Microsoft. Вот остальная информация со страницы Microsoft по вашей проблеме :

Причина

IIS 6.0 использует удостоверение рабочего процесса хостинга для подключения к удаленному каталогу. Затем IIS 6.0 аутентифицирует пользователя по удаленному каталогу. Однако в IIS 7.0 представлены сценарии делегирования. В IIS 7.0 вы можете делегировать настройки веб-сайта и настройки уровня приложения в файл Web.config.

Для сквозной аутентификации файл Web.config хранится в каталоге UNC. Поэтому удостоверение процесса по умолчанию в IIS 7.0 должно сначала проверить файл Web.config, чтобы определить, следует ли применять какие-либо параметры безопасности перед началом процесса проверки подлинности. У удостоверения процесса по умолчанию в IIS 7.0 недостаточно прав для открытия файла Web.config. Таким образом, веб-запрос отклонен.

Если в каталоге UNC нет файла Web.config, IIS 7.0 использует правила, определенные для родительского каталога. Чтобы веб-контент обслуживался в этом сценарии, удостоверение рабочего процесса должно иметь доступ ко всему каталогу контента. В противном случае веб-запрос отклоняется.

Разрешение

Чтобы устранить это поведение и убедиться, что сквозная аутентификация работает правильно, выполните следующие действия:

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

    Примечание. Это поведение аналогично поведению в IIS 6.0.

  2. Убедитесь, что удостоверение рабочего процесса IIS выполняется под учетной записью домена или под учетной записью рабочей группы, которая также существует на файловом сервере UNC. Если это необходимо, создайте учетную запись на файловом сервере UNC с тем же именем пользователя и тем же паролем, что и идентификатор рабочего процесса IIS.

    Примечания

    • Это поведение отличается от поведения в IIS 6.0.
    • По умолчанию пул приложений DefaultAppPool работает под учетной записью сетевой службы. Эта учетная запись является локальной для компьютера, и эта учетная запись не существует на другом компьютере. Поэтому убедитесь, что вы настроили пул приложений DefaultAppPool для использования учетной записи, являющейся пользователем домена. Затем вы можете использовать ту же учетную запись на файловом сервере UNC. Кроме того, вы можете создать учетную запись рабочей группы на файловом сервере UNC и на компьютере под управлением IIS 7.0.
  3. Если в каталоге UNC есть файл Web.config, отредактируйте список контроля доступа (DACL) для файла Web.config, чтобы в DACL содержалась учетная запись, которую вы проверили на шаге 2. В качестве альтернативы, измените DACL для файла Web.config, чтобы DACL содержал учетную запись, созданную на шаге 2.

    Если в каталоге UNC нет файла Web.config, отредактируйте DACL для каталога UNC, чтобы DACL содержал учетную запись, которую вы подтвердили на шаге 2. В качестве альтернативы отредактируйте DACL для каталога UNC, чтобы DACL содержит учетную запись, созданную на шаге 2.

    Примечание. Это поведение отличается от поведения в IIS 6.0.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...