Iusr пользователь что это

Поннятие об анонимной идентификации и учетной записи IUSR

Dreamweaver UltraDev больше не поддерживается, а центр поддержки Dreamweaver UltraDev больше не обновляется. Функция, предоставлявшаяся в Dreamweaver UltraDev, теперь доступна в Dreamweaver, начиная с Dreamweaver MX.

Анонимный доступ, самый популярный способ управления доступом к сайтам, позволяет любому пользователю посещать открытые разделы сайта, но при этом неавторизованные пользователи не получат доступа к функциям администрирования и конфиденциальным данным на веб-сервере. Анонимная идентификация предоставляет пользователям доступ на сайт без запроса имени пользователя или пароля. Когда пользователь пытается подключиться к сайту, веб-сервер назначает такому пользователю учетную запись Windows под названием IUSR_название-компьютера, где «название-компьютера» – это имя имя сервера, на котором работает IIS.

По умолчанию учетная запись IUSR_название-компьютера включена в группу пользователей Windows «Гости» при установленном на сервере IIS. Эта группа имеет ограничения по правам, соответствующие разрешениям NTFS, которые задают уровень доступа и тип содержимого, доступного для обычных пользователей Интернета. Изменения можно внести в учетную запись, используемую для анонимной идентификации, в диспетчере служб Интернета на уровне веб-сервера или для отдельных виртуальных каталогов и файлов. Права доступа для учетной записи IUSR_название-компьютера можно изменить с помощью диспетчера пользователей для Windows NT и раздела «Локальные пользователи и группы» на консоли управления сервером для Windows 2000.

IIS использует учетную запись вида IUSR_название-компьютера следующим образом:

Windows 10, IIS 10: доступ к файлам, часть 3 (IUSR и IIS_IUSRS)

В сервере IIS (начиная с версии 7) есть встроенная учетная запись пользователя, которая называется IUSR, и есть встроенная группа, которая называется IIS_IUSRS. Кое-что (но далеко не всё) про эти встроенные учетную запись и группу рассказано в статье «Understanding Built-In User and Group Accounts in IIS 7» документации на сайте компании «Microsoft».

Кроме того, как уже упоминалось в предыдущем посте, в сервере IIS есть встроенная учетная запись пользователя для каждого пула приложений с именем, совпадающим с именем пула приложений. Например, для пула приложений, созданного автоматически по умолчанию при включении сервера IIS, эта учетная запись называется «DefaultAppPool». Подробнее об этом можно прочитать в статье «Understanding identities in IIS», а также в статье «Application Pool Identities» документации на сайте компании «Microsoft».

Путаница IUSR и IIS_IUSRS

Из-за сходства названий встроенной учетной записи пользователя IUSR и встроенной группы IIS_IUSRS их часто путают. Во-первых, некоторые люди их путают, считая одним и тем же. Очевидно, что это не так.

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

Название пользователя «IUSR» расшифровывается как «Internet User» (по-русски «пользователь интернета»). В качестве пользователя IUSR подразумевается любой пользователь, использующий браузер и обратившийся из браузера с помощью ввода URL-адреса к веб-серверу IIS.

В группу же IIS_IUSRS входят все встроенные учетные записи пулов приложений сервера IIS. То есть изначально в нее по умолчанию у меня входит только встроенная учетная запись пользователя «DefaultAppPool». При добавлении новых пулов приложений их встроенные учетные записи будут добавлены в группу IIS_IUSRS автоматически, то есть вручную их добавлять в эту группу не требуется (так настроено по умолчанию, но это можно изменить, сделав так, чтобы встроенные учетные записи новых пулов приложений нужно было добавлять в эту группу вручную).

Следует иметь в виду, что в программе (в сохраненной консоли программы «mmc.exe») «Управление компьютером» в списке пользователей учетная запись IUSR не отображается, несмотря на то, что она существует.

Группа IIS_IUSRS в программе «Управление компьютером» отображается, но, если попытаться просмотреть, кто в нее входит, то там ничего отображено не будет, несмотря на то, что в этой группе на самом деле есть содержимое. Вот как это выглядит у меня:

Как я понимаю, нет смысла заполнять эту группу вручную, если она пополняется автоматически.

Как используется встроенная учетная запись IUSR

Для пользователей, входящих из своих браузеров на наш сайт, который находится под управлением веб-сервера IIS, можно настроить аутентификацию (проверку подлинности личности). Устройство веб-сервера IIS не позволяет настроить вход на сайт пользователей вообще без аутентификации. В самом простом случае, который настроен автоматически по умолчанию при включении веб-сервера IIS в операционной системе, пользователи проходят на сайт в качестве анонимных пользователей. При этом от пользователей не требуется никаких действий по подтверждению своей личности. Для этого при аутентификации в веб-сервере IIS используется модуль «Анонимная проверка подлинности» (по-английски «Anonymous authentication»).

Если требуется настроить более сложную аутентификацию, этот умолчательный модуль «Анонимная проверка подлинности» нужно будет отключить и включить модуль другого способа аутентификации. Но мы это делать не будем и посмотрим, как настроена умолчательная аутентификация.

В программе «Диспетчер служб IIS» аутентификацию можно настроить на уровне сервера, на уровне сайта, на уровне папки и так далее. Для этого следует в левом меню «Подключения» выбрать нужный уровень (например, уровень сервера). После этого в средней части окна программы следует открыть пункт «Проверка подлинности» (по-английски «Authentication»):

В результате будет показан список готовых к использованию модулей, которые можно использовать для аутентификации пользователей:

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

Также на иллюстрации выше видно, что включен только модуль «Анонимная проверка подлинности», а второй модуль отключен. Заглянем в настройки включенного модуля. Для этого следует выделить его в списке в средней части окна программы, а затем выбрать пункт «Изменить. » в меню «Действия» справа:

Как видно на иллюстрации выше, при работе модуля «Анонимная проверка подлинности» каждый пользователь, входящий на наш сайт из своего браузера, в рамках нашего сервера считается пользователем встроенной учетной записи IUSR (при настройках по умолчанию; как видно из настроек выше, это можно изменить).

В главном файле настроек веб-сервера IIS «applicationHost.config» вышеописанная настройка выглядит так:

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

Под какой учетной записью происходит доступ к файлам сайта

Когда я стал изучать работу веб-сервера IIS, у меня сразу возник следующий вопрос. В прошлом посте я описывал архитектуру веб-сервера IIS, то, как он работает на уровне процессов. Там я описал, что пул приложений «DefaultAppPool» сайта «Default Web Site» запускается в виде рабочего процесса от имени встроенной учетной записи пользователя «DefaultAppPool». Теперь при изучении настроек веб-сервера IIS по умолчанию мы видим, что пользователь сайта числится под учетной записью IUSR. Тогда от имени какой из этих двух учетных записей происходит доступ к файлам сайта?

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

То есть, по идее, в зависимости от вышеописанной настройки, мы можем настроить либо доступ к файлам от имени встроенной учетной записи IUSR, либо от имени встроенной учетной записи «DefaultAppPool».

Итак, по умолчанию доступ к папке нашего сайта регулируется следующим списком доступа:

Шесть позиций, перечисленных в списке доступа на вышеприведенной иллюстрации, совпадают с теми, которые описаны для папки «\inetpub\wwwroot\» в статье «Default permissions and user rights for IIS 7.0 and later» документации на сайте компании «Microsoft». Из них меня сейчас в первую очередь интересуют две группы: «IIS_IUSRS» и «Пользователи».

Насколько я понимаю, встроенная учетная запись «DefaultAppPool» по умолчанию входит в группу «IIS_IUSRS» и в группу «Пользователи» компьютера, а встроенная учетная запись «IUSR» входит только в группу «Пользователи». (Эти факты не видны из программы «Управление компьютером».)

Обеим этим группам, как видно из иллюстрации выше, назначен ограниченный доступ к файлам: разрешены только чтение и выполнение, но не изменение файлов, не создание новых файлов, не удаление файлов и так далее. Последнее не важно для статических сайтов, так как на статических сайтах пользователь только читает файлы, но важно для динамических сайтов (вроде веб-приложения «WordPress»), на которых пользователь должен иметь право изменять файлы, создавать новые файлы и так далее. Таким образом, понятно, что для статических сайтов дополнительных настроек в плане доступа к файлам не требуется, а вот для динамических сайтов дополнительные настройки доступа к файлам могут потребоваться.

