Defaultapppool что за папка windows 10

Application Pool Identities в IIS

Каждый пул приложений в IIS использует свой собственный рабочий процесс (IIS Worker Process). Удостоверение пула приложений (Application Pool Identities) представляет из себя имя учетной записи, под которой выполняется рабочий процесс этого пула.

В IIS 6.0 и IIS 7.0 пул приложений по умолчанию работал под встроенной системной учетной записью NetworkService. Эта запись не требует пароля и имеет на локальном компьютере ограниченные права, что является хорошей практикой с точки зрения безопасности. Однако под этой учетной записью могут одновременно работать разные системные службы Windows, и при использовании одного и того же идентификатора одни службы могут воздействовать на работу других.

Начиная с Windows Server 2008 SP2 для того, чтобы изолировать рабочие процессы IIS от других системных служб, можно использовать виртуальные учетные записи (Virtual Accounts). Они позволяют запускать рабочий процесс для каждого пула приложений под собственной уникальной учетной записью ApplicationPoolIdentity. Эта учетная запись не требует управления и создается автоматически при создании каждого нового пула. Также она не имеет практически никаких привилегий в системе и не использует профиль пользователя, что повышает безопасность веб-сервера.

Для примера возьмем Application Pool с именем PubSite1. Открываем Task Manager и находим рабочий процесс IIS (w3wp.exe), выполняющийся от имени PubSite1. Как видите, имя учетной записи совпадает с именем пула приложений. Дело в том, что начиная с IIS 7.5 для каждого вновь созданного пула приложений по умолчанию создается виртуальная учетная запись с именем этого пула, и его рабочий процесс запускается из под этой записи.

Настройка типа удостоверения пула приложений

При необходимости тип идентификации пула приложений можно изменить. Для этого запускаем IIS Manager, переходим в раздел Application Pools, выбираем нужный пул и открываем его свойства (Advanced Settings).

В свойствах выбираем пункт Identity.

Здесь мы указываем учетную запись, от имени которой будет работать данный пул приложений:

• ApplicationPoolIdentity — учетная запись удостоверения пула приложений. Создается автоматически при запуске пула приложений и имеет самые минимальные права на локальном компьютере. Это наиболее безопасный вариант, начиная с IIS 7.5 используется по умолчанию;
• LocalService – встроенная учетная запись, которая имеет ограниченные права на локальном компьютере. Примерно то же самое, что и NetworkService, но ограничена только локальным компьютером;
• LocalSystem – системная учетная запись, имеющая неограниченные права на локальном компьютере. Наименее безопасный вариант, по возможности не рекомендуется ее использовать;
• NetworkService — учетная запись, которая имеет ограниченные права на локальном компьютере, а также может использоваться для доступа к ресурсам в сети Active Directory на основании учетной записи компьютера.

Кроме того, в качестве удостоверения можно использовать и обычную учетную запись пользователя. Для этого надо выбрать Custom Account, нажать кнопку Set и ввести имя пользователя и пароль. Можно указать любого доменного или локального пользователя.

Примечание. При использовании учетной записи пользователя надо отслеживать срок действия пароля и своевременно менять его.

То же самое можно сделать с помощью утилиты командной строки appcmd. Чтобы указать учетную запись, которая будет использоваться для пула приложений, используется следующий синтаксис:

appcmd set config /section:applicationpools /[name=″имя пула приложений″].processModel.identityType:SpecificUser|NetworkService|LocalService|LocalSystem

Для примера изменим тип удостоверения для пула приложений PubSite1 на NetworkService:

appcmd set config /section:applicationpools
/[name=″PubSite1″].processModel.identityType:NetworkService

Профиль пользователя

Если вы хотите настроить ApplicationPoolIdentity на использование пользовательского профиля, то надо зайти в расширенные свойства пула и перевести параметр Load User Profile в состояние True.

Настройка доступа к ресурсам

Иногда веб-приложению может потребоваться доступ к определенной папке или файлу на диске. Чтобы добавить ApplicationPoolIdentity в Access Control List (ACL):

• Запускаем Windows Explorer;
• Выбираем нужный файл или директорию, кликаем по ней правой клавишей мыши и выбираем пункт Свойства (Properties);
• Переходим на вкладку Безопасность (Security),
• Кликаем по кнопке Изменить (Edit), затем Добавить (Add);
• В поле Размещение (Locations) выбираем локальную машину;
• Вводим имя пользователя в виде ″IIS AppPoolимя пула приложений″. Так для пула приложений PubSite1 имя пользователя будет выглядеть ″IIS AppPoolPubSite1″;
• Проверяем имя клавишей Проверить имена (Check Names) и жмем ОК.

Также при желании можно воспользоваться утилитой командной строки ICACLS. Для примера дадим права на изменение для PubSite1:

ICACLS C:WebPubsite1 /grant ″IIS AppPoolPubSite1″:M

Список разрешений выглядит следующим образом:

D – удаление;
F – полный доступ;
M – изменение;
RX – чтение и выполнение;
R – чтение;
W – запись.

Если ресурс находится в сети, то для доступа к нему лучше всего использовать учетную запись NetworkService. Рабочий процесс, запущенный под этим аккаунтом, для доступа к ресурсам использует учетные данные компьютера, сгенерированные при добавлении компьютера в домен. Для того, чтобы дать процессу доступ к сетевому ресурсу, в качестве пользователя указываем компьютер:

• Выбираем тип объекта (Object Type) Computers;
• В поле Размещение (Locations) выбираем домен;
• Вводим имя пользователя в виде domainnamemachinename$, например contosoSRV12$;
• Проверяем имя и жмем ОК.

Очень удобный способ предоставлять доступ к сетевым ресурсам типа файловых шар или баз данных SQL Server. Однако работает он только при наличии домена AD.

Источник

adontz

Загадочный пользователь «IIS APPPOOLDefaultAppPool»

Именно в контексте пользователя “IIS APPPOOLDefaultAppPool” исполняется пул приложений по умолчанию в IIS7. Выглядит достаточно странно, как будто есть новый домен “IIS APPPOOL” (ну и название, клавиши залипали что ли) и в нём создан пользователь DefaultAppPool.

