Какие разрешения / права нужны пользователю для доступа к WMI на удаленных компьютерах?


33

Я пишу службу мониторинга, которая использует WMI для получения информации с удаленных машин. Наличие локальных прав администратора на всех этих машинах невозможно по политическим причинам.

Это возможно? Какие разрешения / права требуются моему пользователю для этого?

Ответы:


31

Следующее работает на Windows 2003 R2 SP 2, Windows Server 2012 R2

  1. Добавьте соответствующих пользователей в группу « Пользователи системного монитора ».
  2. В разделе «Службы и приложения» откройте диалоговое окно свойств элемента управления WMI (или запустите wmimgmt.msc). На вкладке «Безопасность» выделите пункт « Root/CIMV2Безопасность»; добавьте пользователей системного монитора и включите параметры: Enable AccountиRemote Enable
  3. Беги dcomcnfg. На Сервисы компонентов> Компьютеры> Мой компьютер, на вкладке Безопасность COM диалогового окна Свойства нажмите «Редактировать пределы» для обоих Access Permissionsи Launch and Activation Permissions. Добавьте пользователей системного монитора и разрешите удаленный доступ, удаленный запуск и удаленную активацию.
  4. Выбор инструментария управления Windows под Component Services> Компьютеры> Мой компьютер> Настройка DCOM и дать Remote Launchи Remote Activationпривилегии Performance Monitor Users Group.

Заметки:

  • В качестве альтернативы шагам 3 и 4 можно назначить пользователя в группу « Распределенные пользователи COM» (протестировано на Windows Server 2012 R2).
  • Если пользователю нужен доступ ко всем пространствам имен, вы можете установить параметры в 2. на Rootуровне и восстановить права доступа к подпространствам имен через Advancedокно вSecurity

1
Я обнаружил, что шаги 2 и 3 не нужны, если вы добавляете пользователя в Distributed COM Users.
Nexus

Работая над WinXP и Win7, я не смог добавить группу «Distributed COM Users» - может быть, эта группа доступна только на серверах? Он не разрешается при поиске имени при попытке добавить к разрешениям. Кроме того, я обнаружил, что мне нужно было установить разрешения для WMI на «Root», а также «Root / CIMV2», и что мне пришлось перейти к расширенным разрешениям и применить разрешение для подпространств имен, а также для пространства имен.
Шеннон Вагнер

Работает также для Windows 8! Кроме того, кто-нибудь знает, как сделать то же самое с powershell или другой оболочкой?
Буник

1
В случае, если вы хотите, чтобы пользователь мог получить доступ ко всему пространству имен, вы можете предоставить разрешение Root и всем подпространствам имен, выбрав Root, открыв Security, затем Advanced и настроив рекурсию. По умолчанию эти настройки применяются только к выбранному объекту и не каскадируются.
Томас

это не работает для пространства имен MSCluster
Джон

4

Все, что я делал в Windows 8, добавлял пользователя в группу «Пользователи удаленного управления», и удаленные WQL-запросы работали.


1

По умолчанию только локальная группа «Администраторы» имеет удаленные разрешения для WMI. Вам нужно будет настроить разрешения WMI «Remote Enable».


1

Вам также может потребоваться предоставить «разрешения удаленного доступа DCOM» и / или «разрешения удаленного запуска и активации DCOM» в зависимости от того, что именно вы пытаетесь сделать. В этой статье MSDN приведены пошаговые инструкции.


0

Следующее сработало для меня в среде домена 2012 r2, хотя мне удалось сделать это только на сервер, а не на весь домен:

1) Добавить пользователя в группу пользователей журнала производительности. 2) Запустите wmimgmt.msc, щелкните правой кнопкой мыши «WMI Control (LOCAL)», перейдите на вкладку «Безопасность» и предоставьте соответствующему пользователю «Включить учетную запись» и «Удаленное включение» в требуемом пространстве имен (обычно CIMV2).

Если мне удастся сделать это для всего домена, я вернусь и обновлю.


0

Основываясь на выбранном ответе, я изменил скрипт от Microsoft, чтобы установить безопасность WMI. Мой тестовый пользователь был пользователем домена без прав администратора, который был членом группы «Пользователи удаленного управления» в локальной системе по причинам, не связанным с этой проблемой. После предоставления моему пользователю разрешений EnableAccount, RemoteEnable и ExecuteMethods для целевого пространства имен я смог получить доступ к WMI.

Поэтому я не добавил своего пользователя в локальные группы « Пользователи системного монитора» или « Распределенные пользователи COM» .

Пара замечаний по поводу сценария:

  1. Вы должны указать полный путь к пространству имен. В моем случае пространство имен было Root / Microsoft / SqlServer
  2. Наследование было неверным. Потому что нет листовых объектов, которые вы не можете использовать$OBJECT_INHERIT_ACE_FLAG
  3. Я избавился от встроенной функции, потому что она была слишком маленькой и использовалась только один раз.

Сценарий ниже. Я назвал это Set-WMINamespaceSsecurity.ps1

Param ([Parameter(Mandatory=$true,Position=0)] [string]$Namespace,
       [Parameter(Mandatory=$true,Position=1)] [ValidateSet("Add","Remove")] [string]$Operation,
       [Parameter(Mandatory=$true,Position=2)] [string] $Account,
       [Parameter(Mandatory=$false,Position=3)] [ValidateSet("EnableAccount","ExecuteMethods","FullWrite","PartialWrite","ProviderWrite","RemoteEnable","ReadSecurity","WriteSecurity")] [string[]] $Permissions=$null,
       [Parameter(Mandatory=$false)] [switch]$AllowInherit,
       [Parameter(Mandatory=$false)] [switch]$Deny,
       [Parameter(Mandatory=$false)] [string]$ComputerName=".",
       [Parameter(Mandatory=$false)] [System.Management.Automation.PSCredential]$Credential=$null)

$OBJECT_INHERIT_ACE_FLAG    = 0x1
$CONTAINER_INHERIT_ACE_FLAG = 0x2
$ACCESS_ALLOWED_ACE_TYPE    = 0x0
$ACCESS_DENIED_ACE_TYPE     = 0x1

$WBEM_ENABLE            = 0x01
$WBEM_METHOD_EXECUTE    = 0x02
$WBEM_FULL_WRITE_REP    = 0x04
$WBEM_PARTIAL_WRITE_REP = 0x08
$WBEM_WRITE_PROVIDER    = 0x10
$WBEM_REMOTE_ACCESS     = 0x20
$WBEM_RIGHT_SUBSCRIBE   = 0x40
$WBEM_RIGHT_PUBLISH     = 0x80
$READ_CONTROL           = 0x20000
$WRITE_DAC              = 0x40000
$WBEM_S_SUBJECT_TO_SDS  = 0x43003

$ErrorActionPreference = "Stop"

$InvokeParams=@{Namespace=$Namespace;Path="__systemsecurity=@";ComputerName=$ComputerName}
if ($PSBoundParameters.ContainsKey("Credential")) { $InvokeParams+= @{Credential=$Credential}}

$output = Invoke-WmiMethod @InvokeParams -Name "GetSecurityDescriptor"
if ($output.ReturnValue -ne 0) { throw "GetSecurityDescriptor failed:  $($output.ReturnValue)" }

$ACL = $output.Descriptor

if ($Account.Contains('\')) {
  $Domain=$Account.Split('\')[0]
  if (($Domain -eq ".") -or ($Domain -eq "BUILTIN")) { $Domain = $ComputerName }
  $AccountName=$Account.Split('\')[1]
}
elseif ($Account.Contains('@')) {
  $Somain=$Account.Split('@')[1].Split('.')[0]
  $AccountName=$Account.Split('@')[0]
}
else {
  $Domain = $ComputerName
  $AccountName = $Account
}

$GetParams = @{Class="Win32_Account" ;Filter="Domain='$Domain' and Name='$AccountName'"}
$Win32Account = Get-WmiObject @GetParams
if ($Win32Account -eq $null) { throw "Account was not found: $Account" }

# Add Operation
if ($Operation -eq "Add") {
  if ($Permissions -eq $null) { throw "Permissions must be specified for an add operation" }

  # Construct AccessMask
  $AccessMask=0
  $WBEM_RIGHTS_FLAGS=$WBEM_ENABLE,$WBEM_METHOD_EXECUTE,$WBEM_FULL_WRITE_REP,$WBEM_PARTIAL_WRITE_REP,$WBEM_WRITE_PROVIDER,$WBEM_REMOTE_ACCESS,$READ_CONTROL,$WRITE_DAC
  $WBEM_RIGHTS_STRINGS="EnableAccount","ExecuteMethods","FullWrite","PartialWrite","ProviderWrite","RemoteEnable","ReadSecurity","WriteSecurity"
  $PermissionTable=@{}
  for ($i=0; $i -lt $WBEM_RIGHTS_FLAGS.Count; $i++) { $PermissionTable.Add($WBEM_RIGHTS_STRINGS[$i].ToLower(), $WBEM_RIGHTS_FLAGS[$i]) }
  foreach ($Permission in $Permissions) { $AccessMask+=$PermissionTable[$Permission.ToLower()] }

  $ACE=(New-Object System.Management.ManagementClass("Win32_Ace")).CreateInstance()
  $ACE.AccessMask=$AccessMask
  # Do not use $OBJECT_INHERIT_ACE_FLAG.  There are no leaf objects here.
  if ($AllowInherit.IsPresent) { $ACE.AceFlags=$CONTAINER_INHERIT_ACE_FLAG }
  else { $ACE.AceFlags=0 }

  $Trustee=(New-Object System.Management.ManagementClass("Win32_Trustee")).CreateInstance()
  $Trustee.SidString = $Win32Account.SID
  $ACE.Trustee=$Trustee

  if ($Deny.IsPresent) { $ACE.AceType = $ACCESS_DENIED_ACE_TYPE } else { $ACE.AceType = $ACCESS_ALLOWED_ACE_TYPE }
  $ACL.DACL+=$ACE
}
#Remove Operation
else {
  if ($Permissions -ne $null) { Write-Warning "Permissions are ignored for a remove operation" }
  [System.Management.ManagementBaseObject[]]$newDACL = @()
  foreach ($ACE in $ACL.DACL) {
    if ($ACE.Trustee.SidString -ne $Win32Account.SID) { $newDACL+=$ACE }
  }
  $ACL.DACL = $newDACL
}

$SetParams=@{Name="SetSecurityDescriptor"; ArgumentList=$ACL}+$InvokeParams

$output = Invoke-WmiMethod @SetParams
if ($output.ReturnValue -ne 0) { throw "SetSecurityDescriptor failed: $($output.ReturnValue)" }

-1

Мы сделали это для PRTG. Мы создали нового пользователя домена: создали Dit объекта групповой политики, чтобы поместить его в группу «Пользователи журнала Performnce», и использовали сценарий powershell, чтобы добавить этого пользователя в элемент управления WMI. благодаря:

https://live.paloaltonetworks.com/t5/Management-Articles/PowerShell-Script-for-setting-WMI-Permissions-for-User-ID/ta-p/53646


Пожалуйста, включите соответствующую информацию прямо в ваши ответы. Размещенные ответы должны быть в состоянии автономно, и просто использовать ссылки для справки.
Кори Кнутсон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.