Разное

Iis apppool defaultapppool что это: Defaultapppool что за папка

07.12.1972

Содержание

Defaultapppool что за папка

IIS 7: Identity «IIS APPPOOLDefaultAppPool» не имеет достаточного разрешения на доступ к временному каталогу

У меня есть странная и неразрешимая проблема с моей IIS 7.0 на Windows7.
Я пытаюсь запустить сайт на своем локальном тестовом сервере и получить следующую ошибку:

У меня есть несколько пулов, но только один из них работает правильно. Это Классический .NET AppPool. Запуск сайтов на других я получаю ошибку, которая была предоставлена ​​ранее. Самое интересное, что я не могу найти различия между конфигурациями пулов через пулы приложений диспетчера IIS. Может быть, я что-то упустил?
Я попытался изменить права доступа для WindowsTemp , C:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Files и local settings’ temporary folder , но мои действия не имели эффектов.

Итак, надеюсь на вашу помощь и некоторые советы.

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

Вы должны установить полный доступ к этому пути для своей учетной записи.

Другая причина может заключаться в том, что установлен процессModel в machine.config так что ASP.Net работает внутри dllhost.exe вместо aspnet_wp.exe. Если это так, тогда вам нужно будет предоставить права к учетной записи IWAM_machineName.

Вы можете проверить имя процесса и учетной записи под доступом отклоненная ошибка возникает с помощью утилиты FileMon из sysinternals.com.

Еще один вариант рассмотрения. DefaultAppPool создает свою собственную учетную запись пользователя и папку в каталоге «c:Users», когда пул создается и запускается первым. Фактически это виртуальная учетная запись пользователя и должна быть названа для пула приложений или «DefaultAppPool». Он использует эту временную учетную запись пользователя для запуска пула. В некоторых настройках люди не видят эту папку, кроме папки TEMP, когда к ней обращаются к веб-сайту II и используют пул по умолчанию. Эта папка пользователя используется пулом и ASP.NET для кэширования и записи файловых ресурсов и других вещей, используемых II, ASP.NET и этой виртуальной учетной записью.

Если вы видите папку «TEMP» в папке «Пользователи», у вас есть сломанная учетная запись пула приложений во II и в реестре. Пул создает папку TEMP в качестве резервной копии для этой виртуальной учетной записи, которая может не иметь правильной настройки безопасности. У меня был этот точный сценарий.

Чтобы исправить это, перейдите в реестр: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionПрофильList Посмотрите, есть ли у вас учетная запись пользователя SID с расширением «.bak» для учетной записи пользователя DefaultAppPool. Если удалите его и перезагрузите компьютер. Проверьте свой сайт еще раз, убедившись, что он фактически настроен на использование DefaultAppPool. Теперь он должен воссоздать папку «DefaultAppPool» в «Пользователи», воссоздать запись реестра для пользователя DefaultAppPool, и ваша ошибка должна исчезнуть. т.е. нет папки TEMP.

После этого все ошибки ушли в Visual Studio для моего веб-приложения и всех перезапусков и окончательного сбоя пула приложений в II-х.

Папка 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 необходимо отключить службу, ответственную за восстановление данных об интернет-серверах:

  1. Откройте панель управления, используя поисковую строку. Открываем панель управления
  2. Перейдите в блок «Программы и компоненты». Если вы не видите его в главном списке, воспользуйтесь встроенной поисковой строкой. Переходим в раздел «Программы и компоненты»
  3. Кликните по строке «Включение или отключение компонентов Windows», расположенной в левой части окна. Нажимаем на строку «Включение и отключение компонентов Windows»
  4. Пролистайте развернувшийся список компонентов до строки «Службы IIS» и снимите галочку с главного каталога и со всех подкаталогов. Для деактивации службы IIS снимаем галочку с пункта IIS и всех его подпунктов и нажимаем кнопку OK
  5. Дождитесь, пока изменения вступят в силу, а затем перезагрузите компьютер, чтобы система окончательно применила новые параметры. Ход процесса применения изменений показывается в специальном диалоговом окне
  6. Вернитесь в проводнике к папке Inetpub и, кликнув по ней правой клавишей мыши, выберите в контекстном меню функцию «Удалить», чтобы переместить папку в корзину. Удаляем содержимое папки или всю папку целиком

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

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

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

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

  1. Откройте в «Проводнике» раздел жёсткого диска, отведённый под систему (обычно он обозначается буквой C). Войдите в папку Windows, а затем в подпапку System32. Откройте каталог Drivers, а в нём — подкаталог etc. Найдите и откройте файл hosts. Открываем файл hosts в системной папке etc
  2. Пролистайте содержимое файла до конца. Вы увидите список адресов, начинающийся с двух строк со словом localhost. Это адреса интернет-ресурсов, доступ к которым ограничен. Сотрите все строки в списке, а две первые (со словом localhost) оставьте. Удаляем лишние сайты из списка локальных узлов localhost

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

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

Предоставить разрешение на запись DefaultAppPool к папкам в Wwwroot в EBS AWS

Я пытался дать пользователь право записи IIS AppPool DefaultAppPool двух папок в папке Wwwroot используя .ebextensions container_commands.

Есть два сценария, которые мне нужно покрыть:

  1. Уметь предоставить разрешение записи пользователя DefaultAppPool при публикации в новую среду EBS , где папка Wwwroot
    не
    содержит мое решение , когда .ebextensions бежать.
  2. Уметь переиздать в существующую среду EBS и сохранить права на запись в DefaultAppPool , где папка Wwwroot действительно содержат мое решение , когда .ebextensions бежать.

Я был в состоянии выполнить последнее, но не бывшие. Бывшее терпит неудачу, потому что я указав путь к папкам по Wwwroot кто есть права, которые я хочу изменить, но решение еще не развернуто в Wwwroot приводит к сообщению об ошибке: «Система не может найти указанный файл.»

Я попробовал другой подход, при котором я даю разрешение на запись DefaultAppPool на всю папку Wwwroot в надежде, что, когда извлекается проект, вновь добавленные папки будут наследовать разрешение от Wwwroot. Когда я делаю это, и войти в файл вывод команды Icacls, я могу подтвердить, что права на запись действительно добавлены Wwwroot. Несмотря на возможность убедиться, что разрешения записи добавляются, когда .ebextensions бежать, они как-то переодеться обратно в исходное состояние позже (только для чтения) в процессе развертывания, вероятно, путем:

Это файл .config я использовал, чтобы проверить, что разрешения изменились:

Таким образом, я спрашиваю:

Есть ли способ, чтобы предоставить разрешения DefaultAppPool пользователя на запись этих двух папок, которая работает как при публикации в новой среде EBS и когда переиздание к существующему?

Есть ли способ для запуска команд после того, как приложение было развернуто на Wwwroot, но не раньше, как сделать container_commands?

Когда я смотрю на журналы из моих .ebextensions .config файлов я вижу, что они работают в два раза, это нормально?

Defaultapppool что за папка

592 просмотра

1 ответ

18 Репутация автора

Я пытался дать пользователю IIS APPPOOL DefaultAppPool права на запись в две папки в папке wwwroot, используя .ebextensions container_commands.

Есть два сценария, которые мне нужно рассмотреть:

  1. Быть в состоянии предоставить пользователю DefaultAppPool права на запись при публикации в новой среде EBS, где папка wwwroot не содержит моего решения при запуске .ebextensions.
  2. Уметь переиздать в существующую среду EBS и сохранить права на запись в DefaultAppPool , где папка Wwwroot действительно содержат мое решение , когда .ebextensions бежать.

Я был в состоянии выполнить последнее, но не первое. Первый отказывает, потому что я указываю путь к папкам под wwwroot, чьи разрешения я хочу изменить, но решение еще не развернуто на wwwroot, что приводит к сообщению об ошибке: «Система не может найти указанный файл».

Я попробовал другой подход, где я даю DefaultAppPool права на запись для всей папки wwwroot, надеясь, что при извлечении проекта вновь добавленные папки наследуют разрешения от wwwroot. Когда я делаю это и записываю в файл выходные данные команды icacls, я могу убедиться, что разрешения на запись действительно добавлены для wwwroot. Несмотря на возможность проверки того, что разрешения на запись добавляются при запуске .ebextensions, они каким-то образом возвращаются в исходное состояние (только чтение) позже в процессе развертывания, вероятно, с помощью:

Это файл .config, который я использовал для проверки изменения разрешений:

Таким образом я спрашиваю:

Есть ли способ предоставить пользователю DefaultAppPool права на запись в эти две папки, который работает как при публикации в новой среде EBS, так и при повторной публикации в существующей?

Есть ли способ выполнить команды после того, как приложение было развернуто на wwwroot, но не раньше, чем делают container_commands?

Когда я просматриваю логи из моих .ebextensions .config файлов, я вижу, что они запускаются дважды, это нормально?

плюса

6 Репутация автора

@ Starkadur: у меня точно такая же проблема с развертыванием NET Core на EBS с правами на запись в файл.

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

Заметки практикующего сисадмина

Дядя Саша Кузьмич пишет о работе

IIS DefaultAppPool

After you delete IIS application pool «DefaultAppPool» you will get error «The parameter is incorrect» when creating web site.

После удаления пула приложений IIS «DefaultAppPool» при создании сайтов будет возникать ошибка «Параметр задан неверно».

  1. Не удалять пул приложений «DefaultAppPool».
  2. Остановить IIS и в файле метабазы (%systemroot%system32inetsrvMetaBase.xml) в значении атрибута AppPoolId элемента IIsWebService указать пул приложений по умолчанию для создаваемых сайтов.

Навигация по записям

Добавить комментарий

Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

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



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

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

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

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

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

  • Почему это?
  • В чем разница между классическим .NET AppPool и DefaultAppPool?
  • В чем разница в конвейере между классическим и интегрированным?
iis web-applications iis-7 application-pool
Поделиться Источник Unknown     17 апреля 2009 в 06:59

4 ответа




56

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

На этой странице представлен хороший обзор архитектуры IIS7: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/ . Я включил некоторые ключевые сведения из этой статьи о назначении двух различных типов пулов приложений ниже:

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

Когда пул приложений находится в Интегрированный режим, вы можете воспользоваться преимуществами интегрированного архитектура обработки запросов 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 процесс нарушает работу вашего приложения.

Поделиться Tim Clem     14 мая 2009 в 14:17



4

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


Классический режим выполняет следующие действия :

1.The входящий запрос HTTP принимается через ядро IIS.

2.The запрос обрабатывается через ISAPI.

3.The запрос обрабатывается через ASP.NET.

4.The запрос проходит обратно через ISAPI.

запрос 5.The проходит обратно через ядро IIS, где, наконец, доставляется ответ HTTP


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

1.The входящий запрос HTTP принимается через ядро IIS и ASP.NET.

2.The соответствующий обработчик выполняет запрос и доставляет ответ HTTP

Увеличьте время ожидания сеанса в web.config в соответствии с

помните, что увеличение этого приводит к тому, что приложение потребляет больше ресурсов, например памяти

Поделиться Stuart     18 апреля 2009 в 20:36



2

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

В чем разница между режимами …, уже рассмотренными. Я не уверен в том, как ваши вопросы о трубопроводах и различиях в режимах связаны с вашей проблемой — тайм-аутами.

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

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

Время простоя Никто не прикасается к веб-серверу в течение 20 минут, поэтому выключите его, чтобы сэкономить ресурсы. В IIS 6 это находится на вкладке производительность пула приложений — и его легко отключить. В IIS 7 вы можете задать дополнительные параметры в пуле приложений или в элементе processModel . Я не запускаю столько IIS 7, сколько IIS 6, но похоже, что удаление элемента из web.config или установка значения 0 приводит к бесконечному времени простоя.

Поделиться Precipitous     09 мая 2009 в 04:57




0

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

Поделиться Jeff     12 мая 2009 в 21:39


Похожие вопросы:


Как я могу добавить `IIS AppPool\DefaultAppPool » в группу?

Я добавляю пользователя в группу с помощью: // reference System.DirectoryServices.AccountManagement, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 using (var context = new…


В чем разница между классическим, локальным для mapreduce.framework.name в mapred-site.xml?

Официальное описание этого параметра выглядит следующим образом: The runtime framework for executing MapReduce jobs. Can be one of local, classic or yarn. Я знаю, что значение ‘yarn’ соответствует…


В чем разница между классическим api и унифицированным api ios проектом в xamarin

В чем разница между классическим api и унифицированным api ios проектом в xamarin, как указано на скриншоте ниже?


как исправить Windows NT пользователь или группа ‘IIS APPPOOL\DefaultAppPool’ не найдены?

когда я бегу на sql server 2005: EXEC sp_grantlogin IIS APPPOOL\DefaultAppPool Я получаю ошибку: Msg 15401, Level 11, State 1, Procedure sp_grantlogin, Line 49 Windows NT user or group ‘IIS…


В чем разница между типами пулов приложений IIS7

В IIS7 у вас есть возможность выбрать другой тип пула приложений. У меня есть 4 типа на выбор Пул приложений по умолчанию Классический пул приложений .Net ASP.NET v4.0 ASP.NET v4.0 классический В…


В чем разница между классическим и интегрированным конвейерным режимом в IIS7?

Возможный Дубликат : В чем разница между классическим и интегрированным в IIS7? Я всегда задавался вопросом, в чем разница, Преимущества/Недостатки использования обоих.


URL маршрутизация в ASP.Net webforms работает под классическим .NET AppPool

Кто-нибудь знает, можно ли сделать маршрутизацию URL на веб-сайте ASP.Net webforms, который работает под классическим .NET AppPool. Я пробовал здесь несколько вещей, но это работает только тогда,…


Не удалось войти в систему для пользователя ‘IIS APPPOOL\Classic .NET AppPool’

Я только что добавил свой сайт в IIS. После долгих поисков неисправностей я смог заставить его работать с классическим пулом приложений .NET. Но на странице, которая требует подключения к базе…


в чем разница между классическим текстом и текстом TLF

в чем разница между классическим текстом и текстом TLF


Предоставление sql server доступа к базе данных IIS APPPOOL\DefaultAppPool

У меня есть приложение ASP NET, которое пытается получить доступ к базе данных sql server, когда я запускаю его, я получаю сообщение об ошибке Ошибка входа в систему для пользователя IIS…

Понимание удостоверений в IIS — Internet Information Services

  • Чтение занимает 8 мин

В этой статье

В этой статье приводится справочная информация о удостоверениях в службах интернет-информации (IIS).

Оригинальная версия продукта:   Службы интернет-информации
Исходный номер КБ:   4466942

Идентификаторы пула приложений

Чтобы понять идентификаторы пула приложений, необходимо понять, что такое удостоверение. Проще говоря, удостоверение — это учетная запись Windows. Каждый процесс, который выполняется в Windows, выполняется под удостоверением. Приложения запускаются рабочим процессом с помощью удостоверения Windows. Используемый идентификатор Windows зависит от удостоверения пула приложений, который может быть любой из следующих учетных записей:

  • Локализованная система: Доверяемая учетная запись с высокими привилегиями и доступом к сетевым ресурсам.
  • Служба сети: Ограниченная или ограниченная учетная запись службы, используемая для запуска стандартных, наименее привилегированных служб. Эта учетная запись имеет меньше привилегий, чем учетная запись Локальной системы. Эта учетная запись имеет доступ к сетевым ресурсам.
  • Локализованная служба: Ограниченная или ограниченная учетная запись службы, аналогичная сетевой службе и предназначенная для запуска стандартных, наименее привилегированных служб. Эта учетная запись не имеет доступа к сетевым ресурсам.
  • ApplicationPoolIdentity: При создании нового пула приложений IIS создает виртуальную учетную запись, которая имеет имя нового пула приложений и запускает процесс работы пула приложений под этой учетной записью. Это также наименее привилегированная учетная запись.
  • Настраиваемая учетная запись: Помимо встроенных учетных записей, можно также использовать настраиваемую учетную запись, указав имя пользователя и пароль.

Различия между удостоверениями пула приложений

  • Сценарий 1. Доступ к журналу событий

    В этом сценарии у вас есть одно веб-приложение, которое создает настраиваемый журнал событий (MyWebAppZone) и источник журнала событий (MyWebAppZone.com) во время запуска. Приложения, которые запускают с помощью любого из удостоверений, могут записываться в журнал событий с помощью существующих источников событий. Однако, если они работают под удостоверением, кроме локальной системы, они не могут создавать новые источники событий из-за недостаточного количества разрешений реестра.

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

    При одновременном запуске трассировки ProcMon часто бывает так, что NT AUTHORITY\NETWORK SERVICE не имеет необходимых привилегий для чтения и записи доступа к следующему подкою реестра:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

    Это расположение в реестре, где хранятся все параметры журнала событий.

  • Сценарий 2. Доступ к реестру

    Кроме локальной системы, никакие другие удостоверения пула приложений не имеют доступа к реестру Записи. В этом сценарии вы разработали простое веб-приложение, которое может изменять и отображать имя сервера времени в Интернете, с помощью которого Автоматически синхронизируется Windows. Если вы запустите это приложение в локальной службе, вы получите исключение. Если вы проверяете трассировку ProcMon, вы найдете, что идентификатор пула приложений «NT AUTHORITY\LOCAL SERVICE» не имеет доступа к приложению Read and Write в следующем подкоге реестра:

    HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

    Если вы проверяете журнал событий MyWebAppZone (из сценария 1), вы найдете следующее событие ошибки в журнале. Содержит сообщение Requested registry access is not allowed об ошибке.

    Exception Type: SecurityException  
    Message: Requested registry access is not allowed.  
    Stack Trace  
    at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)  
    at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e)  
    at System.Web.UI.Control.LoadRecursive()  
    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
    at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
    at System.Web.UI.Page.ProcessRequest()  
    at System.Web.UI.Page.ProcessRequest(HttpContext context)  
    at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0  
    at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
    
  • Сценарий 3. Настраиваемая учетная запись в среде проверки подлинности Kerberos и сбалансированной нагрузкой

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

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

    Для работы проверки подлинности Kerberos необходимо настроить SPN для обоих серверов с помощью учетной записи машины. Если пул приложений работает под встроенной учетной записью, он представляет учетные данные компьютера в сети. Например, если имя компьютера — Server1, оно представляет себя как ‘Server1$’. Эта учетная запись компьютера автоматически создается, когда компьютер присоединяется к домену. Поэтому, если есть N-серверы, необходимо установить N-число spNs, соответствующих учетной записи соответствующего компьютера.

    Регистрация SPN в учетной записи компьютера:

    setspn -a HTTP/HOSTNAME MachineAccount$
    

    Пример.

    setspn -a HTTP/MyWebAppZone.com Server1$
    

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

    Регистрация SPN в учетной записи домена:

    setspn -a HTTP/HOSTNAME domain\account
    

    Пример.

    setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
    

Разрешения и права пользователей по умолчанию в wwwroot

IiS 7.0 и более поздние версии также упрощают настройку удостоверения пула приложений и внесение всех необходимых изменений. Когда IIS запускает рабочий процесс, он должен создать маркер, который будет использовать этот процесс. Когда этот маркер создается, IIS автоматически добавляет членство в маркер рабочих IIS_IUSRS процессов во время запуска. Учетные записи, которые работают в качестве удостоверений пула приложений, больше не должны быть явной частью IIS_IUSRS группы. Если вы создаете веб-сайт, а затем указывают физическое расположение следующим пользователям и группам, автоматически добавляются в списки управления C:\inetpub\wwwroot доступом на сайте.

Пользователи / группы Разрешенные разрешения
СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ Специальные разрешения
SYSTEM Полный доступ
Администраторы Полный доступ
Users Чтение &, содержимое папки List, Чтение
IIS_USRS Чтение & выполнения
TrustedInstaller Полный доступ

Если вы хотите отключить эту функцию и вручную добавить учетные записи в группу, установите значение IIS_IUSRS manualGroupMembership в файлеApplicationHost.config. В следующем примере показано, как это можно сделать для пула приложений по умолчанию:

<applicationPools> 
    <add name="DefaultAppPool"> 
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>

Понимание изоляции конфигурации

Рабочие процессы IIS не имеют доступа кApplicationHost.configфайлу. Таким образом, вы можете задаться вопросом, как они могут читать любые наборы конфигураций в этом файле.

Ответ заключается в использовании функции изоляции конфигурации в iiS 7.0 и более поздних версиях. Вместо того чтобы дать рабочим IIS возможность читатьApplicationHost.configнепосредственно при прочтение иерархии файлов конфигурации, служба активации процессов Windows (WAS) создает отфильтрованные копии этого файла. Каждый рабочий процесс IIS использует эти копии в качестве заменыApplicationHost.configпри считывке конфигурации внутри рабочего процесса IIS. Эти файлы создаются по умолчанию в %SystemDrive%\inetpub\Temp\appPools каталоге и называются {AppPoolName}.config. Эти файлы настроены, чтобы разрешить доступ только к рабочим процессам IIS в соответствующем пуле приложений с помощью идентификатора безопасности пула IIS APPPOOL\AppPoolName приложений (SID).

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

ApplicationHost.config могут содержать конфиденциальные персональные данные, такие как имя пользователя и пароль для пользовательских удостоверений пула приложений или имя пользователя и пароль для виртуальных каталогов. Таким образом, разрешение доступа ко всем пулам приложенийApplicationHost.config может нарушить изоляцию пула приложений. Если каждому пулу приложений был предоставлен прямой доступ к файлуApplicationHost.config, эти пулы могли легко взломать конфиденциальные сведения из других пулов приложений, выдав следующую команду:

appcmd list APPPOOL "DefaultAppPool" /text:*

IUSR — анонимная проверка подлинности

Анонимные проверки подлинности позволяют пользователям получать доступ к общедоступным областям веб-сайта без запроса имени пользователя или пароля. В IIS 7.0 и более поздних версиях встроенная учетная запись используется для IUSR предоставления анонимного доступа. Эта встроенная учетная запись не требует пароля. Это будет идентификатор по умолчанию, который используется при включенной анонимной проверке подлинности. В файлеApplicationHost.config вы можете увидеть следующее определение:

<authentication>
     <anonymousAuthentication enabled="true" userName="IUSR" />
 </authentication>

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

  • Вам больше не нужно беспокоиться об истечении срока действия паролей для этой учетной записи.
  • Вы можете использовать xcopy /o для копирования файлов вместе с их собственностью и сведениями ACL на различных компьютерах без проблем.

Кроме того, вы можете предоставить анонимное удостоверение подлинности на сайте с помощью определенной учетной записи Windows или удостоверения пула приложений, а не IUSR учетной записи.

IUSR и Connect как

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

У вас есть веб-сайт по умолчанию, настроенный для использования анонимной проверки подлинности. Однако содержимое веб-сайта на другом сервере, и для доступа к этому ресурсу через пользователя домена используется раздел Test Connect. При входе пользователя он получает проверку подлинности с помощью учетной записи IUSR. Однако к контенту веб-сайта можно получить доступ через учетные данные пользователей, указанные в разделе Connect.

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

ASP.NET вымысление

В буквальном смысле, выдав себя за другого человека, выдав себя за другого человека. С технической точки зрения это ASP.NET безопасности, которая обеспечивает возможность управления удостоверением, под которым работает код приложения. Обезличение происходит, ASP.NET выполняет код в контексте проверки подлинности и авторизованного клиента. IIS предоставляет анонимный доступ к ресурсам с помощью учетной IUSR записи. После того как запрос передается в ASP.NET, код приложения запускается с помощью удостоверения пула приложений.

В коде IIS и ASP.NET можно включить обезличение, если приложение использует анонимную проверку подлинности, и если одно из следующих условий верно:

  • В IMPERSONATION случае отключения идентификатор пула приложений используется для запуска кода приложения.
  • Если IMPERSONATION включен, NT AUTHORITY\IUSR используется для запуска кода приложения.

При включении с помощью IIS в файле Web.config приложения добавляется следующий тег, чтобы выдать себя за учетную запись IIS с проверкой подлинности impersonation или пользователя: <identity impersonate=»true» />

Чтобы выдать себя за конкретного пользователя для всех запросов на всех страницах приложения ASP.NET, можно указать имя пользователя и атрибуты пароля в теге файла Web.config для этого <identity> приложения.

<identity impersonate="true" userName="accountname" password="password" />

Чтобы реализовать себя в ASP.NET коде, см. в примере Implement impersonation in an ASP.NET application

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

Удостоверение пула приложений для приложения задано объекту ApplicationPoolIdentity, а анонимная проверка подлинности предоставляется с помощью IUSR учетной записи. Вы можете легко отследить вымывающий удостоверение с помощью ProcMon. Например, если вы изучите одно из событий CreateFile, соответствующее процессу w3wp.exe, который вы изучаете, вы можете найти вымывающий учетную запись, как показано на следующем скриншоте.

Предоставить Доступ К Базе Данных Для Iis Apppool\Defaultapppool

Я не знаю, что именно вызвало мою проблему, но я нашел решение самостоятельно.

Как-то IIS APPPOOL\DefaultAppPool даже не нуждается в дополнительных разрешениях для сервера базы данных, он может подключиться к нему, даже если его имя не включено в раздел » Logins базы данных». Просто IIS APPPOOL\DefaultAppPool база данных как-то очень тесно связана с IIS APPPOOL\DefaultAppPool (независимо от того, что на самом деле есть) И, если вы удалите базу данных, принадлежащую IIS APPPOOL\DefaultAppPool или любому другому пулу, а затем попытайтесь создать новую базу данных с тем же пулом приложений, он действует так, как будто база данных ранее не удалялась, но, как если бы вы пытались получить доступ к тому, что осталось от нее, с учетной записью, которая ее не создала. Может быть, не очень легко понять, что я говорю, но я думаю, что удаление базы данных, принадлежащей экземпляру пула приложений, не только удаляет ее, но также «отлаживает» ее из этого пула и когда вы пытаетесь создайте новую базу данных в том же пуле приложений, который просто не позволяет вам, потому что вы «отключаетесь» от него, даже если он больше не существует. Возможно, в сервере базы данных все еще есть «ссылки», но они больше недействительны, поэтому пул приложений рассматривается как нечто, которое пытается переопределить остальную часть базы данных, но не имеет прав на это.

ТАК НАКОНЕЦ FIX !!!

Чтобы исправить это, просто создайте новый пул приложений с другим именем, чем тот, который ранее создавал базу данных, переместите приложение там, и оно будет работать. Я не уверен, если вы сможете создать пул приложений с тем же именем, а затем создать базу данных, но я думаю, да. И, конечно же, перезапустите IIS (я перезапущу его через Internet Information Services (IIS) Manager) после создания нового пула.

ОБНОВИТЬ!!!

Да, я только что протестировал и теперь могу подтвердить, что вы можете создать пул приложений с тем же именем, но перед этим вы должны удалить его не только из окна пула приложений IIS Manager, но и из каталога » Users вашего компьютера (где пользователи ‘хранятся файлы, то есть C:\Users), а затем вы можете создать новый пул с тем же именем.

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

Удачи, ребята!

Не удалось войти в систему для пользователя IIS APPPOOL \ DefaultAppPool, не удалось открыть указанную базу данных

Недавно был открыт веб-сайт управления разрешениями. После настройки фреймворка он был опубликован в локальной сети. При доступе и входе через 192.168.0.186:8008 будет выдано исключение.»Базовый провайдер не удалось открыть»,Затем я запускаю его в VS и без проблем вхожу в систему. Я всегда думал, что это проблема в <connectionStrings> </connectionStrings> в web.config. Я проверил исходный код обратно и так далее. Не получилось, безумие. Baidu все еще не работает. Теперь я понимаю, что это не вина всемогущего Baidu. Возможно, этоЯ вообще не нашел настоящей проблемы, Я обнаружил, что причина исходной проблемы заключается в просмотре журнала в sql server 2008 через производствоОшибка входа для пользователя IIS APPPOOL \ DefaultAppPool, не удалось открыть указанную базу данных,Вдруг я вдруг понял и быстро нашел решение проблемы, резюмирую и записываю здесь.

окружение:

Система: win10 64 бит

против версии: 2013

Версия IIS: SQL Server 2008

Архитектура сайта: MVC + EF

Описание проблемы:

Вы можете запустить веб-сайт на VS и войти в систему без каких-либо проблем, но когда вы публикуете его в локальной сети и получаете доступ к нему через IP-адрес (например, 192.168.0.186:8008), VS выдаст исключение при входе в систему.Базовый провайдер не удалось открыть.

Решение:

1. Проверьте строку ссылки в web.config и изменитеисточник данных =., перейдите на источник данных = 192.168.0.186, укажите здесь свой IP-адрес;

<add name="CraneManagerEntities" connectionString="metadata=res://*/CraneManager.Model.csdl|res://*/CraneManager.Model.ssdl|res://*/CraneManager.Model.msl;provider=System.Data.SqlClient;provider connection string="data source=192.168.0.186;initial catalog=CraneManager;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
2. Откройте sql server 2008 и измените его на 192.168.0.186 при входе в систему. Если вы не можете войти, настройте сначала удаленное соединение sql. На этот вопрос есть много ответов. Я также даю адрес:

https://zhidao.baidu.com/question/183427727.html

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

http://bbs.csdn.net/topics/390937299/

3. Если это по-прежнему не работает, просто продолжайте смотреть на него. В любом случае, это все еще не работает. Это необходимо для входа на сервер sql для просмотра журнала:


Найдите проблему в IIS APPPOOL \ DefaultAppPool, исходную проблему пула приложений.

4. Откройте IIS, просмотрите пул приложений веб-сайта.


Найдите его в пуле приложений


После выбора выберите «Расширенные настройки» справа и выберите «Идентификация» в «Модель процесса» во всплывающем окне.


Просто измените его на «LocalSystem»,

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

Iis iusrs что это — Вэб-шпаргалка для интернет предпринимателей!

под Windows Server 2008 с ASP.NET 4.0 установлен целый ряд связанных учетных записей пользователей, и я не могу понять, какой из них, как они отличаются, и какой из них действительно тот, под которым работает мое приложение. Вот список:

  • группу iis_iusrs
  • запись iusr
  • DefaultAppPool
  • ASP.NET v4.0
  • NETWORK_SERVICE
  • МЕСТНАЯ СЛУЖБА.

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:

вы не спрашивали об этом, но я добавляю для полноты. Это локальная встроенная учетная запись. У него достаточно обширные привилегии и доверие. Никогда не следует настраивать веб-сайт или пул приложений для работы под этим удостоверением.

На Практике:

на практике предпочтительным подход к обеспечению безопасности веб-сайта (если сайт получает собственный пул приложений — что является значением по умолчанию для нового сайта в MMC IIS7) должен выполняться под Application Pool Identity . Это означает установку идентификатора сайта в расширенных настройках пула приложений в Application Pool Identity :

на веб-сайте вы должны затем настроить функцию аутентификации:

щелкните правой кнопкой мыши и отредактируйте анонимную аутентификацию запись:

обеспечить «удостоверение пула приложений» выбран:

когда вы приходите, чтобы применить права доступа к файлам и папкам, вы предоставляете удостоверение пула приложений, какие права требуются. Например, если вы предоставляете удостоверение пула приложений для 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С на сервер Вы будете получать ошибку

Запускаем оснастку управление компьютером Win+R -> compmgmt.msc или через меню пуск:

В оснастке выбираем: Локальные пользователи и групп -> Группы -> IIS_IUSRS открываем свойства группы двойным щелчком ЛКМ

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

Набираем имя пользователя IUSR и нажимаем кнопку Проверить имена, если пользователь будет найден, то он станет подчеркнутым, нажимаем ОК. Если пользователь не находится нажмите кнопку Размещение… и смените место поиска.

Проверяем, что наш пользователь появился и жмем ОК

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

Запускаем Диспетчер служб IIS удобным для Вас способом, например: Win+R -> InetMgr

В левой части экрана раскрываем ветку с сайтами. Останавливаем сайт по умолчанию Default Web Site или модифицируем его, я предпочитаю делать отдельный.

Жмем ПКМ на сайты и выбираем пункт Добавить веб-сайт

Заполняем параметры сайта

Имя сайта: Любое
Физический путь: Создаем каталог где будет храниться наш сайт (файлы сайта)
Тип: Выбираем протокол HTTP или HTTPS
Порт: Задаем порт, порт может быть любой свободный. Стандартный порт для HTTP — 80, для HTTPS 443
Сертификаты SSL: Сертификаты нужны если Вы используете защищенный протокол HTTPS. Если у Вас нет сертификата для Вашего узла, можно использовать серверный самоподписанный IIS Express Development Certificate.

Проверяем, что наш сайт появился и запустился

Вместе с сайтом так же должен был создаться пул приложений с таким же названием.
Переходим выше по ветке в раздел Пулы и приложений и находим наше приложение, в данном случае 1с

Выбираем наш пул приложений 1с и нажимаем в правой части Дополнительные параметры…

В Дополнительных параметрах находим строки:
Версия среды .NET Framework — выбираем версию v.4.0+
Разрешены 32-разрядные приложения и выбираем значение True
Внимание! Если Вы будете публиковать x64 битную платформу данное значение оставляем False,иначе будете получать ошибку 0x800700c1
(Эта проблема возникает из-за неверного сопоставление сценариев. Убедитесь в том, что сопоставление сценария указывает на ISAPI DLL-файл, который может обработать запрос. Чтобы сделать это, выполните следующие действия.)
Режим управляемого конвейера — выбираем значение Classic

Настройка доступа для группы IIS_IUSRS

Настройка необходимого доступа для группы IIS_IUSRS, для корректной работы нашего сайта (1с) и корректной публикации.

Для начала необходимо дать права группе IIS_IUSRS к каталогу в котором находятся (будут находиться) файлы нашего сайта. В нашем примере файлы сайта находятся в C:inetpubwww1c.
Переходим в каталог C:inetpubwww -> нажимаем ПКМ на каталоге 1с -> в меню выбираем пункт Свойства -> переходим на вкладку Безопасность -> жмем кнопку Изменить… -> кнопку Добавить… -> в поле вписываем название группы IIS_IUSRS (при необходимости меняем место Размещения) -> нажимаем кнопку Проверить имена.

Если группа найдена она станет подчеркнутой, жмем ОК.

Далее проставляем галочки необходимых прав:

— Чтение и выполнение
— Список содержимого папки
— Чтение

Тоже самое с правами, мы делаем для каталога куда установлена и каталога куда развернута наша файловая база. Если Вы используете базу SQL, то Вам НЕ нужно задавать права на каталог с базой.
Обращаем внимание, что для каталога с базой так же нужны права на запись!

Расположение файловой базы Вы можете посмотреть запустив 1С Предприятие

Публикация 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-сервера стала проще.

Об авторе: Дерек Хетчард ([email protected]) — консультант и тренер, имеет звание Microsoft MVP

Листинг 1. Использование тегов расположения для назначения режима переназначения Deny

Рекомендуем к прочтению

IIS и группа пользователей

в 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 я пошел в эту папку и сделал аутентификацию — > обычная аутентификация — > включено, и в Правила проверки подлинности я установил правило разрешения для моей вновь созданной учетной записи пользователя Windows. Эта работа. Но анализируя доступ на чтение / запись, я с удивлением узнал, что, хотя приложение работает под пользователем пула приложений, пользователю пула приложений нужны только права на чтение (без прав на запись), а недавно созданный пользователь Windows должен иметь права на чтение и запись, чтобы папка была доступна для записи. Может кто-нибудь помочь объяснить, почему это работает таким образом?

удостоверений пула приложений | Документы Microsoft

  • 6 минут на чтение

В этой статье

Томас Демл

Независимо от того, запускаете ли вы свой сайт на собственном сервере или в облаке, безопасность должна быть на первом месте в вашем списке приоритетов. Если это так, вы будете рады услышать, что в IIS есть функция безопасности, называемая удостоверением пула приложений.Эта функция была представлена ​​в пакете обновления 2 (SP2) для Windows Server 2008 и Windows Vista. Удостоверение пула приложений позволяет запускать пул приложений под уникальной учетной записью без необходимости создавать доменные или локальные учетные записи и управлять ими. Имя учетной записи пула приложений соответствует имени пула приложений. На изображении ниже показан рабочий процесс IIS (W3wp.exe), работающий как идентификатор DefaultAppPool.

Учетные записи удостоверений пула приложений

Рабочие процессы в IIS 6.0, а в IIS 7 по умолчанию запускается как сетевая служба. Сетевая служба — это встроенная идентификация Windows. Он не требует пароля и имеет только права пользователя; то есть это относительно низкопривилегированный. Запуск в качестве учетной записи с низким уровнем привилегий является хорошей практикой безопасности, потому что в этом случае злоумышленник не сможет использовать программную ошибку для захвата всей системы.

Однако со временем возникла проблема, поскольку все больше и больше системных служб Windows начинали работать как сетевые службы. Это связано с тем, что службы, работающие как сетевая служба, могут вмешиваться в работу других служб, работающих под тем же идентификатором.Поскольку рабочие процессы IIS по умолчанию запускают сторонний код (классический код ASP, ASP.NET, PHP), пришло время изолировать рабочие процессы IIS от других системных служб Windows и запустить рабочие процессы IIS с уникальными идентификаторами. Операционная система Windows предоставляет функцию, называемую «виртуальные учетные записи», которая позволяет IIS создавать уникальные удостоверения для каждого из своих пулов приложений. Для получения дополнительной информации о виртуальных учетных записях см. Пошаговое руководство по учетным записям служб.

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

Если вы используете IIS 7.5 в Windows Server 2008 R2 или более поздней версии IIS вам не нужно ничего делать, чтобы использовать новое удостоверение. Для каждого создаваемого пула приложений для свойства Identity нового пула приложений по умолчанию установлено значение ApplicationPoolIdentity . Процесс администрирования IIS (WAS) создаст виртуальную учетную запись с именем нового пула приложений и по умолчанию запустит рабочие процессы пула приложений под этой учетной записью.

Чтобы использовать эту виртуальную учетную запись при запуске IIS 7.0 в Windows Server 2008, необходимо изменить свойство Identity создаваемого пула приложений на ApplicationPoolIdentity .Вот как:

  1. Откройте консоль управления IIS (INETMGR.MSC).

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

  3. Щелкните правой кнопкой мыши пул приложений и выберите Advanced Settings

  4. Выберите элемент списка Identity и щелкните многоточие (кнопка с тремя точками).

  5. Появится следующий диалог:

  6. Нажмите кнопку «Встроенная учетная запись», а затем выберите тип удостоверения ApplicationPoolIdentity из поля со списком.

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

 % windir% \ system32 \ inetsrv \ appcmd.exe установить AppPool  -processModel.identityType: ApplicationPoolIdentity
  

Обеспечение безопасности ресурсов

Каждый раз, когда создается новый пул приложений, процесс управления IIS создает идентификатор безопасности (SID), который представляет имя самого пула приложений.Например, если вы создаете пул приложений с именем «MyNewAppPool», в системе безопасности Windows создается идентификатор безопасности с именем «MyNewAppPool». С этого момента ресурсы могут быть защищены с помощью этого удостоверения. Однако личность не является реальной учетной записью пользователя; он не будет отображаться как пользователь в консоли управления пользователями Windows.

Вы можете попробовать это, выбрав файл в проводнике Windows и добавив идентификатор «DefaultAppPool» в список управления доступом (ACL) файла.

  1. Откройте проводник Windows

  2. Выберите файл или каталог.

  3. Щелкните файл правой кнопкой мыши и выберите Properties

  4. Выберите вкладку Безопасность

  5. Нажмите кнопку Изменить , а затем кнопку Добавить

  6. Нажмите кнопку Locations и убедитесь, что вы выбрали свой компьютер.

  7. Введите IIS AppPool \ DefaultAppPool в поле Введите имена объектов для выбора: текстовое поле .

  8. Нажмите кнопку Проверить имена и нажмите ОК .

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

Это можно сделать из командной строки с помощью инструмента ICACLS. В следующем примере предоставляется полный доступ к идентификатору DefaultAppPool.

  ICACLS test.txt / grant «IIS AppPool \ DefaultAppPool: F»
  

Для получения дополнительной информации см. ICACLS.

В Windows 7 и Windows Server 2008 R2 и более поздних версиях Windows пулы приложений по умолчанию запускаются в качестве удостоверения пула приложений. Для этого был введен новый тип удостоверения с именем «AppPoolIdentity». Если выбран тип удостоверения «AppPoolIdentity» (по умолчанию в Windows 7 и Windows Server 2008 R2 и более поздних версиях), IIS будет запускать рабочие процессы в качестве удостоверения пула приложений. С любым другим типом удостоверения идентификатор безопасности будет вставлен только в токен доступа процесса.Если идентификатор введен, контент все еще может находиться в ACL для ApplicationPoolIdentity, но владелец токена, вероятно, не является уникальным. Дополнительные сведения об этой концепции см. В сообщении блога «Новое в IIS 7 — изоляция пула приложений».

Доступ к сети

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

  <имя домена> \ <имя машины> $,
  

Например:

  mydomain \ machine1 $
  

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

А как насчет удостоверений пула приложений?

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

Проблемы совместимости с идентификаторами пула приложений

Руководящая документация

Самая большая проблема совместимости с идентификаторами пула приложений, вероятно, связана с более ранними руководящими документами, в которых явно рекомендуется использовать ресурсы ACL для сетевой службы, то есть идентификатор DefaultAppPool по умолчанию в IIS 6.0 и IIS 7.0. Клиентам придется изменить свои сценарии на ACL для «IIS AppPool \ DefaultAppPool» (или другого имени пула приложений) при работе в IIS 7.5 или более поздней версии (см. Пример выше, чтобы узнать, как это сделать).

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

IIS не загружает профиль пользователя Windows, но некоторые приложения все равно могут использовать его для хранения временных данных. SQL Express — пример приложения, которое делает это. Однако необходимо создать профиль пользователя для хранения временных данных либо в каталоге профиля, либо в кусте реестра. Профиль пользователя для учетной записи сетевой службы был создан системой и всегда был доступен.Однако при переключении на уникальные идентификаторы пула приложений система не создает профиль пользователя. Только стандартные пулы приложений (DefaultAppPool и Classic .NET AppPool) имеют профили пользователей на диске. Профиль пользователя не создается, если администратор создает новый пул приложений.

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

Сводка

Удостоверения пула приложений — это новая мощная функция изоляции, представленная в Windows Server 2008, Windows Vista и более поздних версиях Windows.Это сделает запуск приложений IIS еще более безопасным и надежным.

Понимание удостоверений в IIS — Internet Information Services

  • На чтение 9 минут

В этой статье

В этой статье представлены общие сведения об удостоверениях в службах IIS.

Исходная версия продукта: Internet Information Services
Оригинальный номер базы знаний: 4466942

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

Чтобы понять идентификаторы пула приложений, вы должны понимать, что такое удостоверение. Проще говоря, удостоверение — это учетная запись Windows. Каждый процесс, выполняемый в Windows, работает под удостоверением. Приложения запускаются рабочим процессом с использованием удостоверения Windows. Используемый идентификатор Windows зависит от идентификатора пула приложений, которым может быть любая из следующих учетных записей:

  • Локальная система: Доверенная учетная запись с высокими привилегиями и доступом к сетевым ресурсам.
  • Сетевая служба: Учетная запись с ограниченным или ограниченным доступом, которая используется для запуска стандартных служб с минимальными привилегиями. Эта учетная запись имеет меньше привилегий, чем учетная запись локальной системы. У этой учетной записи есть доступ к сетевым ресурсам.
  • Локальная служба: Учетная запись с ограниченным или ограниченным доступом, аналогичная сетевой службе и предназначенная для запуска стандартных служб с минимальными привилегиями. У этой учетной записи нет доступа к сетевым ресурсам.
  • ApplicationPoolIdentity: Когда создается новый пул приложений, IIS создает виртуальную учетную запись, которая имеет имя нового пула приложений и запускает рабочий процесс пула приложений под этой учетной записью.Это также учетная запись с минимальными привилегиями.
  • Пользовательская учетная запись: В дополнение к этим встроенным учетным записям вы также можете использовать пользовательскую учетную запись, указав имя пользователя и пароль.

Различия между идентификаторами пула приложений

  • Сценарий 1: Доступ к журналу событий

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

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

    При одновременном запуске трассировки ProcMon часто обнаруживается, что NT AUTHORITY \ NETWORK SERVICE не имеет необходимых прав доступа на чтение и запись к следующему подразделу реестра:

    HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Eventlog \

    Это место в реестре, где хранятся все настройки журнала событий.

  • Сценарий 2: Доступ к реестру

    За исключением локальной системы, никакие другие удостоверения пула приложений не имеют доступа на запись в реестр. В этом сценарии вы разработали простое веб-приложение, которое может изменять и отображать имя сервера времени в Интернете, с которым автоматически синхронизируется Windows. Если вы запустите это приложение под локальной службой, вы получите исключение. Если вы проверите трассировку ProcMon, вы обнаружите, что удостоверение пула приложений «NT AUTHORITY \ LOCAL SERVICE» не имеет доступа на чтение и запись в следующем подразделе реестра:

    HKEY_LOCAL_MACHINE ** ** \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ DateTime \ Servers

    Если вы проверите журнал событий MyWebAppZone (из сценария 1), вы обнаружите следующее зарегистрированное событие ошибки.Он содержит сообщение об ошибке Запрошенный доступ к реестру запрещен .

      Тип исключения: SecurityException
    Сообщение: Запрошенный доступ к реестру не разрешен.
    Трассировки стека
    в Microsoft.Win32.RegistryKey.OpenSubKey (имя строки, логическое значение, доступное для записи)
    в Identities.ChangeTimeServer.Page_Load (отправитель объекта, EventArgs e)
    в System.Web.UI.Control.LoadRecursive ()
    в System.Web.UI.Page.ProcessRequestMain (логическое includeStagesBeforeAsyncPoint, логическое includeStagesAfterAsyncPoint)
    в System.Web.UI.Page.ProcessRequest (логическое includeStagesBeforeAsyncPoint, логическое includeStagesAfterAsyncPoint)
    в System.Web.UI.Page.ProcessRequest ()
    в System.Web.UI.Page.ProcessRequest (контекст HttpContext)
    в ASP.changetimeserver_aspx.ProcessRequest (контекст HttpContext) в c: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporary ASP.NET Files \ root \ fd06117a \ f8c94323 \ App_Web_ysqbhk00.2.cs: строка 0
    в System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute ()
    в System.Web.HttpApplication.ExecuteStep (шаг IExecutionStep, логический и завершенный синхронно)
      
  • Сценарий 3: Пользовательская учетная запись в среде проверки подлинности Kerberos и балансировки нагрузки

    В сценариях 1 и 2 вы уже видели некоторые различия между встроенными учетными записями. Теперь давайте обсудим, что такое настраиваемая учетная запись и как она имеет преимущества перед встроенными учетными записями при работе с аутентификацией Kerberos в среде с балансировкой нагрузки.

    Используя этот подход, вы запускаете свое приложение в пуле приложений, который настроен для запуска с использованием определенного удостоверения Windows. Рассмотрим следующую схему, на которой приложение размещено в среде с балансировкой нагрузки, которая включает два сервера и использует проверку подлинности Kerberos для идентификации клиента.

    Чтобы проверка подлинности Kerberos работала, необходимо настроить SPN для обоих серверов, используя их учетную запись компьютера. Если пул приложений работает под встроенной учетной записью, он представляет учетные данные компьютера в сети.Например, если имя компьютера — Server1 , оно представляется как «Server1 $». Эта учетная запись компьютера создается автоматически, когда компьютер присоединяется к домену. Следовательно, если имеется N серверов, вы должны установить N количество имен SPN, которые соответствуют их соответствующей учетной записи компьютера.

    Регистрация SPN для учетной записи компьютера:

      setspn -a HTTP / HOSTNAME MachineAccount $
      

    Пример:

      setspn -a HTTP / MyWebAppZone.com Server1 $
      

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

    Регистрация SPN для учетной записи домена:

      setspn -a HTTP / HOSTNAME домен \ учетная запись
      

    Пример:

      setspn -a HTTP / MyWebAppZone.com contoso.com \ account_alias
      

Разрешения по умолчанию и права пользователя в wwwroot

IIS 7.0 и более поздние версии также упрощают настройку удостоверения пула приложений и внесение всех необходимых изменений. Когда IIS запускает рабочий процесс, он должен создать токен, который будет использовать процесс.При создании этого токена IIS автоматически добавляет членство IIS_IUSRS к токену рабочих процессов во время выполнения. Учетные записи, которые работают как с идентификаторами пула приложений , больше не должны быть явной частью группы IIS_IUSRS . Если вы создаете веб-сайт, а затем указываете его физическое местоположение на C: \ inetpub \ wwwroot , следующие пользователи и группы автоматически добавляются в списки контроля доступа сайта.

Пользователи / группы Разрешенные разрешения
СОЗДАТЕЛЬ ВЛАДЕЛЬЦА Особые разрешения
СИСТЕМА Полный контроль
Администраторы Полный контроль
Пользователи Чтение и выполнение, Список содержимого папки, Чтение
IIS_USRS Прочитать и выполнить
TrustedInstaller Полный контроль

Если вы хотите отключить эту функцию и вручную добавить учетные записи в группу IIS_IUSRS , установите для manualGroupMembership значение true в ApplicationHost.config файл. В следующем примере показано, как это можно сделать с пулом приложений по умолчанию:

  <пулы приложений>
    
        
    

  

Понимание изоляции конфигурации

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

Ответ заключается в использовании функции изоляции конфигурации в IIS 7.0 и более поздних версиях. Вместо того, чтобы разрешать рабочим процессам IIS читать ApplicationHost.config напрямую при чтении иерархии файла конфигурации, служба активации процессов Windows (WAS) создает отфильтрованные копии этого файла. Каждый рабочий процесс IIS использует эти копии в качестве замены ApplicationHost.config , когда конфигурация считывается внутри рабочего процесса IIS. Эти файлы по умолчанию создаются в каталоге % SystemDrive% \ inetpub \ Temp \ appPools и называются {AppPoolName}.конфиг . Эти файлы настроены так, чтобы разрешать доступ только рабочим процессам IIS в соответствующем пуле приложений с использованием идентификатора безопасности (SID) пула приложений IIS APPPOOL \ AppPoolName .

Это сделано для того, чтобы рабочие процессы IIS из пула приложений A не могли читать информацию о конфигурации из файла ApplicationHost.config , который предназначен для пула приложений B.

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

  appcmd list APPPOOL "DefaultAppPool" / текст: *
  

IUSR — анонимная аутентификация

Анонимная аутентификация позволяет пользователям получать доступ к общедоступным областям веб-сайта без запроса имени пользователя или пароля.В IIS 7.0 и более поздних версиях для предоставления анонимного доступа используется встроенная учетная запись IUSR . Эта встроенная учетная запись не требует пароля. Это будет идентификатор по умолчанию, который используется при включенной анонимной проверке подлинности. В файле ApplicationHost.config вы можете увидеть следующее определение:

  
     
 
  

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

  • Вам больше не нужно беспокоиться об истечении срока действия паролей для этой учетной записи.
  • Вы можете использовать xcopy / o для беспрепятственного копирования файлов вместе с информацией об их владельцах и ACL на разные компьютеры.

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

IUSR против Connect as

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

У вас есть веб-сайт по умолчанию, который настроен на использование анонимной аутентификации. Однако содержимое вашего веб-сайта находится на другом сервере, и вы используете раздел Connect as для доступа к этому ресурсу через пользователя домена Test . Когда пользователь входит в систему, он аутентифицируется с помощью учетной записи IUSR. Однако доступ к содержимому веб-сайта осуществляется через учетные данные пользователя, указанные в разделе Connect as .

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

Олицетворение ASP.NET

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

Олицетворение можно включить как через IIS, так и через ASP.NET, если приложение использует анонимную проверку подлинности и выполняется одно из следующих условий:

  • Если IMPERSONATION отключен, идентификатор пула приложений используется для запуска кода приложения.
  • Если включен IMPERSONATION , NT AUTHORITY \ IUSR используется для запуска кода приложения.

Когда олицетворение включено через IIS, он добавляет следующий тег в файл Web.config приложения для олицетворения аутентифицированной учетной записи IIS или пользователя:

Чтобы выдавать себя за конкретного пользователя для всех запросов на всех страницах ASP.NET, вы можете указать атрибуты имени пользователя и пароля в теге файла Web.config для этого приложения.

  
  

Чтобы реализовать олицетворение через код ASP.NET, см. Реализация олицетворения в приложении ASP.NET

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

Идентификатор пула приложений приложения установлен на ApplicationPoolIdentity , а анонимная аутентификация обеспечивается с использованием учетной записи IUSR . Вы можете легко отследить выдающуюся личность с помощью ProcMon. Например, если вы исследуете одно из событий CreateFile, которое соответствует исследуемому процессу w3wp.exe, вы сможете найти олицетворяющую учетную запись, как показано на следующем снимке экрана.

Идентификация пула приложений и интегрированная безопасность

Чтобы повысить безопасность и упростить настройку и обслуживание, Anthology Student будет использовать (по умолчанию) удостоверение пула приложений и интегрированную безопасность для доступа к локальным и сетевым ресурсам, таким как SQL Server.

Идентификатор пула приложений

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

При использовании идентификатора пула приложений доступ к локальным ресурсам осуществляется с использованием идентификатора пула приложений (например, IIS AppPool \ DefaultAppPool), а доступ к сетевым ресурсам осуществляется с использованием идентификатора учетной записи компьютера (например, CMC \ WebServer1 $).

ApplicationPoolIdentity — это идентификатор, рекомендованный корпорацией Майкрософт (и используемый по умолчанию) для пулов приложений IIS. Для получения дополнительной информации об удостоверениях пула приложений и о том, как защитить локальные и сетевые ресурсы, прочтите Удостоверения пула приложений на iis.сеть.

Комплексная безопасность

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

Аутентификация SQL Server

 Источник данных = Server01; Первоначальный каталог = CampusVue; ID пользователя = имя пользователя; Пароль = пароль 

Встроенная безопасность

 Источник данных = Server01; Первоначальный каталог = CampusVue; Интегрированная безопасность = True 

Удостоверение пула приложений для студента-антологии

  • По умолчанию ApplicationPoolIdentity будет идентификатором, используемым пулом приложений (CampusNexusStudentAppPool).

  • По умолчанию все строки подключения в web.config будут использовать встроенную безопасность.

Обычно и рекомендуется использовать группу Active Directory для ведения списка серверов приложений, имеющих доступ к базе данных.Это позволяет связать доступ к ресурсам с группой в целом, а не с каждым отдельным сервером приложений.

Для авторизации доступа веб-сервера к серверу SQL:

  1. На сервере, на котором размещена база данных SQL для Anthology Student, откройте Microsoft SQL Server Management Studio.

  2. Подключитесь к базе данных и в обозревателе объектов перейдите к Security .

  3. Щелкните правой кнопкой мыши Логины и выберите «Новый вход …» .

  4. Предоставьте доступ к серверу SQL для CampusNexusStudentAppPool.

    • Если SQL Server работает на другом компьютере, чем веб-сервер (наиболее часто):

      В поле «Имя для входа» в окне «Вход — Новое» добавьте Имя сервера $ . (Не нажимайте кнопку «Поиск».)

       Домен \ имя_сервера $ 

      Например:

       CMC \ WebServer1 $ 
       
    • Если SQL Server работает на том же компьютере, что и веб-сервер:

      Добавьте учетную запись пула приложений в базу данных:

       IIS AppPool \ appPoolName 

      Например:

       IIS AppPool \ CampusNexusStudentAppPool 
  5. Обязательно предоставьте DB_Owner доступ к базе данных Anthology Student.

Последнее обновление: 30.07.2021 | Менеджер установки 1.23 | © 2021 Anthology Inc. Все права защищены. | www.anthology.com

Пул приложений — обзор

Пользователь службы

При создании пользователя для пула приложений мы должны помнить о концепции минимальных привилегий.Хорошим примером минимальных прав может быть удаление вновь созданных учетных записей служб из группы пользователей домена по умолчанию после их настройки. Группа пользователей домена широко используется многими администраторами для предоставления доступа как для чтения, так и для записи к ресурсам, когда они являются пользователями, аутентифицированными доменом. Нашей учетной записи пользователя не требуется такой доступ, поэтому мы удалим их, как только создадим. Чтобы упростить этот процесс и лучше отслеживать пользователей службы, я создаю глобальную группу для пользователей службы и заполняю эту группу учетными записями служб.Таким образом я могу создавать правила доступа, специфичные для пользователей службы. В этом примере я буду использовать gServiceUsers . Не совсем креативно, но самоочевидно. Этот общий процесс с наименьшими привилегиями подробно описан в главе 5, озаглавленной «Создание и обслуживание пользователей услуг с низкими привилегиями». Здесь также обсуждаются подробные предложения по созданию и администрированию учетных записей служб, в том числе политики истечения срока действия паролей и меры по блокировке учетных записей служб.

Пользователь моей учетной записи службы окажется пользователем с очень низкими привилегиями, который является членом gServiceUsers, и только gServiceUsers. У пользователя должна быть установлена ​​основная группа в AD, и по умолчанию это группа пользователей домена. Другая причина для создания отдельной группы gServiceUsers заключается в том, что вы можете добавить их в группу служб, установить группу служб в качестве основной группы, а затем удалить их членство у пользователей домена. Вы не можете удалить пользователя из числа пользователей домена, пока не сделаете этого.

Согласно инструкциям в главе о пользователях услуг, мы получим скромного пользователя.Я назову аккаунт MyWebApp , который пока является только членом группы gServiceUsers. Это показано на рисунке 2.27.

▪ Рисунок 2.27. Сведения о пользователе MyWebApp и членство в группе

Создайте новый пул приложений в IIS и отредактируйте дополнительные параметры, чтобы изменить запись ApplicationPoolIdentity по умолчанию, указав настраиваемую учетную запись MyWebApp, которая будет использоваться в качестве удостоверения пула приложений. Это показано на рисунке 2.28.

▪ Рисунок 2.28. Расширенные настройки пула приложений TMSB, показывающие изменение идентификатора ApplicationPoolIdentity по умолчанию на настраиваемую учетную запись пользователя MyWebApp

Теперь, когда мы изменили идентификатор пула приложений, как показано на рисунке 2.28, мы все настроены. Обратите внимание на тот факт, что здесь необходимо ввести пользовательские учетные данные, которые хранятся в IIS. Если вы измените пароль учетной записи в AD без изменения пароля, хранящегося здесь, ваше приложение перестанет работать. Пароли не синхронизируются.

Все, что осталось сделать, это добавить учетную запись службы MyWebApp в группу gShared, которая уже настроена для доступа для чтения, и наш сайт готов к работе. Поскольку группа gShared уже содержит Стива и Грега, это простой способ гарантировать, что все участвующие стороны имеют доступ для чтения (см. Рисунок 2.29).

▪ Рисунок 2.29. Обновленная группа gShared, содержащая пользователей и учетную запись службы, которая должна иметь доступ к общему ресурсу пользователей удаленного сервера

Обратите внимание, что этот пример политики доступа по-прежнему предоставит Стиву и Грегу доступ к файлам друг друга, но мы знаем, как изменить разрешения в соответствии с требованиями доступа, как показано на рисунках с 2.12 по 2.14.

Важно, чтобы у нас было веб-приложение, настроенное для обеспечения легкого доступа к виртуальным каталогам на других серверах в контексте учетной записи пользователя, которая очень ограничена в области авторизации.Это хорошая вещь. Поскольку существующие структуры общих ресурсов уже будут иметь разрешения на доступ, соответствующие вашим потребностям, эти общие ресурсы можно расширить для внешних пользователей для удаленного доступа для чтения, просто включив пользователя MyWebApp, группу gShared или эквивалентную группу в доступ для чтения. Теперь мы можем считать, что наша веха достигнута, как показано на Рисунке 2.11. Ура!

Однако, как это обычно бывает в ИТ-безопасности, расширение функциональности часто наследует расширенный диапазон риска.И этот случай ничем не отличается. У нас больше нет пользовательского контекста, ограниченного доступом к файлам только на локальном сервере, если это разрешено. Теперь у нас есть веб-приложение, использующее учетную запись домена, которая, по замыслу, может читать файлы и папки на других серверах (опять же, если это разрешено). Конечно, локализованный IIS APPPOOL \ DefaultAppPool может также подключаться к общей сети, где доступ предоставляется КАЖДОМУ или аутентифицированным пользователям, если веб-сервер является членом домена, но это реальный пользователь домена. Значит, это плохое решение? Нисколько.Если вы хотите, чтобы веб-приложение имело доступ к виртуальным каталогам на других серверах, оно должно иметь возможность читать данные. При настройке этого решения мы провели комплексную проверку дизайна и развернули учетную запись с учетом концепции минимальных привилегий.

Что такое пул приложений IIS — Stackify

Люди, которые плохо знакомы с размещением веб-приложений в IIS (Internet Information Services), иногда испытывают затруднения с концепцией пулов приложений. Что такое пул приложений IIS? Какой цели это служит? В этом посте мы ответим на эти и другие вопросы.

Мы начнем с краткого введения в сам IIS. Если вы уже хорошо знакомы с этой программой, то первый раздел не для вас; не стесняйтесь пропустить это. Те из вас, кто решит прочитать его, узнают немного о IIS и той роли, которую он играет в стеке Microsoft.

После этого мы перейдем к рассмотрению концепции «пулов» в мире технологий. Если вы ИТ-специалист, особенно в области разработки программного обеспечения, вы, вероятно, встретите разумное количество «пулов» в своей повседневной работе, поэтому имеет смысл определить и их.

Затем мы подошли к основной теме статьи: пулы приложений IIS. Вы увидите определение пула приложений IIS, поймете его назначение и узнаете подробности о различных типах пулов.

Краткое введение в IIS

IIS означает Internet Information Services, как вы видели во введении. IIS, ранее известный как «Информационный Интернет-сервер», представляет собой веб-сервер, созданный Microsoft.

В приведенном выше абзаце кратко описывается, что такое IIS.Мы могли бы оставить все как есть и покончить с этим, если бы не «веб-сервер». Видите ли, «веб-сервер» — это несколько двусмысленный термин, потому что он может означать две разные, но взаимосвязанные вещи.

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

Поскольку Microsoft является — или, по крайней мере, была на протяжении большей части своей истории — компанией-разработчиком программного обеспечения, вам не понадобится много времени, чтобы понять, что IIS относится к категории веб-серверов «программное обеспечение».Итак, IIS — это приложение, используемое для размещения и управления веб-приложениями / веб-сайтами в Windows. Он был представлен еще в 1995 году как бесплатное дополнение к Windows NT 3.51 и с тех пор входит в семейство Windows NT.

Концепция «пулов» в технике

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

Согласно Википедии:

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

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

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

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

Пул приложений IIS — что это такое и что он используется для

Мы начали публикацию с обзора IIS, а затем приступили к определению концепции «пулов» в технологиях. Теперь мы готовы собрать все воедино и начать отвечать на заглавный вопрос.

Определение пула приложений IIS

После изучения IIS и понимания значения пула в информатике определение «пула приложений IIS» должно быть почти тривиальным.Пул приложений IIS — это пул, то есть коллекция, в которой размещаются приложения в IIS. Каждый пул приложений состоит из процесса под названием w3wp.exe, который выполняется на сервере. Вот и все.

Возникает очевидный вопрос: почему? Какова цель пулов приложений в IIS? Для чего вы их используете? Есть ли какие-то последствия для ваших приложений?

Пул приложений IIS: понимание потребностей

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

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

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

Наконец, вы также можете захотеть запускать приложения в разных версиях .NET framework. Это еще один случай, когда может пригодиться пул приложений.

Углубление: общие и выделенные пулы приложений

Пулы приложений IIS можно разделить на две основные категории: общие пулы приложений и выделенные пулы приложений.

Общие пулы приложений

Вы называете пул приложений «общим», если в нем размещается несколько веб-приложений, работающих под ним. Обычно вы объединяете множество приложений в один пул приложений, если хотите сохранить память сервера.Как мы уже упоминали, каждый пул состоит из процесса w3wp.exe. Если у вас десять приложений, каждое в своем собственном пуле, это означает, что у вас выполняется десять процессов. С другой стороны, если вы разместите все десять приложений в одном пуле приложений, у вас будет запущен один процесс w3wp.exe.

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

Выделенные пулы приложений

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

  • Изоляция приложений, которым требуется больше ресурсов, чтобы они не снижали производительность других приложений.
  • Предотвращение проблем с одним приложением, приводящим к остановке других приложений
  • Предотвращение доступа приложения к данным из другого.
  • Имеются разные настройки (например, разные версии .NET) для разных приложений.
  • Изоляция приложений с низким уровнем доверия в ограничительной среде с низкими привилегиями для предотвращения несанкционированного доступа к другим приложениям.

Недостаток выделенных пулов приложений сводится к использованию ресурсов: поскольку каждый пул представляет собой отдельный процесс, требуется больше ресурсов.

Какой выбрать?

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

  • По какой-то причине это критическое приложение.
  • Это приложение, которому вы не полностью доверяете (например, стороннее приложение).
  • Потребляет слишком много ресурсов.

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

Пул приложений IIS: узнайте, как его использовать и получить прибыль

Это все, что нужно знать о IIS и его пулах приложений? Напротив: все, что вы прочитали, — не что иное, как верхушка айсберга. Теперь вам нужно подумать о том, чтобы учиться и узнавать больше. Следующим интересным шагом будет изучение того, как отслеживать производительность IIS: он действует как последовательность в теме этой публикации.Если вы хотите сделать еще один шаг, вам следует начать проверять инструменты, имеющиеся в вашем распоряжении. Например, взгляните на Retrace, систему управления производительностью приложений от Stackify.

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

Авторизовать идентификацию пула приложений IIS для ресурсов файловой системы

Веб-приложения могут запускаться на информационном сервере Интернета (IIS) с различными идентификаторами . Это может быть целесообразно или необходимо для получения доступа к Active Directory или другим защищенным системам. Однако вам нужно сделать точное обозначение идентификатора пула.

Для этой цели IIS имеет пулов приложений , которые создают общую инфраструктуру процессов.

  • Каждое веб-приложение привязано к одному конкретному пулу
  • Однако один пул может отвечать за несколько приложений
  • Каждый пул имеет идентификатор пула (идентификатор пула приложений)

Идентификатор пула :

  • Индивидуально настроенный локальный пользователь
  • Пользователь Active Directory или
  • Идентификатор виртуального пула (начиная с IIS 7)

Идентификация и безопасность пула

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

Идентификатор пула для авторизации файловой системы

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

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

Обозначение идентификатора пула

Состоит из следующих символов (обратите внимание на пробелы):

IIS AppPool \ [AppPoolName]

для пула по умолчанию, например:

IIS AppPool \ DefaultAppPool

IIS AppPool \ DefaultAppPool

Это вам помогло? Поделитесь или оставьте комментарий:

Статья создана: 02.10.2014

Что такое пул приложений в IIS и как он работает

Что такое пул приложений?

Пул приложений Internet Information Services (IIS) — это набор URL-адресов, который направляется одному или нескольким рабочим процессам. Пулы приложений, отвечающие за изоляцию одного или нескольких приложений в их собственном процессе. Например, у вас есть два разных веб-сайта, таких как веб-сайт A и веб-сайт B, и вы хотите развернуть их на одном сервере, тогда пул приложений, изолирующий ваш веб-сайт, означает, что веб-сайт A работает в одном пуле приложений, а веб-сайт B запускается в другом пуле приложений.

Он обеспечивает удобный способ администрирования набора веб-сайтов и приложений и соответствующих им рабочих процессов. Границы процессов разделяют каждый рабочий процесс; поэтому на веб-сайт или приложение в одном пуле приложений не будут влиять проблемы с приложениями в других пулах приложений. Пулы приложений значительно повышают надежность и управляемость веб-инфраструктуры.

Что такое повторное использование пула приложений в IIS?

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

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

Как настроить периодическую перезагрузку для пула приложений

  • Откройте Internet Information Services (IIS) Manager :
    • Если вы используете Windows Server 2012 или Windows Server 2012 R2:
      • На панели задач щелкните Server Диспетчер , щелкните Инструменты , а затем щелкните Диспетчер информационных служб Интернета (IIS) .
    • Если вы используете Windows 8 или Windows 8.1:
      • Удерживая нажатой клавишу Windows , нажмите букву X , а затем щелкните Панель управления .
      • Щелкните Администрирование , а затем дважды щелкните Диспетчер информационных служб Интернета (IIS) .
    • Если вы используете Windows Server 2008 или Windows Server 2008 R2:
      • На панели задач щелкните Пуск , укажите Администрирование , а затем щелкните Диспетчер информационных служб Интернета (IIS) .
    • Если вы используете Windows Vista или Windows 7:
      • На панели задач щелкните Пуск , а затем щелкните Панель управления .
      • Дважды щелкните Администрирование , а затем дважды щелкните Диспетчер информационных служб Интернета (IIS) .
  • На панели Подключения разверните имя сервера и щелкните Пулы приложений .
  • На панели Пулы приложений выберите пул приложений, который нужно изменить.
  • На панели Actions щелкните Recycling…
  • На странице Recycling Conditions мастера Edit Application Pool Recycling Settings выберите хотя бы один из параметров в разделе Fixed Intervals введите значения в поле соответствующие текстовые поля, а затем щелкните Далее .
  • (необязательно) На странице «События повторного использования для журнала» мастера изменения параметров повторного использования пула приложений выберите настраиваемые события повторного использования и события повторного использования во время выполнения, которые IIS должен отправлять в журнал событий при их возникновении, а затем щелкните Отделка .

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

В Windows 2003

Перейдите в Пуск -> Администрирование -> Диспетчер информационных служб Интернета (IIS). Разверните сервер и группу «Пулы приложений». Щелкните правой кнопкой мыши пул приложений, который вы хотите настроить, и выберите «Свойства». В первой вкладке вы найдете настройки утилизации.

В Windows 2008 R2

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

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

Другой тип режима управляемого конвейера в IIS

Есть два типа ».Режимы интеграции .NET для приложения ASP.NET, которые определили, как IIS обрабатывает входящий запрос к сайтам, приложениям и веб-службам, которые работают в этом пуле приложений.

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

Интегрированный режим делает ASP.NET неотъемлемой частью IIS. Теперь функциональность сервера IIS разделена на более чем 40 модулей, которые разбивают функциональность IIS и ASP.NET на части. Такие модули, как StaticFileModule, BasicAuthenticationModule, FormsAuthentication, Session, Profile и RoleManager, являются частью конвейера IIS.FormsAuthentication, Session, Profile и RoleManager ранее были частью ASP.NET и не имели никакого отношения к IIS.

Классический режим

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

Учетная запись удостоверения пула приложений

Учетная запись удостоверения пула приложений позволяет запускать приложение под уникальной учетной записью без необходимости создавать домены или локальные учетные записи и управлять ими. В IIS 8.0+ рабочий процесс администратора IIS (WAS) создает виртуальную учетную запись с именем нового пула приложений и по умолчанию запускает рабочие процессы пула приложений под этой учетной записью.

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

В консоли управления IIS в разделе Дополнительные параметры для пула приложений убедитесь, что элемент списка Identity настроен на использование ApplicationPoolIdentity , как показано на изображении ниже.

Защита ресурсов

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

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

  1. Откройте проводник Windows и перейдите в каталог.
  2. Щелкните каталог правой кнопкой мыши и выберите «Свойства».
  3. На вкладке Security нажмите кнопку Edit , а затем кнопку Add
  4. Нажмите Locations и убедитесь, что вы выбрали свой сервер.

  1. Введите IIS AppPool \ DefaultAppPool в Введите имена объектов, чтобы выбрать текстовое поле .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *