Com controlar el teu PC des del mòbil usant PowerShell Remoting

Potser ja automatitzes moltes tasques amb PowerShell de manera local, però on realment PowerShell Remoting marca la diferència és quan executes ordres en màquines remotes, siguin poques o centenars, de manera interactiva o en paral·lel. Aquesta tecnologia, disponible des de Windows PowerShell 2.0 i potenciada a partir de la 3.0, es basa en WS-Management (WinRM) i converteix a PowerShell a un canal d'administració remota robust, escalable i segur.

Abans de res, convé entendre dues idees clau: els cmdlets amb paràmetre -ComputerName (per exemple, Get-Process o Get-Service) no són el camí recomanat a llarg termini per Microsoft, i PowerShell Remoting no funciona com un “hack”. De fet, imposa autenticació mútua, registra auditoria i respecta els teus permisos de sempre, sense emmagatzemar credencials ni executar res amb súper privilegis per art de màgia.

Què és PowerShell Remoting i per què fer-lo servir

Amb Control remot de PowerShell pots executar en remot gairebé qualsevol ordre que podries llançar en una sessió local, des de consultar serveis fins a desplegar configuracions, i fer-ho a centenars d'equips alhora. A diferència dels cmdlets que accepten -ComputerName (molts usen DCOM/RPC), Remoting viatja per WS-Man (HTTP/HTTPS), que és més amigable amb tallafocs, permet paral·lelisme i descarrega el treball al host remot, no en el client.

Això es tradueix en tres avantatges pràctics: millor rendiment en execucions massives, menys fricció en xarxes amb regles restrictives i un model de seguretat coherent amb Kerberos/HTTPS. A més, en no dependre que cada cmdlet implementi la seva pròpia remota, Remoting serveix per a qualsevol guió o funció que estigui disponible a la destinació.

Per defecte, Windows Server recents porten Remoting habilitat; a Windows 10/11 ho actives amb un sol cmdlet. I sí, pots fer servir credencials alternatives, sessions persistents, punts de connexió personalitzats i més.

Ull: Remoting no és sinònim d'obrir-ho tot. Per defecte, només els administradors es poden connectar, i les accions s'executen amb la vostra identitat. Si necessites delegació fina, els endpoints personalitzats et permeten exposar només les ordres imprescindibles.

Com funciona per dins: WinRM, WS-Man i ports

PowerShell Remoting funciona en un model client-servidor. El client envia peticions WS-Management per HTTP (5985/TCP) o HTTPS (5986/TCP). A la destinació, el servei Windows Remote Management (WinRM) escolta, resol el punt de connexió (configuració de sessió) i hostatja la sessió de PowerShell en segon pla (procés wsmprovhost.exe), tornant al client resultats serialitzats en XML via SOAP.

La primera vegada que habiliteu Remoting, es configuren els listeners, s'obre l'excepció de tallafocs adequada i es creen configuracions de sessió. Des de PowerShell 6+ conviuen diverses edicions, i Activar-PSRemoting registra endpoints amb noms que reflecteixen la versió (per exemple, PowerShell.7 i PowerShell.7.xi).

Si al teu entorn només permets HTTPS, pots crear un listener segur amb un certificat emès per una CA fiable (recomanat). Si no, una altra alternativa és fer servir TrustedHosts de forma limitada i conscient dels riscos, per a escenaris de grups de treball o equips fora de domini.

Tingueu en compte que Powershell Remoting pot coexistir amb cmdlets amb -ComputerName, però Microsoft empeny WS-Man com la via estàndard i de futur per a administració remota.

Habilitar PowerShell Remoting i paràmetres útils

Al Windows, només cal obrir PowerShell com a administrador i executar Activar-PSRemoting. El sistema inicia WinRM, configura l'inici automàtic, habilita el listener i crea les regles de tallafocs adequades. En clients amb perfil de xarxa pública, ho pots permetre conscientment amb -SkipNetworkProfileCheck (i reforçar després amb regles específiques):

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

 

La sintaxi admet, a més, -Confirmar y -Què passa si per a control de canvis. Recorda: només està disponible a Windows, i has d'executar la consola elevada. Les regles creades difereixen entre edicions Server i Client, especialment en xarxes públiques, on per defecte es limita a la subxarxa local llevat que ampliïs l'abast (per exemple, amb Set-NetFirewallRule).

Per llistar configuracions de sessió ja registrades i confirmar que tot va quedar llest, utilitza Get-PSSessionConfiguration. Si apareixen endpoints PowerShell.xy, si escau, Workflow, l'esquelet de Remoting està operatiu.

Maneres d'usar: 1 a 1, 1 a molts i sessions persistents

Quan necessites una consola interactiva en un únic equip, recorre a Enter-PSSession. El prompt mostrarà i tot el que executis anirà al host remot. Pots reutilitzar credencials amb Get-Credential per no reintroduir-les constantment:

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

Si el que busques és enviar ordres a diversos equips alhora, l'eina és Invoke-Command amb un scriptblock. Per defecte llança fins a 32 connexions concurrents (ajustable amb ThrottleLimit). Els resultats tornen com objectes deserialitzats (sense mètodes “vius”):

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

Què cal invocar un mètode com .Stop() o .Start()? Fes-ho dins del scriptblock en el context remot, no en l'objecte deserialitzat local, i llest. Si hi ha cmdlet equivalent (Stop-Service/Start-Service), sol ser preferible fer-lo servir per claredat.

Per evitar el cost d'aixecar i tombar sessions a cada trucada, crea una PSSession persistent i reutilitza-la en diverses invocacions. Amb New-PSSession generes la connexió, i amb Invoke-Command-Session reaprofites el túnel. No oblidis tancar amb Remove-PSSession en acabar.

Serialització, límits i bones pràctiques

Un detall important: en viatjar, els objectes «+s'aplanen» i arriben com instantànies deserialitzades, amb propietats però sense mètodes. Això és deliberat i estalvia amplada de banda, però implica que no pots utilitzar membres que executen lògica (com .Kill()) a la còpia local. La solució és òbvia: invoca aquests mètodes en remot i, si només necessiteu certs camps, filtreu amb Select-Object per enviar menys dades.

En scripts, evita Enter-PSSession (pensat per a ús interactiu) i utilitza Invoke-Command amb scriptblocks. Si preveus múltiples trucades o necessites conservar estat (variables, mòduls importats), utilitza sessions persistents i, si escau, desconnecta-les/reconecta-les amb Disconnect-PSSession/Connect-PSSession a PowerShell 3.0+.

Autenticació, HTTPS i escenaris fora de domini

En un domini, l'autenticació nativa és Kerberos i tot flueix. Quan l'equip no pot verificar el nom del servidor, o connectes a una IP o àlies CNAME, necessites una d'aquestes dues vies: 1) Listener HTTPS amb certificat emès per una CA en què confies, o 2) afegir la destinació (nom o IP) a TrustedHosts i utilitzar credencials. La segona opció desactiva l'autenticació mútua per a aquest host, així que redueix l'abast al mínim necessari.

Configurar un listener HTTPS requereix un certificat (idealment del vostre PKI o una CA pública), instal·lat al magatzem d'equip i enllaçat a WinRM. Després s'obre el port 5986/TCP al firewall i, des del client, s'empra -UseSSL als cmdlets remots. Per autenticació per certificat de client, pots mapejar un cert a un compte local i connectar-te amb -CertificateThumbprint (Enter-PSSession no ho accepta directament; crea primer la sessió amb New-PSSession).

El segon salt i delegació de credencials

El famós “doble salt” apareix quan, després de connectar-te a un servidor, necessites que aquest servidor accedeixi a un tercer recurs en nom vostre (per exemple, un recurs compartit SMB). Per permetre-ho hi ha dos enfocaments: CredSSP i la delegació Kerberos restringida basada en recursos.

Amb CredSSP habilites el client i l'intermediari per delegar credencials explícitament, i ajustes política (GPO) per permetre la delegació a determinats equips. És ràpid de configurar, però menys segur perquè les credencials viatgen en clar dins del túnel xifrat. Sempre acota orígens i destins.

L'alternativa preferida en domini és la delegació Kerberos restringida (resource-based constrained delegation) a AD modern. Amb això, l'equip “del final” confia rebre delegació des de l'intermedi per a serveis concrets, evitant exposar la teva identitat a la connexió inicial. Requereix controladors de domini recents i RSAT actualitzat.

