Я не могу осмыслить это. В документах IIS (и бесчисленных сообщениях на форуме) довольно четко описаны права, необходимые для запуска пула приложений IIS, в том числе права на пакетный вход (вход в систему как пакетное задание). Я подтвердил это при запуске пула приложений в качестве учетной записи домена, где рабочий процесс не запускается, если учетная запись домена не имеет этого права.
Однако, когда я запускаю пул приложений с использованием встроенного «удостоверения пула приложений» (IIS AppPool \ [имя пула приложений]), пул работает нормально, даже если этот идентификатор не имеет прав на пакетный вход (он запускается, службы запросы и т. д. без проблем). Это конкретное право заблокировано через объект групповой политики домена, и ни этот идентификатор, ни локальная группа IIS_IUSRS (которая, как я понимаю, встроенным учетным записям пула приложений предоставляется динамически во время выполнения), не имеют этого права.
Теперь IIS автоматически предоставил некоторые другие права идентификаторам пула приложений (и делает это каждый раз, когда создается новый пул приложений), такие как «Генерация аудита безопасности», «Вход в систему как служба» и т. Д. Но они явно не t заменить на то, что в нем отсутствует «Вход в систему как пакетное задание». Запуск инструмента «accesschk» из SysinternalsSuite подтверждает, что эти учетные записи не имеют этого права.
Эта ссылка описывает разрешение по умолчанию в IIS v7 + и отмечает, что идентификаторам пула приложений предоставляются определенные права, и что локальной группе IIS_IUSRS предоставляется «Вход в систему как пакетное задание» по умолчанию (что объясняет, почему идентификаторы пула приложений работают вне коробка):
Но я до сих пор не могу понять, как они могут работать должным образом в среде, где право на пакетный вход заблокировано через GPO домена и ни группа IIS_IUSRS, ни идентификаторы пула приложений не были включены в политику.
Это наблюдается на Server 2012R2 (IIS v8.5), и, что интересно, когда я немного покопался, я также увидел такое же поведение с пулами приложений, работающими как NetworkService в Server 2016 (IIS v10) (та же среда - пакетный вход в систему заблокирован через GPO домена и NetworkService, не включенный в эту политику).
Таким образом, может показаться, что по какой-то причине для локальных учетных записей не требуется право на пакетный вход для запуска пула приложений. Конечно, если мы попытаемся запустить пул под учетной записью домена без этих прав, это абсолютно не удастся. Сначала я подумал, что это всего лишь «виртуальные учетные записи» пула приложений, но это не объясняет такое же поведение с NetworkService - так, может быть, только встроенные локальные учетные записи? Я не знаю.
Кто-нибудь может пролить свет на это?