ПредишенСледващото

Този превод на статията Ондржей Sevecek за конфигурирането на отдалечен достъп WMI и PowerShell протокол WinRM за потребители, които не администратор.

WinRM. наричан също WSMan. Това дистанционно технология за контрол, която предвижда такива средства като WMI, PowerShell, Събитие Forwarding (Event Forwarding) и дори Server Manager (Мениджър сървър) Трафикът през HTTP. WinRM получава искания за HTTP или HTTPS протокол, който след това се предава, вписани в него доставчици (приставки). PowerShell, WMI и насочват събития са регистрирани в съответните доставчици WinRM.

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

WinRM поддържа методи Integrated Windows удостоверяване, като Kerberos, Преговаря (включително NTLM) и Schannel (сертификати). Тъй като тя използва редовно HTTP, тя също така подкрепя Основни и Digest методи за удостоверяване.

Можете да конфигурирате специален DCOM интерфейс да приеме отдалечени команди и заявки (WQL) за отдалечен достъп до инструменти за управление на Windows (WMI, winmgmt), или да се използва WinRM за това. PowerShell, от друга страна, не разполага със собствен сървър, така че да получи отдалечени команди с помощта на специални кратки команди Въведете-PSSession и се позове и управление, които предават исканията за WinRM протокол. PowerShell получава тези команди, да ги обработва на местно ниво, и връща отговор на WinRM протокол.

По същия начин работи мениджъра на сървър (Мениджър сървър) и насочват събитието (Event Forwarding). Въпреки, че пренасочването на събитията, там е услуга Windows Event Collector (wecsvc), но Microsoft реши да използва WinRM за съобщения.

Във всеки случай, WinRM използва специален доставчик (плъгин), започната в рамките на удостоверен потребител, отправил искането.

Въпреки това, и в двата случая, само членовете на групата локални администратори се предоставят отдалечен достъп. Дори ако трябва да проверите състоянието на услугата или да извърши друго не-привилегирован операция, удостоверяване се изисква от потребителя от групата на администраторите. В този случай, той напомня за работата на административните акции (C $), също са достъпни само за администратори.

Ето защо, за да изпълняват основни отдалечени заявки, е необходимо да се даде възможност на отдалечените връзки чрез WinRM за обикновените потребители.

Основи на WinRM

WinRM е работеща в NT ОРГАН # 092; NETWORKSERVICE. Той приема заявки от клиенти удостоверени чрез механизми WIA: Договаряне, Kerberos, NTLM или Schannel (TLS сертификати). На сървър с услугата започва автоматично, относно системите за клиента е необходимо да я стартирате ръчно.

Информация за услугата може да се получи с помощта на следната команда:

Заслужава да се отбележи, че услугата се изпълнява под собственото си потребител (SID неограничен), което означава, че може да се определи правото на този потребител NT SERVICE # 092; WinRM.

По-горе споменахме, че WinRM използва протокола HTTP, но това не се отразява пряко взаимодействат с исканията за HTTP. Това ще доведе до конфликти с други уеб услуги на същия сървър, като например IIS, SQL Докладване Услуги или Hyper-V репликация. Ето защо, WinRM получава искания HTTP чрез драйвера на HTTP.SYS система, както и услугите, посочени по-горе.

HTTP.SYS е шофьор на ядрото, който приема входящи HTTP и HTTPS заявки се обработват от някои HTTP хедъри (обикновено домакин Header URL), и изпраща по искане на една от поддръжка на уеб сървъри. HTTP.SYS присъства в системата, независимо от IIS, така че, когато инсталирате IIS, тя регистрира URL в HTTP.SYS. По този начин, когато HTTP.SYS получава заявката HTTP за един от регистриран IIS URL адреса, той го предава на съответния работен процес W3SVC басейна, ако такова движение, или има достъп до услугата за активиране на процеса на Windows (WAS), за да я стартирате.

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

Вижте регистрирано в HTTP.SYS URI е възможно чрез командата:

Означава ли това, че WinRM е достъпно отдалечено към този порт? Ако се опитате да отворите този порт в защитната стена, след което свържете все още не работи. HTTP.SYS наистина ще поиска стигна до този порт и го пренасочва към WinRM. WinRM провери дали клиентът е локален или отдалечен, и ако клиентът е отдалечена във времето, а след това на WinRM извежда грешка HTTP със статут 404 Не е намерено. Ако искането идва от локален клиент, WinRM го приема.

Малко пояснение. Има два режима на работа: WinRM в услуга хостинг режим Модел WinRM използва собствен сервиз да приема заявки. Ако искането е твърде много, това може да доведе до проблеми с достъпността. Поради това, има и друг режим на работа - чрез разширяване на IIS. По този начин става WinRM виртуална папка в рамките на IIS и контролира чрез IIS (чрез отделен поток W3SVC). В този режим, обменно работи с помощта на WinRM IIS Extension хостинг модел. Когато стартирате отдалечени команди чрез HTTP.SYS те попадат във виртуална папка в IIS WinRM на сървъра Exchange, а след това на местен PowerShell.

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

Сега погледнете настройките на заявките за получател WinRM:

Ако има сертификат с името на машината, можете да активирате HTTPS достъп до WinRM

Какво е SDDL. Тя контролира достъпа до WinRM и нейните доставчици. SDDL щандове за сигурност Descriptor Определение език и е текстов описание на правата за достъп до компонентите на системата: файлове и папки, на системния регистър, WMI, и най-WinRM.
Когато получи искане WinRM идентифицира потребителя, определя правото на доставчика, до които потребителят иска да се свърже с и приемане на заявлението, само ако позволява SDDL доставчик на този потребител да се свърже. Ако доставчикът не се посочва по избор SDDL, тя се използва RootSDDL. Важно е да се разбере, че RootSDDL използва само ако доставчикът не разполага със SDDL.

Да разгледаме структурата на SDDL:

Ние сме заинтересовани в раздел започва с D: П. Тя се състои от един или повече записи (Access Control запис), поставени в скоби. Първата буква в раздел може да бъде - да разрешавате или D - забрана. Тогава там е на ниво на достъп:

достъп на единична линия, което позволява на (А) пълен достъп (GA) местни администратори (BA).

Нека се опитаме да се свърже дистанционно да WMI чрез WinRM от потребителя от тази група.

И се получи грешка достъп.
вина
код
Стойност = S: приемник
Подкод
Стойност = w: InternalError
причина
Текст = услугата WS-управление не може да обработи заявката. Услугата WMI върна "отказан достъп" грешка.

детайл
MSFT_WmiError
CIMStatusCode = 2
CIMStatusCodeDescription = нула
ErrorSource = нула
ErrorSourceFormat = 0
Фиктивната = 0
Съобщението = услугата WS-управление не може да обработи заявката. Услугата WMI върна "отказан достъп" грешка.
MessageID = HRESULT 0x80338104
OtherErrorSourceFormat = нула
OtherErrorType = нула
OwningEntity = нула
PerceivedSeverity = 0
ProbableCause = 0
ProbableCauseDescription = нула
error_Category = 18
ERROR_CODE = 2150859012
ERROR_TYPE = HRESULT
error_WindowsErrorMessage = услугата WS-управление не може да обработи заявката. Услугата WMI върна "отказан достъп" грешка.

Номер на грешката: -2147023537 0x8007054F
Възникна вътрешна грешка.

Връзка WinRM случи, доставчикът на SDDL WMI разрешен достъп, но WMI отказан достъп.

Преглед на събитията
Приложения и услуги Регистри
Microsoft
Дистанционно управление на Windows
кликнете с десния бутон View - Show Аналитична и Debug Logs
кликнете с десния бутон Аналитична - Активиране Вход

  • Свързване с WinRM
    Потребител. удостоверен успешно използване на Kerberos удостоверяване
    Упълномощаване на потребителя
    Обновяване на квота за потребителя
    Разрешението на потребителя е направено успешно
  • Свързване с доставчик WMI в WinRM
    SOAP слушател приемната
    Обработка на заявката на клиента за работа GET
    Услугата WinRM зареди следната приставка: WMI Provider (WsmWmiPl.dll)
    Въвеждане на плъгин за работа Спечелете с Resource URI на.
    Упълномощаване на потребителя
  • Накрая връзка с WMI
    Plug-in за отчитане на данни на обект за операцията Get
    SOAP слушател изпращане
    Plug-in за работа отчитане пълен за Get
  1. Добавяне на потребител в отдалечените потребители Мениджмънт Груп
  2. правата на потребителите, настройка на WMI, за да даде правото на дистанционно свързване (Remote активиране) групови отдалечените потребители за управление
    Отдалечен достъп и PowerShell WMI за neadministratorv, gamelton - с блог
  1. Добавяне на потребител в отдалечените потребители Мениджмънт Груп

Свързани статии

Подкрепете проекта - споделете линка, благодаря!