Идея, в принципе, хорошая, – разделить недоверенные приложения IIS и все остальные сетевые приложения, исполняющиеся в контексте NETWORK SERVICE. А вот реализация, как это нередко бывает, так себе. В частности через графический интерфейс для пользователя “IIS APPPOOLDefaultAppPool” нельзя установить права доступа на файлы. Ответ старый – командная строка. Простая команда

Создаст некоторые начальные права. А вот редактировать их уже можно через графический интерфейс.

Like this:

4 thoughts on “ Загадочный пользователь «IIS APPPOOLDefaultAppPool» ”

А как быть с SQL сервером?

А что с SQL сервером?

Кстати, в Windows 7 права можно установить сразу через графический интерфейс – для этого нужно задавать полное имя пользователя «IIS APPPOOLDefaultAppPool» и установить местонахождение – компьютер, на котором устанавливаются права.ПРоблема возникает, когда нужно запустить DCOM компонент (например Word или Excel). В этом случае, как ни настраивай прва доступа, он все равно упорно пытается запустить его под пользователем пула. МОжет кто-нибудь решил подобную проблему?

Примерный скрипт для SQL
USE [master]
GO
CREATE LOGIN [IIS APPPOOLDefaultAppPool] FROM WINDOWS WITH DEFAULT_DATABASE=[Amethyst]
GO
USE [Amethyst]
GO
CREATE USER [iis] FOR LOGIN [IIS APPPOOLDefaultAppPool]
GO
ALTER ROLE [db_datareader] ADD MEMBER [iis]
ALTER ROLE [db_datawriter] ADD MEMBER [iis]
GO

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Источник

Defaultapppool что за папка

Удаляем пользователя DefaultUser0 в Windows 10

Здравствуйте. С выходом некоторых обновлений Виндовс 10 многие пользователи столкнулись со следующей проблемой. После установки ОС в системе появляется аккаунт пользователя, который может быть заблокирован паролем, и убрать его привычными методами не удается. Сегодня я расскажу, как DefaultUser0 Windows 10 удалить за несколько минут. Поделюсь всеми способами, которые доказали свою эффективность.

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

DefaultUser0: что за пользователь?

Это значение, которое операционка присваивает по умолчанию, если невозможно создать пользовательский аккаунт вследствие критической ошибки. Стоит отметить, что дефект не исчезает даже когда Вы:

Методы удаления

Как видите, назвать точную причину пока не может никто. Уверен, Вас больше интересуют пути выхода из «кризиса». Предлагаю несколько способов, которые помогут DefaultUser0 удалить раз и навсегда!

Используем командную строку

Чтобы применить следующую инструкцию, Вы должны быть в системе. Если перед Вами появляется следующее окно, и Вы не знаете какой пароль, то необходимо загрузиться с диска восстановления (о его создании подробно читайте здесь):

net user /delete defaultuser0

Можете просто скопировать данный код из моей инструкции и вставить его в командную строку, кликнув правой кнопкой мыши.

Можно ли удалить папку defaultuser0? Не только можно, но и нужно! Заходим в проводник, открываем системный диск (обычно, «С») и там в папочке USERS удаляем каталог уже несуществующего пользователя!

Через панель управления

Сразу же перейду к инструкции:

Включаем скрытый аккаунт админа

Данный вариант является единственным путем обхода пароля, который Вы не знаете (увы, никто его не знает, поэтому, можете не искать его в сети).

Этот метод подразумевает запуск системы с диска (флешки) восстановления. Только нужно выбирать не установку Виндовс, а модуль устранения неполадок (ремонт). В этом режиме можно добраться до утилиты командной строки, которая нам как раз и понадобится.

Вводим следующую команду для активации администраторских полномочий:

net user administrator /active:yes

Подтверждаем ввод нажатием клавиши Enter и перезапускаем компьютер. Теперь следует войти в систему под новым аккаунтом админа и удалить ненужного пользователя одним из перечисленных выше способов.

«Юбилейное» обновление

Переходим к последнему методу — удаляем Defaultuser0 в Windows 10 Anniversary Update. В данном случае предыдущие «спасательные» мероприятия могут не сработать. Придется действовать по-другому.

Вот и всё! Не могу гарантировать, что тот или иной способ обязательно Вам поможет. Нужно пробовать: не подойдет один – пробуйте следующий. Будем надеяться, что в скором времени Microsoft выпустит обновление, которое устранит проблему. Жду Ваши комментарии с отзывами об инструкции. Если что-то не получается – обязательно напишите мне.

С уважением, Виктор!

Дело в том, что Windows — это очень странная штука. ) Хотя, на самом деле, имеются скрытые файлы, которые занимают место. Ла и сами папки (даже пустые) имеют некоторый вес.

Равиль, возможно там есть системные или скрытые файлы, которые не видны на первый взгляд. Поэтому так и набирается размер.

Добрый день всем.
Хочу поделиться одним полезным наблюдением.
Купил ноутбук с уже предустановленной Windows 10. Активировал через учетную запись Microsoft. При следующем запуске с изумлением увидел (при запросе пароля) еще две учетные записи с именем «defaultuzer0». Вышел в учетные записи (через параметры), но там числилась только одна такая, которую я удалил (ПК не перезагружал). После этого вышел в учетные записи пользователей (через «netplwiz» в «Выполнить»), там также видел такую запись – удалил. Снял галку с требования запроса пароля, дважды ввел пароль и успокоился.
Зря.
В следующий раз опять запрос пароля для «defaultuzer0», но он был уже один.
Долго пытался его найти, но его не было ни в реестре ни где-либо ещё.
Почти дошел до отчаяния.
В результате от «defaultuzer0» я избавился с помощью командной строки, НО еще некоторое время не знал об этом, т.к. при запуске все же запрашивался пароль.
Истерика и желание послать все на … была близка, но решил в еще раз пройти все варианты.
После каждого варианта перезагружал ноутбук в надежде, что чудо свершилось. Но увы…
Последним вариантом оставалось в учетной записи пользователей (через «netplwiz» в «Выполнить») снять галку с требования запроса пароля.
Вошел. Смотрю галка снята.
Решил поставить галку и снять еще раз. Так и сделал. Ввел дважды пароль и опять запустил перезагрузку.
Каково же было мое изумление, когда винда загрузилась без запроса пароля.
Полагаю, всем будет полезна эта информация, что данная функция может не сработать с первого раза.

Папка Inetpub: что в ней хранится и можно ли её удалить

Изучая содержимое раздела жёсткого диска, отведённого под операционную систему, можно увидеть папку Inetpub. В ней хранится информация, необходимая для работы одного из сервисов Windows 10. Но в некоторых случаях сервис можно отключить, а папку — удалить.

Для чего нужна папка Inetpub

Папка Inetpub создаётся процессом IIS (Internet Information Services), входящим в состав Windows 10. Этот процесс реализует системный сервис, отвечающий за настройку интернет-серверов, передачу файлов по локальной сети и использование различных протоколов обмена данными. В папке Inetpub сервис хранит информацию об имеющихся серверах и их настройках. По умолчанию служба IIS в операционной системе Windows 10 деактивирована, но если её включает пользователь или сторонняя программа, то на диске появляется папка Inetpub.

Можно ли удалить папку Inetpub

Если вы не пользуетесь штатными средствами Windows для создания и обслуживания интернет-серверов, то и процесс IIS, и папка Inetpub вам не пригодятся. Отключение службы и удаление папки вместе с её содержимым не навредит системе, тем более что вы всегда сможете заново активировать IIS и вернуть папку.

IIS имеет смысл отключить не только из-за того, что папка Inetpub занимает место на диске. Работая в фоновом режиме, служба IIS забирает часть ресурсов системы, что снижает производительность и замедляет скорость загрузки компьютера. Конечно, радикальным образом отключение этой службы работу компьютера не улучшит, но если стремиться оптимизировать систему по максимуму, то избавиться от неё можно.

Войдите в раздел «Администрирование» панели управления Windows чтобы определить, запущен ли процесс IIS

Удаление папки Inetpub

Если вы отключили службу IIS, то папка Inetpub вам не нужна и её можно удалить.

Удаляется ли папка Inetpub обычным способом

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

Окончательное удаление папки Inetpub

Для окончательного удаления папки Inetpub необходимо отключить службу, ответственную за восстановление данных об интернет-серверах:

Готово, папка стёрта и после перезапуска компьютера восстанавливаться не будет. Она может появиться снова, только если кто-то из пользователей или какая-нибудь программа запустит службу IIS. Если вы отключили процесс и удалили папку, а потом заметили, что папка автоматически восстановилась, то начинайте искать, кто или что могло перезапустить IIS без вашего разрешения.

Видео: как удалить папку Inetpub

Решение проблемы с доступом к интернет-ресурсам

После отключения службы IIS и удаления папки Inetpub можно столкнуться с тем, что доступ к некоторым интернет-ресурсам (сайтам, онлайн-программам или облачным хранилищам данных) отсутствует или ограничен. Причиной тому могут быть как ваши действия по отключению службы IIS, так и вирус, вызывающий блокировку определённых сайтов. Выполните полную проверку системы на наличие вредоносных программ, используя имеющийся у вас антивирус, а затем выполните следующие действия:

Готово. Осталось сохранить изменения, внесённые в документ, и перезагрузить компьютер, чтобы изменения вступили в силу. После повторного входа в систему вы сможете зайти на ранее заблокированные сайты.

Папка Inetpub принадлежит службе IIS. Чтобы её удалить, необходимо предварительно отключить процесс IIS. Если этого не сделать, то папка самостоятельно восстановится при перезапуске компьютера. Деактивировать IIS можно через панель управления. Если после отключения службы возникнут проблемы с доступом к каким-либо ресурсам, необходимо отредактировать файл hosts.

Учетная запись defaultuser0 в Windows 10 и как ее удалить?

Узнайте, что это учетную запись defaultuser0 в Windows 10 и почему вы не должны ее игнорировать! Также читайте, как отключить / удалить defaultuser0 используя lusrmgr, в этой статье.

Что такое учетная запись «defaultuser0» в Windows 10 и почему вы должны заботиться о ней?

Но вы можете подумать, что произойдет, если вы не удалить его?

Ну из опыта прошлых лет, было замечено, что иногда defaultuser0 может создавать сложные ситуации для вас, как:

1. Вы выполнили сброс в Windows 10. Затем Windows 10 заставляет вас войти в систему как ‘ defaultuser0 ‘ (выше изображение иллюстрирует это). Но запись не имеет пароля, соответственно вход не возможен. Теперь вам придется сделать, чистую установку системы, потеряв свои данные и потратив свое время.

2. В некоторых случаях defaultuser0 снова появляется после чистой установки и все может повторится.

Как удалить defaultuser0 В операционной системе Windows 10?

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

Вариант 1 — Удалить defaultuser0 полностью

2. Откройте оснастку lusrmgr, набрав lusrmgr.msc с помощью команды Выполнить.

3. Откройте папку Пользователи и правой кнопкой мыши кликните на записи defaultuser0. Выберите Удалить.

Закройте оснастку lusrmgr.

6. В левой панели окна редактора реестра, перейдите к следующему разделу реестра:

Папку в которой найдется defaultuser0 нужно удалить. Кликните правой кнопкой мыши на ней и выберите Удалить. Закройте редактор реестра. Перезагрузитесь в нормальный режим работы.

Таким образом, учетная запись defaultuser0 будет полностью удалена.

Вариант 2 — Установка пароля на defaultuser0

Если вы решили не удалять defauluser0, вы можете пойти другим путем, установить пароль для него.

1. Повторите шаги 1 и 2 из первого варианта.

2. В окне lusrmgmr, нажмите на папку Пользователи и кликните правой кнопкой мыши на записи defaultuser0, выбрав в контекстном меню опцию — Задать пароль.

3. Затем нажмите кнопку Продолжить :

5. Вы получите подтверждение того, что был установлен пароль для defaultuser0, теперь вы можете расслабиться. Перезагрузитесь в нормальный режим работы.

В чем разница между DefaultAppPool и Classic.NET AppPool в IIS7?

web-applications iis-7 (3)

У меня проблема с тайм-аутами в IIS. В web.config таймаут сеанса был установлен на 60 минут, но через 20 минут сеанс заканчивается.

Эта проблема возникает только в IIS7, а не в IIS5.

После некоторого расследования я обнаружил, что это связано с тайм-аутом пула приложений. Если пул приложений оставлен на 20 минут без каких-либо действий, IIS завершает сеанс.

Оба режима имеют тайм-аут простоя, но только в DefaultAppPool это происходит.

DefaultAppPool игнорирует настройки таймаута сеанса в web.config, но ASPNet App Pool будет использовать настройки в web.config.

IIS7 имеет ряд важных изменений для лучшей поддержки WCF, и одним из ключевых компонентов является новый объединенный пул приложений. Эта сессия PDC рассказывает о некоторых из этих проблем с точки зрения улучшения работы служб WCF: http://channel9.msdn.com/pdc2008/TL38/

Интегрированный режим пула приложений

Когда пул приложений находится в интегрированном режиме, вы можете воспользоваться встроенной архитектурой обработки запросов IIS и ASP.NET. Когда рабочий процесс в пуле приложений получает запрос, запрос проходит через упорядоченный список событий. Каждое событие вызывает необходимые собственные и управляемые модули для обработки частей запроса и для генерации ответа. Существует несколько преимуществ запуска пулов приложений в интегрированном режиме. Сначала модели обработки запросов IIS и ASP.NET интегрированы в единую модель процесса. Эта модель исключает шаги, которые ранее дублировались в IIS и ASP.NET, такие как аутентификация. Кроме того, встроенный режим позволяет использовать управляемые функции для всех типов контента.

Классический пул приложений

Когда пул приложений находится в классическом режиме, IIS 7.0 обрабатывает запросы, как в режиме изоляции рабочего процесса IIS 6.0. Сначала запросы ASP.NET проходят собственные этапы обработки в IIS и затем направляются в Aspnet_isapi.dll для обработки управляемого кода в управляемой среде выполнения. Наконец, запрос направляется обратно через IIS для отправки ответа. Такое разделение моделей обработки запросов IIS и ASP.NET приводит к дублированию некоторых этапов обработки, таких как аутентификация и авторизация. Кроме того, функции управляемого кода, такие как проверка подлинности форм, доступны только приложениям ASP.NET или приложениям, для которых у вас есть сценарий, отображающий все запросы, обрабатываемые aspnet_isapi.dll. Обязательно протестируйте существующие приложения для совместимости в интегрированном режиме, прежде чем обновлять производственную среду до IIS 7.0 и назначать приложения для пулов приложений в интегрированном режиме. Вы должны добавлять приложение в пул приложений в классическом режиме, если приложение не работает в интегрированном режиме. Например, ваше приложение может полагаться на токен аутентификации, переданный из IIS, в управляемую среду выполнения, а из-за новой архитектуры в IIS 7.0 процесс прерывает ваше приложение.

Я думаю, что на ваш вопрос есть ответ. IIS 6 и 7 имеют концепцию тайм-аута пула приложений, это отличается от тайм-аута сеанса.

Некоторая перспектива: тайм-аут ожидания не будет происходить на веб-сайте с любым трафиком. Вероятно, у вас есть проблема, которая возникает только на сайте QA или в вашем блоке dev. Установка тайм-аута в режиме ожидания существует для экономии ресурсов в вашем блоке разработчиков и 5-месячных хостинговых компаниях с большим количеством недоиспользуемых веб-сайтов (например, моего блога). Вероятно, вы не хотите простоя в режиме ожидания на общедоступном сайте.

Тайм-аут сеанса — устанавливается в веб-конфигурации, если пользователь не попадает на сервер, время их сеанса отключается.

Удалите эти файлы и папки Windows, чтобы освободить место на диске

Windows содержит множество файлов и папок, которые вам не нужны.

Давайте рассмотрим некоторые файлы и папки Windows, которые можно безопасно удалить, чтобы освободить место на диске, и узнать, почему вы можете стереть их. Обратите внимание, что некоторые из этих папок находятся в защищенных местах, поэтому будьте осторожны при их удалении.

Лучший способ очистки папок Windows: очистка диска

Прежде чем мы рассмотрим несколько файлов и папок Windows, которые вы можете безопасно удалить, вы должны знать, что удаление их вручную – не лучший способ сделать это.

Помимо того, что вы можете тратить время на это самостоятельно, когда вы можете автоматизировать процесс, безопаснее позволить инструменту очистки диска выполнить эту очистку за вас. Это позволяет избежать случайного удаления файлов, которые вам нужны, или работы с неправильными папками.

Средство очистки диска Windows помогает вам освободить дисковое пространство на вашем компьютере и является простым в использовании. Вы можете открыть его, выполнив поиск Очистка диска в меню «Пуск».

Позвольте ему сканировать, и вы увидите несколько категорий файлов, которые вы можете стереть. Для получения дополнительных параметров выберите Очистить системные файлы, чтобы получить права администратора.

Если это слишком старая школа, перейдите в « Настройки»> «Система»> «Хранилище», чтобы попробовать более новую утилиту очистки хранилища в Windows 10. Нажмите Освободить место сейчас, чтобы использовать его.

Что удалить в очистке диска

Это не полное руководство по инструменту очистки диска, поэтому мы не будем рассматривать все варианты, которые он предлагает. Тем не менее, следующие несколько опций являются обязательными (не забудьте выбрать Очистить системные файлы, чтобы увидеть их все):

1. Файл гибернации

Расположение: C: hiberfil.sys

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

Конечно, это занимает место, для чего предназначен файл гибернации.

Это все, что нужно, чтобы отключить спящий режим. Windows должен удалить hiberfil.sys сам по себе, когда вы сделаете это; не стесняйтесь удалить его, если виндовс не удалит.

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

2. Папка Windows Temp

Расположение: C: Windows Temp

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

Помимо очистки с помощью Disk Cleanup. Вы можете посетить эту папку и удалить ее содержимое, нажав Ctrl + A выбрать все, а затем нажмите удалить. Когда вы делаете это, Windows может выдать вам ошибку о паре элементов – просто проигнорируйте их и очистите все остальное.

Расположение: shell:RecycleBinFolder

Технически, Корзина – это не папка. И хотя это может быть очевидным для некоторых, мы включаем это в случае, если некоторые читатели не знают.

Каждый раз, когда вы удаляете файл в своей системе, Windows отправляет его в корзину. Это особое место, где удаленные файлы хранятся до тех пор, пока вы не удалите их навсегда или не восстановите. Если вы не помните, чтобы регулярно очищать корзину, там может быть несколько гигабайт старых данных.

Вы можете получить доступ к корзине через ярлык на рабочем столе. Если у вас его нет, введите shell: RecycleBinFolder в панели навигации Проводника. Оказавшись здесь, вы увидите все, что вы недавно удалили.

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

4. Папка Windows.old

Расположение: C: Windows.old

При необходимости вы можете использовать эту папку для отката к предыдущей версии Windows. Вы также можете открыть папку и взять несколько ненужных файлов, если вам нужно.

Windows автоматически удаляет эту папку через короткое время, но вы можете удалить ее самостоятельно, если вам не хватает места. Он не удалится, если вы попытаетесь пройти через проводник, поэтому введите « Очистка диска» в меню «Пуск» и запустите инструмент, как описано ранее.

Нажмите Очистить системные файлы в нижней части окна и позвольте утилите выполнить повторное сканирование. После этого найдите предыдущие установки Windows и удалите их с помощью этого инструмента.

Очевидно, что удаление этих файлов затрудняет восстановление данных в случае возникновения проблемы. После обновления до Windows (даже до последней версии Windows 10) мы советуем вам сохранять эту папку, пока вы не убедитесь, что все работает правильно.

5. Загруженные программные файлы

Расположение: C: Windows Загруженные программные файлы

Название этой папки немного сбивает с толку. На самом деле она содержит файлы, используемые элементами управления ActiveX Internet Explorer и апплетами Java, поэтому, если вы используете одну и ту же функцию на веб-сайте, вам не нужно загружать ее дважды.

По сути, эта папка бесполезна. ActiveX является чрезвычайно устаревшей технологией, которая полна дыр в безопасности, и Java редко используется в современной сети. ActiveX является эксклюзивным для Internet Explorer, и вы, вероятно, встретите его только на древних корпоративных сайтах.

Большинство домашних пользователей больше не используют IE, не говоря уже о ActiveX. Ваша папка « Загруженные программные файлы » может быть уже пустой, но вы можете очистить ее содержимое, если это не так.

6. LiveKernelReports

Место нахождения: C: Windows LiveKernelReports

Расположение: C: Windows LiveKernelReports

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

Если происходит сбой Windows или возникают другие серьезные проблемы с компьютером, не удаляйте эти файлы дампа сразу. Вы можете использовать такую ​​программу, как WhoCrashed, чтобы получить от них больше информации.

7. Rempl Папка

Расположение: C:Program Filesrempl

Хотя папка Rempl невелика, вы можете удивиться, увидев ее в своей системе. Он содержит несколько небольших файлов, и вы можете даже заметить несколько процессов диспетчера задач, связанных с ним.

Эта папка подключена к доставке обновлений Windows 10. Он включает в себя « улучшения надежности», которые помогут сделать обновления Windows 10 гладкими и устранить проблемы совместимости.

Так вы можете удалить папку Rempl? По-видимому, никаких негативных последствий от этого нет. Тем не менее, поскольку он занимает всего несколько мегабайт и может сделать обновления Windows менее сложными, лучше его оставить.

Какие папки Windows вы удаляете?

Источник

В пост внесены исправления 11 ноября 2022 г.

Начало:
1. Windows 10, IIS 10: доступ к файлам, часть 1 (основы, термины)
2. Windows 10, IIS 10: доступ к файлам, часть 2 (архитектура IIS)

В сервере IIS (начиная с версии 7) есть встроенная учетная запись пользователя, которая называется IUSR, и есть встроенная группа, которая называется IIS_IUSRS. Кое-что (но далеко не всё) про эти встроенные учетную запись и группу рассказано в статье «Understanding Built-In User and Group Accounts in IIS 7» документации на сайте компании «Microsoft».

Кроме того, как уже упоминалось в предыдущем посте, в сервере IIS есть встроенная учетная запись пользователя для каждого пула приложений с именем, совпадающим с именем пула приложений. Например, для пула приложений, созданного автоматически по умолчанию при включении сервера IIS, эта учетная запись называется «DefaultAppPool». Подробнее об этом можно прочитать в статье «Understanding identities in IIS», а также в статье «Application Pool Identities» документации на сайте компании «Microsoft».

Путаница IUSR и IIS_IUSRS

Из-за сходства названий встроенной учетной записи пользователя IUSR и встроенной группы IIS_IUSRS их часто путают. Во-первых, некоторые люди их путают, считая одним и тем же. Очевидно, что это не так.

Во-вторых, их путают и на более тонком уровне. Некоторые люди считают, что пользователь IUSR входит в группу IIS_IUSRS. Конечно, технически это можно сделать (я бы не рекомендовал), но изначально, по умолчанию, пользователь IUSR не входит в группу IIS_IUSRS и, как я понимаю, не имеет к ней никакого отношения. Ниже я это попробую показать.

Название пользователя «IUSR» расшифровывается как «Internet User» (по-русски «пользователь интернета»). В качестве пользователя IUSR подразумевается любой пользователь, использующий браузер и обратившийся из браузера с помощью ввода URL-адреса к веб-серверу IIS.

В группу же IIS_IUSRS входят все встроенные учетные записи пулов приложений сервера IIS. То есть изначально в нее по умолчанию у меня входит только встроенная учетная запись пользователя «DefaultAppPool». При добавлении новых пулов приложений их встроенные учетные записи будут добавлены в группу IIS_IUSRS автоматически, то есть вручную их добавлять в эту группу не требуется (так настроено по умолчанию, но это можно изменить, сделав так, чтобы встроенные учетные записи новых пулов приложений нужно было добавлять в эту группу вручную).

Следует иметь в виду, что в программе (в сохраненной консоли программы «mmc.exe») «Управление компьютером» в списке пользователей учетная запись IUSR не отображается, несмотря на то, что она существует.

Группа IIS_IUSRS в программе «Управление компьютером» отображается, но, если попытаться просмотреть, кто в нее входит, то там ничего отображено не будет, несмотря на то, что в этой группе на самом деле есть содержимое. Вот как это выглядит у меня:

Как я понимаю, нет смысла заполнять эту группу вручную, если она пополняется автоматически.

Как используется встроенная учетная запись IUSR

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

Если требуется настроить более сложную аутентификацию, этот умолчательный модуль «Анонимная проверка подлинности» нужно будет отключить и включить модуль другого способа аутентификации. Но мы это делать не будем и посмотрим, как настроена умолчательная аутентификация.

В программе «Диспетчер служб IIS» аутентификацию можно настроить на уровне сервера, на уровне сайта, на уровне папки и так далее. Для этого следует в левом меню «Подключения» выбрать нужный уровень (например, уровень сервера). После этого в средней части окна программы следует открыть пункт «Проверка подлинности» (по-английски «Authentication»):

В результате будет показан список готовых к использованию модулей, которые можно использовать для аутентификации пользователей:

На иллюстрации выше видно, что в моем случае есть только два доступных модуля для аутентификации. Но это только по умолчанию. Другие модули существуют, их можно доустановить. Но я этого делать не буду, так как моя цель — изучить настройки веб-сервера IIS по умолчанию.

Также на иллюстрации выше видно, что включен только модуль «Анонимная проверка подлинности», а второй модуль отключен. Заглянем в настройки включенного модуля. Для этого следует выделить его в списке в средней части окна программы, а затем выбрать пункт «Изменить…» в меню «Действия» справа:

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

В главном файле настроек веб-сервера IIS «applicationHost.config» вышеописанная настройка выглядит так:

<?xml version="1.0" encoding="UTF-8"?>
...
<configuration>
    ...
    <system.webServer>
        ...
        <security>
            ...
            <authentication>
                <anonymousAuthentication enabled="true" userName="IUSR" />
                <basicAuthentication />
                <clientCertificateMappingAuthentication />
                <digestAuthentication />
                <iisClientCertificateMappingAuthentication />
                <windowsAuthentication />
            </authentication>
            ...
        </security>
        ...
    </system.webServer>
    ...
</configuration>

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

Под какой учетной записью происходит доступ к файлам сайта

Когда я стал изучать работу веб-сервера IIS, у меня сразу возник следующий вопрос. В прошлом посте я описывал архитектуру веб-сервера IIS, то, как он работает на уровне процессов. Там я описал, что пул приложений «DefaultAppPool» сайта «Default Web Site» запускается в виде рабочего процесса от имени встроенной учетной записи пользователя «DefaultAppPool». Теперь при изучении настроек веб-сервера IIS по умолчанию мы видим, что пользователь сайта числится под учетной записью IUSR. Тогда от имени какой из этих двух учетных записей происходит доступ к файлам сайта?

Веб-сервер IIS может быть настроен по-разному. Но, если говорить о рассмотренных выше умолчательных настройках веб-сервера IIS, то, насколько я понимаю, рабочий процесс веб-сервера IIS, осуществляющий доступ к файлам сайта, имеет первичный токен доступа от учетной записи «DefaultAppPool» и в качестве токена имперсонации (олицетворения) — токен доступа от учетной записи IUSR. Таким образом, доступ к файлам при рассмотренных выше настройках происходит от имени учетной записи IUSR.

То есть, по идее, в зависимости от вышеописанной настройки, мы можем настроить либо доступ к файлам от имени встроенной учетной записи IUSR, либо от имени встроенной учетной записи «DefaultAppPool».

Итак, по умолчанию доступ к папке нашего сайта регулируется следующим списком доступа:

Шесть позиций, перечисленных в списке доступа на вышеприведенной иллюстрации, совпадают с теми, которые описаны для папки «inetpubwwwroot» в статье «Default permissions and user rights for IIS 7.0 and later» документации на сайте компании «Microsoft». Из них меня сейчас в первую очередь интересуют две группы: «IIS_IUSRS» и «Пользователи».

Насколько я понимаю, встроенная учетная запись «DefaultAppPool» по умолчанию входит в группу «IIS_IUSRS» и в группу «Пользователи» компьютера, а встроенная учетная запись «IUSR» входит только в группу «Пользователи». (Эти факты не видны из программы «Управление компьютером».)

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

Я думаю, что для дополнительной настройки доступа к файлам сайта не стоит менять настройки доступа для групп, так как это может затронуть других пользователей, входящих в эти группы. Думаю, что для расширения прав доступа к файлам динамического сайта следует добавить в список доступа на вышеприведенной иллюстрации либо пользователя «IUSR», либо пользователя «DefaultAppPool» (в зависимости от того, кто из этих пользователей выбран при настройке анонимной аутентификации, описанной выше), назначив им необходимые права доступа.

Продолжение следует.

Каждый пул приложений в IIS использует свой собственный рабочий процесс (IIS Worker Process). Удостоверение пула приложений (Application Pool Identities) представляет из себя имя учетной записи, под которой выполняется рабочий процесс этого пула.

В IIS 6.0 и IIS 7.0  пул приложений по умолчанию работал под встроенной системной учетной записью NetworkService. Эта запись не требует пароля и имеет на локальном компьютере ограниченные права, что является хорошей практикой с точки зрения безопасности. Однако под этой учетной записью могут одновременно работать разные системные службы Windows, и при использовании одного и того же идентификатора одни службы могут воздействовать на работу других.

Начиная с  Windows Server 2008 SP2 для того, чтобы изолировать рабочие процессы IIS от других системных служб, можно использовать виртуальные учетные записи (Virtual Accounts). Они позволяют запускать рабочий процесс для каждого пула приложений под собственной уникальной учетной записью ApplicationPoolIdentity. Эта учетная запись не требует управления и создается автоматически при создании каждого нового пула. Также она не имеет практически никаких привилегий в системе и не использует профиль пользователя, что повышает безопасность веб-сервера.

Для примера возьмем Application Pool с именем PubSite1. Открываем Task Manager и находим рабочий процесс IIS (w3wp.exe), выполняющийся от имени PubSite1. Как видите, имя учетной записи совпадает с именем пула приложений. Дело в том, что начиная с IIS 7.5 для каждого вновь созданного пула приложений по умолчанию создается виртуальная учетная запись с именем этого пула, и его рабочий процесс запускается из под этой записи.

Настройка типа удостоверения пула приложений

При необходимости тип идентификации пула приложений можно изменить. Для этого запускаем IIS Manager, переходим в раздел Application Pools, выбираем нужный пул и открываем его свойства (Advanced Settings).

В свойствах выбираем пункт Identity.

Здесь мы указываем учетную запись, от имени которой будет работать данный пул приложений:

• ApplicationPoolIdentity — учетная запись удостоверения пула приложений. Создается автоматически при запуске пула приложений и имеет самые минимальные права на локальном компьютере. Это наиболее безопасный вариант, начиная с IIS 7.5 используется по умолчанию;
• LocalService – встроенная учетная запись, которая имеет ограниченные права на локальном компьютере. Примерно то же самое, что и NetworkService, но ограничена только локальным компьютером;
• LocalSystem – системная учетная запись, имеющая неограниченные права на локальном компьютере. Наименее безопасный вариант, по возможности не рекомендуется ее использовать;
• NetworkService — учетная запись, которая имеет ограниченные права на локальном компьютере, а также может использоваться для доступа к ресурсам в сети Active Directory на основании учетной записи компьютера.

Кроме того, в качестве удостоверения можно использовать и обычную учетную запись пользователя. Для этого надо выбрать Custom Account, нажать кнопку Set и ввести имя пользователя и пароль. Можно указать любого доменного или локального пользователя.

Примечание. При использовании учетной записи пользователя надо отслеживать срок действия пароля и своевременно менять его.

То же самое можно сделать с помощью утилиты командной строки appcmd. Чтобы указать учетную запись, которая будет использоваться для пула приложений, используется следующий синтаксис:

appcmd set config /section:applicationpools /[name=″имя пула приложений″].processModel.identityType:SpecificUser|NetworkService|LocalService|LocalSystem

Для примера изменим тип удостоверения для пула приложений PubSite1 на NetworkService:

appcmd set config /section:applicationpools
/[name=″PubSite1″].processModel.identityType:NetworkService

Профиль пользователя

По умолчанию IIS не использует профиль пользователя, но некоторые приложения могут потребовать использование профиля, например для хранения временных файлов. Профиль для учетной записи NetworkService создается системой и всегда доступен. Стандартные пулы приложений (DefaultAppPool, Classic .NET AppPool и т.п.) также имеют профиль пользователя на диске, однако при использовании ApplicationPoolIdentity профиль не создается автоматически.

Если вы хотите настроить ApplicationPoolIdentity на использование пользовательского профиля, то надо зайти в расширенные свойства пула и перевести параметр Load User Profile в состояние True.

Настройка доступа к ресурсам

Иногда веб-приложению может потребоваться доступ к определенной папке или файлу на диске. Чтобы добавить ApplicationPoolIdentity в Access Control List (ACL):

• Запускаем Windows Explorer;
• Выбираем нужный файл или директорию, кликаем по ней правой клавишей мыши и выбираем пункт Свойства (Properties);
• Переходим на вкладку Безопасность (Security),
• Кликаем по кнопке Изменить (Edit), затем Добавить (Add);
• В поле Размещение (Locations) выбираем локальную машину;
• Вводим имя пользователя в виде ″IIS AppPoolимя пула приложений″. Так для пула приложений PubSite1 имя пользователя будет выглядеть ″IIS AppPoolPubSite1″;
• Проверяем имя клавишей Проверить имена (Check Names) и жмем ОК.

Также при желании можно воспользоваться утилитой командной строки ICACLS. Для примера дадим права на изменение для PubSite1:

ICACLS C:WebPubsite1 /grant ″IIS AppPoolPubSite1″:M

Список разрешений выглядит следующим образом:

D – удаление;
F – полный доступ;
M – изменение;
RX – чтение и выполнение;
R – чтение;
W – запись.

Если ресурс находится в сети, то для доступа к нему лучше всего использовать учетную запись NetworkService. Рабочий процесс, запущенный под этим аккаунтом, для доступа к ресурсам использует учетные данные компьютера, сгенерированные при добавлении компьютера в домен. Для того, чтобы дать процессу доступ к сетевому ресурсу, в качестве пользователя указываем компьютер:

• Выбираем тип объекта (Object Type) Computers;
• В поле Размещение (Locations) выбираем домен;
• Вводим имя пользователя в виде domainnamemachinename$, например contosoSRV12$;
• Проверяем имя и жмем ОК.

Очень удобный способ предоставлять доступ к сетевым ресурсам типа файловых шар или баз данных SQL Server. Однако работает он только при наличии домена AD.

^{This is a very good question and sadly many developers don’t ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes….}

To cover the identities listed:

IIS_IUSRS:

This is analogous to the old IIS6 IIS_WPG group. It’s a built-in group with it’s security configured such that any member of this group can act as an application pool identity.

IUSR:

This account is analogous to the old IUSR_<MACHINE_NAME> local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site’s properties).

For more information about IIS_IUSRS and IUSR see:

Understanding Built-In User and Group Accounts in IIS 7

DefaultAppPool:

If an application pool is configured to run using the Application Pool Identity feature then a «synthesised» account called IIS AppPool<pool name> will be created on the fly to used as the pool identity. In this case there will be a synthesised account called IIS AppPoolDefaultAppPool created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added using IIS AppPool<pool name>. You also won’t see these pool accounts in your computers User Manager. See the following for more information:

Application Pool Identities

ASP.NET v4.0: —

This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See DefaultAppPool above.

NETWORK SERVICE: —

The NETWORK SERVICE account is a built-in identity introduced on Windows 2003. NETWORK SERVICE is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site’s anonymous account (IUSR_ or whatever you configured as the anonymous identity).

In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually NETWORK SERVICE). Alternatively you could configure ASP.NET to impersonate the site’s anonymous account via the <identity impersonate="true" /> setting in web.config file locally (if that setting is locked then it would need to be done by an admin in the machine.config file).

Setting <identity impersonate="true"> is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).

In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity, IUSR or a specific custom anonymous account.

LOCAL SERVICE:

The LOCAL SERVICE account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:

LocalService Account

LOCAL SYSTEM:

You didn’t ask about this one but I’m adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.

LocalSystem Account

In Practice:

In practice the preferred approach to securing a website (if the site gets its own application pool — which is the default for a new site in IIS7’s MMC) is to run under Application Pool Identity. This means setting the site’s Identity in its Application Pool’s Advanced Settings to Application Pool Identity:

In the website you should then configure the Authentication feature:

Right click and edit the Anonymous Authentication entry:

Ensure that «Application pool identity» is selected:

When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the ASP.NET v4.0 pool permissions then you can either do this via Explorer:

Click the «Check Names» button:

Or you can do this using the ICACLS.EXE utility:

icacls c:wwwrootmysite /grant "IIS AppPoolASP.NET v4.0":(CI)(OI)(M)

…or…if you site’s application pool is called BobsCatPicBlogthen:

icacls c:wwwrootmysite /grant "IIS AppPoolBobsCatPicBlog":(CI)(OI)(M)

Update:

I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read:

https://stackoverflow.com/questions/510170/the-difference-between-the-local-system-account-and-the-network-service-acco/510225#510225

^{This is a very good question and sadly many developers don’t ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes….}

To cover the identities listed:

IIS_IUSRS:

This is analogous to the old IIS6 IIS_WPG group. It’s a built-in group with it’s security configured such that any member of this group can act as an application pool identity.

IUSR:

This account is analogous to the old IUSR_<MACHINE_NAME> local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site’s properties).

For more information about IIS_IUSRS and IUSR see:

Understanding Built-In User and Group Accounts in IIS 7

DefaultAppPool:

If an application pool is configured to run using the Application Pool Identity feature then a «synthesised» account called IIS AppPool<pool name> will be created on the fly to used as the pool identity. In this case there will be a synthesised account called IIS AppPoolDefaultAppPool created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added using IIS AppPool<pool name>. You also won’t see these pool accounts in your computers User Manager. See the following for more information:

Application Pool Identities

ASP.NET v4.0: —

This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See DefaultAppPool above.

NETWORK SERVICE: —

The NETWORK SERVICE account is a built-in identity introduced on Windows 2003. NETWORK SERVICE is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site’s anonymous account (IUSR_ or whatever you configured as the anonymous identity).

In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually NETWORK SERVICE). Alternatively you could configure ASP.NET to impersonate the site’s anonymous account via the <identity impersonate="true" /> setting in web.config file locally (if that setting is locked then it would need to be done by an admin in the machine.config file).

Setting <identity impersonate="true"> is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).

In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity, IUSR or a specific custom anonymous account.

LOCAL SERVICE:

The LOCAL SERVICE account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:

LocalService Account

LOCAL SYSTEM:

You didn’t ask about this one but I’m adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.

LocalSystem Account

In Practice:

In practice the preferred approach to securing a website (if the site gets its own application pool — which is the default for a new site in IIS7’s MMC) is to run under Application Pool Identity. This means setting the site’s Identity in its Application Pool’s Advanced Settings to Application Pool Identity:

In the website you should then configure the Authentication feature:

Right click and edit the Anonymous Authentication entry:

Ensure that «Application pool identity» is selected:

When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the ASP.NET v4.0 pool permissions then you can either do this via Explorer:

Click the «Check Names» button:

Or you can do this using the ICACLS.EXE utility:

icacls c:wwwrootmysite /grant "IIS AppPoolASP.NET v4.0":(CI)(OI)(M)

…or…if you site’s application pool is called BobsCatPicBlogthen:

icacls c:wwwrootmysite /grant "IIS AppPoolBobsCatPicBlog":(CI)(OI)(M)

Update:

I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read:

https://stackoverflow.com/questions/510170/the-difference-between-the-local-system-account-and-the-network-service-acco/510225#510225

В Windows Server 2012 R2 IIS работает как веб-сервер в обычных условиях. Однако веб-контент не из c:inetpubwwwroot а из какой-то другой папки. Веб-приложения по-прежнему работают под своим собственным пользователем из defaultAppPool.

Я на самом деле забыл дать IIS_IUSRS права на чтение / выполнение папки веб-материалов. Папка, тем не менее, давала доступ users . Я добавил IIS_IUSRS только права чтения / выполнения / записи, если подпапка должна быть доступна для записи.

Желая немного повысить безопасность, я просмотрел права доступа к папке с веб-контентом и методом проб и ошибок узнал, что теперь отсутствует доступ к IIS_IUSRS , именно доступ для группы users отвечает за все, что все еще работает. Потому что, когда я удаляю доступ к группе users , приложение перестает работать.

Я попытался предоставить доступ к некоторым другим учетным записям / группам и выяснил, что предоставление доступа обоим users и IIS_IUSRS отдельности запускает мое приложение. Предоставлять доступ только к IIS APPPOOL нет. Но дает доступ моему конкретному пользователю пула приложений (например, IISAPPPOOLnl-x-homepage). И это последнее, что я хочу, так как я не хочу, чтобы одно приложение могло обращаться к файлам другого приложения.

Но мне было интересно … Как точно работают учетные записи, подобные IIS? Почему предоставление доступа users также работает для моего пула приложений для доступа к папке веб-материалов? Я не вижу своего конкретного пользователя пула приложений в lusrmgr, но я предполагаю, что мой конкретный пользователь пула приложений находится в группе users или в какой-то другой группе, которая находится в группе users . Кто-нибудь может это подтвердить?

И последний вопрос к этому вопросу: для того, чтобы определенные папки были защищены паролем, я создал обычного пользователя в Windows, удалил этого пользователя из группы users , а в IIS Manager я зашел в эту папку и выполнил Аутентификацию -> Базовую аутентификацию. -> Включено, и в Правилах аутентификации я установил правило Разрешить для моей вновь созданной учетной записи пользователя Windows. Это работает. Но, проанализировав доступ на чтение / запись, я с удивлением узнал, что, хотя приложение работает под пользователем пула приложений, пользователю пула приложений нужны только права на чтение (без прав на запись), а у вновь созданного пользователя Windows должны быть и права чтения, и Кроме того, права на запись должны быть доступны для записи. Может кто-нибудь помочь объяснить, почему это так работает?