Это перевод статьи 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