Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу 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
Стоит обратить внимание, что сервис работает под собственным пользователем (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.
После 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? Это контроль доступа к 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
