В Windows Server 2012 R2 IIS работает как веб-сервер в обычных условиях. Однако веб-контент не из этой c:\inetpub\wwwroot\папки, а из какой-то другой. Веб-приложения по-прежнему работают под своим собственным пользователем, который находится в defaultAppPool.
Я вообще-то забыл дать IIS_IUSRSправа на чтение/выполнение для папки веб-контента. Папка давала доступ, usersхотя. Я добавлял IIS_IUSRSправа на чтение/выполнение/запись только в том случае, если подпапка должна быть доступна для записи.
Желая немного усилить безопасность, я просмотрел права доступа к папке веб-контента и методом проб и ошибок узнал, что теперь, когда доступ к IIS_IUSRSотсутствовал, именно доступ к usersгруппе отвечает за то, чтобы все работало. Потому что когда я удаляю доступ к группе users, приложение перестает работать.
Я пробовал предоставить доступ некоторым другим аккаунтам/группам и понял, что предоставление доступа обоим usersи IIS_IUSRSпо отдельности запускает мое приложение. Предоставление доступа просто IIS APPPOOL\не дает результата. Но предоставление доступа моему конкретному пользователю пула приложений (EG IISAPPPOOL\nl-x-homepage) дает. И этот последний бит — то, что мне нужно, так как я не хочу, чтобы одно приложение могло получать доступ к файлам другого приложения.
Но мне было интересно... Как именно работают учетные записи IIS? Почему предоставление доступа usersтакже работает для моего пула приложений для доступа к папке веб-контента? Я не вижу моего конкретного пользователя пула приложений в lusrmgr, но предполагаю, что мой конкретный пользователь пула приложений находится в группе usersили в какой-то другой группе, которая находится в usersгруппе. Может ли кто-нибудь это подтвердить?
И последний вопрос по этому вопросу: чтобы иметь определенные папки «защищенными паролем», я создал обычного пользователя в Windows, удалил его из группы users, и в диспетчере IIS я перешел в эту папку и сделал Authentication -> Basic Authentication -> Enabled, и в Authentication Rules я установил правило Allow для моей новой учетной записи пользователя Windows. Это работает. Но анализируя доступ на чтение/запись, я был удивлен, узнав, что хотя приложение работает под пользователем пула приложений, пользователю пула приложений нужны только права на чтение (без прав на запись), а новый пользователь Windows должен иметь как права на чтение, так и права на запись, чтобы папка была доступна для записи. Может кто-нибудь помочь объяснить, почему это работает таким образом?
решение1
Поведение, с которым вы сталкиваетесь, кажется мне вполне логичным.
IIS_IUSRS — это группа, а не учетная запись, единственное назначение которой — дать возможность ее членам назначаться в качестве идентификаторов пула приложений, поэтому простого ее добавления недостаточно (как вы уже выяснили).
Группа пользователей содержит учетную запись ASPNET, которая имеет достаточно разрешений для работы веб-сайта, поэтому ее добавления было достаточно для разрешений по умолчанию. Я считаю, что учетная запись ASPNET используется как DefaultAppPool.
Файл или папка, созданные пользователем, всегда имеют разрешение на чтение, поскольку создатель является владельцем и имеет все разрешения. В случае, когда другой пользователь создал файл или папку, предоставление только разрешений на запись без права на чтение никогда не работало в Windows, поскольку доступ на чтение требуется для проверки разрешений и доступного места и т. п. перед записью.
решение2
IIS_IUSRS — это группа учетных записей рабочих процессов IIS. Эта встроенная группа имеет доступ ко всем необходимым файловым и системным ресурсам, так что учетная запись, добавленная в эту группу, может беспрепятственно действовать как идентификатор пула приложений.
Если вы щелкните правой кнопкой мыши по домену и откроете Edit permissions, вы должны увидеть перечисленные группы и разрешения. На вкладке Security вы увидите MACHINE_NAME\IIS_IUSRS, а также /Users. IIS автоматически имеет разрешение только на чтение для этого каталога.
Для каждого созданного вами пула приложений свойство Identity нового пула приложений по умолчанию устанавливается на ApplicationPoolIdentity. Процесс администрирования IIS (WAS) создаст виртуальную учетную запись с именем нового пула приложений и запустит рабочие процессы пула приложений под этой учетной записью по умолчанию. Всякий раз, когда создается новый пул приложений, процесс управления IIS создает идентификатор безопасности (SID), который представляет имя самого пула приложений. Например, если вы создаете пул приложений с именем "MyFirstPool", в системе безопасности Windows создается идентификатор безопасности с именем "MyFirstPool". С этого момента ресурсы можно защищать, используя эту идентификацию.Однако эта личность не является реальной учетной записью пользователя; она не будет отображаться как пользователь в консоли управления пользователями Windows.. Это нормальное поведение. Если вы хотите предоставить доступ к определенной папке, просто добавьте ее в папку, отредактировав разрешения. Однако вам нужно проверить конфигурацию аутентификации по умолчанию (анонимная идентификация) и посмотреть, доступен ли правильный выбор, или настроить ее так, чтобы избежать ошибок доступа.
Эта почтаотвечает на остальные вопросы. Наследование.
Очевидно, что пользователь Windows, которого вы добавляете здесь, требует разрешений, поскольку учетная запись должна наследовать разрешения от необходимых групп. Разрешение на чтение здесь жизненно важно. Однако оно предназначено для доступа к локальным ресурсам.