Я думаю, что для дополнительной настройки доступа к файлам сайта не стоит менять настройки доступа для групп, так как это может затронуть других пользователей, входящих в эти группы. Думаю, что для расширения прав доступа к файлам динамического сайта следует добавить в список доступа на вышеприведенной иллюстрации либо пользователя «IUSR», либо пользователя «DefaultAppPool» (в зависимости от того, кто из этих пользователей выбран при настройке анонимной аутентификации, описанной выше), назначив им необходимые права доступа.

IIS — Включение и конфигурирование проверки подлинности

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

Включение проверки подлинности

Любой метод проверки подлинности или их комбинация могут быть включены для любого веб- или FTP-узла, виртуального каталога или файла.

Чтобы включить метод проверки подлинности для WWW

1. Создайте учетную запись пользователя, соответствующую методу проверки подлинности. Если целесообразно, добавьте учетную запись в группу пользователей Windows. Более подробные сведения о создании учетных записей Windows см. в разделе Защита файлов средствами NTFS.
2. Сконфигурируйте разрешения NTFS для каталога или файла, доступом к которым необходимо управлять. Дополнительные сведения см. в разделе Задание разрешений NTFS для каталога или файла.
3. В оснастке IIS выберите веб-узел, каталог или файл и откройте вкладки его свойств.
4. Выберите соответствующую вкладку: Безопасность файла или Безопасность каталога. В группе Анонимный доступ и проверка подлинности нажмите кнопку Изменить.
5. В диалоговом окне Способы проверки подлинности выберите один или несколько способов.

Чтобы включить метод проверки подлинности для FTP

1. Выполните шаги 1-3 процедуры, описанной выше.
2. Выберите вкладку Безопасные учетные записи. Установите флажок Разрешить анонимные подключения.

Примечание. Для FTP проверка подлинности может быть установлена только на уровне узла.

Примечание. Синхронизацию паролей можно использовать только для учетных записей анонимных пользователей, которые определены на локальном компьютере, но не для анонимных учетных записей на других компьютерах в сети.

Примечание

• Анонимная и встроенная проверка подлинности Windows выбраны по умолчанию.
• И краткая, и встроенная проверка подлинности имеют приоритет перед обычной проверкой. Чтобы гарантировать проверку подлинности всех пользователей только обычной проверкой, сбросьте все остальные флажки.
• Краткая и встроенная проверки подлинности не могут быть использованы для узлов FTP.

Веб-сервер будет использовать обычную, краткую и встроенную проверку подлинности только при выполнении следующих условий:

• Анонимный доступ не разрешен.
• Попытка анонимного доступа оказалась неудачной или доступ к файлам и каталогам ограничен разрешениями NTFS.

Важно! При попытке изменить свойства веб-узла или виртуального каталога, веб-сервер запросит разрешение сбросить свойства отдельных подкаталогов или файлов, расположенных на этом узле или в каталоге. Если такое подтверждение получено, предыдущие значения свойств будут заменены новыми. Дополнительные сведения о настройке свойств см. в разделе «Свойства и наследование свойств на узлах» раздела О веб- и FTP-узлах.

Конфигурирование анонимной проверки подлинности

По умолчанию пользователь IUSR_ИмяКомпьютера включается Windows в группу пользователей «Гости». Может быть создано несколько учетных записей анонимных пользователей, по одной на каждый веб- или FTP-узел, каталог или файл. Предоставляя этим учетным записям различные права на доступ или назначая эти учетные записи разным группам пользователей, можно предоставить анонимным пользователям доступ к различным областям веб- и FTP-узлов.

Учетная запись анонимного пользователя должна давать пользователю права локального подключения. Если учетная запись не имеет права «Локальный вход в систему», IIS не сможет обслуживать никакие анонимные запросы. В контроллерах домена учетная запись IUSR_ИмяКомпьютера по умолчанию не имеет права «Локальный вход в систему»; чтобы разрешить анонимные подключения, ей нужно предоставить его.

Можно также изменить привилегии безопасности для учетной записи IUSR_Имя_компьютера в Windows. Однако если учетная запись анонимного пользователя не дает права доступа к определенному ресурсу, веб-сервер не установит анонимное соединение с этим ресурсом. Дополнительные сведения см. в разделе Задание разрешений для веб-сервера.

