Краткая версия:
Для веб-приложений IIS 7.5 с проверкой подлинности Windows завершается пользователь должен иметь доступ к файлу Read?
Длинная версия:
У меня есть веб-приложение ASP.NET для интрасети, использующее проверку подлинности Windows. Он установлен на десятках разных компаний, и обычно аутентификация работает нормально: пользователи переходят на сайт, например. http://appserver/MyApp, приложение распознает, во что они вошли, и отображает страницы соответственно. Я просто установил его у нового клиента и столкнулся с проблемой:
При подключении, например, на http://appserver/MyApp Мне будет предложено ввести учетные данные Windows, но после ввода их мне будет предложено повторно. После нескольких повторных ввода учетных данных мне показана страница с ошибкой 401 с сообщением "401 - Несанкционированное: доступ запрещен из-за недопустимых учетных данных". Таким образом, он не только не проходит через мою личность, но даже при вводе имени пользователя и пароля он все еще отрицает доступ.
Предоставление разрешений для чтения и выполнения конечным пользователям приложения решает эту проблему, но я не думаю, что это должно быть необходимо вообще.
В журнале событий приложений Windows появляется сообщение "Авторизация авторизации для запроса" вместе с именем учетной записи Thread: NT AUTHORITY\NETWORK SERVICE и User: [правильная учетная запись домена пользователей рабочей станции]. Это говорит о том, что доступ к файлам выполняется с идентификатором пользователя, а не с идентификатором AppPool сетевой службы. Разумеется, если я дам разрешение на чтение и выполнение конечного пользователя (я не пробовал только чтение) в каталог приложения, тогда все будет работать правильно: когда пользователь просматривает сайт, они автоматически аутентифицируются, не запрашиваются, а веб-сайт правильно распознает их личность! Поэтому мое решение проблемы заключается в предоставлении Read и Execute разрешения для Everybody в каталоге приложений... но это не идеальное решение.
Это кажется очень странным. Я никогда не делал этого раньше в IIS 7.5, насколько я помню, и определенно никогда не нуждался в IIS 6 или IIS 7. Является ли это новой версией IIS7.5? В документации указано, что олицетворение отключено по умолчанию. Я добавил элемент в web.config, конечно, удалил права на файлы, отличные от Network Service, но проблема осталась.
Любые мысли? Нормально ли для Windows Authenticated sites в IIS 7.5 для конечных пользователей необходимы разрешения на файлы в файлах веб-сервера?
Некоторые релевантные детали:
- Сетевая служба имеет права доступа к файлу полного доступа к папке приложения.
- При подключении к самому серверу мне было предложено ввести учетные данные
но после ввода их я аутентифицирован и приложение работает
правильно, включая отображение моего входа в Windows и подключение и
извлечение данных из db. Позже я решил, что это побуждает
для учетных данных, потому что
http://localhostнаходился на доверенных сайтах и поэтому не признается в качестве зоны интрасети и, следовательно, не передавая идентичность через. Я также решил, что он работает как этот идентификатор пользователя, поскольку он является администратором, у которого есть файл разрешения. - На веб-сервере работает Windows Server 2008 R2/IIS 7,5. На нем не было IIS, пока я не установил его. Я установил функции по умолчанию, а также Windows Authentication, ASP.NET и возможно, несколько других предметов. Отдельное приложение WCF, которое я установил использует IIS, анонимная аутентификация и .net 2.0 работает нормально этот веб-сервер.
- Процесс установки приложения - это ручная копия файлов, создание пулов приложений IIS и веб-приложений, обновление строк подключения, и т.д.
- Я проверил настройки безопасности IE. Было признано как в зоне интрасети, и имел опцию "Автоматический вход в систему" только в зоне интрасети ". Также в разделе" Дополнительные настройки "Была отмечена опция" Включить встроенную проверку подлинности Windows".
- После того, как
установка IIS Я запустил
aspnet_regiis -iдля .net 2.0 иaspnet_regiis -iruдля .net 4.0. - Анонимная аутентификация отключено для моего приложения и Windows Authentication.
- Приложение работает на ASP.NET v4, но есть другое приложение, которое я установил испытывая ту же проблему, что и ASP.NET v2.
- Приложение запущено с Identity = Network Service и в 32-битном режиме.
- Database
строка подключения включает
Trusted Connection=Trueи базу данных разрешения предоставляются учетной записи веб-сервера[domain]\[server]$напримерDGM\MyServer$. - В IIS > Аутентификация > Аутентификация Windows > Провайдеры, в списке был Negotiate first, затем NTLM. Я попробовал переупорядочить так, чтобы NTLM был первым.
- В журнале событий безопасности Windows были серии событий аудита безопасности Microsoft Windows: вход в систему и выход из системы. Они указали, что Logon был успешным и был отображение Идентификатора пользователя пользователя рабочей станции. Это от того времени, когда Я подключаюсь с другой рабочей станции и получаю 401 Несанкционирован после нескольких попыток.
Я вижу, что у этой проблемы была проблема здесь, но без решения. Первоначально я опубликовал в ASP, а затем IIS форумы без ответов.
Обновление: В этой статье msdn говорится
Когда проверка подлинности Windows включена, но олицетворение отключено, ASP.NET выполняет проверки доступа к файлам в авторизация файла модуль , используя учетные данные, которые отправляются из браузера (мой акцент). Олицетворение не должно быть включено, поскольку модуль FileAuthorizationModule гарантирует, что запрашивающему пользователю разрешен доступ на чтение или запись доступа к ресурсу, в зависимости от глагола запроса (например, GET или POST) перед выполнением запроса. Это относится к любым запросам, которые вводят управляемый код. В более ранних версиях ASP.NET доступ к файлам на основе URI, таких как "Default.aspx", вызвал проверку доступа. В приложениях ASP.NET MVC, где доступ к ресурсам обычно выполняется с использованием URL-адресов без продолжения, эта проверка обычно не применяется, потому что нет физического файла для проверки. В этом случае класс FileAuthorizationModule возвращается к проверке списков управления доступом (ACL) для этой папки.
Это означает, что конечный пользователь нуждается в разрешениях для файлов (в случае .aspx) или в папке (для MVC)... хотя все же это кажется слегка спрятанным и не определенным. В этой статье о пулах приложений говорится, что они используются как идентификатор для защиты ресурсов, что противоречит идее предоставления привилегий конечным пользователям. Если правила не отличаются для пулов приложений и NETWORK SERVICE, что может быть так, но было бы удивительно.
