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

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

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

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

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

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

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

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

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

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

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

• 10/09/2020
• Чтение занимает 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 доступом на сайте.

Если вы хотите отключить эту функцию и вручную добавить учетные записи в группу, установите значение 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" />

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 битную платформу 1С данное значение оставляем False,иначе будете получать ошибку 0x800700c1
(Эта проблема возникает из-за неверного сопоставление сценариев. Убедитесь в том, что сопоставление сценария указывает на ISAPI DLL-файл, который может обработать запрос. Чтобы сделать это, выполните следующие действия.)
Режим управляемого конвейера — выбираем значение Classic

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

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

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

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

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

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

Тоже самое с правами, мы делаем для каталога куда установлена 1с и каталога куда развернута наша файловая база. Если Вы используете базу 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

• 28.03.2014
• 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

• 09.10.2020
• На чтение 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_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, поймете его назначение и узнаете подробности о различных типах пулов.