Использование учетной записи LocalSystem в качестве учетной записи входа службы
Одним из преимуществ использования учетной записи LocalSystem является то, что служба имеет полный неограниченный доступ к локальным ресурсам. Это также недостаток LocalSystem, поскольку служба LocalSystem может выполнять действия, которые могут привести к выводу всей системы. В частности, служба, работающая под учетной записью LocalSystem на контроллере домена (DC), имеет неограниченный доступ к службам домен Active Directory. Это означает, что ошибки в службе или атаки безопасности на службу могут повредить систему или, если служба находится на контроллере домена, что приводит к повреждению всей корпоративной сети.
По этим причинам администраторам домена в конфиденциальных установках будет необходимо соблюдать осторожность, чтобы разрешить службам работать в качестве LocalSystem. На самом деле, они могут иметь политики для него, особенно на контроллерах домена. Если служба должна работать под учетной записью LocalSystem, документация для вашей службы должна выровняться с администраторами домена по причинам предоставления службе прав на выполнение с повышенными привилегиями. Службы не должны запускаться от имени LocalSystem на контроллере домена. Дополнительные сведения и пример кода, демонстрирующий, как установщик службы или службы может определить, работает ли он на контроллере домена, см. в разделе Проверка работы на контроллере домена.
Если служба выполняется под учетной записью LocalSystem на компьютере, который является членом домена, служба имеет какой-либо сетевой доступ к учетной записи компьютера или к любым группам, членом которых является учетная запись компьютера. имейте в виду, что в Windows 2000 учетная запись компьютера домена является субъектом-службой, похожей на учетную запись пользователя. Это означает, что учетная запись компьютера может находиться в группе безопасности, а запись ACE в дескрипторе безопасности может предоставлять доступ к учетной записи компьютера. Имейте в виду, что добавление учетных записей компьютеров в группы не рекомендуется по двум причинам:
Учетные записи компьютеров обычно имеют неограниченные привилегии и не принадлежат к группам. Защита ACL по умолчанию в службах домен Active Directory Services допускает минимальный доступ для учетных записей компьютеров. Следовательно, службы, работающие как LocalSystem, на компьютерах, отличных от DCs, имеют только минимальный доступ к службам домен Active Directory.
Если служба выполняется под учетной записью LocalSystem, необходимо протестировать службу на рядовом сервере, чтобы обеспечить наличие у службы достаточных прав для чтения и записи на контроллеры домен Active Directory. контроллер домена не должен быть единственным Windows компьютером, на котором проверяются службы. имейте в виду, что служба, работающая под учетной записью LocalSystem на Windows контроллере домена, имеет полный доступ к домен Active Directory службам и что рядовой сервер работает в контексте учетной записи компьютера, имеющей гораздо меньше прав.
Изоляция служб в Windows
Как известно, службы Windows представляют собой одно из наиболее излюбленных мест для атак на операционную систему. В худшем (для нас, конечно) случае атакующий получает возможность действовать на атакованном компьютере в контексте учетной записи, от имени которой запущена взломанная служба. И если эта учетная запись обладает административными правами, то фактически злоумышленник получает полный контроль над компьютером. От версии к версии в Windows появляются новые механизмы, обеспечивающие дополнительную изоляцию служб и, как следствие, усиливающие безопасность системы в целом. Я хотел бы вкратце рассмотреть, что принципиально изменилось в этом направлении за последние несколько лет.
Первые существенные изменения в механизмах защиты служб появились в Windows XP Service Pack 2. Сейчас уже сложно себе это представить, но до выхода SP2 все службы самой операционной системы запускались в контексте встроенной учетной записи Local System, обладающей на компьютере максимально полными административными правами. SP2 добавил еще две записи: Local Service и Network Service. Принципиальные отличия трех перечисленных записей можно найти в табл. 1.
| Учетная запись | Локальные ресурсы | Сетевые ресурсы |
|---|---|---|
| Local System | Полный доступ ко всем ресурсам компьютера | Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена |
| Local Service | Права стандартного пользователя + небольшой набор дополнительных привилегий | Анонимное подключение к сетевым ресурсам |
| Network Service | Права стандартного пользователя + небольшой набор дополнительных привилегий | Подключение к сетевым ресурсам в контексте учетной записи компьютера, на котором запущена. Маркер доступа также содержит SID групп Everyone и Authenticated Users |
Таблица 1
Соответственно, начиная с Windows XP SP2, администратор мог настраивать запуск службы в контексте одной из встроенных учетных записей, локальной или доменной учетной записи. Тем не менее, большая часть служб самой Windows по-прежнему запускается в контексте Local System. Но даже если абстрагироваться от этого, ситуация, когда несколько служб запускаются в контексте одной и той же учетной записи, приводит к тому, что успешный взлом одной службы, пусть даже без административных привилегий, потенциально открывает для атакующего любые другие ресурсы, к которым имеет доступ учетная запись взломанной службы.
В Windows Vista появилось несколько механизмов, повышающих изоляцию служб. Я остановлюсь на двух.
Первый механизм – это уникальный идентификатор безопасности службы (Service SID). Данный SID генерируется для каждой службы путем хеширования имени службы с помощью алгоритма SHA-1. К результату добавляется префикс S-1-5-80-. Просмотреть SID службы можно с помощью команды sc showsid, указав в качестве параметра имя службы (см. рис. 1).
Рис. 1
Нажимаете Check Names, затем ОК и видите пользователя (см. рис. 3), которому можно назначать права. 
Рис. 3
Еще раз подчеркну, что w32time не является объектом-пользователем. Это – SID, но раз так, его можно использовать в списках ACL, причем как в графическом интерфейсе, так и в командной строке и программным путем. Более того, сервисные SID-ы можно использовать в настройках Windows Firewall, применяя те или иные правила к конкретной службе, точнее конкретному Service SID.
Второй изменение, появившееся в Vista, это идентификаторы безопасности нового типа – Write Restricted SID. Если служба помечена типом Write Restricted SID, то ее SID добавляется в ее же маркере доступа в специальный список – Restricted SID list. При попытке такой службы записать что-либо в какой-либо файл алгоритм проверки прав доступа несколько изменяется. А именно, служба сможет записать в файл только в том случае, если разрешение Write дано явным образом SID-у этой службы, либо группе Everyone.
Например, учетная запись ServiceAccount1 некоторой службы Service1 является членом группы Group1. Группа Group1 и только она имеет разрешение Write на папку Folder1. Что произойдет, если служба попытается что-то изменить в папке Folder1? В обычной ситуации ServiceAccount1 получит возможность записи в папку за счет членства в Group1. Но если служба Service1 помечена типом Write Restricted SID, то ее маркер доступа обрабатывается иначе, и она не сможет записать что-либо в папку, поскольку ей явным образом не дано разрешение Write, равно как не дано это право и Everyone.
Просмотреть тип идентификатора безопасности можно с помощью команды sc qsidtype (см. рис. 4).
Рис. 4
В частности, на рис. 4 вы видите, что служба Windows Firewall относится как раз к упомянутому типу. Естественно, что введен этот тип был для того, чтобы дополнительно ограничить возможности службы (возможности стереть или перезаписать что-либо) в случае ее успешного взлома. Надо также добавить, что данный механизм предназначен в первую очередь не для администраторов систем, а для разработчиков служб. Только бы пользовались.
В Windows 7 и Windows Server 2008 R2 работа над изоляцией служб была продолжена. Появились виртуальные учетные записи (virtual accounts) и управляемые учетные записи служб (managed service accounts). А собственно в чем проблема? Нужно изолировать службы – давайте создадим нужное количество локальных (или доменных) учетных записей пользователей. Для каждой критически важной службы свой account. Да, это решение. Но для локальных служб, которым не нужен сетевой доступ к ресурсам, необходимо вручную задавать пароли, длинные и сложные. И также вручную их периодически обновлять. Ну, раз уж мы за безопасность. Для служб, которые должны по сети обращаться к ресурсам в контексте доменных учетных записей, плюс к этому еще нужно регистрировать Service Principal Name (SPN), свой для каждой службы. Это неудобно. Но неудобство становится реальной проблемой, когда служба из-за просроченного пароля не может стартовать. А админ просто забыл сменить для нее пароль.
Так вот для локальных служб вы можете использовать virtual accounts. Виртуальная учетная запись используется только для запуска конкретной службы, точнее для создания контекста безопасности конкретной службы. Вы не найдете эту запись среди пользователей в Computer Management. И, тем не менее, это – account, со своим уникальным SID-ом, со своим пользовательским профилем. А стало быть, вы можете назначать ему разрешения и, тем самым, разграничивать права доступа и четко их контролировать. Но также как и в случае с Local System, Local Service и Network Service операционная система берет на себя задачи управления паролями для virtual accounts. Мы изолируем нужные службы, и у нас не болит голова о паролях.
Чтобы создать виртуальную учетную запись, нужно в настройках службы указать в качестве учетной записи: NT SERVICE\ (см. рис 5) 
Рис. 5
После запуска службы virtual account отобразится в консоли Services (рис. 6), а в папке Users вы заметите появление нового пользовательского профиля. 
Рис. 6
По формату это очень напоминает сервисный SID. Но подчеркну, это не просто дополнительный уникальный SID для службы как в Vista, это отдельная учетная запись и, соответственно, другой уровень изоляции. По умолчанию виртуальные учетные записи используются, например, для пулов приложений (application pool) в IIS 7.5 в Windows Server 2008 R2. Надо иметь в виду, что virtual accounts предназначены для локального использования. Если служба, запущенная в контексте virtual account, обращается по сети, то это обращение происходит от имени учетной записи компьютера, на котором служба запущена. Если же необходимо, чтобы служба, например SQL Server, работала по сети от имени доменной учетной записи, то здесь как раз помогут managed service accounts. С ними, однако, связано больше тонкостей, и их рассмотрение выходит за рамки данного поста. Более подробно с MSA можно познакомиться здесь.
Перечисленные мною механизмы изоляции служб на этом не заканчиваются. Можно еще упомянуть об изоляции нулевого сеанса, уровнях целостности, механизме DEP. Я сосредоточился на тех, которые, как мне кажется, в меньшей степени известны, но при этом имеют вполне практический смысл для администратора. Ну и конечно, работа по усилению защищенности служб в последующих версиях Windows будет продолжена.
Local system account что это
Как всем, наверное, известно, в системе есть такие встроенные пользователи как:
Что это за пользователи, и чем они отличаются? Зачем они собственно нужны? Особенно первые два.
Сначала о них. Первые два пользователя появились в win2k3/win xp. Эти учетные записи созданы специально для обеспечения безопасного исполнения служб. Раньше все службы исполнялись либо с правами Local System, либо с правами специально созданного пользователя. Это, в некотором роде создавало проблему, поскольку не все стремились создавать пользователей под каждую установленную службу, а тем более следить за паролями и правами этих пользователей.
В конечном итоге родились два этих специфических пользователя. Первый из них, обладает следующими привилегиями:
При работе в сети этот пользователь аутентифицируется как анонимный пользователь. В отличие от него NetworkService представляется другим системам в сети как учетная запись компьютера, на котором он запущен, а так же его маркер доступа (token) содержит SID’ы групп everyone и Authenticated Users. Имеет такой набор привилегий:
И наконец LocalSystem. В сети он представляется как компьютер, на котором он запущен. Однако набор его привилегий намного более обширен:
На самом деле, редко каким службам необходим такой набор возможностей. Поэтому Microsoft рекомендует использовать для своих целей любой из первых двух, в зависимости от потребностей.
Мало того, в Vista/Win7 появилась возможность еще более активно манипулировать привилегиями. Для этого в sc.exe появился параметр privs:
sc privs
ОПИСАНИЕ.
Изменение параметра необходимых прав для службы.
Параметры прав вступают в силу, когда процесс службы запускается при
запуске первой службы процесса. В этот момент диспетчер управления
службами (SCM) определяет набор всех прав, необходимых всем
службам-участникам этого процесса, а затем создает процесс с такими
правами. Если данный параметр отсутствует, предполагается, что службе
требуются все права, разрешенные подсистемой безопасности для процесса,
который выполняется от имени учетной записи, настроенной для этой
службы.
ИСПОЛЬЗОВАНИЕ:
sc privs [имя службы] [права]
ПАРАМЕТРЫ:
права =
[Например, SeBackupPrivilege/SeRestorePrivilege]
Этот параметр позволяет дополнительно управлять (удалять/добавлять) привилегии службы. На самом деле эти настройки хранятся в реестре, например у dhcp клиента они такие:
Однако это не всегда так. Например:
в случае с одним из экземпляров процесса svchost, запущеным под LocalService, набор привилегий складывается как все привилегии перечисленные в той группе служб, в которой запускается наш dhcp клиент. В итоге у процесса этих самых привилегий может оказаться немножко больше.
Локальные учетные записи
Относится к:
Эта справочная тема для ИТ-специалистов описывает локальные учетные записи пользователей по умолчанию для серверов, в том числе управление этими встроенными учетных записями на сервере-члене или автономных серверах.
О локальных учетных записях пользователей
Локальные учетные записи пользователей хранятся локально на сервере. Этим учетным записям могут быть назначены права и разрешения на определенном сервере, но только на этом сервере. Локальные учетные записи пользователей — это принципы безопасности, которые используются для обеспечения и управления доступом к ресурсам на автономных или серверных членах служб или пользователей.
В этом разделе описывается следующее:
Сведения о главных задачах безопасности см. в см. в руб.
Учетные записи локальных пользователей по умолчанию
Локальные учетные записи по умолчанию — это встроенные учетные записи, которые создаются автоматически при установке Windows.
После Windows установлено, локальные учетные записи пользователей по умолчанию не могут быть удалены или удалены. Кроме того, локальные учетные записи пользователей по умолчанию не предоставляют доступ к сетевым ресурсам.
Локальные учетные записи по умолчанию используются для управления доступом к ресурсам локального сервера на основе прав и разрешений, которые назначены учетной записи. Локальные учетные записи пользователей по умолчанию и локальные учетные записи пользователей, которые вы создаете, находятся в папке «Пользователи». Папка «Пользователи» расположена в локальной папке «Пользователи и группы» в локальной консоли управления компьютерами Microsoft Management Console (MMC). Управление компьютером — это набор административных средств, которые можно использовать для управления одним локальным или удаленным компьютером. Дополнительные сведения см. в разделе How to manage local accounts later in this topic.
Локальные учетные записи пользователей по умолчанию описаны в следующих разделах.
Учетная запись администратора
Учетная запись администратора полностью контролирует файлы, каталоги, службы и другие ресурсы на локальном компьютере. Учетная запись администратора может создавать других локальных пользователей, назначать права пользователей и назначать разрешения. Учетная запись администратора может контролировать локальные ресурсы в любое время, просто изменяя права и разрешения пользователей.
Учетная запись администратора по умолчанию не может быть удалена или заблокирована, но ее можно переименовать или отключить.
В Windows 10 и Windows Server 2016 Windows настройка отключает встроенную учетную запись администратора и создает другую локализованную учетную запись, которая входит в группу Администраторы. Члены групп Администраторы могут запускать приложения с повышенными разрешениями без использования параметра Run as Administrator. Быстрая переключение пользователей является более безопасной, чем использование Runas или высоты для разных пользователей.
Членство в группе учетных записей
По умолчанию учетная запись администратора устанавливается в качестве члена группы администраторов на сервере. Ограничение числа пользователей в группе Администраторов является наиболее оптимальным, поскольку члены группы Администраторы на локальном сервере имеют разрешения на полный контроль на этом компьютере.
Учетная запись администратора не может быть удалена или удалена из группы администраторов, но ее можно переименовать.
Вопросы безопасности
Так как известно, что учетная запись администратора существует во многих версиях операционной системы Windows, лучше отключить учетную запись администратора, если это возможно, чтобы злоумышленникам было сложнее получить доступ к серверу или клиенту.
Можно переименовать учетную запись Администратора. Однако переименованная учетная запись администратора продолжает использовать тот же автоматически назначенный идентификатор безопасности (SID), который может быть обнаружен вредоносными пользователями. Дополнительные сведения о том, как переименовать или отключить учетную запись пользователя, см. в записи Отключение или активация учетной записи локального пользователя и переименование учетной записи локального пользователя.
В качестве наилучшей практики безопасности используйте локализованную (не администратор) учетную запись для регистрации, а затем используйте Run в качестве администратора для выполнения задач, которые требуют более высокого уровня прав, чем стандартная учетная запись пользователя. Не используйте учетную запись администратора для регистрации на компьютере, если это не является полностью необходимым. Дополнительные сведения см. в программе Run a program with administrative credentials.
Для сравнения, Windows клиентской операционной системе пользователь с локальной учетной записью пользователя, которая имеет права администратора, считается системным администратором клиентского компьютера. Первая локализованная учетная запись пользователя, созданная во время установки, помещается в локализованную группу администраторов. Однако, когда несколько пользователей работают в качестве локальных администраторов, ИТ-сотрудники не могут контролировать этих пользователей или их клиентские компьютеры.
В этом случае групповая политика может использоваться для обеспечения безопасных параметров, которые могут автоматически контролировать использование локальной группы администраторов на каждом сервере или клиентских компьютерах. Дополнительные сведения о групповой политике см. в обзоре групповой политики.
Пустые пароли не допускаются в версиях, указанных в списке Applies To в начале этой темы.
Даже если учетная запись администратора отключена, ее можно использовать для получения доступа к компьютеру с помощью безопасного режима. В консоли восстановления или в безопасном режиме учетная запись администратора автоматически включена. При возобновлении обычных операций он отключается.
Гостевая учетная запись
Учетная запись Гостевой по умолчанию отключена при установке. Учетная запись Гостевой позволяет случайным или разовым пользователям, у которых нет учетной записи на компьютере, временно войти на локальный сервер или клиентский компьютер с ограниченными правами пользователя. По умолчанию у гостевой учетной записи есть пустой пароль. Поскольку учетная запись Гостевой может предоставлять анонимный доступ, это риск безопасности. По этой причине следует оставить учетную запись Гостевой учетной записи отключенной, если ее использование не является полностью необходимым.
Членство в группе учетных записей
По умолчанию гостевая учетная запись является единственным членом группы гостей по умолчанию (SID S-1-5-32-546), которая позволяет пользователю войти на сервер. Иногда администратор, в который входит группа администраторов, может настроить пользователя с учетной записью «Гость» на одном или нескольких компьютерах.
Вопросы безопасности
При включив учетную запись «Гость», выдайте только ограниченные права и разрешения. По соображениям безопасности учетная запись Гостевой не должна использоваться по сети и быть доступной для других компьютеров.
Кроме того, гостевой пользователь учетной записи «Гость» не должен просматривать журналы событий. После включения учетной записи «Гость» необходимо часто отслеживать учетную запись «Гость», чтобы убедиться, что другие пользователи не могут использовать службы и другие ресурсы, например ресурсы, которые были непреднамеренно доступны предыдущему пользователю.
Учетная запись HelpAssistant (установленная с сеансом удаленной помощи)
Учетная запись HelpAssistant — это локализованная учетная запись по умолчанию, включенная при запуске сеанса удаленной помощи. Эта учетная запись автоматически отключена, если не ожидается никаких запросов на удаленную помощь.
HelpAssistant — это основная учетная запись, используемая для создания сеанса удаленной помощи. Сеанс удаленной помощи используется для подключения к другому компьютеру, Windows операционной системе, и он инициировался по приглашению. Для получения удаленной помощи пользователь отправляет приглашение с компьютера по электронной почте или в файле лицу, который может оказать помощь. После того, как приглашение пользователя на сеанс удаленной помощи будет принято, автоматически создается учетная запись HelpAssistant по умолчанию, чтобы предоставить человеку, который предоставляет помощь, ограниченный доступ к компьютеру. Учетная запись HelpAssistant управляется службой диспетчера сеансов помощи удаленным рабочим столам.
Вопросы безопасности
К siD-данным, которые относятся к учетной записи HelpAssistant по умолчанию, относятся:
Для операционной Windows Server удаленная помощь является необязательным компонентом, который не устанавливается по умолчанию. Необходимо установить удаленную помощь, прежде чем она может быть использована.
Сведения о атрибутах учетной записи HelpAssistant см. в следующей таблице.
Атрибуты учетной записи HelpAssistant
Гости
DefaultAccount
DefaultAccount, также известная как учетная запись системы по умолчанию (DSMA), — встроенная учетная запись, представленная в Windows 10 версии 1607 и Windows Server 2016. DSMA — это хорошо известный тип учетной записи пользователя. Это нейтральная учетная запись пользователя, которая может быть использована для запуска процессов, которые являются либо несколькими пользователями известно или пользователь агностик. DSMA отключена по умолчанию на настольных skUs (полные windows SKUs) и WS 2016 с настольным компьютером.
DSMA является членом известной группы system Managed Accounts Group, которая имеет хорошо известный SID S-1-5-32-581.
Псевдоним DSMA можно получить доступ к ресурсам во время автономной постановки еще до создания самой учетной записи. Учетная запись и группа создаются во время первой загрузки компьютера в диспетчере учетных записей безопасности (SAM).
Использование Windows DefaultAccount
С точки зрения разрешений defaultAccount — это стандартная учетная запись пользователя. DefaultAccount необходим для запуска приложений с несколькими манифестами пользователей (приложения MUMA). Приложения MUMA запускают все время и реагируют на вход и вход пользователей с устройств. В отличие Windows desktop, где приложения работают в контексте пользователя и прекращаются, когда пользователь прекращает работу, приложения MUMA запускаются с помощью DSMA.
Приложения MUMA функциональны в общих сеансах skUs, таких как Xbox. Например, оболочка Xbox — это приложение MUMA. Сегодня Xbox автоматически включит учетную запись в качестве гостевой учетной записи и все приложения будут работать в этом контексте. Все приложения хорошо осведомлены о пользователях и реагируют на события, запускаемые менеджером пользователя. Приложения работают в качестве учетной записи «Гость».
Кроме того, Телефон в качестве учетной записи «DefApps», которая схожа со стандартной учетной записью пользователя в Windows, но с несколькими дополнительными привилегиями. В качестве этой учетной записи работают брокеры, некоторые службы и приложения.
В модели сходящихся пользователей приложения и брокеры, осведомленные о нескольких пользователях, должны будут работать в контексте, отличаемом от контекста пользователей. Для этого система создает DSMA.
Как создается defaultAccount на контроллерах домена
Если домен создан с помощью контроллеров домена, Windows Server 2016, defaultAccount будет существовать на всех контроллерах домена в домене. Если домен был создан с контроллерами домена, которые управляют более ранней версией Windows Server, defaultAccount будет создан после того, как роль PDC Emulator будет передана контроллеру домена, который выполняет Windows Server 2016. После этого defaultAccount будет реплицироваться ко всем другим контроллерам домена в домене.
Рекомендации для управления учетной записью по умолчанию (DSMA)
Корпорация Майкрософт не рекомендует изменять конфигурацию по умолчанию, в которой учетная запись отключена. Угрозы безопасности при найме учетной записи в состоянии отключения не существует. Изменение конфигурации по умолчанию может помешать будущим сценариям, которые зависят от этой учетной записи.
Учетные записи локальной системы по умолчанию
SYSTEM
Учетная запись SYSTEM используется операционной системой и службами, работающими Windows. В операционной системе Windows множество служб и процессов, которые нуждаются в возможности для внутрисистемной регистрации, например во время Windows установки. Учетная запись SYSTEM была разработана для этой цели, Windows управляет правами пользователей учетной записи SYSTEM. Это внутренняя учетная запись, которая не показывается в диспетчере пользователей и не может быть добавлена в группы.
С другой стороны, учетная запись SYSTEM действительно появляется в томе файловой системы NTFS в файлоуправлении в части Permissions меню Security. По умолчанию учетная запись SYSTEM предоставляет разрешения на полный контроль для всех файлов в томе NTFS. Здесь учетная запись SYSTEM имеет те же функциональные права и разрешения, что и учетная запись администратора.
Предоставление разрешений на групповые файлы администраторов учетных записей не дает неявно разрешения учетной записи SYSTEM. Разрешения учетной записи SYSTEM можно удалить из файла, но мы не рекомендуем удалять их.
NETWORK SERVICE
Учетная запись NETWORK SERVICE — это предопределяемая локализованная учетная запись, используемая диспетчером управления службами (SCM). Служба, которая работает в контексте учетной записи NETWORK SERVICE, представляет учетные данные компьютера удаленным серверам. Дополнительные сведения см. в записи NetworkService.
ЛОКАЛИЗОВАННАЯ СЛУЖБА
Учетная запись LOCAL SERVICE — это предопределяемая локализованная учетная запись, используемая диспетчером управления службой. Он имеет минимальные привилегии на локальном компьютере и представляет анонимные учетные данные в сети. Дополнительные сведения см. в записи LocalService.
Управление учетной записью локальных пользователей
Локальные учетные записи пользователей по умолчанию и локальные учетные записи пользователей, которые вы создаете, находятся в папке «Пользователи». Папка Пользователи расположена в локальных пользователях и группах. Дополнительные сведения о создании и управлении учетной записью локальных пользователей см. в рублях Управление локальными пользователями.
Вы можете использовать локальные пользователи и группы для назначения прав и разрешений на локальном сервере и только на этом сервере, чтобы ограничить возможности локальных пользователей и групп выполнять определенные действия. Право разрешает пользователю выполнять определенные действия на сервере, такие как архивирование файлов и папок или закрытие сервера. Разрешение доступа — это правило, связанное с объектом, как правило, файлом, папкой или принтером. Он регулирует, какие пользователи могут иметь доступ к объекту на сервере и каким образом.
Вы не можете использовать локальные пользователи и группы в контроллере домена. Однако для удаленных компьютеров, которые не являются контроллерами домена в сети, можно использовать локальные пользователи и группы на контроллере домена.
Пользователи и компьютеры Active Directory используются для управления пользователями и группами в Active Directory.
Вы также можете управлять локальными пользователями, NET.EXE пользовательскими группами и управлять локальными группами с помощью NET.EXE LOCALGROUP или с помощью различных cmdlets PowerShell и других технологий скриптов.
Ограничение и защита локальных учетных записей с помощью административных прав
Администратор может использовать ряд подходов, чтобы предотвратить использование злоумышленниками украденных учетных данных, таких как украденный пароль или hash паролей, для использования локальной учетной записи на одном компьютере для проверки подлинности на другом компьютере с административными правами; это также называется «lateral movement».
Самый простой подход заключается в входе на компьютер со стандартной учетной записью пользователя вместо использования учетной записи администратора для выполнения задач, например для просмотра Интернета, отправки электронной почты или использования текстовых процессоров. Если вы хотите выполнить административную задачу, например установить новую программу или изменить параметр, влияющий на других пользователей, вам не нужно переключаться на учетную запись администратора. Вы можете использовать управление учетной записью пользователя (UAC) для запроса разрешения или пароля администратора перед выполнением задачи, как описано в следующем разделе.
Другие подходы, которые можно использовать для ограничения и защиты учетных записей пользователей с помощью административных прав:
Соблюдение локальных ограничений учетной записи для удаленного доступа.
Запретить логотип сети для всех учетных записей администратора.
Создание уникальных паролей для локальных учетных записей с административными правами.
Каждый из этих подходов описан в следующих разделах.
Эти подходы не применяются, если отключены все административные локальные учетные записи.
Соблюдение локальных ограничений учетной записи для удаленного доступа
Управление учетной записью пользователей (UAC) — это функция безопасности в Windows, которая используется в Windows Server 2008 и Windows Vista, а также операционных системах, к которым относится список Applies To. UAC позволяет управлять компьютером, информируя о том, когда программа вносит изменения, которые требуют разрешения администратора. UAC работает путем настройки уровня разрешений учетной записи пользователя. По умолчанию UAC должен уведомлять вас, когда приложения пытаются внести изменения на компьютер, но вы можете изменить, как часто UAC уведомляет вас.
UAC позволяет рассматривать учетную запись с административными правами как стандартную учетную запись пользователя без администратора, пока не будут запрашиваться и утверждены полные права, также называемые высотой. Например, UAC позволяет администратору вводить учетные данные во время сеанса пользователей, не имеющих администратора, для выполнения случайных административных задач без необходимости переключать пользователей, выходить или использовать run в качестве команды.
Кроме того, UAC может потребовать от администраторов специально утверждать приложения, которые внося изменения в систему до получения разрешения на запуск этих приложений, даже в сеансе пользователя администратора.
Например, функция UAC по умолчанию отображается при висении локальной учетной записи с удаленного компьютера с помощью логотипа Network (например, с помощью NET.EXE USE). В этом случае ему выдан стандартный маркер пользователя без административных прав, но без возможности запрашивать или получать высоту. Следовательно, локальные учетные записи, входив с помощью логотипа Сети, не могут получить доступ к административным акциям, таким как C$, ИЛИ ADMIN$, или выполнять любое удаленное администрирование.
Дополнительные сведения об UAC см. в см. в twitter.ru.
В следующей таблице показаны параметры групповой политики и реестра, которые используются для применения локальных ограничений учетной записи для удаленного доступа.
| Нет. | Параметр | Подробное описание |
|---|---|---|
| Расположение политики | Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Параметры безопасности | |
| 1 | Имя политики | Контроль учетных записей пользователей: все администраторы работают в режиме одобрения администратором |
| Параметр политики | Enabled | |
| 2 | Расположение политики | Конфигурация компьютера\Параметры Windows\Параметры безопасности\Локальные политики\Параметры безопасности |
| Имя политики | Контроль учетных записей пользователей: все администраторы работают в режиме одобрения администратором | |
| Параметр политики | Enabled | |
| 3 | Раздел реестра | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System |
| Имя значения реестра | LocalAccountTokenFilterPolicy | |
| Тип значения реестра | DWORD | |
| Данные о значении реестра | 0 |
Вы также можете применить по умолчанию для LocalAccountTokenFilterPolicy с помощью настраиваемой ADMX в шаблонах безопасности.
Выполнение локальных ограничений учетной записи для удаленного доступа
Запустите консоль управления групповой политикой (GPMC).
В дереве консоли расширь forest \Domains\ Domain, ** **** ** а затем объекты групповой политики, где лес — это имя леса, а домен — это имя домена, в котором необходимо установить объект групповой политики (GPO).
В дереве консоли правой кнопкой мыши объекты групповой политикии > New.
В диалоговом окне New GPO и > ОК, где gpo_name является именем нового GPO. Имя GPO указывает на то, что GPO используется для ограничения прав местного администратора, которые не будут перенаправлены на другой компьютер.
В области сведений правой кнопкой и > изменить.
Убедитесь, что UAC включен и что ограничения UAC применяются к учетной записи администратора по умолчанию, делая следующее:
Перейдите к конфигурации компьютера\Windows Параметры\Security Параметры\Local Policies\\and > Security Options.
Дважды щелкните управление учетной записью пользователя: запустите всех администраторов в режиме утверждения администратора > включен > ОК.
Дважды щелкните управление учетной записью пользователя: режим утверждения администратора для встроенной учетной записи администратора > **** > Включено ОК.
Убедитесь, что локальные ограничения учетной записи применяются к сетевым интерфейсам, делая следующее:
Перейдите к конфигурации компьютера\Предпочтения и Windows Параметры и > реестру.
Правой кнопкоймыши Реестр и > новый > элемент реестра.
В диалоговом окне New Registry Properties на вкладке General измените параметр в поле Действия на Замену.
Убедитесь, что поле Hive задает HKEY_LOCAL_MACHINE.
Щелкните (. ), просмотрите следующее расположение для выбора пути ключа **** > **** для: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
В области имя значения введите LocalAccountTokenFilterPolicy.
В поле Тип значения из выпадаемого списка выберите REG_DWORD для изменения значения.
В поле Значение данных убедитесь, что значение за установлено до 0.
Проверьте эту конфигурацию и > ОК.
Привяжете GPO к первому организационному подразделению Workstations( OU), выполнив следующее:
Перейдите по \Domains\ \OU.
Щелкните правой кнопкой мыши OU рабочих станций и > щелкните ссылку на существующий GPO.
Выберите только что созданный GPO и > ОК.
Проверьте функциональные возможности корпоративных приложений на рабочих станциях в этом первом OU и уладить все проблемы, вызванные новой политикой.
Создайте ссылки на все другие OUs, содержащие рабочие станции.
Создайте ссылки на все другие OUs, содержащие серверы.
Отказ от логотипа сети для всех учетных записей локального администратора
Отказ локальным учетным записям в возможности выполнять сетевые логонсы может помочь предотвратить повторное повторное распространение локального пароля учетной записи во время вредоносной атаки. Эта процедура помогает предотвратить дальнейшее перемещение, гарантируя, что учетные данные локальных учетных записей, украденных из скомпрометированной операционной системы, не могут использоваться для компрометации дополнительных компьютеров, которые используют те же учетные данные.
Чтобы выполнить эту процедуру, сначала необходимо определить имя локальной учетной записи администратора по умолчанию, которая не может быть по умолчанию имя пользователя «Администратор», и любые другие учетные записи, которые являются членами локальной группы администраторов.
В следующей таблице показаны параметры групповой политики, используемые для отказа в логотипе сети для всех локальных учетных записей администратора.
| Нет. | Параметр | Подробное описание |
|---|---|---|
| Расположение политики | Конфигурация компьютера\Windows Параметры\Security Параметры\Local Policies\User Rights Assignment | |
| 1 | Имя политики | Отказ в доступе к компьютеру из сети |
| Параметр политики | Локализованная учетная запись и член группы Администраторы | |
| 2 | Расположение политики | Конфигурация компьютера\Windows Параметры\Security Параметры\Local Policies\User Rights Assignment |
| Имя политики | Запретить вход в систему через службу удаленных рабочих столов | |
| Параметр политики | Локализованная учетная запись и член группы Администраторы |
Отказ от логотипа сети для всех учетных записей локального администратора
Запустите консоль управления групповой политикой (GPMC).
В дереве консоли расширь forest \Domains\ **** ** ** а затем объекты групповой политики, где лес — это имя леса, а домен — это имя домена, в котором необходимо установить объект групповой политики (GPO).
В дереве консоли правой кнопкой мыши объекты групповой политикии > New.
В диалоговом окне New GPO > **** gpo_name является именем нового GPO, указывает на то, что он используется для ограничения использования локальных административных учетных записей от интерактивной регистрации на компьютер.
В области сведений правой кнопкой и > изменить.
Настройте права пользователей на отказ от сетевых логотипов для административных локальных учетных записей следующим образом:
Перейдите к конфигурации компьютера\Windows Параметры\security Параметры\\и > назначению прав пользователей.
Дважды щелкните Запретить доступ к этому компьютеру из сети.
Щелкните Добавить пользователя или группу, введите локализованную учетную запись и членагруппы администраторов и > ОК.
Настройте права пользователей на отказ от логотипов удаленного рабочего стола (Remote Interactive) для административных локальных учетных записей следующим образом:
Перейдите к конфигурации компьютера\Политики\Windows Параметры и локальные политики, а затем нажмите кнопку Назначение прав пользователей.
Дважды нажмите кнопку Запретить вход через удаленные службы настольных компьютеров.
Щелкните Добавить пользователя или группу, введите локализованную учетную запись и членагруппы администраторов и > ОК.
Увязка GPO с первым OU рабочих станций следующим образом:
Перейдите по \Domains\ \OU.
Щелкните правой кнопкой мыши OU рабочих станций и > щелкните ссылку на существующий GPO.
Выберите только что созданный GPO и > ОК.
Проверьте функциональные возможности корпоративных приложений на рабочих станциях в этом первом OU и уладить все проблемы, вызванные новой политикой.
Создайте ссылки на все другие OUs, содержащие рабочие станции.
Создайте ссылки на все другие OUs, содержащие серверы.
Возможно, вам придется создать отдельное GPO, если имя пользователя учетной записи администратора по умолчанию отличается на рабочих станциях и серверах.
Создание уникальных паролей для локальных учетных записей с административными правами
Пароли должны быть уникальными для каждой учетной записи. Хотя это обычно верно для отдельных учетных записей пользователей, многие предприятия имеют одинаковые пароли для общих локальных учетных записей, таких как учетная запись администратора по умолчанию. Это также происходит, когда одинаковые пароли используются для локальных учетных записей во время развертывания операционной системы.
Пароли, которые синхронно остаются неизменными или изменяются синхронно, чтобы сохранить их идентичными, добавляют значительный риск для организаций. Рандомизация паролей смягчает атаки «pass-the-hash» с помощью различных паролей для локальных учетных записей, что затрудняет возможность вредоносных пользователей использовать хеши паролей этих учетных записей для компрометации других компьютеров.
Пароли можно рандомизировать по:
Приобретение и реализация корпоративного средства для выполнения этой задачи. Эти средства обычно называются «привилегированным управление паролями».
Настройка решения локального пароля администратора (LAPS) для выполнения этой задачи.
Создание и реализация настраиваемой скрипта или решения для рандомизации локальных паролей учетных записей.
См. также
Следующие ресурсы предоставляют дополнительные сведения о технологиях, связанных с локальными учетной записью.
