Iis iusrs что это
под Windows Server 2008 с ASP.NET 4.0 установлен целый ряд связанных учетных записей пользователей, и я не могу понять, какой из них, как они отличаются, и какой из них действительно тот, под которым работает мое приложение. Вот список:
1 ответов
это очень хороший вопрос, и, к сожалению, многие разработчики не задают достаточно вопросов о IIS / ASP.NET security в контексте веб-разработчика и настройки IIS. Вот так.
чтобы покрыть перечисленные идентификаторы:
IIS_IUSRS:
это аналогично старому IIS6 IIS_WPG группы. Это встроенная группа безопасности настроена таким образом, что любой член этой группы может выступать в качестве пула приложений тождественность.
IUSR:
этот счет аналогичен старому IUSR_ локальная учетная запись, которая была анонимным пользователем по умолчанию для веб-сайтов IIS5 и IIS6 (т. е. настроенная на вкладке Безопасность каталога свойств сайта).
подробнее о IIS_IUSRS и IUSR посмотреть:
DefaultAppPool:
если пул приложений настроен для запуска с помощью функции идентификации пула приложений, то «синтезированная» учетная запись называется IIS AppPool
будет создан на лету, чтобы использовать в качестве удостоверения пула. В этом случае будет синтезированная учетная запись под названием IIS AppPoolDefaultAppPool создано на время жизни бассейна. Если вы удалите пул, эта учетная запись больше не будет существовать. При применении разрешений к файлам и папкам необходимо добавить с помощью IIS AppPool
. Вы также не увидите эти учетные записи пула в Диспетчере пользователей компьютеров. Дополнительные сведения см. В следующем разделе:
ASP.NET v4.0: —
это будет идентификатор пула приложений для ASP.NET v4.0 Пул Приложений. См. DefaultAppPool выше.
NETWORK SERVICE: —
на NETWORK SERVICE учетная запись-это встроенный идентификатор представлен в Windows 2003. NETWORK SERVICE — это низко привилегированная учетная запись, под которой вы можете запускать пулы приложений и веб-сайты. Веб-сайт, работающий в пуле Windows 2003, все еще может олицетворять анонимную учетную запись сайта (IUSR_ или что бы вы ни настроили как анонимное удостоверение).
In ASP.NET до Windows 2008 вы могли бы иметь ASP.NET выполнение запросов под учетной записью пула приложений (обычно NETWORK SERVICE ). В качестве альтернативы вы можете настроить ASP.NET к олицетворение анонимной учетной записи сайта через настройка в web.config файл локально (если этот параметр заблокирован, то это должно быть сделано администратором в ).
задание распространен в средах общего хостинга, где используются общие пулы приложений (в сочетании с параметрами частичного доверия для предотвращения расплетения олицетворенной учетной записи).
в IIS7.x / ASP.Управление net impersonation теперь настроено через аутентификацию функция конфигурации сайта. Таким образом, вы можете настроить запуск в качестве идентификатора пула, IUSR или специального анонимного аккаунта.
LOCAL SERVICE:
на LOCAL SERVICE учетная запись-это встроенная учетная запись, используемая диспетчером управления службами. Она имеет минимальный набор привилегий на локальном компьютере. Он имеет довольно ограниченный объем использования:
LOCAL SYSTEM:
вы не спрашивали об этом, но я добавляю для полноты. Это локальная встроенная учетная запись. У него достаточно обширные привилегии и доверие. Никогда не следует настраивать веб-сайт или пул приложений для работы под этим удостоверением.
На Практике:
на веб-сайте вы должны затем настроить функцию аутентификации:
щелкните правой кнопкой мыши и отредактируйте анонимную аутентификацию запись:
обеспечить «удостоверение пула приложений» выбран:
когда вы приходите, чтобы применить права доступа к файлам и папкам, вы предоставляете удостоверение пула приложений, какие права требуются. Например, если вы предоставляете удостоверение пула приложений для ASP.NET v4.0 разрешения пула, то вы можете сделать это через Explorer:
нажмите Кнопка «Проверить имена»:
или вы можете сделать это с помощью ICACLS.EXE утилиты:
. или. если пул приложений сайта называется BobsCatPicBlog затем:
я надеюсь, это поможет прояснить ситуацию.
обновление:
я просто наткнулся на этот отличный ответ от 2009 года, который содержит кучу полезной информации, стоит прочитать:
В нашем примере будет использоваться 1C с локальной файловой базой
Установка IIS на Windows 7
Пуск — Панель управления — Программы и компоненты — Включение или отключение компонентов Windows
Выбираем необходимые компоненты: Службы IIS, ASP.NET, Консоль управления IIS и нажимаем ОК
Установка IIS на Windows Server
Установка IIS на Windows Server происходит аналогично через Добавление Ролей и компонентов
Настройка IIS под 1С
Добавление пользователя IUSR в группу IIS_IUSRS
Для настройки прав доступа необходимо добавить пользователя IUSR в группу IIS_IUSRS, иначе при попытке публикации 1С на сервер Вы будете получать ошибку
В эту группу нам необходимо добавить пользователя IUSR, для того чтобы предоставить необходимые права доступа, для этого жмем кнопку Добавить
Набираем имя пользователя IUSR и нажимаем кнопку Проверить имена, если пользователь будет найден, то он станет подчеркнутым, нажимаем ОК. Если пользователь не находится нажмите кнопку Размещение… и смените место поиска.
Проверяем, что наш пользователь появился и жмем ОК
Настройка сайта и приложения в IIS
В левой части экрана раскрываем ветку с сайтами. Останавливаем сайт по умолчанию Default Web Site или модифицируем его, я предпочитаю делать отдельный.
Жмем ПКМ на сайты и выбираем пункт Добавить веб-сайт
Заполняем параметры сайта
Имя сайта: Любое
Физический путь: Создаем каталог где будет храниться наш сайт (файлы сайта)
Тип: Выбираем протокол HTTP или HTTPS
Порт: Задаем порт, порт может быть любой свободный. Стандартный порт для HTTP — 80, для HTTPS 443
Сертификаты SSL: Сертификаты нужны если Вы используете защищенный протокол HTTPS. Если у Вас нет сертификата для Вашего узла, можно использовать серверный самоподписанный IIS Express Development Certificate.
Проверяем, что наш сайт появился и запустился
Вместе с сайтом так же должен был создаться пул приложений с таким же названием.
Переходим выше по ветке в раздел Пулы и приложений и находим наше приложение, в данном случае 1с
Выбираем наш пул приложений 1с и нажимаем в правой части Дополнительные параметры…
Настройка доступа для группы IIS_IUSRS
Настройка необходимого доступа для группы IIS_IUSRS, для корректной работы нашего сайта (1с) и корректной публикации.
Если группа найдена она станет подчеркнутой, жмем ОК.
Далее проставляем галочки необходимых прав:
— Чтение и выполнение
— Список содержимого папки
— Чтение
Тоже самое с правами, мы делаем для каталога куда установлена 1с и каталога куда развернута наша файловая база. Если Вы используете базу SQL, то Вам НЕ нужно задавать права на каталог с базой.
Обращаем внимание, что для каталога с базой так же нужны права на запись!
Расположение файловой базы Вы можете посмотреть запустив 1С Предприятие
Публикация 1с
Выбираем каталог где будут файлы сайта и жмем Опубликовать
Уязвимые места в защите Web-сервера могут привести к катастрофическим последствиям. Наглядный пример: Microsoft Internet Information Services (IIS) 5.0 печально известна недостаточной продуктивностью.
Успешное управление Web-сервером и уменьшение вероятности атак
Со временем компания Microsoft перепроектировала IIS с акцентом на безопасность. В результате появилась версия IIS 6.0, признанная самым надежно защищенным коммерческим Web-сервером (об этом свидетельствует малое число рекомендаций по продукту на сайте Secunia, см. secunia.com/product/1438).
В версии IIS 7.0 надежно защищенная архитектура IIS 6.0 получила дальнейшее развитие. Благодаря модульности можно полностью удалять отдельные компоненты, снижая вероятность атаки на Web-сервер. Пулы приложений, реализованные в IIS 6.0 с целью изолировать приложения друг от друга (и процессов Web-сервера), размещены в «песочнице». Новые функции делегирования позволяют владельцам управлять сайтами без необходимости в повышении прав. Фильтрация запросов с помощью URLscan встроена в сервер. А администраторы могут непосредственно в IIS 7.0 задать правила, указывающие, кто из пользователей имеет доступ к различным URL-адресам.
Эти новшества относятся к числу улучшений безопасности IIS 7.0. Они заслуживают внимательного изучения и могут даже заставить администраторов пересмотреть подходы к управлению и настройке Web-узлов.
«Песочницы» для приложений
Представим себе компанию, которая занимается исследованиями рынка и размещает аналитические отчеты или создает небольшие сайты для конкурирующих компаний на одном компьютере. Или представьте сервер, на котором размещены платежная ведомость для небольшого числа пользователей и самостоятельно разработанный внутренний портал компании. В обоих случаях важно, чтобы приложения, выполняемые на одном сервере, были изолированы друг от друга.
Web-приложения выполняются в рабочих процессах. Пулы приложений сопоставляют Web-приложения с рабочими процессами. Конкретный рабочий процесс используется только для приложений из одного пула. Файл рабочего процесса в IIS 6.0 и IIS 7.0 — w3wp.exe.
В IIS 6.0 новые Web-узлы и приложения размещаются в одном пуле приложений. Этот пул приложений по умолчанию работает с учетной записью NetworkService. Администратор может вручную создавать новые пулы приложений и распределять Web-приложения по пулам. По умолчанию эти пулы приложений также работают с учетной записью NetworkService, что может привести к нежелательным последствиям во время выполнения, когда все Web-приложения функционируют с одинаковыми правами. Приложение в пуле A может прочитать конфигурацию пула приложений B и даже получить доступ к содержимому файлов приложений пула B. Достаточно просто создать новые пулы приложений и настроить для каждого специальные учетные записи, но управлять этими учетными записями в течение длительного времени утомительно.
В IIS 7.0 для каждого Web-узла автоматически формируется новый пул приложений. По умолчанию этот пул приложений настроен на работу с учетной записью NetworkService. Но когда создается рабочий процесс, IIS 7.0 вставляет в маркер безопасности NetworkService специальный идентификатор SID, уникальный для пула приложений. IIS 7.0 также создает файл конфигурации для рабочего процесса и настраивает список управления доступом к файлу, разрешая обращения только к уникальному идентификатору SID для пула приложений. В результате конфигурация пула приложений не может быть прочитана другими пулами.
В качестве дополнительной меры предосторожности можно изменить списки управления доступом ACL файлов с контентом, чтобы предоставить доступ к уникальному идентификатору SID пула вместо NetworkService. Это помешает приложению в пуле A прочитать файлы контента приложения в пуле B.
IUSR и IIS_IUSRS
С идентификацией процесса косвенно связан вопрос об удостоверении, используемом сервером для анонимных запросов. В прошлых версиях IIS в качестве удостоверения для анонимных пользователей применялась локальная учетная запись IUSR_servername. В IIS 7.0 появилась новая встроенная учетная запись IUSR. Нельзя выполнить локальную регистрацию с учетной записью IUSR, поэтому у нее нет пароля (то есть нет опасности отгадывания паролей). Учетная запись IUSR всегда имеет один и тот же идентификатор SID, поэтому списки управления доступом можно переносить между компьютерами Windows Server 2008 (а также компьютерами Windows Vista). Если применять учетную запись IUSR нельзя (например, если анонимным запросам требуется доступ к сети с проверкой подлинности), можно отключить учетную запись анонимного пользователя, и IIS 7.0 будет применять для анонимных запросов учетные данные рабочего процесса.
Еще одно новшество — встроенная группа IIS_IUSRS. Эта группа заменяет группу IIS_WPG. В IIS 6.0 группа IIS_WPG обеспечивает минимальные права для запуска рабочего процесса, и администратор должен вручную добавить в эту группу учетную запись, чтобы предоставить пользовательские учетные данные для рабочего процесса. В IIS 7.0 аналогичную роль играет группа IIS_IUSRS, но явно добавлять учетные записи в группу не требуется. Вместо этого IIS 7.0 автоматически зачисляет учетные записи в IIS_IUSRS, когда они назначаются в качестве удостоверения для пула приложений. Как и учетная запись IUSR, группа IIS_IUSRS — встроенная, поэтому у нее всегда одинаковое имя и идентификатор SID во всех экземплярах Server 2008. В результате списки управления доступом и другие настройки полностью переносимы между компьютерами Windows Server 2008 (и Vista).
Делегирование функций
Не каждую настройку Web-сервера нужно защищать административными правами. Некоторые настройки представляют собой простые решения уровня приложения, которые могут быть выполнены разработчиками и менеджерами продуктов. Например, в IIS 6.0 административные права необходимы, чтобы изменить документ по умолчанию для Web-приложения. Но действительно ли для замены default.aspx на profile.aspx всегда требуются административные права?
В IIS 7.0 решения о конфигурации можно делегировать владельцам сайта или приложения. В IIS 7.0 применяется новая система настройки на основе XML, созданная по образцу ASP.NET. На уровне сайта и приложения параметры конфигурации как IIS 7.0, так и ASP.NET находятся в одинаковых файлах web.config.
Делегированные настройки, такие как документ по умолчанию, можно изменить на уровне Web-узла или приложения, непосредственно изменив файл web.config, или из графического интерфейса пользователя IIS Manager (Экран 1), который обновляет web.config за администратора. В разделе system.webServer файла web.config содержатся параметры конфигурации IIS 7.0, как показано на Экране 2.
Нужные разделы определены в специальном файле конфигурации, именуемом applicationHost.config. У каждого раздела applicationHost.config есть режим делегирования по умолчанию. В примере на Экране 3 можно изменить документ по умолчанию и настройки просмотра каталогов, но не разделы asp, caching и cgi.
Как поступить, если существуют веские основания запретить владельцу Web-узла изменять документ по умолчанию? Решение простое: в IIS 7.0 можно блокировать элементы конфигурации, которые в результате нельзя назначить или изменить в файлах web.config. В случае с документом по умолчанию можно глобально изменить стандартный режим переназначения на Deny или явно установить режим переназначения Deny для конкретных мест с помощью тегов расположения. Группа разработчиков IIS предложила вводить такие изменения с помощью тегов расположения, как показано в Листинге 1. Делегирование функций очень удобно для перегруженных работой администраторов, так как позволяет наделить владельцев Web-узлов и приложений правом управлять теми настройками Web-сервера, которые влияют лишь на их сайты и приложения
Административное делегирование
Многие администраторы считают целесообразным предоставить административный доступ всем, кому нужно изменить настройки сайта или приложения. Безусловно, такой подход связан с огромным риском. К сожалению, выбор оказывается сложным: можно или щедро назначать административные права или затруднить обновления, создав единую точку администрирования. В IIS 7.0 администратор сервера может предоставить административные права для конкретного Web-узла или приложения одному или нескольким пользователям, не повышая прав пользователей.
В IIS Manager, как показано на Экране 4, пользователи могут подключиться к серверу IIS 7.0 с применением учетных данных Windows или учетных данных IIS Manager. Удобство учетных записей IIS Manager заключается в том, что они обеспечивают очень узкий и ограниченный набор прав для пользователя: административные права Web-узла IIS. Эти учетные данные вне IIS Manager бесполезны.
Для дистанционного использования имеется автономная версия IIS Manager для Windows Vista, Windows Server 2003 и XP. Прежде чем установить удаленное соединение в IIS Manager, необходимо явно разрешить дистанционное управление на Web Server:
Правила брандмауэра или политики удаленного доступа могут затруднить дистанционное использование инструментов. По этой причине IIS Manager работает через протокол HTTPS, одновременно безопасный и согласующийся с брандмауэрами. По умолчанию служба Web Management Service использует самозаверяющий сертификат и прослушивает порт 8172.
Компания Microsoft предоставляет IIS 7.0 Manager для дистанционного управления по адресу www.iis.net/go/1524. Дополнительные ресурсы (в том числе подробные инструкции по настройке) можно найти, выполнив поиск с ключевыми словами «IIS 7.0 remote administration» на сайте iis.net. На этом сайте Microsoft приведены дополнительные сведения о новых компонентах IIS.
Встроенный фильтр запросов
Многие администраторы IIS-серверов знакомы с UrlScan, загружаемым инструментом для IIS 4.0 и более поздних версий, который ограничивает типы запросов, обслуживаемых IIS. Цель фильтрации запросов — защитить Web-сервер от потенциально опасных запросов.
В IIS 7.0 инструмент UrlScan был усовершенствован и вошел в состав модуля фильтрации запросов Web-сервера. Модуль фильтрации запросов отвергает запросы на основе настраиваемого критерия. Например, модуль может отвергнуть запросы с двойным кодированием или запросы необычного размера (большой объем полезных данных POST или слишком длинные URL-адреса). Можно также отвергать запросы по типу файлов, пути или командам HTTP, не поддерживаемым на сайте.
Настройку фильтрации запросов в IIS 7.0 можно делегировать, предоставив администраторам сайтов возможность определить собственные правила фильтрации в файлах web.config, чего нельзя сделать с помощью UrlScan в IIS 6.0.
Авторизация URL
У Web-приложений часто есть области, доступ к которым предоставляется только определенным пользователям. Например, только менеджеру разрешено обращаться к отчетам о продуктивности сотрудников в системе управления кадрами. Страницы с ограничением обычно группируются в каталогах с такими именами, как Administration, Reporting или Moderation. В прошлых версиях IIS было довольно неудобно организовать надежную защиту этих разделов от несанкционированного доступа. Даже при использовании встроенной функции ASP.NET авторизации URL необходимо защитить такие данные, как файлы PDF и Excel, не подходящие для ASP.NET. Для управления правилами URL-авторизации ASP.NET приходится прибегать к утомительному процессу редактирования XML.
В IIS 7.0 сохранилась URL-авторизация ASP.NET, но в самом Web-сервере появилась дополнительная функция авторизации URL. Доступом к материалам любого типа (например, статическим, PHP, ASP) можно управлять по пользователям, группам и URL-адресам. Например, не составляет труда предоставить доступ ко всем объектам на пути Reporting только пользователям, принадлежащим к группе Managers, не затрагивая списков доступа к файлам. На Экране 5 показана конфигурация правил авторизации URL в IIS Manager.
Правила авторизации URL сохраняются в разделе system.webServer файлов web.config с синтаксисом, чуть отличным от правил авторизации ASP.NET, как показано в Листинге 2.
Поскольку правила авторизации целиком содержатся в файлах конфигурации (локальных web.config), их легко переносить между приложениями и серверами. А авторизация URL в IIS 7.0 применима к пользователям и группам Windows, так же, как к пользователям и ролям ASP.NET.
IIS совершенствуется
Разработчики IIS 7.0 усовершенствовали добротную систему безопасности IIS 6.0, сохранив базовую архитектуру IIS 6.0 с моделью изоляции пулов приложений/рабочих процессов, которая оказалась очень эффективной. При обсуждении мер безопасности IIS 7.0 особое внимание уделяется новшествам модульной архитектуры, но благодаря автоматическому распределению приложений по «песочницам», делегированию функций и авторизации URL задача надежной защиты Web-сервера стала проще.
Об авторе: Дерек Хетчард (derek@ardentdev.com) — консультант и тренер, имеет звание Microsoft MVP
Листинг 1. Использование тегов расположения для назначения режима переназначения Deny
Понимание удостоверений в IIS
В этой статье приводится справочная информация о удостоверениях в службы IIS (IIS).
Оригинальная версия продукта: службы IIS
Исходный номер КБ: 4466942
Идентификаторы пула приложений
Чтобы понять идентификаторы пула приложений, необходимо понять, что такое удостоверение. Проще говоря, удостоверение — это Windows учетная запись. Каждый процесс, который Windows выполняется в соответствии с удостоверением. Приложения запускаются рабочим процессом с помощью Windows удостоверений. Используемый Windows зависит от удостоверения пула приложений, которое может быть любой из следующих учетных записей:
Различия между удостоверениями пула приложений
Сценарий 1. Доступ к журналу событий
В этом сценарии у вас есть одно веб-приложение, которое создает настраиваемый журнал событий (MyWebAppZone) и источник журнала событий (MyWebAppZone.com) во время запуска. Приложения, которые запускают с помощью любого из удостоверений, могут записываться в журнал событий с помощью существующих источников событий. Однако, если они работают под удостоверением, кроме локальной системы, они не могут создавать новые источники событий из-за недостаточного количества разрешений реестра.
Например, если вы запустите приложение в сетевой службе, вы получите следующее исключение для безопасности:
При одновременном запуске трассировки ProcMon часто бывает так, что NT AUTHORITY\NETWORK SERVICE не имеет необходимых привилегий для чтения и записи доступа к следующему подкою реестра:
Это расположение в реестре, где хранятся все параметры журнала событий.
Сценарий 2. Доступ к реестру
Кроме локальной системы, никакие другие удостоверения пула приложений не имеют доступа к реестру Записи. В этом сценарии вы разработали простое веб-приложение, которое может изменять и отображать имя сервера времени в Интернете, с Windows автоматически синхронизируется. Если вы запустите это приложение в локальной службе, вы получите исключение. Если вы проверяете трассировку ProcMon, вы найдете, что идентификатор пула приложений «NT AUTHORITY\LOCAL SERVICE» не имеет доступа к приложению Read and Write в следующем подкоге реестра:
Если вы проверяете журнал событий MyWebAppZone (из сценария 1), вы найдете следующее событие ошибки в журнале. Содержит сообщение Requested registry access is not allowed об ошибке.
Сценарий 3. Настраиваемая учетная запись в среде проверки подлинности Kerberos и сбалансированной нагрузкой
Вы уже видели в сценариях 1 и 2 некоторые различия между встроенными учетной записью. Теперь давайте обсудим, что такое настраиваемая учетная запись и как она имеет преимущества перед встроенными учетными записями при работе с проверкой подлинности Kerberos в сбалансированной среде нагрузки.
С помощью этого подхода вы запустите свое приложение в пуле приложений, который настроен для запуска с помощью определенного Windows удостоверения. Рассмотрим следующую схему, на которой приложение находится в сбалансированной нагрузкой среде, которая включает два сервера и использует проверку подлинности Kerberos для идентификации клиента.
Для работы проверки подлинности Kerberos необходимо настроить SPN для обоих серверов с помощью учетной записи машины. Если пул приложений работает под встроенной учетной записью, он представляет учетные данные компьютера в сети. Например, если имя компьютера — Server1, оно представляет себя как ‘Server1$’. Эта учетная запись компьютера автоматически создается, когда компьютер присоединяется к домену. Поэтому, если есть N-серверы, необходимо установить N-число spNs, соответствующих учетной записи соответствующего компьютера.
Регистрация SPN в учетной записи компьютера:
Чтобы преодолеть этот недостаток, можно запустить приложение в настраиваемом удостоверении Windows домена, а затем установить spN только для конкретной учетной записи домена в контроллере домена.
Регистрация SPN в учетной записи домена:
Разрешения и права пользователей по умолчанию в wwwroot
IiS 7.0 и более поздние версии также упрощают настройку удостоверения пула приложений и внесение всех необходимых изменений. Когда IIS запускает рабочий процесс, он должен создать маркер, который будет использовать этот процесс. Когда этот маркер создается, IIS автоматически добавляет членство в маркер рабочих IIS_IUSRS процессов во время запуска. Учетные записи, которые работают в качестве удостоверений пула приложений, больше не должны быть явной частью IIS_IUSRS группы. Если вы создаете веб-сайт, а затем указывают физическое расположение следующим пользователям и группам, автоматически добавляются в списки управления C:\inetpub\wwwroot доступом на сайте.
| Пользователи / группы | Разрешенные разрешения |
|---|---|
| СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ | Специальные разрешения |
| SYSTEM | Полный доступ |
| Администраторы | Полный доступ |
| Пользователи | Чтение &, содержимое папки List, Чтение |
| IIS_USRS | Чтение & выполнения |
| TrustedInstaller | Полный доступ |
Если вы хотите отключить эту функцию и вручную добавить учетные записи в группу, установите значение IIS_IUSRS manualGroupMembership в файлеApplicationHost.config. В следующем примере показано, как это можно сделать для пула приложений по умолчанию:
Понимание изоляции конфигурации
Рабочие процессы IIS не имеют доступа кApplicationHost.configфайлу. Таким образом, вы можете задаться вопросом, как они могут читать любые наборы конфигураций в этом файле.
Ответ заключается в использовании функции изоляции конфигурации в iiS 7.0 и более поздних версиях. Вместо того чтобы дать рабочим IIS возможность читатьApplicationHost.configнепосредственно при прочтение иерархии файлов конфигурации, служба активации Windows процесса (WAS) создает отфильтрованные копии этого файла. Каждый рабочий процесс IIS использует эти копии в качестве заменыApplicationHost.configпри считывке конфигурации внутри рабочего процесса IIS. Эти файлы создаются по умолчанию в %SystemDrive%\inetpub\Temp\appPools каталоге и называются
Дополнительные информацию о SID см. в разделе Идентификаторы безопасности на веб-сайте Microsoft Docs.
Это делается для того, чтобы рабочие процессы IIS из пула приложений A не могли читать сведения о конфигурации в файлеApplicationHost.config, предназначенного для пула приложений B.
ApplicationHost.config могут содержать конфиденциальные персональные данные, такие как имя пользователя и пароль для пользовательских удостоверений пула приложений или имя пользователя и пароль для виртуальных каталогов. Таким образом, разрешение доступа ко всем пулам приложенийApplicationHost.config может нарушить изоляцию пула приложений. Если каждому пулу приложений был предоставлен прямой доступ к файлуApplicationHost.config, эти пулы могли легко взломать конфиденциальные сведения из других пулов приложений, выдав следующую команду:
IUSR — анонимная проверка подлинности
Анонимные проверки подлинности позволяют пользователям получать доступ к общедоступным областям веб-сайта без запроса имени пользователя или пароля. В IIS 7.0 и более поздних версиях встроенная учетная запись используется для IUSR предоставления анонимного доступа. Эта встроенная учетная запись не требует пароля. Это будет идентификатор по умолчанию, который используется при включенной анонимной проверке подлинности. В файлеApplicationHost.config вы можете увидеть следующее определение:
Это указывает IIS на использование новой встроенной учетной записи для всех анонимных запросов на проверку подлинности. Самыми большими преимуществами для этого являются следующие:
Кроме того, вы можете предоставить анонимное удостоверение подлинности на веб-сайте с помощью определенной Windows учетной записи или удостоверения пула приложений вместо IUSR учетной записи.
IUSR и Подключение как
Подключение как вариант в IIS, который позволяет определить, какие учетные данные вы хотите использовать для доступа к веб-сайту. Вы можете использовать либо проверку подлинности учетных данных пользователей, либо конкретные учетные данные пользователей. Чтобы понять разницу, рассмотрим следующий сценарий:
У вас есть веб-сайт по умолчанию, настроенный для использования анонимной проверки подлинности. Однако содержимое веб-сайта на другом сервере, и вы используете Подключение в качестве раздела для доступа к этому ресурсу через Test пользователя домена. При входе пользователя он получает проверку подлинности с помощью учетной записи IUSR. Однако к контенту веб-сайта можно получить доступ через учетные данные пользователей, указанные в Подключение в разделе.
Проще говоря, анонимная проверка подлинности — это механизм, используемый веб-сайтом для идентификации пользователя. Но при использовании этой функции пользователю не нужно предоставлять учетные данные. Однако может быть похожий сценарий, в котором содержимое на сетевой совместной основе. В таких случаях для доступа к сетевой сети нельзя использовать встроенные учетные записи. Вместо этого для этого необходимо использовать определенную учетную запись (домен).
ASP.NET вымысление
В буквальном смысле, выдав себя за другого человека, выдав себя за другого человека. С технической точки зрения это ASP.NET, которая обеспечивает возможность управления удостоверением, под которым работает код приложения. Обезличение происходит, ASP.NET выполняет код в контексте аутентификации и авторизованного клиента. IIS предоставляет анонимный доступ к ресурсам с помощью учетной IUSR записи. После того как запрос передается в ASP.NET, код приложения запускается с помощью удостоверения пула приложений.
В коде IIS и ASP.NET можно включить обезличение, если приложение использует анонимную проверку подлинности, и если одно из следующих условий верно:
При включении с помощью IIS в файле Web.config приложения добавляется следующий тег, чтобы выдать себя за учетную запись IIS с проверкой подлинности impersonation или пользователя:
Чтобы выдать себя за конкретного пользователя для всех запросов на всех страницах приложения ASP.NET, можно указать имя пользователя и атрибуты пароля в теге файла Web.config для этого приложения.
Откройте рабочий процесс IIS тестового веб-сайта, который является локальным пользователем, и проверьте, можно ли найти учетную запись для обезличения, под которой работает код Test приложения.
