Назад | Перейти на главную страницу

Почему общая конфигурация в IIS 7.5 не реплицирует идентификаторы безопасности пула приложений?

У нас есть ферма серверов IIS 7.5, настроенная с использованием общей конфигурации. Файлы конфигурации были экспортированы в общий сетевой ресурс, доступный для обеих машин. Мы знаем, что общая конфигурация работает, потому что все синхронизировано - новые сайты, привязки сайтов, правила перезаписи URL - все Кроме идентификаторы безопасности пула приложений.

Создание пула приложений в IIS 7.5 запускает создание нового удостоверения пула приложений с SID, начинающимся с S-1-5-82 (больше информации). При включенной общей конфигурации пул приложений отображается на обоих узлах, поскольку он хранится в ApplicationHost.config, но его соответствующий SID создается только на узле, на котором я прошел через процесс «Добавить пул приложений».

Я могу открыть Управление компьютером на первом узле и увидеть удостоверение пула приложений в группе IIS_IUSRS. Однако на другом узле эта группа пуста.

Это ошибка в IIS или мы что-то не так сделали с нашей общей конфигурацией?

Обновить: Группа IIS_IUSRS несущественна. Проблема проявляется в том, что я могу назначить права доступа к файлам для удостоверения пула приложений на одном узле, но не на другом. Это похоже на тему этот вопрос, но запуск IISRESET не исправляет его на втором узле.

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

S-1-5-82- {SHA1 имени пула приложений} будет общим для всех блоков, в которых существует пул приложений, с тем же именем. Shared Config создаст одинаковые пулы приложений на всех устройствах; для пулов приложений будет создан тот же SID.

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

но соответствующий ему SID создается только на узле, где я прошел через процесс «Добавить пул приложений»

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

Сделаем еще один шаг: обычно не требуется, чтобы что-либо было членом IIS_IUSRS. Только если manualGroupMembership имеет значение true, учетные записи пула приложений необходимо добавлять в эту группу.

Так что звуки как будто кто-то вручную добавил «IIS AppPool \ YourAppPoolName» (интервал между заметками) в группу IIS_IUSRS на одной машине и не беспокоился о второй.

Удостоверения пула приложений никогда не отображаются как учетные записи пользователей (AFAIK) и обычно не отображаются в этой группе (поскольку по умолчанию используется manualGroupMembership = false, и все в целом довольны этим), а также членство в этой группе не что-то дает вам Shared Config.

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

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

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

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