Aceasta este traducerea articolului Ondrej Sevecek despre configurarea accesului la distanță WMI și PowerShell prin intermediul WinRM pentru utilizatorii fără drepturi administrative.
WinRM. numit și WSMan. Aceasta este o tehnologie de control de la distanță, care oferă instrumente cum ar fi WMI, PowerShell, Redirecționarea evenimentelor și chiar administrarea serverului prin HTTP. WinRM acceptă cereri prin intermediul protocolului HTTP sau HTTPS, care apoi trece la furnizorii înregistrați în acesta (plug-in-uri). PowerShell, WMI și redirecționarea evenimentelor sunt înregistrate în WinRM ca furnizori respectivi.
Dacă ați fost dezvoltator al unei aplicații client-server, ați putea crea propriul furnizor (plug-in) pentru WinRM, pe care l-ați putea folosi pentru gestionarea de la distanță a aplicației. Desigur, puteți scrie interfața web DCOM sau HTTP, dar WinRM oferă un cadru de aplicație standard (framework), care facilitează administrarea acestuia.
WinRM acceptă metode autentice de autentificare Windows, cum ar fi Kerberos, Negotiate (inclusiv NTLM) și Schannel (certificate). Deoarece utilizează HTTP convențional, sunt acceptate și metodele de autentificare Basic și Digest.
Puteți configura o interfață specială DCOM pentru a accepta comenzi de la distanță și interogări (WQL) pentru accesul de la distanță la Windows Management Instrumentation (WMI, winmgmt), sau de a folosi WinRM la acest lucru. PowerShell, pe de altă parte, nu are propriul server, astfel încât să primească comenzi de la distanță folosind cmdleturile speciale Enter-PSSession și invocați-comandă, care transmite cereri de protocol WinRM. PowerShell acceptă aceste comenzi, le procesează local și returnează un răspuns folosind protocolul WinRM.
În același mod, lucrează Server Manager (Server Manager) și Redirecționarea evenimentelor. Deși redirecționarea evenimentului are propriul serviciu Windows Event Collector (wecsvc), Microsoft a decis să utilizeze WinRM pentru redirecționarea mesajelor.
În toate cazurile descrise, WinRM utilizează un furnizor special (plug-in), lansat sub un utilizator autentificat care face o solicitare.
Cu toate acestea, în ambele cazuri, numai membrii grupului local de administratori au acces la distanță. Chiar dacă trebuie să verificați starea serviciului sau să efectuați altă acțiune defavorizată, trebuie să vă autentificați sub utilizator din grupul Administrators. În acest caz, aceasta seamănă cu activitatea folderelor publice administrative (C $), care sunt, de asemenea, accesibile numai administratorilor.
Prin urmare, pentru a efectua interogări la distanță de bază, devine necesar să se permită conectarea la distanță prin intermediul WinRM pentru utilizatorii obișnuiți.
Bazele WinRM
WinRM este un serviciu care rulează sub userul NT AUTHORITY # 092; NetworkService. Acceptă solicitări din partea clienților autentificați prin intermediul mecanismelor WIA: Negotiate, Kerberos, NTLM sau Schannel (certificate TLS). La serviciile de servere ale serverului pornește automat, pe sistemele client trebuie să fie pornit manual.
Informații despre serviciu pot fi obținute utilizând comanda:
Este demn de remarcat faptul că serviciul operează sub propriul său utilizator (SID nerestricționat), ceea ce înseamnă că este posibil să se determine drepturile pentru acest utilizator NT SERVICE # 092; winrm.
Anterior a fost menționat că WinRM utilizează protocolul HTTP, dar nu interacționează direct cu cererile HTTP. Acest lucru ar duce la conflicte cu alte servicii web de pe același server, cum ar fi IIS, SQL Reporting Services sau Hyper-V Replication. Prin urmare, WinRM primește cereri HTTP prin driverul de sistem HTTP.SYS, precum și serviciile menționate mai sus.
HTTP.SYS este un driver de kernel care acceptă HTTP și HTTPS cereri de intrare procesate de către unele antete HTTP (în general, gazdă URL-ul Antet), și transmite cererea unuia dintre servere de web care rulează. HTTP.SYS este prezent în sistem, indiferent de IIS, deci atunci când instalați IIS, acesta înregistrează URL-urile sale în HTTP.SYS. Astfel, atunci când HTTP.SYS primește cererea HTTP pentru unul dintre URL-ul IIS înregistrat, acesta transmite la fluxul de lucru piscina W3SVC corespunzătoare în cazul în care o astfel de funcționare, sau accesează Serviciul procesul de activare pentru Windows (a fost) să-l înceapă.
WinRM își înregistrează URI-ul / WSMan în HTTP.SYS pe un port non-standard (nu 80 TCP).
Puteți vizualiza URI-ul înregistrat în HTTP.SYS prin intermediul comenzii:
Acest lucru înseamnă că WinRM este accesibil de la distanță în acest port? Dacă încercați să deschideți acest port în paravanul de protecție, atunci nu vă puteți conecta oricum. HTTP.SYS acceptă într-adevăr cererea care a venit la acest port și îl redirecționează către WinRM. WinRM va verifica dacă clientul este local sau la distanță și dacă clientul este la distanță, WinRM va returna o eroare HTTP cu starea 404 Not Found. Dacă cererea vine de la clientul local, WinRM o va accepta.
O mică clarificare. Există două moduri de funcționare WinRM: în modelul Service Hosting, WinRM utilizează propriul serviciu pentru a accepta cererile. Dacă există prea multe solicitări, atunci pot apărea probleme de disponibilitate. Prin urmare, există un alt mod de funcționare - printr-o extensie pentru IIS. În acest fel, WinRM devine un folder virtual în interiorul IIS și este gestionat prin IIS (printr-un flux de lucru separat W3SVC). În acest mod, Exchange rulează utilizând modelul WinRM IIS Extension Hosting. Când comenzile de la distanță sunt executate prin HTTP.SYS, ele intră în folderul virtual WinRM din IIS de pe serverul Exchange și apoi în PowerShell local.
Explicarea criptării. Se pare că mesajele din WinRM sunt transmise necriptate, deoarece este activat numai transportul HTTP. Cu toate acestea, acest lucru nu este adevărat, într-adevăr criptarea TLS nu este folosit, dar mesajul real este încă criptat de WinRM cheie (parametrul AllowUnencrypted = fals) obținut din metoda de autentificare pentru Windows implicit.
Acum, uita-te la setările destinatarului cererii WinRM:
Dacă aveți un certificat cu numele mașinii, puteți activa accesul HTTPS la WinRM
Ce este SDDL? Acesta este controlul accesului la WinRM și la furnizorii săi. SDDL reprezintă limba de definire a descriptorilor de securitate și este o descriere text a drepturilor de acces la componentele sistemului: fișiere și foldere, registru, WMI și WinRM în sine.
La primirea unei cereri WinRM autentifică utilizatorul, determină dreptul furnizorului de la care utilizatorul dorește să se conecteze la, și acceptă cererea numai în cazul permisă de SDDL acestui utilizator să se conecteze. Dacă furnizorul nu are propriul SDDL, atunci RootSDDL este utilizat. Este important să înțelegeți că RootSDDL este utilizat numai dacă furnizorul nu are propriul SDDL.
Luați în considerare structura SDDL:
Suntem interesați de secțiunea care începe cu D: P. Se compune din una sau mai multe intrări (Access Control Entry), închise în paranteze. Prima literă din secțiune poate fi A-resolve sau D-prohibit. Urmează nivelul de acces:
Singura linie de acces permite (A) accesul complet (GA) la administratorii locali (BA).
Să încercăm să conectăm de la distanță la WMI prin WinRM sub utilizatorul din acest grup.
Și avem o eroare de acces.
eroare
cod
Valoare = s: Receiver
subcod
Valoare = w: InternalError
motiv
Text = Serviciul WS-Management nu poate procesa cererea. Serviciul WMI a returnat o eroare de acces refuzată.
detaliu
MSFT_WmiError
CIMStatusCode = 2
CIMStatusCodeDescription = null
ErrorSource = null
ErrorSourceFormat = 0
ErrorType = 0
Mesaj = Serviciul WS-Management nu poate procesa cererea. Serviciul WMI a returnat o eroare de acces refuzată.
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 = Serviciul WS-Management nu poate procesa cererea. Serviciul WMI a returnat o eroare de acces refuzată.
Număr eroare: -2147023537 0x8007054F
A apărut o eroare internă.
A avut loc conexiunea WinRM, permisiunea WMI SDDL a permis accesul, însă WMI a refuzat accesul.
Vizualizator de evenimente
Aplicații și jurnale de service
Microsoft
Windows Remote Management
butonul de mouse dreapta Afișați - afișați jurnalele de analiză și depanare
dați clic dreapta pe Analiză - Activați jurnalul
- Conectarea la WinRM
Utilizator. autentificat cu succes folosind autentificarea Kerberos
Autorizarea utilizatorului
Actualizarea cotei pentru utilizator
Autorizarea utilizatorului - Conectarea la furnizorul WMI în WinRM
Primirea SOAP de ascultător
Prelucrarea solicitării clientului pentru operația GET
Serviciul WinRM încărcat următorul plugin: WMI Provider (WsmWmiPl.dll)
Introducerea plugin-ului pentru operare.
Autorizarea utilizatorului - În cele din urmă, conectați-vă la WMI în sine
Plugin obiect de date de raportare pentru funcționare Obțineți
Transmiterea SOAP de ascultător
Funcția de raportare a pluginurilor este completă pentru Get
- Adăugați utilizator la grupul de utilizatori gestionați la distanță
- În configurarea drepturilor utilizatorilor în WMI, acordați permisiunea de activare la distanță pentru grupul de utilizatori la distanță
- Adăugați utilizator la grupul de utilizatori gestionați la distanță
Articole similare
Trimiteți-le prietenilor: