Az IRF tárgy keretében nézegettem a Common Information Modelt (CIM) és a Windows Management Instrumentationt (WMI). Egész jó dolgokat lehet lekérdezni belőlük, a gép gyári számától kezdve a feltelepített kodekekig szinte majdnem mindent:). A beépített wmic parancssori eszköz kicsit nehézkes, de a PowerShell Get-WmiObjectjével már könnyen lehet egy-egy lekérdezést megejteni (nagyon jó WMI leírás van a PowerShell könyvben! Ez pedig egy hasznos grafikus lekérdező felület: PowerShell WMI Explorer). Ha már a WMI előkerült, akkor az ahhoz kapcsolódó WS-Management szabványt is megnéztük, amivel CIM alapú rendszereket lehet lekérdezni és menedzselni szabványos, tűzfalbarát módon. És ezzel már el is érkeztünk a Windows Remote Managementhez (WinRM), ami a WSMAN protokollt használja WMI adatok lekérdezéséhez vagy távoli shellhez. [Megjegyzés: azért nem rossz, hogy ahhoz, hogy elmondjuk egy mondatban, hogy mi a WinRM, legalább két másik rövidítést kellett előbb feloldani;-]
Tehát megnéztem a WinRM leírását, és gondoltam kipróbálom gyorsan a laptopom Vistája és egy virtuális gépben futó Vista között. Az MSDN-en lévő leírásban a telepítés elég rövid, főleg tartományi környezetre fókuszál, és valahogy a hitelesítésről szóló részben se találtam meg mindent (pl. a tanúsítvány hitelességéről szóló kapcsoló a TechNeten lévő leírásban van csak benne.). Meglepően részletes viszont a winrm parancs helpje, az winrm help paranccsal elég sok általános leírást is kapunk (remoting, auth…) Pár lépésben viszont azért be lehet állítani, hogy két munkacsoportban lévő gép között is működjön a WinRM
1. WinRM beállítása a célgépen:
winrm quickconfig
Erre elvileg el kéne indítania a szolgáltatást, meg létrehozni egy HTTP figyelőt, azonban nálam nem történt semmi. Nem sikerült rájönnöm, hogy miért, de itt szerencsére megtaláltam, hogy mivel lehet elvégezni ezeket. (Azóta több gépen is csináltam quickconfig-ot, és máshol sehol sem volt ez a gond.)
sc config "WinRM" start= auto net start WinRM winrm create winrm/config/listener?Address=*+Transport=HTTP netsh firewall add portopening TCP 80 "Windows Remote Management"
2. Kapcsolódási kísérlet (identify)
Az id (identify) művelet megnézi, hogy figyel-e a célgép:
winrm id -remote:192.168.127.140
Ez volt az eredmény:
WSManFault Message = The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be us ed or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. You can get more information about that by running the following command : winrm help config. Error number: -2144108316 0x803380E4
A WinRM tartományi környezetben Kerberost használ, munkacsoportos környezetben pedig Negotiate hitelesítési módszerrel próbál áthitelesíteni a bejelentkezett felhasználó vagy a -u és -p kapcsolókkal megadott felhasználó adataival. Ezen kívül meg lehet adni a -r: kapcsolónál, hogy http vagy https szállítási csatornát használjon. A HTTPS listener létrehozásához előbb a célgépnek tanúsítványt kellett volna kiállítani, ezért a TrustedHosts-os megoldás mellett döntöttem:
3. A kliensen a célgép hozzáadása a megbízható gépek listájához
Egy adminisztrátori jogokkal futó parancssorból adjuk ki a következő utasítást:
winrm set winrm/config/client @{TrustedHosts="192.168.127.140"}
4. Újabb kapcsolódási kísérlet
winrm id -remote:192.168.127.140 -u:user Enter the password for 'user' to connect to '192.168.127.140': WSManFault Message = Access is denied. Error number: -2147024891 0x80070005 Access is denied.
Pedig a user felhasználó rendszergazda a távoli gépen. A User Account Control (UAC) miatt még egy lépést meg kellett tenni a célgépen.
5. LocalAccountTokenFilterPolicy megadása
A következő bekezdés segít a probléma megoldásában:
Starting with Windows Vista, User Account Control (UAC) affects access to the WinRM service. When negotiate authentication is used in a workgroup, only the built-in Administrator account can access the service. To allow all accounts in the Administrators group to access the service, set the following registry key to 1 : HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy.
Tehát mivel nem az Administrator felhasználóval akartam csatlakozni, hanem egy másik, de az Administrators csoportban lévő felhasználóval, ezért még ezt engedélyeznem kell (Windows XP-s célgép esetén értelemszerűen erre nincs szükség). Miután beállítottam a megfelelő registry kulcsot, már ment rendesen a kapcsolódás.
A fenti képen például a C: lemez adatait kérdezem le a távoli gép WMI tárából.
A jó hír az, hogy hiába HTTP a szállítási csatorna, a windows integrált hitelesítés (Negotiate) használata esetén a HTTP üzenetek tartalmát titkosítja is az átvitel során:
Ha ezzel megvagyunk, akkor ráadásképpen a távoli parancs-végrehajtásra képes WinRS (Windows Remote Shell) is működik.
Összegezve némi állítgatás után azért könnyedén be lehet élesíteni a WinRM-et, és egész hasznos dolgokat lehet lekérdezni a segítségével.
Érdekes cikket írtál. Vannak-e tapasztalataid “winrm set”-tel?
A.
Szervusz!
Nem nagyon, ami beavatkozást csináltam, azt már inkább valami magasabb szinten írtam meg, pl. PowerShell v2 már tud WinRM-et használó remotingot használni. A WinRM parancssori felülete csak demonstrációs célra kellett, hogy egyáltalán hogyan néz ki ez a technológia.
Micskei Zoltán