Endpoints personalitzats (configuracions de sessió)

Una de les joies de Remoting és poder registrar punts de connexió amb capacitats i límits a mida. Primer generes un fitxer amb New-PSSessionConfigurationFile (mòduls a precarregar, funcions visibles, àlies, ExecutionPolicy, LanguageMode, etc.), i després el registres amb Register-PSSessionConfiguration, on pots establir RunAsCredential i permisos (SDDL o interfície GUI amb -ShowSecurityDescriptorUI).

Per a delegació segura, exposa només el necessari amb -VisibleCmdlets/-VisibleFunctions i desactiva scripting lliure si escau amb LanguageMode RestrictedLanguage o NoLanguage. Si deixes FullLanguage, algú podria utilitzar un bloc de script per invocar ordres no exposades, la qual cosa, combinat amb RunAs, seria un forat. Dissenya aquests endpoints amb lupa i en documenta l'abast.

Dominis, GPO i treball en grup

A AD pots desplegar Powershell Remoting a escala amb GPO: permetre la configuració automàtica de listeners de WinRM, ajustar el servei a Automàtic, i crear l'excepció de tallafocs. Recordeu que GPO canvia configuració, però no sempre encén el servei a l'instant; de vegades toca reiniciar o forçar gpupdate.

En grups de treball (sense domini), configura Remoting amb Activar-PSRemoting, ajusta TrustedHosts al client (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) i utilitza credencials locals. Per HTTPS, pots muntar certificats autosignats, encara que el recomanable és fer servir una CA fiable i validar el nom que utilitzaràs a -ComputerName al certificat (coincidència CN/SAN).

Cmdlets i sintaxi clau

Un grapat d'ordres cobreixen el 90% d'escenaris diaris. Per activar/desactivar:

Enable-PSRemoting    
Disable-PSRemoting

Sessió interactiva 1 a 1 i sortida:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 a molts, amb paral·lelisme i credencials:

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

Sessions persistents i reutilització:

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

Proves i WinRM útil:

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

Notes pràctiques sobre firewall, xarxa i ports

Obre 5985/TCP per a HTTP i 5986/TCP per a HTTPS a l'equip de destinació ia qualsevol firewall intermedi. En clients Windows, Enable-PSRemoting crea regles per a perfils de domini i privat; per a públic limita a la subxarxa local a no ser que modifiquis l'abast amb Set-NetFirewallRule -RemoteAddress Any (valor a avaluar en el teu risc).

Si utilitzeu integracions SOAR/SIEM que executen ordres remotes (per exemple, des de XSOAR), assegureu-vos que el servidor tingui resolució DNS cap als hosts, connectivitat a 5985/5986 i credencials amb permisos locals suficients. En alguns casos, l'autenticació NTLM/Bàsica pot requerir ajustaments (per exemple, utilitzar usuari local a Basic amb SSL).

Paràmetres d'Enable-PSRemoting (resum operatiu)

-Confirm demana confirmació abans dexecutar; -Force omet els avisos i realitza els canvis necessaris; -SkipNetworkProfileCheck habilita Remoting en xarxes públiques de clients (limitant per defecte a subxarxa local); -WhatIf et mostra què passaria sense aplicar canvis. A més, com qualsevol cmdlet estàndard, suporta paràmetres comuns (-Verbose, -ErrorAction, etc.).

Recordeu que “Enable” no crea listeners HTTPS ni certificats per tu; si necessites xifrat end-to-end des de l'inici i l'autenticació basada en certificats, configura el listener HTTPS i valida CN/SAN contra el nom que utilitzaràs a -ComputerName.

Ordres útils de WinRM i PowerShell Remoting

Alguns imprescindibles de capçalera per al dia a dia:

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

A l'hora d'administrar Windows a escala, Remoting us permet passar d'“anar equip a equip” a un enfocament declaratiu i segur. Combinant sessions persistents, autenticació robusta (Kerberos/HTTPS), endpoints restringits i traces clares per a diagnòstic, ganes velocitat i control sense sacrificar seguretat ni auditoria. Si a més estandarditzes l'activació via GPO i domines els casos especials (TrustedHosts, doble salt, certificats), tindràs una plataforma remota sòlida per a operació diària i resposta davant d'incidents.