Dneska se podívám detailně na to, jak funguje Windows Remote Management (WinRM, neboli také WSMan) a prozkoumáme jaké je jeho zabezpečení. WinRM se používá pro vzdálenou správu počítačů, jak pomocí dalších technologií, jako je WMI (Windows Management Instrumentation), Server Manager nebo PowerShell, nebo i třeba technologie pro sběr událostí Event Forwarding.
Znamená to, že WinRM/WSMan je taková společná přenosová technologie, přes kterou se dá přistupovat například k WMI, nebo PowerShell běžícímu na vzdáleném počítači. Prostě místo toho, abyste se na WMI připojovali přes jeho normální protokol DCOM, tak se tam připojíte přes WinRM a ono to pak chodí do WMI už jenom lokálně. PowerShell žádný DCOM sám od sebe nemá, takže v jeho případě je to ještě logičtější řešení.
Proč byste dělali takové harakiry, když se tam můžete dostat rovnou na DCOM? Možná, že právě nemůžete. DCOM používá dynamické porty. Zatímco WinRM se přenáší přes HTTP, nebo dokonce zašifrovaně přes HTTPS, umí procházet přes HTTP proxy, a je to prostě mnohem jednodušší protokol, než DCOM.
I z toho důvodu tento transport používá pro vzdálený PowerShell (PowerShell Remoting) a třeba sběr událostí z prohlížeče událostí (event forwarding).
Zdá se, že to je tedy technologie budoucnosti. Tak se pojďme podívat jak to vlastně funguje. Jedna věc co nás zajímá moooc je také to, jak se na vzdálený počítač připojit jako obyčejný uživatel, člen maximálně tak různých ne-administrátorských skupin (non-admin). Jasně, když děláte vzdálenou správu, tak je obvyklé, že máte přihlašovací údaje na člena Administrators na to vzdáleném počítači. Jenže ne vždycky. V citlivě zabezpečených prostředích, s jakými se setkávám já, je tohle velmi často problém.
V dalším se budeme zabývat pouze WinRM 2.0, které je přímo ve výbavě Windows 7 a Windows Server 2008 R2 a do ostatních systémů se dá stáhnout odsud. Existuje i novější WinRM 3.0, to máte rovnou na Windows 8 a Windows Server 2012. Taky lze stáhnout do starších operačních systémů, ale nedělejte to.
Nejprve nějaké vnitřnosti WinRM na straně serveru
WinRM je služba, která se i přesně takto jmenuje. Běží jako NT AUTHORITH\NetworkService, takže může přijímat ověřené vzdálené uživatele. Umí přijímat jak normální Windows ověření (Negotiate, Kerberos, NTLM), tak i ověřování pomocí klientského TLS certifikátu (Schannel), ale i standardní Basic a Digest autentizace. On je to totiž vlastně web server. Na serverových edicích Windows je služba startována automaticky i ve výchozím stavu, na stanicích je nastavena na Manual.
Pro úplnost, parametry služby si vypíšete pomocí příkazu SC a jeho parametrů QUERY, QC a QSIDTYPE takto:
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
Lépe řečeno, jedná se o webovou HTTP SOAP službu (web service), která využívá zabudovaný HTTP.SYS driver, stejně jako IIS, nebo jako další takové služby - například SQL Reporting Services, nebo SSTP VPN server. Mohla by tedy pracovat normálně na portu TCP 80, kdybyste si ji tak nastavili. A dokonce k tomu ani IIS nepotřebujete. On je ten HTTP.SYS driver v jádře ve výchozí instalaci operačního systému a není potřeba vůbec instalovat IIS.
HTTP.SYS je ten, kdo přijímá HTTP a HTTPS požadavky a rozděluje je podle čísla portu a URI (tedy té části URL, která je za lomítkem) do jednotlivých web service - podívejte se v mém předchozím článku, v tabulečce je to pěkně seřazené. WinRM služba prostě očekává požadavky na URI /WSMan.
Pokud chcete, můžete se rovnou podívat, na nějakém WinRM serveru, jaké URI má vůbec váš HTTP.SYS registrovány. Použije se příkaz NETSH HTTP SHOW SERVICESTATE - v následujícím výpisu je čistá instalace Windows 2008 R2:
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
Jak zřejmě vidíte v přechozím výpisu, je tam skutečně registrován WSMan. Číslo procesu (process ID) služby WinRM je vidět úplně dole v položce Process IDs. Ano, ve výchozím stavu WinRM poslouchá na portu 47001. Můžete si i ověřit, že je ten port skutečně otevřený pomocí NETSTAT:
C:\netstat -ano | findstr :47001
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4
TCP [::]:47001 [::]:0 LISTENING 4
A sakra. Znamená to snad, že je WinRM dostupné vzdáleně automaticky po instalaci? Ne. Ten port je jen pro lokální přístup. WinRM na něm nepřijímá požadavky z jiných počítačů ze sítě. On ten port je sice skutečně dostupný přes síť (pokud byste udělali výjimku ve firewallu), HTTP.SYS na něm opravdu požadavky přijímá, ale WinRM na ně vrací HTTP error 404 Not Found. Tento port se používá jen při přístupu sama na sebe ze stejného počítače. Navíc windows firewall pro něho nemá ani výjimku. Takže to je bezpečné.
Na Windows 2012 je tomu už ale jinak. Ten nový Server Manager silně podporuje vzdálenou správu, a tak je WinRM automaticky zpřístupněno i ze sítě. To ale už poslouchá na jiném portu. Na portu TCP 5985. V následujícím výpisu uvidíte tedy oba dva porty TCP 47001 i TCP 5985. Takhle je to výchozí na Windows 2012:
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
Vadí to? Mě jo, ale jinak ne zase až tak moc. Port 5985 vyžaduje ve výchozím stavu Kerberos, nebo Negotiate (tedy i NTLM) ověření. Takže to je i tak docela pojištěné (tedy asi tak stejně, jako admin share).
Odbočka - ještě bych měl pro úplnost zmínit, že to není jediná možnost, jak provozovat serverovou stranu WinRM. Ještě si můžete taky nainstalovat do IIS rozšíření zvané WinRM Extension. To dělá třeba Exchange kvůli vzdálenému přístupu na svoje PowerShell příkazy. Místo aby jste chodili přímo do té WinRM služby, chodíte oklikou do IIS. V IIS tak ale může být nějaký komplikovanější ASP.NET web service, lépe se tomu škáluje výkon a podobné nesmysly. Pokud byste měli to IIS WinRM Extension, tak se to jmenuje přesně WinRM IIS Extension Hosting Model. Pro nás je ale podstatný ten jednoduchý model zvaný WinRM Service Hosting Model.
Když už rozumíme transportu, pojďme se podívat na službu WinRM detailněji. Nejprve si vypišmě konfiguraci služby. Tohle je výpis výchozí konfigurace na Windows 2008 R2:
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
A na Windows 2012 je jen nepatrná změna, hlavně v položce RootSDDL (vydržte, vysvětlíme později):
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
Ve výpisu výchozích nastavení obou operačních systémů vidíte položku DefaultPorts. Jak jsem říkal, na Windows 2008 to stejně na nich neposlouchá. Jedná se jen o výchozí předvolbu. Na to, aby se dalo na WinRM vůbec připojit vzdáleně, musí tam být ještě nějaký tzv. listener.
Následuje výpis z Windows 2012, kde takový listener existuje automaticky hned po instalaci. Na Windows 2008 R2 byste si ho mohli nechat jednoduše vytvořit pomocí příkazu winrm qc:
C:\winrm enumerate winrm/config/listener
Listener
Address = *
Transport = HTTP
Port = 5985
Hostname
Enabled = true
URLPrefix = wsman
CertificateThumbprint
ListeningOn = 10.10.0.12
Ještě jednou - pokud chcete vzdálený přístup na Windows 2008 R2 a starší, musíte si přidat listener. Jednoduše se to udělá pomocí winrm qc. Nebo složitěji pomocí příkladu i pro HTTPS a vlastní číslo portu (to byste ale museli mít certifikát):
winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Port="30000"}
Opakování - takže pokud máte listener, bude vidět registrace i v HTTP.SYS a váš WinRM server bude dostupný ze sítě. Jo, nesmíte zapomenout na výjimku ve firewallu.
Teďka něco o pludžinech
WinRM je jenom takový hostitel různých služeb pro vzdálenou správu - jak jsme říkali, WMI, PowerShell, event forwarding, server manager apod. Je to udělané úplně obecně. Kdybyste třeba vyvýjeli svoje vlastní účetnictví, mohli byste si udělat plug-in (provider) do WinRM a váš účetní server by se dal vzdáleně spravovat.
Každý WinRM provider plug-in je DLL. Musí být registrován do WinRM a lze to taky vypsat. Následuje výpis - zjednodušený - pro Windows 2008 R2:
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/*
Na Windows 2012 to vypadá trošku jinak. Je jich tam víč a mají občas jiné 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)
Hlavně si všimněte rozdílu u plug-inu WMI Provider. Na Windows 2012 má svoje vlastní SDDL, zatímco na Windows 2008 R2 nemá žádné SDDL. Pokud nějaký provider nemá vlastní SDDL, používá to RootSDDL, které jste viděli v předchozím výpisu winrm get winrm/config.
Co je to sakra to SDDL a jak se vlastně řídí přístup k WinRM?
To je to, co kontroluje přístup. Security Descriptor Definition Language. Tedy textový zápis popisovačů zabezpečení - security descriptor. Na tenhle jazyk se dají převézt libovolná oprávnění, NTFS, registry, WMI i právě WinRM.
WinRM na sebe nepouští jen tak někoho. Každého nejprve ověří. Když pak zná jeho identitu, může zkontrolovat přístup právě pomocí svých security descriptorů. Buď se použije ten SDDL, který je přímo na konkrétním poskytovateli, nebo se vezme RootSDDL celé služby. RootSDDL se ale používá jen v případě, že daný poskytovatel opravdu žádné svoje SDDL nemá. RootSDDL tedy není dalším filtrem, ale jen náhradním výchozím filtrem.
SDDL jazyku by bylo dobře trošičku porozumět. Reference najdete tady a tady a tady. Takže formát je tento:
O:<vlastník>D:P<oprávnění>S:P<auditování>
Nás tedy zajímá hlavně přední část začínající D:P. Je to složené z jednotlivých závorek. Každá závorka je jedno ACE. První písmenko A značí Allow, kdyby tam bylo náhodou D, tak to je Deny. My tu máme ale samá Allow. V prostředku najdete oprávnění:
GA = Generic All (Full Control)
GR = Generic Read
GW = Generic Write
GX = Generic Execute
A úplně poslední v každé závorce je identita, pro kterou to ACE vlastně platí. Buď je tam konkrétní SID, ale v našem případě jsou tam skoro všude jen náhražky:
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__
Tak se na to SDDL mrkněme. Co když chceme přistupovat vzdáleně přes WinRM na WMI na server, který je Windows 2008 R2? WMI Provider na 2008 R2 nemá vlastní SDDL, takže se použije RootSDDL. To zní takto:
O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
Jediné jeho ACE (zbytek je auditing) říká Allow, Generic All to BUILTIN\Administrators. Takže na WMI se přes WinRM nedá dostat jinak, než že jste členy lokálních Administrators na tom vzdáleném WinRM serveru.
Zatímco na Windows 2012 je to SDDL trošku bohatší a je přímo na WMI Providerovi, takže se RootSDDL ignoruje:
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)
Zde vidíte celkem čtyři ACE. Všechno je Allow, všechno je Generic All. První pro Administrators, druhé pro INTERACTIVE, třetí pro Remote Management Users a čtvrté pro skupinu WinRMRemoteWMIUsers__. No hezky. Takže na Windows 2012 byste se mohli dát buď do skupiny Remote Management Users, nebo WinRMRemoteWMIUsers__ a měli byste se dostat na vzdálenou správu WMI přes WinRM, i když nebudete zrovna členy lokálních Administrators.
Fakt? Ne. To nestačí.
Nejprve vůbec vyzkoušení vzdáleného přístupu
Tak samozřejmě je potřeba ten vzdálený přístup nejprve vyzkoušet. Doporučuju nejprve ověřit vůbec TCP spojení na port 5985. Co když jsou po cestě nějaké firewally, že? Musí to napsat LISTENING:
portqry -n 10.10.0.12 -e 5985
No a potom už můžete klidně zkusit rovnou winrm příkaz a vypsat si WMI informace, třeba o spooler službě:
winrm get wmicimv2/Win32_Service?Name=spooler –remote:srv-data1
Do paremtru -remote musíte napsat jméno serveru. Zřejmě tam nelze napsat IP adresu, nějak se mi to nedaří. Ale můžete tam dát i port. Takže kdyby server náhodou běžel na jiném, než výchozím portu TCP 5985 (nebo klient byl nějak jinak nastaven), tak dáte třeba -remote:srv-data1:30000.
Pokud to zkusíte pod účtem člena skupiny Administrators, vypíše se to všechno ok. Když to zkusíte pod nějakým obyčejňákem, dostanete rovnou od WinRM chybovou hlášku Access denied:
WSManFault
Message = Access is denied.
Error number: -2147024891 0x80070005
Access is denied.
Takže vás samozřejmě může napadnout, že byste se tedy na cílovém serveru přidali do skupiny Remote Management Users, nebo WinRMRemoteWMIUsers__. Dobrá. Tentokrát už projdete kontrolou WinRM v pořádku. Přesně, jak je uvedeno v jeho vlastním SDDL. Tyto skupiny mají Generic All, tedy full control. Jenže po nějaké chvilce čekání stejně dostanete podobný error, jenom tentokrát přímo od WMI:
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.
A to je děti přesně ten problém. Soudruzi v Redmondu totiž na něco zapomněli. Ono totiž WMI má také svoje vlastní zabezpečení. Než to vyřešíme, ještě se podívejme na nějaké auditování a sledování na WinRM serveru.
Sledování aktivity a řešení potíží WinRM serveru
Abyste pěkně viděli trace log WinRM, stačí si pustit konzoli Event Viewer a udělat následující:
Event Viewer
Application and Service Logs
Microsoft
Windows Remote Management
right-click View - Show Analytic and Debug Logs
right-click Analytic - Enable Log
A všechno krásně uvidíte. V logu bude něco jako hlášky:
User ... authenticated successfuly using Kerberos authentication
Authorizing the user
Updating quota for the user
The authorization of the user was done successfully
Pokud se to dostalo až sem, znamená to, že jste prošli SDDL služby WinRM. Pokud jste jím neprošli, hnedka druhá hláška by říkala Access denied.
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
A když to skončí až tady, tak je jasné, že jde o zabezpečení WMI, které vás už dál nepustí. Jinak byste museli vidět pokračování:
Plugin reporting data object for operation Get
SOAP listener sending
Plugin reporting operation complete for Get
Tak co s tím sakra. Jak rozjedu vzdálené WMI přes WinRM na Windows 2012?
Na Windows 2012 je to hračka. Nejprve si vyberte svoji skupinu. Buď Remote Management Users, nebo tu divnou WinRMRemoteWMIUsers__. To je jedno.
A pro ni musíte přidělit WMI oprávnění na příslušné WMI namespace. Já to dělám rovnou pro celý Root, ale možná by někomu mohlo stači jen CIMv2. Jednoduše a hravě podle následujících obrázků:
Přímo pro namespace Root přidejte vaši skupinu a zapněte jí Execute Methods, Enable Account a hlavně Remote Enable. To ale není všechno. Musíte se ujistit, že se ta položka dědí i na nižší namespace:
A je to! Můžete to vyzkoušet! Je to vlastně to stejné, jako v mém starším článku o udělování vzdáleného přístupu na WMI pro ne-administrátory.
A jak to uděláte na Windows 2008 R2?
To bude o něco složitější. Zaprvé si musíte svoji vzdálenou skupinu vytvořit sami. Budete taky potřebovat zjistit její SID. To půjde pomocí příkazu WHOAMI /all, jestliže jste jejím členem. V mém případě se to přeložilo na SID:
S-1-5-21-3412575342-4025462326-617077526-1002
Za druhé jí musíte přidělit přístup do WinRM pomocí RootSDDL.
winrm set winrm/config/service @{RootSDDL="O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-21-3412575342-4025462326-617077526-1002)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)"}
Rozumíte předchozímu zápisu? Prostě jsem vzal výchozí RootSDDL a doplnil jsem do něho jedno ACE pro tu svoji skupinu. Až to budete dělat, raději vezměte svoje RootSDDL, které tam v tom okamžiku máte. A samozřejmě ho doplňte o svůj SID :-)
No a jako koncovku samozřejmě musíte zase přidělit přístup i na WMI, stejně jako v předchozím případě u Windows 2012.
To je žrááááádlóóóóóóóóóó!
Takže jak je to se vzdáleným přístupem na PowerShell Remoting?
Běžte se podívat nahoru na SDDL pro plug-in microsoft.powershell (pwrshplugin.dll) a jeho URI http://schemas.microsoft.com/powershell/microsoft.powershell. Co tam vidíte?
Na Windows 2008 R2 to říká:
O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
Z toho je vidět, že ve výchozím stavu se na vzdálený PowerShell remoting dostane jen skupina Administrators.
Zatímco na Windows 2012 je tam hodnota:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
Z čehož by již každému mělo být jasné, že potřebuje být členem skupiny Remote Management Users. Jak vidítě, skupina WinRMRemoteWMIUsers__ tam nevystupuje. Takže jestli se chcete dostat na vzdálený stroj příkazem Enter-PSSession, musíte být prostě členem jeho skupiny Remote Management Users. Skupina WinRMRemoteWMIUsers__ je v tomto případě na nic.
Popravdě nechápu, na co vůbec je. To je nějaký zbytek. Zřejmě to je kvůli tomu, že WinRM 3.0 ji vytváří na starších systémech až při své instalaci, takže ji proto přidali i do Windows 2012 jako takovou připomínku vlastní pitomosti.
Ale jak povolím PowerShell Remoting na Windows 2008 R2 pro ne-administrátory?
Tak jestli jste se dostali až sem, tak to je už za pusu. Na Windows 2008 R2 v PowerShellu instalujete remoting pomocí příkazu Enable-PSRemoting. Tenhle příkaz ve skutečnosti provede to, že přidá další plug-in s těmito parametry:
microsoft.powershell32 (pwrshplugin.dll)
URI: http://schemas.microsoft.com/powershell/microsoft.powershell32
SDDL: -
Takže co stačí udělat, když to URI nemá vlastní SDDL? No anóóóó. Přece jenom opravit RootSDDL pro tu vaši skupinu a fičíme z kopcééééé!
Skoro.
Ještě musíme upravit SDDL pro plug-in microsoft.powershell. Ten je výchozí na Windows 2008 R2 opět takto:
O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
Jenže jak ho upravíte? Jednoduše. Na to je v PowerShellu dokonce GUIčkové klikátko. Stačí spustit příkaz:
Set-PSSessionConfiguration -name Microsoft.PowerShell -ShowSecurityDescriptorUI
A teď je to už definitivně hotovo!
Poznámka: no dobrá, samozřejmě stačilo pustit to GUI dvakrát, podruhé pro Microsoft.PowerShell32, ale chtěl jsem, abyste to pochopili a byli schopni taky řešit nějaké potíže. Vždycky nejde všechno tak hladce, jak se píše v učebnicích. Už jsem se s tím párkrát pěkně napálil, proto tento článek.
Tak na zdraví!