Каким образом, когда я добавляю доступ IIS_IUSRS RW к папке, он автоматически не предоставляет доступ ISUR RW?

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

Теперь даже при том, что Вы не сказали это, позвольте мне предположить - это приложение является классическим asp? (Иначе, если это - .NET затем, необходимо использовать олицетворение). Так или иначе, что происходит, то, что к ресурсам получают доступ как явленные олицетворением идентификационные данные, значение, анонимный пользователь в Вашем случае, означая IUSR. Именно поэтому необходимо предоставить ему права. В .NET, если Вы выключаете олицетворение, Вы найдете, что IIS_IUSRS сыграет роль, как Вы ожидаете. В Классике ASP (и для статических файлов), у Вас нет выбора, олицетворение всегда "включается"; так всегда пользовательские идентификационные данные, которые используются, не идентификационные данные пула. Таким образом, так как IIS_IUSRS для идентификационных данных пула, это не находится в игре.

Редактирование после OP добавило больше информации:

Легко перепутать IUSR и IIS_IUSRS из-за их имен. К способу видеть то, что они отличаются, должно помнить, что IIS_IUSRS является заменой для IIS_WPG в IIS6, который был Worker Process Group. Этим группам Вы добавляете учетные записи, что Вы хотите выполнить свои объединения под, не скоро идентификационные данные, скоро полномочия, как предполагается, более ограничены. например, иногда Вы могли бы хотеть использовать учетную запись домена для выполнения пула для kerberos делегации других сетевых ресурсов. Затем Вы добавили бы что сервисная учетная запись к этой группе.

Когда олицетворению включают, пул/процесс симулирует быть пользователем, потому что этому сказали. В случае скоро автора (Ваш случай), тот пользователь является IUSR. В случае автора окон это были бы windows\domain идентификационные данные пользователя. Это также, почему Вы поражали производительность олицетворением, потому что процесс должен переключиться на другие идентификационные данные для доступа ресурса.

Если Вы используете.NET и анонимную аутентификацию, то я не вижу, почему Вы включили бы олицетворение все же. В случае, если Вы не используете или не нуждаетесь в олицетворении, необходимо знать о еще некотором обмане в случае IIS7: можно заставить IUSR уйти полностью и закончить весь беспорядок. Я думаю, что Вы хотели бы это, и это - мой предпочтительный метод также. Все, что необходимо сделать, должно сказать этому снова использовать идентификационные данные пула как анонимные идентификационные данные.

Таким образом, после этого необходимо будет только иметь дело с группой IIS_IUSRS. Но не запутывайтесь, это все еще не означает, что эти два являются тем же! Для идентификационных данных процесса может быть возможно заменить IUSR, но не наоборот!

Еще немного обмана IIS7 для знания: при рассмотрении IIS_IUSRS это может быть пусто. Поэтому Ваши виртуальные идентификационные данные пула автоматически добавляются к нему, когда пул запускается, таким образом, Вы не должны волноваться об этих вещах.

Эта таблица должна помочь разъяснить лучше, как идентификационные данные выполнения потока определяются:

Impersonation  Anonymous Access   Resources Accessed As

Enabled          Enabled           IUSR_computer in IIS5/6 or,
                                       IUSR in IIS7 or,
                                       If you changed the anon user account 
                                       in IIS,  whatever you set there
Enabled          Disabled          MYDOM\MyName
Disabled         Enabled           NT Authority\Network Service (pool identity)
Disabled         Disabled          NT Authority\Network Service (pool identity)