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


11

Я использую IIS7 (Windows Server 2008 x64), и у меня есть настройка сайта с использованием анонимной аутентификации. Аноним пользователя настроен как IUSR. Приложение записывает файлы в папку, и я даю разрешения RW группы IIS_IUSRS на эту папку. Это не работает Я должен явно дать разрешения IUSR RW, чтобы приложение могло записывать в папку.

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

При устранении неполадок я использую Process Monitor для просмотра доступа к папке и определил, что сетевая служба (удостоверение пула приложений) олицетворяет IUSR (это то, что я ожидал), но предоставление разрешений RW группе IIS_IUSRS не позволило IUSR получить доступ к доступ к файлу запрещен).

Кто-нибудь может объяснить, является ли IUSR членом группы IIS_IUSRS или нет?

Я просмотрел следующую документацию и не нашел четкого ответа:

Общие сведения о встроенных учетных записях пользователей и групп в IIS 7

Идентификационные данные пула приложений

Ответы:


14

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

Теперь, даже если вы не сказали этого, позвольте мне догадаться - это приложение классического Asp? (В противном случае, если это .Net, то вы должны использовать олицетворение). В любом случае происходит то, что к ресурсам обращаются как к олицетворенной личности, то есть к анонимному пользователю в вашем случае, то есть к IUSR. Вот почему вы должны предоставить ему права. В .Net, если вы отключите олицетворение, вы обнаружите, что IIS_IUSRS вступит в игру, как вы ожидаете. В Classic ASP (и для статических файлов) у вас нет выбора, олицетворение всегда «включено»; поэтому всегда используется идентификация пользователя, а не идентификация пула. Так как IIS_IUSRS предназначен для идентификаторов пула, он не находится в игре.


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

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

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

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

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

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

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

Ресурсы анонимного доступа для олицетворения, доступные как

Включено Включено IUSR_computer в IIS5 / 6 или
                                       IUSR в IIS7 или,
                                       Если вы изменили учетную запись пользователя anon 
                                       в IIS, все, что вы там установили
Включено Отключено MYDOM \ MyName
Отключено Включено NT Authority \ Сетевая служба (удостоверение пула)
Отключено Отключено NT Authority \ Сетевая служба (удостоверение пула)


Мы определенно используем .Net (3.5 таргетинг), но он может использовать олицетворение. Я должен проверить с моими разработчиками, чтобы быть уверенным. Мое замешательство связано с тем фактом, что я предположил (неверно кажется), что анонимный пользовательский идентификатор автоматически был членом группы IIS_IUSRS. Так как он не позволяет мне уточнить и, пожалуйста, поправьте меня, если я беспокоюсь.

1) Используя классический ASP, права доступа к файлу используют анонимный идентификатор пользователя. В IIS 7 или более поздней версии этот пользователь по умолчанию не является членом группы IIS_IUSRS. 2) Используя ASP.Net, права доступа к файлу используют анонимную идентификацию пользователя, если олицетворение включено. В IIS 7 или более поздней версии этот пользователь по умолчанию не является членом группы IIS_IUSRS. 3) Используя ASP.Net, права доступа к файлу используют идентификацию рабочего процесса, если олицетворение отключено. В IIS 7 или более поздней версии этот пользователь по умолчанию всегда является членом группы IIS_IUSRS.

Да, абсолютно правильно по всем пунктам! Чтобы быть совершенно ясным, в # 1 и # 2 вы должны добавить "если IIS anon auth включен", который я не должен был включать ранее, потому что вы уже сказали, что используете anon. Смотрите таблицу, которую я добавил, чтобы лучше объяснить это.
Амит Найду

Большое спасибо за разъяснение этого. Это согласуется с тем, что я обнаружил методом проб и ошибок, но я нигде не видел этого очень четко задокументированного. Это крайне важно для администраторов, которые используют LUA на своих серверах при настройке приложений IIS, которым необходимо разрешение на запись.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.