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

Когда учетная запись Windows должна быть в группе «Пользователи»?

Когда вы создаете учетную запись в Windows через графический интерфейс, она автоматически добавляется в локальный Users группа. Есть возможность удалить учетную запись из этой группы. Например, при использовании учетной записи для пула приложений IIS вы можете удалить ее из Users и добавить его в IIS_IUSRS. Или ты можешь уйти Users на месте в этом сценарии. Я видел, как системные администраторы делали это обоими способами. Каковы последствия каждого способа? Как ты решишь?

Когда я удаляю пользователя из Users group, я все еще могу выполнять следующие команды:

runas /user:name cmd.exe
whoami /groups

Тем не менее, BUILTIN\Users по-видимому, неожиданно все еще отображается для этого пользователя. Где это объяснено?

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

Учетную запись или группу может потребоваться добавить в группу «Пользователи», если известный участник безопасности «Прошедшие проверку» удаляется из группы «Пользователи». Членство в группе «Пользователи, прошедшие проверку подлинности» может также объяснить, почему членство в группе «Пользователи» появляется при запуске. whoami /groups.

Учетная запись пула приложений обычно не требует членства в группе «Пользователи». Если вы обнаружите, что это так, лучшим подходом может быть ACL необходимых ресурсов с участником безопасности IIS_Users.

Встроенный участник безопасности IIS_Users (ранее IIS_WPG до Windows 2008) - это просто метод предоставления разрешений ресурсам для учетных записей пула приложений IIS. Эти ресурсы не обязательно могут иметь доступ, предоставленный встроенной группе пользователей, а учетные записи, которые являются членами IIS_Users, не обязательно могут быть членами встроенной группы пользователей.

Для получения дополнительной информации о назначении и предыстории IIS_Users:

Общие сведения о встроенных учетных записях пользователей и групп в IIS 7
http://www.iis.net/learn/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis

Введение

В более ранних версиях IIS во время установки создается локальная учетная запись с именем IUSR_MachineName. IIS использовал учетную запись IUSR_MachineName по умолчанию всякий раз, когда была включена анонимная проверка подлинности. Это использовалось службами FTP и HTTP.

Также была группа под названием IIS_WPG, которая использовалась в качестве контейнера для всех удостоверений пула приложений. Во время установки IIS всем соответствующим ресурсам в системе были предоставлены правильные права пользователя для группы IIS_WPG, так что администратору нужно было только добавить свою личность в эту группу при создании новой учетной записи пула приложений.

Эта модель работала хорошо, но имела свои недостатки: учетная запись IUSR_MachineName и группа IIS_WPG были локальными по отношению к системе, в которой они были созданы. Каждой учетной записи и группе в Windows дается уникальный номер, называемый идентификатором безопасности (SID), который отличает ее от других учетных записей. При создании ACL используется только SID. Как часть дизайна в более ранних версиях IIS, IUSR_MachineName был включен в файл metabase.xml, так что если вы попытаетесь скопировать metabase.xml с одного компьютера на другой, это не сработает. Учетная запись на другом компьютере будет иметь другое имя.

Кроме того, вы не могли «xcopy / o» ACL с одного компьютера на другой, так как SID были разными от компьютера к компьютеру. Одним из обходных путей было использование учетных записей домена, но для этого потребовалось добавить в инфраструктуру активный каталог. Группа IIS_WPG имела аналогичные проблемы с правами пользователей. Если вы установите ACL в файловой системе одного компьютера для IIS_WPG и попытаетесь «xcopy / o» их на другой компьютер, это не удастся. Этот опыт был улучшен в IIS 7 и более поздних версиях за счет использования встроенной учетной записи и группы.

Операционная система гарантирует, что встроенная учетная запись и группа всегда имеют уникальный SID. IIS 7 и более поздние версии пошли дальше и гарантируют, что фактические имена, используемые новой учетной записью и группой, никогда не будут локализованы. Например, независимо от языка Windows, который вы устанавливаете, имя учетной записи IIS всегда будет IUSR, а имя группы будет IIS_IUSRS.

Таким образом, IIS 7 и выше предлагают следующее:

  • Встроенная учетная запись IUSR заменяет учетную запись IUSR_MachineName.
  • Встроенная группа IIS_IUSRS заменяет группу IIS_WPG.

Учетной записи IUSR больше не нужен пароль, потому что это встроенная учетная запись. Логически вы можете думать об этом как о том же, что и учетные записи NETWORKSERVICE или LOCALSERVICE. И новая учетная запись IUSR, и группа IIS_IUSRS более подробно рассматриваются в разделах ниже.

Понимание новой учетной записи IUSR

Учетная запись IUSR заменяет учетную запись IUSR_MachineName в IIS 7 и выше. Учетная запись IUSR_MachineName по-прежнему будет создаваться и использоваться, если вы устанавливаете FTP 6-совместимый сервер, входящий в состав Windows Server 2008. Если вы не установите FTP-сервер, входящий в состав Windows Server 2008, эта учетная запись не будет создана.

Эта встроенная учетная запись не требует пароля и будет идентификатором по умолчанию, который используется при включенной анонимной проверке подлинности. Если вы посмотрите файл applicationHost.config, вы увидите следующее определение: 

<anonymousAuthentication enabled="true" userName="IUSR" defaultLogonDomain="" />

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

  • Установите разрешения файловой системы для учетной записи IUSR с помощью проводника Windows или любого из многих инструментов командной строки.
  • Больше не нужно беспокоиться об истечении срока действия паролей для этой учетной записи.
  • Используйте xcopy / o для беспрепятственного копирования файлов вместе с информацией об их владельцах и ACL на разные компьютеры.

Примечание. Учетная запись IUSR похожа на LOCALSERVICE тем, как она действует анонимно в сети. Учетные записи NETWORKSERVICE и LOCALSYSTEM могут выступать в качестве удостоверения машины, но учетная запись IUSR не может, потому что для этого потребуется повышение прав пользователя. Если вам требуется, чтобы анонимная учетная запись имела права в сети, вы должны создать новую учетную запись пользователя и вручную установить имя пользователя и пароль, как вы делали это раньше для анонимной аутентификации.

Чтобы предоставить права анонимной учетной записи в сети с помощью диспетчера IIS:

  1. Нажмите кнопку Пуск, введите INetMgr.exe и нажмите клавишу ВВОД. При появлении запроса нажмите «Продолжить», чтобы повысить свои разрешения.
  2. В разделе «Подключения» нажмите кнопку «+» рядом с именем вашего компьютера.
  3. В диспетчере IIS дважды щелкните сайт, который хотите администрировать.
  4. В представлении функций дважды щелкните Проверка подлинности.
  5. Выберите «Анонимная проверка подлинности», а затем нажмите «Изменить» на панели «Действия».
  6. В диалоговом окне «Изменить учетные данные для анонимной проверки подлинности» выберите параметр «Определенный пользователь» и нажмите «Установить».
  7. В диалоговом окне «Установить учетные данные» введите желаемое имя пользователя и пароль, а затем нажмите «ОК».

Понимание новой группы IIS_IUSRS

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

Как и встроенная учетная запись, эта встроенная группа решает несколько препятствий для развертывания xcopy. Если вы установите разрешения для своих файлов для группы IIS_WPG (которая была доступна в системах IIS 6.0) и попытаетесь скопировать эти файлы на другой компьютер с Windows, SID группы будет отличаться на разных компьютерах, и конфигурации вашего сайта будут нарушены.

Поскольку SID группы в IIS 7 и более поздних версиях одинаков во всех системах, работающих под управлением Windows Server 2008, вы можете использовать «xcopy / o» для сохранения информации о ACL и владельце при перемещении файлов с компьютера на компьютер. Это упрощает развертывание xcopy.

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

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

<applicationPools>
    <add name="DefaultAppPool">
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>