Це переклад статті 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 використовує спеціальний провайдер (плагін), запущений під аутентифицироваться користувачем, який звернувся з проханням.
Однак в обох випадках, тільки членам групи локальних Адміністраторів дозволений віддалений доступ. Навіть якщо вам потрібно перевірити стан сервісу або зробити інше непривілейований дію, необхідна аутентифікація під користувачем з групи Адміністраторів. В даному випадку це нагадує роботу адміністративних загальних папок (C $), доступних також тільки Адміністраторам.
Тому для виконання базових віддалених запитів, виникає необхідність дозволу віддаленого підключення через WinRM для звичайних користувачів.
основи WinRM
WinRM є сервісом, запущеним під користувачем NT AUTHORITY # 092; NetworkService. Він приймає запити від клієнтів, аутентіфіцированний через WIA механізми: Negotiate, Kerberos, NTLM або Schannel (TLS сертифікати). На серверних ОС сервіс стартує автоматично, на клієнтських системах його потрібно запустити вручну.
Інформацію про сервіс можна отримати, скориставшись командою:
Варто звернути увагу, що сервіс працює під власним користувачем (SID unrestricted), що означає, що можна визначати права цього користувачеві NT SERVICE # 092; 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) для його запуску.
WinRM реєструє свій / WSMan URI в HTTP.SYS на нестандартному порту (не 80 TCP).
Подивитися зареєстровані в HTTP.SYS URI можна через команду:
Чи означає це, що WinRM доступний віддалено з цього порту? Якщо спробувати відкрити цей порт в брандмауері, то підключитися все одно не вийде. HTTP.SYS дійсно прийме запит прийшов на цей порт, і перенаправляє його до WinRM. WinRM перевірить, чи є клієнт локальним або віддаленим, і якщо клієнт віддалений, то WinRM поверне HTTP помилку зі статусом 404 Not Found. Якщо запит прийшов від локального клієнта, то WinRM його прийме.
Невелике уточнення. Існують два режими роботи WinRM: в режимі Service Hosting Model WinRM використовує власний сервіс для прийняття запитів. Якщо ж запитів стає занадто багато, то можуть виникнути проблеми з доступністю. Тому існує інший режим роботи - через розширення для IIS. Таким чином WinRM стає віртуальною папкою всередині IIS і управляється через IIS (через окремий робочий процес W3SVC). В такому режимі працює Exchange використовуючи WinRM IIS Extension Hosting Model. При запуску віддалених команд, через HTTP.SYS вони потрапляють в віртуальну папку WinRM в IIS на сервері Exchange, і потім в локальний PowerShell.
Пояснення з приводу шифрування. Може здатися, що повідомлення в WinRM передаються нешифрованими оскільки включений тільки HTTP транспорт. Однак це не зовсім так, дійсно TLS шифрування не застосовується, однак самі повідомлення все одно шифруються самим WinRM (параметр AllowUnencrypted = false) ключами, отриманими з методу аутентифікації Windows використовується за умовчанням.
Тепер подивимося на настройки одержувача запитів WinRM:
При наявності сертифіката з ім'ям машини, можна включити HTTPS доступ до WinRM
Що ж таке SDDL. Це контроль доступу до WinRM і його провайдерам. SDDL розшифровується як Security Descriptor Definition Language і являє собою текстовий опис прав доступу до компонентів системи: файлів і папок, реєстру, WMI і самому WinRM.
При прийомі запиту WinRM аутентифікує користувача, визначає права до провайдера, до якого хоче підключитися користувач, і приймає запит тільки в тому випадку, якщо SDDL провайдера дозволяє даному користувачеві підключатися. Якщо у провайдера не вказано власний SDDL, то використовується RootSDDL. Важливо розуміти, що RootSDDL використовується тільки в тому випадку, якщо у провайдера немає свого SDDL.
Розглянемо структуру SDDL:
Нас цікавить секція, що починається з D: P. Вона складається з однієї або декількох записів (Access Control Entry), укладених в круглі дужки. Перша буква в секції може бути A - дозволити, або D - заборонити. Далі йде рівень доступу:
Єдина рядок доступу, дозволяє (A) повний доступ (GA) локальним адміністраторам (BA).
Спробуємо віддалено підключитися до WMI через WinRM під користувачем з цієї групи.
І отримаємо помилку доступу.
Fault
Code
Value = s: Receiver
Subcode
Value = w: InternalError
Reason
Text = The WS-Management service can not 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 can not 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 can not 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
- Додати користувача до групи Remote Management Users
- У налаштуванні прав користувачів в WMI, дати право віддаленого підключення (Remote Enable) групі Remote Management Users
- Додати користувача до групи Remote Management Users