Чтобы изменить учетную запись, используемую для анонимной проверки подлинности

1. В оснастке IIS выберите веб-узел, каталог или файл и откройте вкладки его свойств.
2. Выберите соответствующую вкладку: Безопасность файла или Безопасность каталога. В группе Анонимный доступ и проверка подлинности нажмите кнопку Изменить.
3. В диалоговом окне Способы проверки подлинности в группе Анонимный доступ нажмите кнопку Изменить.
4. В диалоговом окне Учетная запись анонимного пользователя либо введите действительную учетную запись пользователя Windows, которую нужно использовать для анонимного доступа, либо выберите ее с помощью кнопки Обзор.
5. Сбросьте флажок Разрешить управление паролем из IIS, чтобы ввести пароль этой учетной записи.

Важно! Если изменить учетную запись IUSR_ИмяКомпьютера, изменения коснутся каждого анонимного запроса, который обслуживается веб-сервером. Будьте внимательны при изменении этой учетной записи.

Конфигурирование обычной проверки подлинности

Включение обычной проверки подлинности не приводит к автоматическому включению проверки подлинности пользователей на веб-сервере. Должны быть созданы учетные записи пользователей Windows и установлены разрешения NTFS (как это описано выше).

Чтобы правильно проверять подлинность пользователей обычным методом, учетные записи пользователей Windows, используемые для обычной проверки подлинности, должны иметь право «Локальный вход в систему». Это право должно быть назначено, поскольку обычная проверка подлинности имитирует локального пользователя (то есть, пользователя, который физически подключен к серверу). По умолчанию учетным записям пользователей на основном контроллере домена Windows (PDC) не предоставляется право локального входа в систему.

Примечание. Требования для права локального входа в систему могут быть изменены с помощью Active Directory Service Interfaces (ADSI). Для получения дополнительной информации см. раздел LogonMethod в руководстве по Active Server Pages.

Необходимо установить стандартный домен для входа. Дополнительные сведения см. в разделе Задание стандартного домена для входа.

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

Конфигурирование краткой проверки подлинности

Microsoft Internet Explorer версии 5 является единственным обозревателем, поддерживающим в настоящее время краткую проверку подлинности.

Краткая проверка подлинности будет функционировать только на доменах, контроллеры которых управляются операционной системой Windows 2000. Контроллер домена должен иметь копии используемых паролей в виде обычного текста, поскольку он должен выполнить операцию хэширования и сравнить результат со значением хэша, переданного обозревателем на компьютере пользователя. Дополнительные сведения о хранении этих паролей и по другим вопросам см. в документации Windows 2000 Server.

Важно! Поскольку контроллер домена хранит копии паролей в виде обычного текста, он должен быть защищен от физической и сетевой атак. Для получения более подробной информации о защите контроллера домена см. пакет Microsoft Windows 2000 Server Resource Kit.

Конфигурирование встроенной проверки подлинности Windows

Встроенная проверка подлинности Windows не работает через прокси-серверы и другие брандмауэры.

Если встроенная проверка подлинности Windows закончилась неудачей из-за неверных учетных сведений или других проблем, обозреватель предложит пользователю ввести имя и пароль.

Только обозреватель Microsoft Internet Explorer версии 2.0 или более поздней поддерживает встроенную проверку подлинности.

Каковы все учетные записи пользователей для IIS / ASP.NET и чем они отличаются?

В Windows Server 2008 с установленным ASP.NET 4.0 есть целая группа связанных учетных записей пользователей, и я не могу понять, какой из них, как они отличаются, и какой ДЕЙСТВИТЕЛЬНО тот, который запускается моим приложением под. Вот список:

• IIS_IUSRS
• IUSR
• DefaultAppPool
• ASP.NET v4.0
• NETWORK_SERVICE
• МЕСТНОЕ ОБСЛУЖИВАНИЕ.

1 ответ

Это очень хороший вопрос, и, к сожалению, многие разработчики не задают достаточно вопросов о безопасности IIS/ASP.NET в контексте создания веб-разработчика и настройки IIS. Итак, здесь идет.

Чтобы охватить перечисленные тождества:

IIS_IUSRS:

Это аналогично старой группе IIS6 IIS_WPG . Это встроенная группа с безопасностью, настроенная таким образом, что любой член этой группы может действовать как идентификатор пула приложений.

IUSR:

Эта учетная запись аналогична старой локальной учетной записи IUSR_<MACHINE_NAME> , которая была анонимным пользователем по умолчанию для веб-сайтов IIS5 и IIS6 (т.е. настроенных с помощью вкладки «Безопасность каталога» свойств сайта).

Для получения дополнительной информации о IIS_IUSRS и IUSR см.

DefaultAppPool:

Если пул приложений настроен на запуск с использованием функции идентификации пула приложений, тогда «синтезированная» учетная запись под названием IIS AppPool\<pool name> будет создана «на лету» для использования в качестве идентификатора пула. В этом случае будет создана синтезированная учетная запись IIS AppPool\DefaultAppPool , созданная для времени жизни пула. Если вы удалите пул, эта учетная запись больше не будет существовать. При применении разрешений к файлам и папкам их необходимо добавить с помощью IIS AppPool\<pool name> . Вы также не увидите эти учетные записи пула на своих компьютерах Диспетчер пользователей. Для получения дополнительной информации см. Следующее:

ASP.NET v4.0: —

Это будет идентификатор пула приложений для пула приложений ASP.NET v4.0. См. Выше DefaultAppPool .

NETWORK SERVICE: —

Учетная запись NETWORK SERVICE — это встроенный идентификатор, введенный в Windows 2003. NETWORK SERVICE — это низкоприоритетная учетная запись, в соответствии с которой вы можете запускать пулы приложений и веб-сайты. Веб-сайт, запущенный в пуле Windows 2003, все еще может олицетворять анонимную учетную запись сайта (IUSR_ или все, что вы настроили как анонимное удостоверение).

В ASP.NET до Windows 2008 вы могли бы выполнить запросы ASP.NET в учетной записи пула приложений (обычно NETWORK SERVICE ). В качестве альтернативы вы можете настроить ASP.NET для олицетворения анонимной учетной записи сайта с помощью параметра <identity impersonate=»true» /> в локальном каталоге web.config (если этот параметр заблокирован, то это должно быть сделано администратором в файле machine.config ).

Настройка <identity impersonate=»true»> распространена в средах с общим хостингом, где используются общие пулы приложений (в сочетании с настройками частичного доверия, чтобы предотвратить разглашение выданной учетной записи).

В IIS7.x/ASP.NET контроль олицетворения теперь настраивается с помощью функции конфигурации аутентификации на сайте. Таким образом, вы можете настроить запуск в качестве идентификатора пула, IUSR или конкретной пользовательской анонимной учетной записи.

LOCAL SERVICE:

Учетная запись LOCAL SERVICE — это встроенная учетная запись, используемая диспетчером управления сервисами. Он имеет минимальный набор привилегий на локальном компьютере. Он имеет довольно ограниченный объем использования:

LOCAL SYSTEM:

Вы не спрашивали об этом, но я добавляю для полноты. Это локальная встроенная учетная запись. У этого есть довольно обширные привилегии и доверие. Вы никогда не должны настраивать веб-сайт или пул приложений для работы под этим идентификатором.

На практике:

На практике предпочтительный подход к обеспечению безопасности веб-сайта (если сайт получает свой собственный пул приложений, который является стандартным для нового сайта в MMC IIS7) должен работать под Application Pool Identity . Это означает, что для параметра «Идентификация сайта» в его расширенных настройках пула приложений Application Pool Identity :

На веб-сайте вы должны настроить функцию проверки подлинности:

Щелкните правой кнопкой мыши и отредактируйте запись анонимной аутентификации:

Убедитесь, что выбрано «Идентификатор пула приложений»:

Когда вы приходите для применения прав на файлы и папки, вы предоставляете идентификатор пула приложений все права, необходимые. Например, если вы предоставляете идентификатор пула приложений для разрешений пула ASP.NET v4.0 , вы можете либо сделать это через Explorer:

Нажмите кнопку «Проверить имена»:

Или вы можете сделать это с помощью утилиты ICACLS.EXE :

. или. если ваш пул приложений сайта называется BobsCatPicBlog , тогда:

Я надеюсь, что это поможет разобраться.

Update:

Я просто столкнулся с этим отличным ответом от 2009 года, который содержит кучу полезной информации, которую стоит прочитать: