Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Řešení potíží WinRM a povolení vzdáleného přístupu pro ne-administrátory na WMI i pro PowerShell Remoting
duben 03
Řešení potíží WinRM a povolení vzdáleného přístupu pro ne-administrátory na WMI i pro PowerShell Remoting

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í!

Comments

chyba v texte

Dobry den

V texte mate nepodstatnu chybicku: "V následujícím výpisu uvidíte tedy oba dva porty TCP 47001 i TCP 4985. Takhle je to výchozí na Windows 2012:"

Druhy port by mal byt spomenuty 5985 (aj ked si to kazdy domysli...)
David Papp on 9.5.2013 22:01

chyba v texte

Dobry den

V texte mate nepodstatnu chybicku: "V následujícím výpisu uvidíte tedy oba dva porty TCP 47001 i TCP 4985. Takhle je to výchozí na Windows 2012:"

Druhy port by mal byt spomenuty 5985 (aj ked si to kazdy domysli...)
David Papp on 10.5.2013 7:49

Re: Řešení potíží WinRM a povolení vzdáleného přístupu pro ne-administrátory na WMI i pro PowerShell Remoting

děkuju za poznámku.
ondass on 11.5.2013 11:02

vse je null

Dobry den,
postupoval jsem podle clanu, ale porad mam nekde chybu :-(
Uz nedostavam Access is denied, ale na dotaz :C:\>winrm get wmicimv2/win32_service?Name=spooler -remote:winrm1:5985
Win32_Service
    AcceptPause = null
    AcceptStop = null
    Caption = null
    CheckPoint = null
    CreationClassName = null
    Description = null
    DesktopInteract = null
    DisplayName = null
    ErrorControl = null
    ExitCode = null
    InstallDate = null
    Name = spooler
    PathName = null
    ProcessId = null
    ServiceSpecificExitCode = null
    ServiceType = null
    Started = null
    StartMode = null
    StartName = null
    State = null
    Status = null
    SystemCreationClassName = null
    SystemName = null
    TagId = null
    WaitHint = null
dostanu jen null. Pokud ucet pridam do lokalnich administratoru, udaje dostanu. Poradite, kde je potreba jeste nasstavit prava?
Cilovy stav je sluzbu zastavit. winrm invoke stopservice wmicimv2/win32_service?Name=spooler -remote:winrm1:5985
Prava jsem pridelil pomoci subinacl /service spooler /GRANT=domena\ucet
Moc dekuji
Ales on 4.6.2015 16:17

SCMANAGER

Ahoj, tak pro non-admina je jeste potreba sluzba scmanager napr. takto sc sdset SCMANAGER D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
Ales on 18.9.2015 16:08

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments