Windows impersonation что это
Обновлено: 06.07.2024
Олицетворение - это стандартная техника, которую службы используют для ограничения клиентского доступа к ресурсам домена службы. В роли ресурсов домена службы могут выступать ресурсы компьютера, например локальные файлы (олицетворение), или ресурсы, расположенные на другом компьютере, например общая папка (делегирование). Пример приложения см. в разделе Impersonating the Client. Пример использования олицетворения см. в разделе How to: Impersonate a Client on a Service.
Следует иметь в виду, что при олицетворении клиента в службе служба выполняется с учетными данными клиента, которые могут иметь более высокий уровень разрешений, чем серверный процесс.
Обзор
Для олицетворения и делегирования у клиента должно быть удостоверение Windows. Если у клиента нет удостоверения Windows, единственным решением является передача удостоверения клиента второй службе.
Основные принципы олицетворения
Windows Communication Foundation (WCF) поддерживает олицетворение для различных клиентских учетных данных. В этом разделе описана поддержка модели служб для олицетворения вызывающего объекта во время реализации метода службы. Также рассматриваются распространенные сценарии развертывания, включающие олицетворение и параметры безопасности SOAP и WCF в этих сценариях.
В этом разделе основное внимание уделяется олицетворению и делегированию в WCF при использовании безопасности SOAP. Вы также можете использовать олицетворение и делегирование в WCF при использовании безопасности транспорта, как описано в разделе использование олицетворения с защитой транспорта.
Два метода
Безопасность WCF SOAP имеет два различных метода для выполнения олицетворения. Выбор используемого метода зависит от привязки. Первый - олицетворение на основании маркера Windows, получаемого из интерфейса поставщика поддержки безопасности (SSPI) или при проверке подлинности Kerberos, который затем кэшируется службой. Второй метод - олицетворение на основании маркера Windows, получаемого из расширений Kerberos, имеющих общее имя Service-for-User (S4U).
Олицетворение с использованием кэшированного маркера
Для олицетворения с использованием кэшированного маркера используются следующие элементы:
любая привязка CustomBinding , использующая учетные данные клиента Windows, где свойство requireCancellation имеет значение true . (Свойство доступно в следующих классах: SecureConversationSecurityTokenParameters , SslSecurityTokenParameters и SspiSecurityTokenParameters .) Если для привязки используется безопасный диалог, для свойства также должно быть requireCancellation задано значение true .
любая привязка CustomBinding , в которой клиент представляет имя пользователя. При использовании в привязке безопасного обмена данными свойство requireCancellation также должно иметь значение true .
Олицетворение на базе S4U
Для олицетворения на базе S4U используются следующие элементы:
любая привязка CustomBinding , использующая учетные данные клиента Windows, где свойство requireCancellation имеет значение false ;
любая привязка CustomBinding , использующая имя пользователя или учетные данные клиента Windows, а также безопасный обмен данными, где свойство requireCancellation имеет значение false .
Уровень олицетворения клиента службой зависит от привилегий, доступных учетной записи при попытке олицетворения, используемого типа олицетворения и, возможно, от уровня олицетворения, разрешенного клиентом.
Олицетворение в методе службы: декларативная модель
Большинство сценариев олицетворения предполагают выполнение метода службы в контексте вызывающего объекта. WCF предоставляет функцию олицетворения, которая делает это простым, позволяя пользователю указать требование олицетворения в OperationBehaviorAttribute атрибуте. Например, в следующем коде инфраструктура WCF олицетворяет вызывающий объект перед выполнением Hello метода. Все попытки обратиться к собственным ресурсам внутри метода Hello окажутся успешными только в том случае, если список управления доступом (ACL) ресурса дает права на доступ вызывающему объекту. Чтобы включить олицетворение, присвойте свойству Impersonation одно из значений перечисления ImpersonationOption : ImpersonationOption.Required или ImpersonationOption.Allowed, как показано в следующем примере.
Если у службы имеется больше прав, чем у удаленного клиента, то используются учетные данные службы, если свойство Impersonation имеет значение Allowed. Это значит, что если пользователь с более узкими правами предоставляет свои учетные данные, то метод выполняется с более широкими правами службы, и пользователь получает доступ к ресурсам, доступ к которым он бы сам получить не смог.
инфраструктура WCF может олицетворять вызывающий объект только в том случае, если вызывающий объект прошел проверку подлинности с учетными данными, которые можно сопоставить с учетной записью пользователя Windows. Если служба настроена на прохождение проверки подлинности с использованием учетных данных, которые невозможно сопоставить с учетной записью Windows, метод службы не выполняется.
в Windows XP олицетворение завершается сбоем, если создается SCT с отслеживанием состояния, что приводит к созданию InvalidOperationException . Дополнительные сведения см. в разделе неподдерживаемые сценарии.
Олицетворение в методе службы: императивная модель
Иногда вызывающему объекту требуется олицетворять не весь метод службы, а лишь его часть. В этом случае необходимо получить удостоверение Windows вызывающего объекта внутри метода службы и императивно выполнить олицетворение. Для этого необходимо с помощью свойства WindowsIdentity объекта ServiceSecurityContext возвратить экземпляр класса WindowsIdentity и вызвать метод Impersonate перед использованием этого экземпляра.
Олицетворение для всех методов службы
В некоторых случаях требуется выполнять в контексте вызывающего объекта все методы службы. Вместо явного включения этой функции для каждого метода в отдельности можно воспользоваться классом ServiceAuthorizationBehavior. Как показано в следующем фрагменте кода, установите свойство ImpersonateCallerForAllOperations равным true . Объект ServiceAuthorizationBehavior извлекается из коллекции расширений функциональности класса ServiceHost . Также обратите внимание, что свойство Impersonation объекта OperationBehaviorAttribute , применяемого к каждому из методов, тоже должно иметь значение Allowed или Required.
В следующей таблице описывается поведение WCF для всех возможных сочетаний функций ImpersonationOption и ImpersonateCallerForAllServiceOperations .
| ImpersonationOption | ImpersonateCallerForAllServiceOperations | Поведение |
|---|---|---|
| Обязательно | Недоступно | WCF олицетворяет вызывающего |
| Разрешено | false | WCF не олицетворяет вызывающего |
| Разрешено | Да | WCF олицетворяет вызывающего |
| NotAllowed | false | WCF не олицетворяет вызывающего |
| NotAllowed | Да | Disallowed. (Создается исключение InvalidOperationException .) |
Уровень олицетворения, получаемый на основании учетных данных Windows, и олицетворение с использованием кэшированного маркера
В некоторых сценариях при использовании учетных данных клиента Windows клиент может лишь частично управлять уровнем олицетворения в службе. Один из таких сценариев имеет место, когда клиент задает уровень олицетворения Anonymous. Второй сценарий имеет место при олицетворении с использованием кэшированного маркера. Для этого задается свойство AllowedImpersonationLevel класса WindowsClientCredential , к которому происходит обращение как к свойству универсального класса ChannelFactory<TChannel> .
Задание уровня олицетворения Anonymous приводит к тому, что клиент входит в систему службы анонимно. Поэтому служба должна разрешать анонимный вход независимо от того, будет ли выполняться олицетворение.
Клиент может установить один из следующих уровней олицетворения: Anonymous, Identification, Impersonationили Delegation. При этом создается только маркер на заданном уровне, как показано в следующем фрагменте кода.
В следующей таблице показаны уровни олицетворения, получаемые службой при олицетворении с использованием кэшированного маркера.
| Значение AllowedImpersonationLevel | У службы есть SeImpersonatePrivilege | Служба и клиент поддерживают делегирование | Кэшированный маркер ImpersonationLevel |
|---|---|---|---|
| Анонимный | Да | Недоступно | Олицетворение |
| Анонимный | нет | Недоступно | Идентификация |
| Идентификация | Недоступно | Недоступно | Идентификация |
| Олицетворение | Да | Недоступно | Олицетворение |
| Олицетворение | нет | Недоступно | Идентификация |
| Делегирование | Да | Да | Делегирование |
| Делегирование | Да | нет | Олицетворение |
| Делегирование | нет | Недоступно | Идентификация |
Уровень олицетворения, получаемый на основании учетных данных имени пользователя, и олицетворение с использованием кэшированного маркера
| AllowedImpersonationLevel | У службы есть SeImpersonatePrivilege | Служба и клиент поддерживают делегирование | Кэшированный маркер ImpersonationLevel |
|---|---|---|---|
| Недоступно | Да | Да | Делегирование |
| Недоступно | Да | нет | Олицетворение |
| Недоступно | нет | Недоступно | Идентификация |
Уровень олицетворения при олицетворении на базе S4U
| У службы есть SeTcbPrivilege | У службы есть SeImpersonatePrivilege | Служба и клиент поддерживают делегирование | Кэшированный маркер ImpersonationLevel |
|---|---|---|---|
| Да | Да | Недоступно | Олицетворение |
| Да | нет | Недоступно | Идентификация |
| нет | Недоступно | Недоступно | Идентификация |
Сопоставление сертификата клиента с учетной записью Windows
Клиент может выполнить свою проверку подлинности в службе с использованием сертификата, чтобы служба сама сопоставила клиент с существующей учетной записью в Active Directory. В следующем примере XML-кода показано, как настроить службы для сопоставления сертификата.
В следующем примере кода показано, как настроить службу.
Делегирование
Чтобы выполнить делегирование внутренней службе, служба должна выполнить многоступенчатую (SSPI без резервной проверки подлинности NTLM) проверку подлинности или прямую проверку подлинности Kerberos во внутренней службе, используя удостоверение Windows клиента. Для делегирования внутренней службе создайте объект ChannelFactory<TChannel> и канал, а затем используйте этот канал для взаимодействия при олицетворении клиента. При такой модели делегирования расстояние, на котором внутренняя служба может располагаться относительно внешней службы, зависит от уровня олицетворения, полученного внешней службой. Если уровень олицетворения равен Impersonation, внешняя и внутренняя службы должны выполняться на одном компьютере. Если уровень олицетворения равен Delegation, внешняя и внутренняя службы могут выполняться как на различных компьютерах, так и на одном компьютере. Для включения олицетворения уровня делегирования необходимо, чтобы политика домена Windows разрешала делегирование. Дополнительные сведения о настройке поддержки делегирования в Active Directory см. в разделе Включение делегированной проверки подлинности.
Если клиент проходит проверку подлинности во внешней службе с использованием имени пользователя и пароля, соответствующих учетной записи Windows во внутренней службе, внешняя служба может пройти проверку подлинности во внутренней службе, используя имя пользователя и пароль клиента. Это особенно мощная форма потока обработки удостоверений, поскольку передача имени пользователя и пароля внутренней службе позволяет этой службе выполнять олицетворение; однако в этом случае невозможно делегирование, так как не использует проверка подлинности Kerberos. Действие элементов управления делегированием службы каталогов Active Directory не распространяется на проверку подлинности имени пользователя и пароля.
Возможность делегирования как функция уровня олицетворения
| Уровень олицетворения | Служба может выполнять делегирование между процессами | Служба может выполнять делегирование между компьютерами |
|---|---|---|
| Identification | нет | нет |
| Impersonation | Да | нет |
| Delegation | Да | Да |
В следующем примере кода показано, как использовать делегирование.
Настройка приложения для использования ограниченного делегирования
Для использования ограниченного делегирования необходимо предварительно настроить отправитель, получатель и контроллер домена. Ниже перечислены операции по включению ограниченного делегирования. Дополнительные сведения о различиях между делегированием и ограниченным делегированием см. в части раздела Расширения Kerberos Windows Server 2003 , посвященной ограниченному делегированию.
На контроллере домена снимите флажок Учетная запись важна и не может быть делегирована для учетной записи, от имени которой выполняется клиентское приложение.
На контроллере домена установите флажок Учетная запись доверена для делегирования для учетной записи, от имени которой выполняется клиентское приложение.
На контроллере домена настройте компьютер промежуточного уровня, чтобы он был доверен для делегирования. Для этого установите параметр Доверять компьютеру делегирование .
На контроллере домена настройте компьютер промежуточного уровня, чтобы он использовал ограниченное делегирование. Для этого установите параметр Этот компьютер доверенный для делегирования указанных служб .
Более подробные инструкции по настройке ограниченного делегирования см. в разделе Смена протокола Kerberos и ограниченное делегирование.
Impersonation is the ability of a thread to execute in a security context that is different from the context of the process that owns the thread. When running in the client's security context, the server "is" the client, to some degree. The server thread uses an access token representing the client's credentials to obtain access to the objects to which the client has access.
The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do. For example, suppose a file server has files containing confidential information and that each of these files is protected by an ACL. To help prevent a client from obtaining unauthorized access to information in these files, the server can impersonate the client before accessing the files.
Access Tokens for Impersonation
Access tokens are objects that describe the security context of a process or thread. They provide information that includes the identity of a user account and a subset of the privileges available to the user account. Every process has a primary access token that describes the security context of the user account associated with the process. By default, the system uses the primary token when a thread of the process interacts with a securable object. However, when a thread impersonates a client, the impersonating thread has both a primary access token and an impersonation token. The impersonation token represents the client's security context, and this access token is the one that is used for access checks during impersonation. When impersonation is over, the thread reverts to using only the primary access token.
You can use the OpenProcessToken function to get a handle to the primary token of a process. Use the OpenThreadToken function to get a handle to the impersonation token of a thread.
Давным-давно, когда трава была зеленее, а интернет безопаснее, в ИТ родилась инициатива Web Based Enterprise Management (WBEM). Первоначально спонсируемая в 1996 году такими компаниями как Cisco Systems, Intel и Microsoft, она получила широкое распространение и реализацию на различных платформах: от MAC OS до Redhat. WBEM четко документирован, основан на стандартах Интернета и представляет собой иной подход к управлению системами, отличный, например, от SNMP протокола.
Адаптация WBEM для Windows получила название WMI (Windows management interface) и впервые была представлена в Windows XP. Нам известно, что системы обновляются быстрее, чем их компоненты и многие уязвимости, бывшие ранее удобным инструментом управления, кочуют из версии в версию. В этой статье я хочу описать как выполняются задачи WMI и как избежать потенциальных рисков.
В силу своей мощности, WMI позволяет с помощью специальных утилит или сценариев производить различные потенциально опасные действия на ПК, в том числе, остановку критичных для работы служб и даже выключение компьютера. Например, так:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges).Win32Shutdown(5)
(GWMI -Class Win32_Service -Filter «name='WinRM'» -ComputerName Server).StopService()
Кроме того, на удаленной машине эти действия выполнить так же просто, как на локальной — достаточно написать имя нужной машины в пути к WMI-объекту.
Пространство имен WMI – это раздел репозитория WMI, который призван группировать классы и объекты WMI по назначению, плюс, определять атрибуты безопасности при доступе к классам и объектам в каждом таком контейнере. Все пространства имен начинаются с корня, который в WMI обозначается ключевым словом root. После имени корня через косую черту указывается пространство имен. Пространства имен могут быть вложенными. Большинство интересных классов и объектов размещается в пространстве имен root/CIMv2.
Одно из существующих в Windows пространств имен WMI может быть выбрано по умолчанию. Это означает, что если вы попытаетесь подключиться к этому хосту, не указав пространство имен, то вы автоматически будете подключены к выбранному по умолчанию. В стандартной инсталляции Windows по умолчанию выбрано пространство root\cimv2.
Технология WMI предназначена для администраторов Windows, и вся система безопасности в WMI устроена так, чтобы с помощью сценариев WMI пользователь мог на заданном ПК выполнить лишь те действия, на которые ему даны разрешения/привилегии. Это так называемые привилегии по умолчанию. Так реализуется безопасность WMI на уровне операционной системы: если пользователю на уровне операционной системы не дана привилегия перезагружать компьютер, то и с помощью WMI он и не сможет этого сделать.
Дополнительные политики безопасности в WMI реализованы на уровне пространств имен протокола Distributed СОМ (DCOM) – распределенной объектной модели компонентов. Чтобы более подробно рассмотреть эти типы безопасности WMI, кратко напомню основные общие понятия, связанные с безопасностью в Windows. А основана эта безопасность на именах пользователей и их паролях.
О разрешениях WMI
Когда в Windows создается пользователь, его системной учетной записи присваивается уникальный идентификатор безопасности (Security IDentifier или SID). На основе SID для пользователя формируется маркер доступа (Access Token), в который также добавляется список групп, членом которых является пользователь и список привилегий, которыми он обладает (например, остановка служб или выключение компьютера). Этот маркер доступа присваивается также всем процессам, которые запускает пользователь. В это время каждый объект операционной системы, доступ к которому определяет система безопасности – файл, либо процесс, либо служба или что-то ещё, имеет дескриптор безопасности (Security Descriptor, SD). В этом дескрипторе, в свою очередь, хранится список контроля доступа (Access Control List, ACL) для этого объекта.
Итак, при обращении пользователя или запущенного им процесса к объекту происходит сравнение маркера доступа данного пользователя со списком контроля доступа. В зависимости от результатов выдается или отклоняется разрешение/привилегия на выполнение запрашиваемых действий над объектом.
На уровне пространств имен механизм безопасности WMI соответствует общей модели безопасности Windows. Каждое пространство имен может иметь собственный дескриптор безопасности, на котором хранится список контроля доступа (ACL).
Каждая запись списка контроля доступа (Access Control Entry, АСE) содержит информацию о том, какие разрешения имеет определенный пользователь при выполнении различных операций в этом пространстве имен.
А вот и список разрешений при работе с пространством имен:
Выполнение методов (Execute Methods). Позволяет вызывать методы классов из определенного пространства имен. Будет ли метод выполнен или произойдет отказ, зависит от того, имеет ли пользователь разрешение на выполнение этой операции в системе.
Полная запись (Full Write). Разрешает создавать и модифицировать подпространства имен, системные классы и экземпляры классов.
Частичная запись (Partial Write). Открывает возможность создавать и модифицировать любые статические классы и экземпляры несистемных классов.
Запись поставщика (Provider Write). Позволяет записывать в репозиторий CIM классы провайдеров WMI и экземпляры этих классов.
Включить учетную запись (Enable Account). Предоставляет право чтения пространства имен WMI. Пользователи с этим разрешением, могут запускать на локальном компьютере сценарии, которые читают данные WMI.
Включить удаленно (Remote Enable). Разрешает пользователям получить доступ к пространству имен WMI на удаленном компьютере. По умолчанию этим разрешением обладают только администраторы, обычные пользователи не могут получать данные WMI с удаленных машин.
Прочесть безопасность (Read Security). Дает право читать дескриптор безопасности для пространства имен WMI без возможности его модификации.
Изменение правил безопасности (Edit Security). Позволяет изменять дескриптор безопасности для пространства имен WMI.
Все эти записи списка контроля доступа хранятся в репозитории WMI. Разрешения WMI для конкретного пространства имен применяются ко всем подпространствам имен и классам, которые определены в этом пространстве (наследуются ими). Собственные же разрешения безопасности для отдельного класса WMI определить нельзя.
О настройке по умолчанию
В Windows группа администраторов обладает всеми разрешениями из таблицы выше, а для остальных пользователей включена учетная запись (Enable Account), разрешено вызывать методы (Execute Methods) и записывать в CIM экземпляры классов провайдеров (Provider Write).
Администратор может изменить разрешения для определенных пользователей с помощью утилиты для настройки параметров WMI (оснастка wmimgmt.msc консоли управления ММС).
Скриншот 1.
Для доступа к инфраструктуре WMI на удаленном компьютере используется вышеуказанный протокол DCOM. Пользователь запускает сценарий или подключается к WMI с помощью специальных утилит и выступает в качестве клиента, а объект WMI, к которому идет обращение, является сервером. Чтобы определить, какой маркер доступа будет применяться при работе с WMI на удаленном компьютере, используются стандартные уровни имперсонации протокола DCOM.
Об имперсонации или Impersonation Levels
По-русски звучит несколько коряво. Что такое имперсонация и зачем она нужна? Это метод, при котором для подключения к ресурсу процесс или система должны использовать не свой контекст безопасности, а учетные данные другого субъекта безопасности.
Еще для этого контекст безопасности службы должен обладать привилегией создания маркеров доступа.
Бывает более сложный вариант имперсонации – делегирование. Этот вариант необходим тогда, когда подключение к конечному ресурсу выполняется не самим субъектом безопасности (в примере выше – службой от лица пользователя), а через посредника (например, промежуточный сервер).
Представьте: пользователь подключается не напрямую к базе данных, а через веб-приложение на третьем сервере. Для осуществления такого подключения веб-приложение должно получить от субъекта безопасности (нашей службы) маркер доступа с правом делегирования – это позволит веб-приложению использовать маркер доступа субъекта безопасности уже при подключении к базе данных.
В случае с WMI делегирование может выглядеть так: мы, работая на станции администратора, подключаемся по WMI к некому серверу и запускаем на нем процесс с помощью метода Execute класса Win32_Process. Этот процесс не что иное, как другой скрипт WMI, который подключается к ещё одному хосту в сети для того, чтобы совершить какие-то действия. Если мы не воспользуемся делегированием, то на конечной машине скрипт будет запущен в контексте безопасности учетной записи промежуточного сервера, что далеко не всегда желаемо. С другой стороны, подобная ситуация с делегированием в реальной жизни случается достаточно редко.
Об уровнях Impersonation Levels
Анонимный доступ (Anonymous). Объект-сервер не имеет права получить информацию о пользователе или процессе, который обращается к данному объекту (иными словами, объект не может олицетворить клиента). Этот уровень олицетворения в WMI не используется.
Идентификация (Identify). Объект-сервер может запросить маркер доступа, связанный с клиентом, но не может произвести олицетворение.
В сценариях WMI этот уровень олицетворения используется редко, в этом случае нельзя запускать сценарии WMI на удаленных машинах.
Олицетворение (Impersonate). Объект-сервер может пользоваться всеми правами и привилегиями, которыми обладает клиент. В сценариях WMI рекомендуется использовать именно этот уровень олицетворения, ибо в таком случае сценарий WMI на удаленной машине сможет выполнять все действия, которые разрешено осуществлять пользователю, запустившему этот сценарий.
Делегирование (Delegate). Объект на сервере, к которому обращается клиент, может обратиться от имени клиента к другому объекту на другом сервере. Делегирование позволяет сценарию использовать на удаленной машине маркер доступа запустившего его пользователя. Тот же маркер используется для доступа к объектам WMI на других рабочих станциях. Применение данного уровня олицетворения связано с потенциальным риском, делегирование в сценариях WMI следует применять только в случае особой необходимости.
Выбираемый по умолчанию уровень олицетворения зависит от версии WMI на целевом компьютере. В версиях WMI ниже 1.5 по умолчанию используется уровень Идентификация (Identify), в версии WMI 1.5 и выше —Олицетворение (Impersonate). При необходимости можно изменить уровень олицетворения по умолчанию — для этого необходимо записать наименование нужного уровня (например, impersonate или Delegate) в ключ реестра
HKEY_LOCAL_MACHINE\Software\Microsoft\Wbem\Scripting\Default Impersonation Level.
Скриншот 2.
Протокол DCOM также предоставляет возможность запросить для соединения WMI определенный уровень аутентификации (проверки подлинности) и конфиденциальности:
Отсутствует (None). Проверка подлинности отсутствует.
По умолчанию (Default). Для выбора уровня проверки подлинности используются стандартные настройки безопасности. Рекомендуется использовать именно этот уровень, так как к клиенту будет применен уровень проверки подлинности, который задается сервером.
Подключений (Connect). Клиент проходит проверку подлинности только во время подключения к серверу. После того как соединение установлено, никаких дополнительных проверок не производится.
Вызовов(Call). Клиент проходит проверку подлинности в начале каждого вызова, во время приема запросов сервером. При этом заголовки пакетов подписываются, однако сами данные (содержимое пакетов), передаваемые между клиентом и сервером, не подписываются и не шифруются.
Пакет (Pkt). Проверке подлинности подвергаются все пакеты данных, которые поступают серверу от клиентов. Как и при проверке подлинности на уровне вызовов, заголовки пакетов подписываются, но не шифруются. Сами пакеты не подписываются и не шифруются.
Целостности пакетов (Pktlntegrity). Все пакеты данных проходят проверку подлинности и целостности. Проверяется, что содержимое пакета не было изменено во время передачи от клиента серверу. При этом данные подписываются, но не шифруются.
Привилегии (PktPrivacy). Все пакеты данных проходят проверку подлинности и целостности, при этом данные подписываются и шифруются, что обеспечивает конфиденциальность передаваемых данных.
Администраторам Windows хорошо известны настройки безопасности системы, доступные в консоли безопасности системы и групповых политиках домена и раздел «User Right Assignments» (привилегии пользователей). Ряд действий с операционной системой можно проделать только при наличии у пользователя или группы, куда он входит, той или иной привилегии. К таким действиям, например, относятся: перезагрузка системы (завершение её работы), восстановление состояния системы из резервной копии или смена системного времени.
Поскольку с использованием WMI можно выполнить все эти действия, разработчики WMI заложили дополнительный механизм защиты: даже если учетная запись пользователя обладает привилегиями, необходимыми для действия с системой, он все равно не сможет выполнить это действие, пока явно не активирует привилегию перед выполнением действия. В частности, если администратор запустит скрипт WMI, запрашивающий перезагрузку системы, этого все равно не произойдет, пока в скрипте не будет явно активирована эта привилегия.
Резюме
Что предлагается сделать для обеспечения безопасности WMI-подключений:
- Изменить уровень имперсонации для критичных сервисов (Скриншот 2).
- Настроить разрешения wmimgmt.msc (Скриншот 1).
- Изменить репозиторий по умолчанию. Это может нарушить сценарий шаблонных атак.
4. Изменить группы лиц с возможностями удаленного запуска и активации WMI через утилиту DCOMCNFG
5. Чтобы запустить WMI пользователь должен быть членом группы administrators либо DCOM users. Также должна быть доступна служба remote registry.
6. Настроить файервол – входящие подключения к DCOM идут по 135 TCP-порту и (имеют?) динамический диапазон RPC.
В заключение хочу сказать следующее: WMI дает скорость, мощь и легкость запуска команд на удаленных хостах, а SQL based-семантика команд делает его легким для освоения.
В интернете очень много информации о взломах и WMI-атаках, ведь они вписываются в нынешний атакующий тренд – использование нативных инструментов взлома системы – наряду с telnet NTP и DNS. Наша задача — этот тренд уловить и найти методы противодействия уже заложенные в систему.
I am using the code to impersonate a user account to get access to a file share.
I get an "Access Denied" error.
This user supposely has access to this share. I can map a drive, use "net use" but this code will not work. Now I am thinking it is the code. Does anyone see anything? Is there a better way of doing this?
24k 12 12 gold badges 88 88 silver badges 107 107 bronze badges 745 1 1 gold badge 11 11 silver badges 29 29 bronze badges Where is this running from? If this is an app hosted on IIS, then the default IIS user may not have the rights to impersonate3 Answers 3
Usage :
If I'm understanding correctly, your intention is to run the process in the impersonation context.
The doc from CreateProcess (which is used by Process.Start) says: If the calling process is impersonating another user, the new process uses the token for the calling process, not the impersonation token. To run the new process in the security context of the user represented by the impersonation token, use the CreateProcessAsUser or CreateProcessWithLogonW function.
So, you're using the wrong API for doing that.
Instead of using your Impersonator class, what happens when you call Process.Start and pass in a ProcessStartInfo instance that contains the username, password and domain that you want to run the process as?
Perhaps, if that works, then your Impersonator class should create a ProcessStartInfo instance and use that to create new processes (encapsulate that within the class itself).
Setting the Domain, UserName, and the Password properties in a ProcessStartInfo object is the recommended practice for starting a process with user credentials.
You should also set the working directory when starting a process with different user creds.
Читайте также: