Så här styr du din dator från din mobiltelefon med PowerShell Remoting

Du kanske redan automatiserar många uppgifter med PowerShell lokalt, men var gör du egentligen det? PowerShell-fjärrstyrning gör skillnaden Det är när du kör kommandon på fjärrmaskiner, oavsett om det är några eller hundratals, interaktivt eller parallellt. Denna teknik, tillgänglig sedan Windows PowerShell 2.0 och förbättrad sedan 3.0, är ​​baserad på WS-Management (WinRM) och konverterar PowerShell i en robust, skalbar och säker fjärrhanteringskanal.

Först och främst är det viktigt att förstå två huvudidéer: cmdlets med -Datornamn-parameter (t.ex. Get-Process eller Get-Service) är inte den långsiktiga väg som rekommenderas av Microsoft, och PowerShell Remoting fungerar inte som ett "hack". Faktum är att framtvingar ömsesidig autentisering, granskar loggar och respekterar dina vanliga behörigheter, utan att lagra inloggningsuppgifter eller magiskt köra något med superbehörigheter.

Vad är PowerShell Remoting och varför ska man använda det?

Med PowerShell-fjärrstyrning burk kör nästan vilket kommando som helst på distans som du kan starta i en lokal session, från att fråga tjänster till att distribuera konfigurationer, och göra det på hundratals datorer samtidigt. Till skillnad från cmdlets som accepterar -ComputerName (många använder DCOM/RPC), Remoting reser via WS-Man (HTTP/HTTPS), som är mer brandväggsvänlig, tillåter parallellitet och avlastar arbete till fjärrvärden, inte klienten.

Detta innebär tre praktiska fördelar: bättre prestanda vid massiva avrättningar, mindre friktion i nätverk med restriktiva regler och en säkerhetsmodell som överensstämmer med Kerberos/HTTPS. Dessutom, genom att inte vara beroende av varje cmdlet för att implementera sin egen fjärrstyrning, Remoting Det fungerar för alla manus eller roller som finns tillgänglig på destinationen.

Som standard levereras nyare Windows-servrar med fjärrstyrning aktiverad; i Windows 10/11 du aktiverar den med en enda cmdlet. Och ja, du kan använda alternativa autentiseringsuppgifter, beständiga sessioner, anpassade slutpunkter och mer.

Obs: Fjärrstyrning är inte synonymt med att öppna allt. Som standard, endast administratörer De kan ansluta, och åtgärder utförs under deras identitet. Om du behöver detaljerad delegering kan du med anpassade slutpunkter endast exponera de viktigaste kommandona.

Så fungerar det inuti: WinRM, WS-Man och portar

PowerShell Remoting fungerar i en klient-server-modell. Klienten skickar WS-Management-förfrågningar via HTTP (5985/TCP) eller HTTPS (5986/TCP)På målet lyssnar Windows Remote Management (WinRM)-tjänsten, matchar slutpunkten (sessionskonfiguration) och är värd för PowerShell-sessionen i bakgrunden (wsmprovhost.exe-processen), returnera serialiserade resultat till klienten i XML via SOAP.

Första gången du aktiverar fjärrstyrning konfigureras lyssnare, lämpligt brandväggsundantag öppnas och sessionskonfigurationer skapas. Från PowerShell 6+ kan flera utgåvor samexistera, och Aktivera PSRemoting Registrerar slutpunkter med namn som återspeglar versionen (till exempel PowerShell.7 och PowerShell.7.xy).

Om du bara tillåter HTTPS i din miljö kan du skapa en säker lyssnare med ett certifikat utfärdat av en betrodd CA (rekommenderas). Alternativt är ett annat alternativ att använda TrustedHosts på ett begränsat, riskmedvetet sätt, för arbetsgruppsscenarier eller datorer utanför domänen.

Observera att Powershell Remoting kan samexistera med cmdlets med -ComputerName, men Microsoft lanserar WS-Man som standard- och framtidssäkrat sätt för fjärradministration.

Aktivera PowerShell-fjärrstyrning och användbara parametrar

I Windows, öppna bara PowerShell som administratör och kör Aktivera PSRemotingSystemet startar WinRM, konfigurerar autostart, aktiverar lyssnaren och skapar lämpliga brandväggsregler. På klienter med en offentlig nätverksprofil kan du medvetet tillåta detta med -Hoppa över nätverksprofilkontroll (och sedan förstärka med specifika regler):

Enable-PSRemoting
Enable-PSRemoting -Force
Enable-PSRemoting -SkipNetworkProfileCheck -Force

 

Syntaxen tillåter också, -Bekräfta y -Tänk om för ändringskontroll. Kom ihåg: Den är bara tillgänglig på Windows, och du måste köra den förhöjda konsolen. Reglerna som skapas skiljer sig mellan Server- och Client-utgåvor, särskilt på publika nätverk, där de som standard är begränsade till det lokala delnätet om du inte utökar omfånget (till exempel med Set-NetFirewallRule).

För att lista redan inspelade sessionskonfigurationer och bekräfta att allt är klart, använd Get-PSSessionConfigurationOm PowerShell.x- och, om tillämpligt, arbetsflödesslutpunkterna visas är Remoting-ramverket i drift.

Användningslägen: 1 till 1, 1 till många och ihållande sessioner

När du behöver en interaktiv konsol på en enda dator, vänd dig till Enter-PSSessionPrompten visas och allt du kör går till fjärrdatorn. Du kan återanvända inloggningsuppgifter med Get-Credential för att undvika att behöva ange dem ständigt igen:

$cred = Get-Credential
Enter-PSSession -ComputerName dc01 -Credential $cred
Exit-PSSession

Om det du letar efter är att skicka kommandon till flera datorer samtidigt, är verktyget det Invoke-kommando med ett scriptblock. Som standard startar den upp till 32 samtidiga anslutningar (justerbart med -ThrottleLimit). Resultaten returneras som avserialiserade objekt (utan "live"-metoder):

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service -Name W32Time } -Credential $cred

Behöver du anropa en metod som .Stop() eller .Start()? Gör det. inuti skriptblocket i fjärrkontexten, inte det lokala avserialiserade objektet, och det är allt. Om det finns en motsvarande cmdlet (Stop-Service/Start-Service) är det vanligtvis att föredra att använda den för tydlighetens skull.

För att undvika kostnaden för att starta och avsluta sessioner vid varje samtal, skapa en Ihållande PSSession och återanvänd den över flera anrop. Använd New-PSSession för att skapa anslutningen och använd Invoke-Command-Session för att återanvända tunneln. Glöm inte att stänga den med Remove-PSSession när du är klar.

Serialisering, begränsningar och god praxis

En viktig detalj: när man reser "+plattas föremålen till" och anländer som avserialiserade ögonblicksbilder, med egenskaper men inga metoder. Detta är avsiktligt och sparar bandbredd, men det betyder att du inte kan använda medlemmar som exekverar logik (som .Kill()) på den lokala kopian. Lösningen är uppenbar: anropa dessa metoder. i fjärrkontrollen och om du bara behöver vissa fält, filtrera med Select-Object för att skicka mindre data.

I skript, undvik Enter-PSSession (avsedd för interaktiv användning) och använd Invoke-Command med skriptblock. Om du förväntar dig flera anrop eller behöver bevara tillstånd (variabler, importerade moduler), använd ihållande sessioner och, om tillämpligt, koppla bort/återanslut dem med Disconnect-PSSession/Connect-PSSession i PowerShell 3.0+.

Autentisering, HTTPS och scenarier utanför domänen

I en domän är inbyggd autentisering Kerberos Och allt flyter på. När enheten inte kan verifiera servernamnet, eller om du ansluter till en CNAME-IP eller ett alias, behöver du ett av dessa två alternativ: 1) Lyssnare HTTPS med certifikat utfärdad av en CA du litar på, eller 2) lägg till destinationen (namn eller IP) till TrustedHosts och använd inloggningsuppgifterDet andra alternativet inaktiverar ömsesidig autentisering för den värden, så det minskar omfattningen till ett minimum.

Att konfigurera en HTTPS-lyssnare kräver ett certifikat (helst från din PKI eller en publik CA), installerat i teamarkivet och bundet till WinRM. Port 5986/TCP öppnas sedan i brandväggen och används från klienten. -Använd SSL i fjärr-cmdlets. För autentisering av klientcertifikat kan du mappa ett certifikat till ett lokalt konto och ansluta till -CertifikatTumavtryck (Enter-PSSession accepterar inte detta direkt; skapa sessionen först med New-PSSession.)

Det andra hoppet och delegeringen av autentiseringsuppgifter

Det berömda "dubbelhoppet" uppstår när du, efter att ha anslutit till en server, behöver att servern ska komma åt en tredje resursen för din räkning (t.ex. en SMB-resurs). Det finns två sätt att tillåta detta: CredSSP och resursbaserad begränsad Kerberos-delegering.

Med CredSSP Du gör det möjligt för klienten och mellanhanden att explicit delegera autentiseringsuppgifter, och du anger en policy (GPO) för att tillåta delegering till specifika datorer. Det är snabbt att konfigurera, men mindre säkert eftersom autentiseringsuppgifterna skickas i klartext inom den krypterade tunneln. Begränsa alltid källor och destinationer.

Det föredragna alternativet inom domänen är begränsad Kerberos-delegering (resursbaserad begränsad delegering) i modern AD. Detta gör att slutpunkten kan förlita sig på att ta emot delegering från mellanpunkten för specifika tjänster, vilket undviker att din identitet exponeras vid den initiala anslutningen. Kräver nya domänkontrollanter och en uppdaterad RSAT.

Anpassade slutpunkter (sessionskonfigurationer)

En av fördelarna med Remoting är att kunna registrera kopplingspunkter med skräddarsydda funktioner och begränsningarFörst genererar du en fil med New-PSSessionConfigurationFile (moduler att förladda, synliga funktioner, alias, ExecutionPolicy, LanguageMode, etc.), och sedan registrerar du den med Register-PSSessionConfiguration, där du kan ställa in Kör som autentiseringsuppgifter och behörigheter (SDDL eller GUI-gränssnitt med -ShowSecurityDescriptorUI).

För säker delegering, exponera endast det som är nödvändigt med -VisibleCmdlets/-VisibleFunctions och inaktivera fri skriptning om det är lämpligt med Språkläge Begränsat språk eller NoLanguage. Om du lämnar FullLanguage kan någon använda ett skriptblock för att anropa oexponerade kommandon, vilka i kombination med RunAs, det skulle vara ett hålUtforma dessa slutpunkter noggrant och dokumentera deras omfattning.

Domäner, gruppolicyobjekt och groupware

I AD kan du distribuera Powershell Remoting i stor skala med GPO: tillåt automatisk konfiguration av WinRM-lyssnare, ställ in tjänsten på Automatiskoch skapa brandväggsundantaget. Kom ihåg att gruppolicyobjekt ändrar inställningar, men de aktiverar inte alltid tjänsten direkt; ibland behöver du starta om eller tvinga fram en gpupdate.

I arbetsgrupper (icke-domäner), konfigurera Remoting med Aktivera PSRemoting, sätt TrustedHosts på klienten (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) och använd lokala autentiseringsuppgifter. För HTTPS kan du montera självsignerade certifikat, även om det rekommenderas att använda en betrodd CA och validera namnet som du kommer att använda i -Datornamn i certifikatet (CN/SAN-matchning).

Viktiga cmdlets och syntax

En handfull kommandosoldater täcker 90 % av dagliga scenarierFör att aktivera/avaktivera:

Enable-PSRemoting    
Disable-PSRemoting

Interaktiv session 1 till 1 och utgång:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 till många, med parallellism och meriter:

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service W32Time } -Credential $cred

Ihållande sessioner och återanvändning:

$s = New-PSSession -ComputerName localhost -ConfigurationName PowerShell.7
Invoke-Command -Session $s -ScriptBlock { $PSVersionTable }
Remove-PSSession $s

Testning och WinRM användbar:

Test-WSMan -ComputerName host
winrm get winrm/config
winrm enumerate winrm/config/listener
winrm quickconfig -transport:https

Praktiska anteckningar om brandvägg, nätverk och portar

Öppna 5985/TCP för HTTP och 5986/TCP för HTTPS på måldatorn och på någon mellanliggande brandväggPå Windows-klienter skapar Enable-PSRemoting regler för domän- och privata profiler. För offentliga profiler är det begränsat till det lokala undernätet om du inte ändrar omfånget med Set-NetFirewallRule -RemoteAddress Any (ett värde som du kan bedöma baserat på din risk).

Om du använder SOAR/SIEM-integrationer som kör fjärrkommandon (t.ex. från XSOAR), se till att servern har DNS-upplösning till värdarna, anslutning till 5985/5986 och inloggningsuppgifter med tillräckliga lokala behörigheter. I vissa fall kan NTLM/Basic-autentisering kräva justeringar (t.ex. användning av en lokal användare i Basic med SSL).

Aktivera-PSRemoting-parametrar (operativ sammanfattning)

-Bekräfta frågar efter bekräftelse innan körning; -Tvinga fram ignorerar varningarna och gör nödvändiga ändringar; -SkipNetworkProfileCheck aktiverar fjärrstyrning på offentliga klientnätverk (begränsat som standard till det lokala subnätet); -WhatIf visar dig vad som skulle hända utan att tillämpa ändringar. Dessutom, precis som alla vanliga cmdlets, stöder den gemensamma parametrar (-Utförlig, -Felåtgärd, etc.).

Kom ihåg att "Aktivera" inte skapar HTTPS-lyssnare eller certifikat åt dig; om du behöver end-to-end-kryptering från början och autentisering baserad på certifikat, konfigurera HTTPS-lyssnaren och validera CN/SAN mot namnet du ska använda i -Datornamn.

Användbara WinRM- och PowerShell-fjärrkommandon

Några viktiga sängkläder för dag till dag:

winrm get winrm/config
winrm enumerate winrm/config/listener
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any
Test-WSMan -ComputerName host -Authentication Default -Credential (Get-Credential)
New-PSSession -ComputerName host 
Enter-PSSession -ComputerName host 
Enable-PSRemoting -SkipNetworkProfileCheck -Force

När du hanterar Windows i stor skala kan du med fjärrstyrning gå från "dator-till-dator" till en deklarativ och säker metod. Genom att kombinera permanenta sessioner, stark autentisering (Kerberos/HTTPS), begränsade slutpunkter och tydliga spår för diagnostik, du får snabbhet och kontroll utan att offra säkerhet eller granskning. Om du även standardiserar GPO-aktivering och behärskar specialfall (TrustedHosts, double hop, certifikat) får du en solid fjärrplattform för daglig drift och incidenthantering.