3

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

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

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

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

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

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

2 ответа2

1

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

Если вы щелкнете правой кнопкой мыши по домену и откроете разрешения на изменение, вы должны увидеть перечисленные группы и разрешения. На вкладке Безопасность вы увидите MACHINE_NAME\IIS_IUSRS, а также /Users. IIS автоматически имеет разрешение только для чтения для каталога.

Для каждого создаваемого пула приложений по умолчанию для свойства Identity нового пула приложений установлено значение ApplicationPoolIdentity. Процесс администрирования IIS (WAS) создаст виртуальную учетную запись с именем нового пула приложений и запустит рабочие процессы пула приложений под этой учетной записью по умолчанию. Каждый раз, когда создается новый пул приложений, процесс управления IIS создает идентификатор безопасности (SID), который представляет имя самого пула приложений. Например, если вы создаете пул приложений с именем "MyFirstPool", в системе безопасности Windows создается идентификатор безопасности с именем "MyFirstPool". С этого момента ресурсы могут быть защищены с помощью этой идентичности. Однако личность не является реальной учетной записью пользователя; он не будет отображаться как пользователь в консоли управления пользователями Windows. Это нормальное поведение. Если вы хотите предоставить доступ к определенной папке, просто добавьте ее в папку, отредактировав разрешения. Однако вы должны проверить конфигурацию аутентификации по умолчанию (анонимная идентификация) и посмотреть, доступен ли правильный выбор, или настроить ее, чтобы избежать ошибок доступа.

Подробнее о пулах приложений.

Этот пост посвящен остальным вопросам. Наследование.

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

1

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

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

Группа «Пользователи» содержит учетную запись ASPNET, которая имеет достаточные разрешения для работы веб-сайта, поэтому для ее добавления было достаточно разрешений по умолчанию. Я считаю, что учетная запись ASPNET используется как DefaultAppPool.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .