Удаленный доступ по WMI и PowerShell для неадминистраторв

Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу WinRM для пользователей без прав администратора.

WinRM

WinRM, также называемый WSMan, это технология удаленного управления, которая предоставляет для таких средств как WMI, PowerShell, Перенаправление событий (Event Forwarding) и даже Диспетчер сервера (Server Manager) транспорт по протоколу HTTP. WinRM принимает запросы по HTTP или HTTPS протоколу, которые затем передает зарегистрированным в нем провайдерам (плагинам). PowerShell, WMI и Перенаправление событий зарегистрированы в WinRM как соответствующие провайдеры.

Если бы вы были разработчиком клиент-серверного приложения, то вы могли бы создать свой провайдер (плагин) для WinRM, который можно было бы использовать для удаленного управления вашим приложением. Конечно можно и самому написать DCOM или HTTP веб-интерфейс, но WinRM предоставляет стандартный каркас приложения (фреймворк), что облегчает его администрирование.

WinRM поддерживает методы встроенной аутентификации Windows, такие как

Kerberos
Negotiate (включая NTLM)
Schannel (сертификаты)

Поскольку он использует обычный HTTP, то поддерживаются также методы аутентификации

Basic
Digest

Для удаленного доступа к инструментарию управления Windows (WMI, winmgmt) можно настроить специальный DCOM интерфейс на прием удаленных команд и запросов (WQL), или же использовать WinRM для этого. PowerShell, с другой стороны, не имеет своего собственного сервера, поэтому для приема удаленных команд используются специальные командлеты Enter-PSSession и Invoke-Command, которые передают запросы по WinRM протоколу. PowerShell принимает эти команды, обрабатывает их локально и возвращает ответ по протоколу WinRM.

Таким же образом работает Диспетчер сервера (Server Manager) и Перенаправление событий (Event Forwarding). Хотя у перенаправления событий, есть свой сервис Windows Event Collector (wecsvc), но Microsoft решила использовать WinRM для пересылки сообщений.

Во всех описанных случаях WinRM использует специальный провайдер (плагин), запущенный под аутентифицированным пользователем, делающим запрос.

По умолчанию WinRM запрещает удаленный доступ на системах Windows 2008 R2 и старше. Но его можно включить командой

winrm quickconfig

Начиная с Windows 2012, WinRM разрешает удаленное подключение для аутентифицированных HTTP запросов.

Однако в обоих случаях, только членам группы локальных Администраторов разрешен удаленный доступ. Даже если вам нужно проверить состояние сервиса или совершить другое непривилегированное действие, необходима аутентификация под пользователем из группы Администраторов. В данном случае это напоминает работу административных общих папок (C$), доступных также только Администраторам.

Поэтому для выполнения базовых удаленных запросов, возникает необходимость разрешения удаленного подключения через WinRM для обычных пользователей.

Дальше будет рассмотрена настройка WinRM 2.0 (входящего в Windows 7 и 2008R2 в составе Windows Management Framework 2.0) и WinRM 3.0 (входящего в Windows 8 и 2012 в WMF 3.0).

Основы WinRM

WinRM является сервисом, запущенным под пользователем NT AUTHORITY\NetworkService. Он принимает запросы от клиентов, аутентифицированных через WIA механизмы:

Negotiate
Kerberos
NTLM
Schannel (TLS сертификаты)

На серверных ОС сервис стартует автоматически, на клиентских системах его нужно запустить вручную.

Информацию о сервисе можно получить, воспользовавшись командой:

C:\sc query winrm

SERVICE\NAME: winrm
        STATE              : 4  RUNNING

C:\sc qc WinRM

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: winrm
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Windows\System32\svchost.exe -k NetworkService
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Remote Management (WS-Management)
        DEPENDENCIES       : RPCSS
                           : HTTP
        SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\sc qsidtype winrm

[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: winrm
SERVICE_SID_TYPE:  UNRESTRICTED

HTTP.SYS

Стоит обратить внимание, что сервис работает под собственным пользователем (SID unrestricted), что означает, что можно определять права этому пользователю NT SERVICE\winrm.

Ранее упоминалось, что WinRM использует HTTP протокол, однако напрямую он не взаимодействует с HTTP запросами. Это привело бы к конфликтам с другими веб-сервисами на том же сервере, такими как IIS, SQL Reporting Services или Hyper-V Replication. Поэтому WinRM получает HTTP запросы через системный драйвер HTTP.SYS, также, как и сервисы, указанные выше.

HTTP.SYS это драйвер ядра, который принимает входящий HTTP и HTTPS запрос, обрабатывает некоторые HTTP заголовки (обычно Host Header URL) и перенаправляет запрос к одному из запущенных веб-серверов. HTTP.SYS присутствует в системе независимо от IIS, поэтому когда вы устанавливаете IIS, он регистрирует свои URL в HTTP.SYS. Таким образом, когда HTTP.SYS получает HTTP запрос для одного из зарегистрированных в IIS URL, то он передает его соответствующему рабочему процессу W3SVC пула, если такой запущен, или обращается к Windows Process Activation Service (WAS) для его запуска.

По этой же причине, SQL Server Reporting Services не использует IIS. Он регистрирует свой URL в HTTP.SYS по адресу /Reports и /ReportServer. Другими пользователями HTTP.SYS являются:

SSTP VPN сервер (с URL /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75})
IPHTTPS сервер (с URL /IPHTTPS)

WinRM регистрирует свой /WSMan URI в HTTP.SYS на нестандартном порту (не 80 TCP).

Посмотреть зарегистрированные в HTTP.SYS URI можно через команду:

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000320000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000340000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 1
            Registered URLs:
                HTTP://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            152

Вывод команды показывает настройку WinRM по умолчанию в системе Windows 2008R2. WinRM регистрирует URI /WSMan и привязывает его к порту TCP 47001. Можно посмотреть, что порт действительно прослушивается:

C:\netstat -ano | findstr :47001

  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    \[::\]:47001             \[::\]:0                 LISTENING       4

Означает ли это, что WinRM доступен удаленно по этому порту? Если попробовать открыть этот порт в брандмауэре, то подключиться все равно не получится. HTTP.SYS действительно примет запрос пришедший на этот порт, и перенаправит его к WinRM. WinRM проверит, является ли клиент локальным или удаленным, и если клиент удаленный, то WinRM вернет HTTP ошибку со статусом 404 Not Found. Если запрос пришел от локального клиента, то WinRM его примет.

Удалённое подключение

Как было сказано ранее, Windows 2012 принимает по умолчанию удаленные подключения WinRM (параметр AllowRemoteAccess = true в выводе команды ниже). Для удаленных запросов WinRM использует порт TCP 5985, при этом порт 47001 также продолжает прослушиваться. Помимо автоматического запуска сервиса, в брандмауэре открыт доступ на этот порт.

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000120000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000140000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 2
            Registered URLs:
                HTTP://+:5985/WSMAN/
                HTTP://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            960

Небольшое уточнение. Существуют два режима работы WinRM:

в режиме Service Hosting Model WinRM использует собственный сервис для принятия запросов. Если же запросов становится слишком много, то могут возникнуть проблемы с доступностью. Поэтому существует другой режим работы
через расширение для IIS. Таким образом WinRM становится виртуальной папкой внутри IIS и управляется через IIS (через отдельный рабочий процесс W3SVC). В таком режиме работает Exchange используя WinRM IIS Extension Hosting Model. При запуске удаленных команд, через HTTP.SYS они попадают в виртуальную папку WinRM в IIS на сервере Exchange, и затем в локальный PowerShell.

Настройки WinRM

После HTTP.SYS конфигурации, настало время посмотреть настройки WinRM. Сделать это можно через команду WINRM. Ниже приведены настройки по умолчанию в системе Windows 2008R2:

C:\winrm get winrm/config

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = \*
        IPv6Filter = \*
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5

Настройки в Windows 2012 немного отличаются правами в RootSDDL:

Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 1500
        EnumerationTimeoutms = 240000
        MaxConnections = 300
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = \*
        IPv6Filter = \*
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
        AllowRemoteAccess = true
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 7200000
        MaxConcurrentUsers = 10
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 25
        MaxMemoryPerShellMB = 1024
        MaxShellsPerUser = 30

Стоит обратить внимание на настройку портов по умолчанию (DefaultPorts). Она отвечает только за то на каких портах будет прослушивать WinRM при включении удаленного доступа. Но сам удаленный доступ выключен по умолчанию на Windows 2008R2 и включен только для HTTP в Windows 2012.

Пояснение по поводу шифрования. Может показаться, что сообщения в WinRM передаются нешифрованными поскольку включен только HTTP транспорт. Однако это не совсем так, действительно TLS шифрование не применяется, однако сами сообщения все равно шифруются самим WinRM (параметр AllowUnencrypted = false) ключами, полученными из метода аутентификации Windows используемого по умолчанию.

Теперь посмотрим на настройки получателя запросов WinRM:

C:\winrm enumerate winrm/config/listener

Listener
    Address = \*
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.10.0.12

При наличии сертификата с именем машины, можно включить HTTPS доступ к WinRM

winrm create winrm/config/listener?Address=\*+Transport=HTTPS @{Port="5986"}

Плагины

Как упоминалась ранее, WinRM поддерживает плагины для поддержки удаленного доступа к различным приложениям. Посмотреть список зарегистрированных плагинов (DLL) можно командой WINRM, ниже представлен вывод для системы Windows 2008R2:

