nt authority что за пользователь
Nt authority что за пользователь
Добрый день! Уважаемые читатели и гости одного из популярнейших блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами подробно рассмотрели командлет Restart-Computer и научились с его помощью производить локальную или удаленную перезагрузку компьютера или сервера, это полезный навык. В сегодняшней публикации я бы хотел вас научить запускать оболочку PowerShell с максимальными правами от имени системной учетной записи «СИСТЕМА (NT AUTHORITY\SYSTEM)» или ее еще иногда называют Local System. Это то же полезный скил, который вас может сильно выручить в разных обстоятельствах. Давайте от слов к практике.
Что можно делать с PowerShell от имени SYSTEM
Я не буду расписывать, что из себя представляет локальная, системная учетная запись, напомню лишь, что из под нее работает подавляющее количество сервисов Windows и она имеет максимальные права на все в вашей ОС (Папки, файлы, кусты реестра, тома). Имея запущенное окно PowerShell от системной учетной записи вы можете абсолютно все в этой системе, например можете отключать службы, которые были ограничены, или подключаться к чужой RDP сессии, поправить защищенные ветки реестра, например, как в случае с ошибкой 10016.
Методы запуска PowerShell от имени системной учетной записи
Я могу выделить ряд методов, которыЕ помогут нам решить нашу задачу, сразу хочу отметить, что вы спокойно можете при наличии прав запускать оболочку и удаленно от имени SYSTEM.
Запуск PowerShell от учетной записи NT AUTHORITY\SYSTEM из PSexec
Далее вам необходимо ваш архив извлечь, дабы получить папку с утилитами. У вас есть два варианта запуска PSexec, из командной строки или же из свой PowerShell. Давайте опробуем командную строку, которую вы должны ОБЯЗАТЕЛЬНО открыть от имени администратора, далее вы должны перейти в cmd в расположение с утилитой PSexec. Делается это командой:
После чего вы пишите команду, которая запустит окно PowerShell от имени системы:
В результате у вас откроется дополнительное окно PowerShell в режиме администратора и от имени «nt authority\система«. Проверить, это можно командой whoami.
То же самое можно сделать и из самой PowerShell(), тут вам нужно будет так же открыть PowerShell от имени администратора и ввести команды:
Чтобы удаленно получить окно PowerShell через PSexec, вам необходимо выполнить:
Где svt2019s01, это имя моего сервера с Windows Server 2019. Как видим идет попытка подключения, где на удаленном компьютере запускается служба PSexec, вам будут необходимы права локального администратора там. Если подключение не проходит, то у вас блокируется брандмауэром, убедитесь, что порт WinRM (TCP 5985) у вас разрешен.
После успешного подключения можно ввести команду hostname, чтобы посмотреть, правильно ли вы подключились, ну и посмотреть командой whoami, из под кого запущен PowerShell, как видно из скриншота, это учетная запись nt authority\система.
Так же вы можете из оболочки запустить команду:
Она так же все запустит, единственное поменяйте в ней путь до утилиты PSexec на свой.
Запуск PowerShell от учетной записи NT AUTHORITY\SYSTEM из планировщика заданий
Данный метод более изощренный нежели использование внешней утилиты PSexec, но я уверен, что его так же полезно знать. В окне выполнить введите команду taskschd.msc.
Открываем библиотеку планировщика заданий и щелкаем по нему правым кликом, из контекстного меню выберите пункт «Создать простую задачу«
Задаем ее имя у меня оно будет «Запуск PowerShell NT».
В настройках тригера выставим запуск задачи «Однократно«.
Задаем время запуска.
Оставляем пункт «Запустить программу» и нажимаем далее.
Тут нам необходимо заполнить два пункта:
В поле программы вам нужно вписать строку в зависимости от разрядности вашей архитектуры:
В качестве аргумента, вам необходимо указать путь до нашего скрипта, расположенного по пути C:\Scripts\Get-CurrentUser.ps1
ExecutionPolicy, это команда позволяющая выполнять не подписанные скрипты.
заканчиваем создание простого задания, обязательно выставите галку «Открыть окно «Свойств» для этой задачи после нажатия кнопки «Готово«.
заканчиваем создание простого задания, обязательно выставите галку «открыть окно «Свойств» для этой задачи после нажатия кнопки «Готово». Далее у вас откроется окно свойств данной задачи, вы можете заметить, что она по умолчанию выполняется от того пользователя, кто ее создал, в моем примере, это ROOT\Администратор, это нужно поменять. Нажмите кнопку изменить.
Если у вас русская Windows, то в окне поиска введите «СИСТЕМА», если английская версия, то введите SYSTEM.
В результате вы увидите, что задача запускается от системной учетной записи (nt authority\система).
Nt authority что за пользователь
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Добрый день.
Антивирусное ПО (Kaspersky Endpoint Security 10 для Windows) в системе мониторинга (KSC10) статистика «наиболее заражающее пользователи» NT AUTHORITY\система более 4 тыс алертов за сутки
пример:
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:39:03 C:\Windows\31779272.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\31779272.exe
UDS:DangerousObject.Multi.Generic 13 ноября 2017 г. 9:16:56 C:\Windows\33089992.exe неизвестно Результат: Удалено: UDS:DangerousObject.Multi.Generic Пользователь: NT AUTHORITY\система (Системный пользователь) Объект: C:\Windows\33089992.exe
Есть ли какая то возможно ограничить использование учётной записи NT AUTHORITY\система? Сеть доменная.
Ответы
Скорее всего, это у вас компьютеры кто-то по сети заражает: подключается по сети с правами администратора и копирует туда тело вируса (скорее всего, чтобы запустить его либо как службу, либо через WMI). Вариантов заражения тут два: либо производится подключение с правами администратора с заражённой машины, либо через использование уязвимости.
А по поводу использования уязвимостей (прищнаком чего будет отсутствие вхоодо по сети) нужно начать с того, что установить все обновления безопасности на все подверженные атакам компьютеры. Если не поможет (что вряд ли), то придётся анализировать сетевой трафик, чтобы установить источник атаки.
Все ответы
Как не прескорбно но лечить нужно ту систему, которая ОС.
Ограничить пользователя система нельзя да и смысла нет так как это равносильно стрельбе в ногу, с тем же успехом можно выключить ПК.
Так же стоит помнить о необходимости установки обновлений ОС на оставшихся машинах, обновлении и активации проверок антивируса, включении UAC, смена админских паролей, настройке бекапов критичных сервисов и пр. бестпрактисы которые многие игнорируют.
Дабы попробовать локализовать проблему проверяйте службы, отключая все что не подписано сертификатами МС, проверяйте шедульные задачи, парки автозапуска, ветки реестра автозапуска и пр.
The opinion expressed by me is not an official position of Microsoft
Это пользователь, который для каких-либо устаревших целей отображается как группа?
Примечание. Что такое пользователь NT AUTHORITY \ SYSTEM? похоже, но не отвечает на вопрос, почему он отображается как группа и ведет себя как пользователь.
Во-вторых, NT-AUTHORITY и SYSTEM не являются ни учетными записями, ни группами, несмотря на то, что говорят различные другие источники (даже внутри Microsoft). У SID обычно есть имя, которое отображается при необходимости. Учетная запись пользователя будет предоставлять свой SID в качестве основного SID для токена доступа, который также будет определять имя, отображаемое различными утилитами. Но токен доступа может содержать дополнительные SID, например, для всех групп, к которым принадлежит эта учетная запись пользователя. При проверке разрешений Windows будет искать любой SID в маркере доступа, который имеет это разрешение.
Некоторые известные Windows SID будут иметь имена, сообщаемые Windows, хотя на самом деле они не принадлежат какой-либо учетной записи.
SID не должен даже определять учетную запись пользователя или группу. Он просто определяет набор разрешений. Вышеупомянутая статья Википедии добавляет:
Windows предоставляет или запрещает доступ и привилегии к ресурсам на основе списков контроля доступа (ACL), которые используют SID для уникальной идентификации пользователей и их членства в группах. Когда пользователь входит в систему, генерируется токен доступа, который содержит SID пользователя и группы и уровень привилегий пользователя. Когда пользователь запрашивает доступ к ресурсу, токен доступа сверяется с ACL, чтобы разрешить или запретить конкретное действие с конкретным объектом.
SID NT-AUTHORITY\SYSTEM может быть добавлен к другим учетным записям. Например, это сказано об учетной записи LocalSystem :
Учетная запись LocalSystem является предопределенной локальной учетной записью, используемой диспетчером управления службами. [. ] Его токен включает идентификаторы NT AUTHORITY \ SYSTEM и BUILTIN \ Administrators; эти учетные записи имеют доступ к большинству системных объектов.
В приведенном выше тексте уже можно увидеть путаницу, которая царит даже в документации Microsoft относительно системных идентификаторов безопасности, которые не являются ни учетными записями, ни группами, а представляют собой просто набор разрешений. Эта путаница распространяется и на другие утилиты и статьи, поэтому любая возвращенная информация должна быть тщательно изучена.
В статье Microsoft « Известные идентификаторы безопасности в операционных системах Windows» подробно описаны все системные идентификаторы безопасности, некоторые из которых я приведу ниже:
Встроенные участники системы безопасности
Эффективное использование мощных идентификаторов Администраторы, не использующие встроенных участников безопасности (well-known security principal), вряд ли представляют себе их сложность и широкие функциональные возможности. В Windows Server 2003 появились новые встроенные
Эффективное использование мощных идентификаторов
Администраторы, не использующие встроенных участников безопасности (well-known security principal), вряд ли представляют себе их сложность и широкие функциональные возможности. В Windows Server 2003 появились новые встроенные участники безопасности, и эта статья поможет освоить способы их применения для управления доступом к ресурсам Windows. Но прежде чем перейти к подробному описанию способов управления, хочу коротко пояснить, что представляют собой участники безопасности вообще и встроенные участники безопасности в частности. Затем мы подробно рассмотрим управление этими сложными элементами. Участник системы безопасности Windows — это аутентифицированный элемент, который использует ресурсы (например, файлы, принтеры), приложения или службы, размещенные на компьютерах Windows. Каждый участник безопасности имеет уникальный идентификатор, встроенный как SID.
Встроенные участники — отдельная категория участников безопасности. Они представляют собой особые сущности, определенные заранее и управляемые подсистемой безопасности Windows. Примерами могут служить учетные записи Everyone, Authenticated Users, System, Self и Creator Owner.
В отличие от типовых участников безопасности, этих участников нельзя переименовать или удалить. Невозможно также создать собственных встроенных участников безопасности; они одинаковы во всех системах Windows, хотя список встроенных участников безопасности в разных версиях слегка различается. Кроме того, встроенный участник безопасности имеет один и тот же SID в любой системе Windows. Например, SID S-1-5-10 всегда предоставляется участнику Self, а SID S-1-3-0 всегда представляет участника Creator Owner.
Обзор встроенных участников безопасности
В табл. 1 перечислены встроенные участники безопасности Windows 2003, Windows XP Service Pack 2 (SP2) и Windows 2000. В табл. 2 приведен список встроенных участников безопасности, введенных в Windows 2003; звездочкой отмечены участники, поддерживаемые XP SP2. Для каждого встроенного участника безопасности в таблице указан соответствующий SID. Список всех встроенных SID Windows приведен также в статье Microsoft «Well-known security identifiers in Windows operating systems» по адресу http://support.microsoft.com/?kbid=243330. Большинство встроенных участников безопасности, перечисленных в табл. 1 и 2, будут подробнее описаны ниже.
В Windows 2003 появились встроенные участники безопасности Local Service, Network Service, Digest Authentication, NTLM Authentication, Remote Interactive Logon, SChannel Authentication, Restricted Code, Other Organization и This Organization. Эти новые участники видны в Active Directory (AD), только если контроллер домена (DC), которому принадлежит роль эмулятора PDC, работает на Windows 2003. Для контроллеров доменов, созданных как на Windows 2003, так и на Windows 2000, необходимо сначала передать роль мастера данной операции контроллеру домена Windows 2003. Эта процедура документирована в статье Microsoft «Local Service and other well-known security principals do not appear on your Windows Server 2003 domain controller» по адресу http://support.microsoft.com/?kbid=827016. Данное ограничение не должно оказать заметного влияния на инфраструктуру AD, так как многие новые компоненты, использующие нового встроенного участника безопасности Windows 2003, требуют уровня однородного функционирования Windows 2003.
Большинство встроенных участников безопасности, перечисленные в табл.1 и 2 (например, Everyone, Authenticated Users), можно увидеть как встроенные группы участников безопасности. В отличие от типовых групп, операционная система (не администратор) автоматически управляет членством, которое зависит от ряда условий. Например, в XP и Windows 2000 операционная система автоматически вводит пользователя в группу Interactive, если данный пользователь работает локально за компьютером, на котором размещен ресурс, или если пользователь зарегистрировался на этом компьютере через соединение RDP. В Windows 2003 такой пользователь вводится в группу Remote Interactive Logon.
Встроенные группы участников безопасности можно рассматривать и как динамические группы, так как операционная система динамически определяет их членов. Их не следует путать с динамическими группами LDAP на базе запросов, которые были впервые представлены в Windows 2003 Authorization Manager (AzMan).
Интересная особенность встроенных участников безопасности — способ их репликации между экземплярами AD. Они могут применяться к тысячам объектов AD, но реплицируются только их имена, а не членство в группах. В результате нельзя использовать классический запрос AD и административный инструментарий для выяснения их членства в группах. Из-за способов использования встроенных участников безопасности хранить информацию об их членстве не требуется. Основная роль встроенных участников безопасности — обеспечить SID, который можно добавить в маркер доступа пользователя, когда тот регистрируется в системе или обращается к ресурсу. Присутствие конкретного встроенного участника безопасности дает пользователю определенные разрешения в системе или при обращениях к ресурсу. Просмотреть содержимое маркера доступа можно с помощью инструмента WhoAmI с ключом /all (WhoAmI поставляется c Windows 2003 и с Microsoft Windows 2000 Resource Kit) или такого бесплатного инструмента, как SecTok (который можно загрузить по адресу http://www.joeware.net), как показано на экране 1.
Администрирование встроенных участников безопасности
Встроенные участники безопасности существуют во всех операционных системах Windows, установленных как в домене, так и автономно. Однако в автономные системы вводятся не все встроенные участники безопасности. Кроме того, как объяснялось ранее, список встроенных участников безопасности в разных версиях операционных систем немного различается.
В домене Windows объекты AD, представляющие встроенных участников безопасности, хранятся в контейнере WellKnown Security Principals под контейнером Configuration. Для просмотра содержимого контейнера используется оснастка ADSIEdit консоли Microsoft Management Console (MMC) (экран 2). В автономной системе встроенные участники безопасности хранятся в локальной базе данных безопасности (Security Account Manager, SAM).
Встроенных участников безопасности можно добавить к другим группам и спискам управления доступом (ACL) объектов Windows. В AD можно даже делегировать разрешения встроенным участникам безопасности. Как ни странно, при первой попытке добавить встроенного участника безопасности в другую группу его не удается найти в оснастке Active Directory Users and Computers консоли MMC. Необходимо знать правильное имя встроенного участника безопасности; для поиска объекта нельзя задействовать инструментарий выбора объектов оснастки Active Directory Users and Computers. Дело в том, что в оснастке Active Directory Users and Computers сделан акцент на управление данными в контексте именования домена AD, а встроенные участники безопасности хранятся в контексте именования конфигурации AD. Та же проблема возникает при использовании оснастки MMC Local Users and Groups. В этом случае встроенные участники безопасности скрыты от пользователя.
В оснастке Active Directory Users and Computers встроенный участник безопасности отображается в контейнере ForeignSecurityPrincipals. Например, если ввести встроенного участника безопасности Authenticated Users в группу Print Operators, то элемент Authenticated Users будет добавлен в контейнер ForeignSecurityPrincipals (экран 3). Следует отметить, что в легкочитаемых именах большинства встроенных участников безопасности присутствует строка NT AUTHORITY. NT AUTHORITY — диспетчер безопасности во встроенном домене безопасности Windows, который существует в каждой системе Windows.
Встроенных участников безопасности можно добавлять в другие группы или в списки управления доступом (ACL) к ресурсам из командной строки. Это можно сделать с помощью команд Net Group и Net Localgroup. Например, чтобы добавить группу Interactive в локальную группу Backup Operators, следует ввести команду
Добавить встроенный участник безопасности в список ACL ресурса можно с помощью утилиты командной строки subinacl.exe из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit. Комплект можно загрузить по адресу http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en.
Например, чтобы предоставить группе Local Service право чтения в разделе реестра MyApplication, следует ввести команду
Итак, повторюсь, встроенные участники безопасности Windows (специальная категория участников безопасности, заранее определенных и управляемых подсистемой безопасности Windows) представляют собой мощные инструменты для управления и поддержания безопасности на должном уровне. Выше уже было показано, как встроенные участники безопасности упрощают администрирование доступа к ресурсам Windows. Встроенные участники безопасности определяются операционной системой: их нельзя создать, переименовать или удалить, и они одинаковы во всех системах Windows. Далее будут подробно рассмотрены индивидуальные встроенные участники безопасности, указаны компоненты Windows, в которых они применяются, и даны рекомендации по их эффективному использованию.
Authenticated Users и Everyone
Встроенный участник безопасности группа Authenticated Users охватывает всех пользователей, которых Windows аутентифицирует с помощью набора действительных пользовательских учетных данных при регистрации в системе. В группу Authenticated Users входят все пользователи с действительными учетными данными в лесу и его доменах и пользователи из других лесов, которые обращаются к ресурсам в локальном лесу через действительные учетные данные и доверительные отношения в лесу или между лесами.
Встроенный участник безопасности группа Everyone представляет собой надмножество группы Authenticated Users и охватывает ее и учетную запись Guest. Членство в группе определяется сложными правилами. В табл. 3 показаны специфические члены групп Authenticated Users и Everyone. В службе Active Directory (AD) версий Windows XP и Windows 2000 учетная запись Anonymous автоматически имеет членство в группе Everyone, но не в Authenticated Users. В Windows Server 2003 AD и Windows XP Service Pack 2 (SP2) учетная запись Anonymous по умолчанию не является членом группы Everyone, но ее можно поместить туда, установив параметр политики безопасности Network Access: Let Everyone permissions apply to anonymous users. Этот режим еще можно активизировать, присвоив параметру реестра HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetControlLSAEveryoneIncludes Anonymous (REG_DWORD) значение 1. Учетная запись Anonymous не является членом групп Authenticated Users.
System, Local Service и Network Service
В Windows 2000 и более ранних версиях службы и приложения независимых поставщиков обычно выполняются в контексте безопасности встроенного участника безопасности System (также именуемого учетной записью LSA или Local System). System функционирует как учетная запись данного компьютера в сети и как таковая представлена в сети именем Domain namemachine name$. Имя учетной записи в локальной системе NT AUTHORITYSystem. Учетная запись не имеет пароля, которым должен управлять администратор: используются данные учетной записи компьютера, автоматически назначаемые и управляемые Windows.
Разрешения System сопоставимы с учетной записью root в UNIX. При запуске службы или приложения в контексте безопасности System данная служба или приложение располагает почти неограниченными разрешениями в системе Windows. Например, если служба регистрируется на контроллере домена (DC) с использованием встроенного участника безопасности System, то она получает права локальной системы на DC. Получив контроль над службой, злоумышленник может внести изменения в AD. Следует быть осторожным — действуя в соответствии с принципом минимальности достаточных разрешений, лучше избегать использования System.
Чтобы не нарушать принципы и избежать риска, связанного с System, в Windows 2003 и XP SP2 предусмотрено два альтернативных варианта учетных записей: Local Service и Network Service. Local Service предоставляет минимальный уровень разрешений службам, которым достаточно доступа только к локальным ресурсам. Службы Smart Card, Remote Registry и Telnet используют учетную запись Local Service. Служба, работающая от имени Local Service, обращается к сетевым ресурсам в нуль-сеансе с учетными данными Anonymous. Чтобы настроить службу на использование Local Service, следует ввести NT AUTHORITYLocalService во вкладке Log On диалогового окна Alerter Properties. Пароль не требуется.
Network Service обеспечивает минимальный уровень разрешений для служб, которым необходим доступ к другим компьютерам в сети. Как и служба с разрешениями System, служба Network Service обращается к сетевым ресурсам с данными учетной записи компьютера. Службам Domain Name System (DNS) и Remote Procedure Call (RPC) по умолчанию присваиваются разрешения Network Service. Чтобы настроить службу на использование Network Service, следует ввести NT AUTHORITYNetworkService на вкладке Log On диалогового окна Alerter Properties. Пароль не нужен.
This Organization и Other OrganizationWindows 2003 располагают встроенными участниками безопасности This Organization и Other Organization, которые относятся к новой функции безопасности при доверительных отношениях между лесами, именуемой селективной аутентификацией и брандмауэром аутентификации. Селективная аутентификация позволяет определить дополнительный уровень управления доступом к ресурсам между лесами. Например, селективную аутентификацию можно использовать для выполнения регистрации на компьютере, а затем предоставить или запретить доступ к объектам на данном компьютере.
Селективную аутентификацию можно назначить как для доверительных отношений в лесу, так и между лесами, а также для внешних доверительных отношений между доменами. Администратор может задать доверительные отношения лесов между корневыми доменами двух лесов, и эти отношения будут применяться ко всему трафику аутентификации между лесами. Можно организовать внешние доверительные отношения между любыми двумя доменами в двух лесах, и затем они будут применяться к трафику аутентификации между этими двумя доменами.
С помощью мастера Trust Wizard или свойств доверительного отношения можно настроить доверительные отношения в лесу или внешние по отношению к лесу для селективной аутентификации. Для настройки селективной аутентификации из диалогового окна Properties доверительных отношений следует перейти на вкладку Authentication и активизировать Selective Authentication.
Режим селективной аутентификации может быть назначен, только если доверяющий домен или лес работают на функциональном уровне Windows 2003. Можно назначить селективную аутентификацию при настройке доверительных отношений для домена Windows NT 4.0, если нужно ограничить доступ к ресурсам домена Windows 2003.
Если лес или внешнее доверительное отношение используют селективную аутентификацию, а пользователь пытается обратиться к ресурсу в другом лесу (задействуя доверительные отношения между лесами), то Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Other Organization. Пользователи, которые обращаются к ресурсам, применяя доверительное отношение между лесами, по умолчанию имеют в своем маркере доступа встроенного участника безопасности This Organization. Когда пользователь задействует доверительные отношения в лесу или внешнее отношение между лесами без селективной аутентификации, Windows добавляет This Organization к маркеру доступа данного пользователя. В этом случае членство в группе This Organization такое же, как в группе Authenticated Users.
Если в маркере доступа имеется встроенный участник безопасности Other Organization, то серверы ресурсов проверяют, действительно ли пользователь, запросивший доступ, имеет разрешение Allowed-to-Authenticate на сервере ресурсов. Разрешение Allowed-to-Authenticate можно установить из редактора ACL для объекта «компьютер». Если пользователь имеет разрешение Allowed-to-Authenticate, то аутентификация между лесами проходит успешно. На этапе аутентификации сервер ресурсов проверяет наличие определенных разрешений для Other Organization, а затем, соответственно, разрешает или запрещает доступ к ресурсам.
Restricted Code
Windows добавляет к маркеру доступа пользователя встроенного участника безопасности Restricted Code при выполнении команды RunAs с параметром Run this program with restricted access в Windows 2003 или параметром Protect my computer and data from unauthorized program activity в XP. Для учетных записей с большими разрешениями (например, administrator) RunAs — удобный способ переключиться в контекст безопасности пользователя с минимальными правами при запуске программы. Таким образом, снижается опасность запуска вредоносной программы в контексте безопасности с большими разрешениями.
Если маркер доступа пользователя располагает встроенным участником безопасности Restricted Code, то Windows отменяет все разрешения для пользователя, кроме Bypass Traverse Checking. В результате приложение не может получить доступ к профилю пользователя, и разрешается только доступ по Read к базам данных настроек в реестре HKEY_LOCAL_MACHINE и HKEY_CURRENT_USER.
Restricted Code — удобный способ применять минимальные разрешения, не запоминая имен двух пользовательских учетных записей и двух паролей. Вместо использования RunAs для переключения в контекст безопасности с минимальными разрешениями можно применить RunAs для перехода в ограниченный вариант текущего контекста безопасности учетной записи — без ввода данных второй учетной записи. Более подробно о RunAs и использовании в ней Restricted Code рассказано в статье Аарона Маргосиса «Running Restricted» по адресу http://blogs.msdn.com/aaron_margosis/archive/ 2004/09/10/227727.aspx.
Типы Logon и Authentication
В Windows 2003, XP и Windows 2000 имеются встроенные участники безопасности, которые операционные системы добавляют в маркеры доступа других встроенных участников безопасности в зависимости от типа регистрации участника. Эти встроенные участники безопасности типа регистрации — Batch, Dialup, Interactive, Network, Service и Terminal Server User. Terminal Server User предназначен для всех пользователей, зарегистрированных с использованием режима совместимости с приложениями Terminal Services 4.0
Windows 2003 и XP SP2 дополнены встроенным участником безопасности Remote Interactive Logon, который идентифицирует пользователей, регистрирующихся с помощью версий Terminal Services для Windows 2003 или XP либо через соединение Remote Desktop.
Windows 2003 также дополнена тремя встроенными участниками безопасности типа аутентификации — NTLM Authentication, SChannel Authentication и Digest Authentication. Эти участники отражают в маркере доступа участника протокол аутентификации, который использовался участником для аутентификации в Windows. Следует отметить, что Microsoft не предоставила участников для аутентификации Kerberos и Basic.
Для более детального управления авторизацией можно использовать встроенные участники безопасности как типа регистрации, так и типа аутентификации. Эти новые участники позволяют назначить пользователям различные уровни доступа к ресурсам в зависимости от протокола аутентификации (например, NTLM, Digest, SSL) и типа регистрации (т. е. консоли или через терминальные службы).
Self, Creator Owner и Creator Group
Несколько иерархических структур объектов Windows (в том числе AD, реестр и файловая система) обеспечивают наследование разрешений. Разрешения определяются в родительском объекте, а затем автоматически передаются дочерним объектам. Windows располагает встроенными участниками безопасности Self, Creator Owner и Creator Group для администрирования разрешений в этих иерархических структурах.
Как правило, все три участника вводятся в список управления доступом (ACL) родительского объекта, а затем дочерние объекты наследуют этих участников следующим образом.
По умолчанию Windows предоставляет разрешение на чтение для Self на атрибут членства в группе. Поэтому все члены группы могут видеть других пользователей, принадлежащих к группе. AD также предоставляет группе Authenticated Users доступ на чтение к списку членов группы, и пользователи из Authenticated Users тоже видят эту информацию.
Мощный, но сложный инструмент
Мы познакомились с широкими возможностями встроенных участников безопасности и немного разобрались в трудностях, возникающих при управлении доступом к ресурсам Windows. Учитывая, что встроенные участники безопасности добавлены в Windows 2003, а также принимая во внимание растущее значение делегированного и самостоятельного администрирования, можно ожидать, что в будущем в Windows появится еще больше встроенных участников безопасности.
Поделитесь материалом с коллегами и друзьями