C:\winrm enumerate winrm/config/plugin -format:pretty

 Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.servermanager (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.servermanager
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 URI: http://schemas.dmtf.org/wbem/wscim/1/\*

Для системы Windows 2012 количество плагинов отличается, также обратите внимание на права в SDDL:

Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell.workflow (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell.workflow
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell32 (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell32
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.windows.servermanagementworkflows (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.windows.servermanagerworkflows
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/\*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/cim-xml/2/cim-schema/2/\*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

У WMI провайдера в Windows 2012 появился свой SDDL, когда провайдер не имеет своего SDDL он использует RootSDDL, который мы видели ранее в выводе команды winrm get winrm/config.

SDDL

Что же такое SDDL? Это контроль доступа к WinRM и его провайдерам. SDDL расшифровывается как Security Descriptor Definition Language и представляет собой текстовое описание прав доступа к компонентам системы: файлам и папкам, реестру, WMI и самому WinRM. При приеме запроса WinRM аутентифицирует пользователя, определяет права к провайдеру, к которому хочет подключиться пользователь, и принимает запрос только в том случае, если SDDL провайдера разрешает данному пользователю подключаться. Если у провайдера не указан собственный SDDL, то используется RootSDDL. Важно понимать, что RootSDDL используется только в том случае, если у провайдера нет своего SDDL.

Рассмотрим структуру SDDL:

O:<владелец>D:P<разрешение>S:P<аудит>

Нас интересует секция, начинающаяся с D:P. Она состоит из одной или нескольких записей (Access Control Entry), заключенных в круглые скобки. Первая буква в секции может быть

A - разрешить
D - запретить

Дальше идет уровень доступа:

Сокращение	Полное название
`GA`	Generic All (Full Control)
`GR`	Generic Read
`GW`	Generic Write
`GX`	Generic Execute

И последним идет идентификатор пользователя или группы (SID):

Сокращение	Полное название
`BA`	BUILTIN\Administrators
`WD`	Everyone
`ER`	BUILTIN\Event Log Readers
`IU`	NT AUTHORITY\Interactive
`RM`	BUILTIN\Remote Management Users
`S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000`	WinRMRemoteWMIUsers__

Удалённый доступ

Рассмотрим RootSDDL в Windows 2008R2, который применяется к WMI, поскольку у него нет своего SDDL:

O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

Единственна строчка доступа, позволяет (A) полный доступ (GA) локальным администраторам (BA).

В Windows 2012 WMI использует собственную SDDL:

O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

Она состоит из четырех записей доступа. Первая запись, такая же как в Windows 2008R2, вторая для интерактивных пользователей. А вот третья позволяет (A) полный доступ (GA) локальной группе удаленных пользователей (RM - Remote Management Users). Четвертая запись использует конкретный SID от группы WinRMRemoteWmiUsers__. Таким образом может показаться, что достаточно пользователя добавить в группу Remote Management Users или WinRMRemoteWMIUsers__ , что позволит удаленно обращаться к WMI. Но это не совсем так.

Попробуем удаленно подключиться к WMI через WinRM под пользователем из этой группы.

winrm get wmicimv2/Win32_Service?Name=spooler –remote:srv-data1

И получим ошибку доступа. Fault Code Value = s:Receiver Subcode Value = w:InternalError Reason Text = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error.

Detail MSFT_WmiError CIMStatusCode = 2 CIMStatusCodeDescription = null ErrorSource = null ErrorSourceFormat = 0 ErrorType = 0 Message = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. MessageID = HRESULT 0x80338104 OtherErrorSourceFormat = null OtherErrorType = null OwningEntity = null PerceivedSeverity = 0 ProbableCause = 0 ProbableCauseDescription = null error_Category = 18 error_Code = 2150859012 error_Type = HRESULT error_WindowsErrorMessage = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. Error number: -2147023537 0x8007054F An internal error occurred.

Подключение по WinRM произошло, SDDL провайдера WMI разрешил доступ, но сам WMI запретил доступ.

Заглянув в Просмотр событий, можно увидеть следующее:

Event Viewer Application and Service Logs Microsoft Windows Remote Management правая кнопка мыши View - Show Analytic and Debug Logs правая кнопка мыши Analytic - Enable Log

Подключение к WinRM User ... authenticated successfuly using Kerberos authentication Authorizing the user Updating quota for the user The authorization of the user was done successfully
Подключение к WMI провайдеру в WinRM SOAP listener receiving Processing client request for operation GET The WinRM service loaded the following plugin: WMI Provider (WsmWmiPl.dll) Entering plugin for operation Get with Resource URI of ... Authorizing the user
И наконец подключение к самому WMI Plugin reporting data object for operation Get SOAP listener sending Plugin reporting operation complete for Get

Удалённый доступ для обычный пользователей

Для того чтобы предоставить удаленный доступ к WMI для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users
В настройке прав пользователей в WMI, дать право удаленного подключения (Remote Enable) группе Remote Management Users

Для того чтобы предоставить удаленный доступ к PowerShell для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users