PowerShell à distance : la façon sécurisée de gérer des PC (sans TeamViewer)

Pourquoi le contrôle à la TeamViewer est un mauvais choix par défaut

Les outils de contrôle à distance résolvent un problème précis : « je dois voir ce que voit l’utilisateur ». C’est légitime pour quelques soucis orientés utilisateur — bugs d’interface, paramètres par utilisateur bizarres, situations du type « ma souris est hantée ». Mais comme canal de gestion par défaut pour un parc Windows, c’est le bazar :

• Il est difficile à auditer de façon significative. Un enregistrement vidéo n’est pas un journal de sécurité. Vous voulez des journaux structurés : qui a exécuté quoi, quand, sur quelle machine et avec quels paramètres.
• Ça ne s’échelonne pas. Votre temps devient le goulot d’étranglement. Les opérations sur flotte exigent le parallélisme.
• Ça encourage l’administration par instinct. On clique jusqu’à ce que ça marche. Ensuite personne ne peut reproduire l’action.
• Souvent trop permissif. La prise de session interactive plus l’admin locale font exploser les privilèges, surtout quand des comptes partagés apparaissent.
• Ça augmente la surface d’attaque. Tout outil tiers de contrôle à distance est un agent de plus, un mécanisme de mise à jour de plus, une source de CVE en plus, un chemin de confiance fournisseur supplémentaire.

PowerShell à distance n’est pas « le nouveau TeamViewer ». C’est un plan de gestion. Si vous le traitez comme tel, vous gagnerez en répétabilité, responsabilité et en moins de sauvetages à 2 heures du matin.

Ce qu’est réellement PowerShell à distance (et ce que ce n’est pas)

Le remoting PowerShell est une manière d’exécuter des commandes PowerShell sur une autre machine Windows en utilisant le protocole WS-Management (WinRM). Concrètement, vous avez trois schémas courants :

• Un-à-un ad hoc : Enter-PSSession pour se connecter à un hôte unique pour un dépannage interactif.
• Un-à-plusieurs en diffusion : Invoke-Command -ComputerName ... pour exécuter la même chose sur de nombreux endpoints.
• Sessions persistantes : New-PSSession pour réutiliser des connexions (utile quand vous faites plusieurs étapes).

Ce que ce n’est pas : un remplacement en pixels du bureau à distance. Vous ne réparerez pas un ruban Excel cassé avec ça. Vous pourrez déterminer si Excel plante à cause d’un add-in, si la machine est patchée, si le disque est plein, ou si le processus est bloqué — et vous le ferez sans demander à l’utilisateur de « cliquer sur Démarrer et taper… ».

Quand on dit « le remoting PowerShell est insecure », la plupart du temps on veut dire : « je l’ai activé à la va-vite, en HTTP, avec une authentification faible et sans audit. » Ce n’est pas un problème du protocole. C’est un problème d’encadrement adulte.

Faits et historique importants en production

Ce ne sont pas des anecdotes pour un quiz. Ils expliquent pourquoi certains paramètres par défaut existent et pourquoi certaines « bonnes pratiques » dépendent du contexte.

1. PowerShell 2.0 (2009) a introduit le remoting en utilisant WS-Management, s’alignant sur une norme industrielle plutôt que d’inventer un schéma RPC propriétaire.
2. WinRM précède l’usage moderne de PowerShell ; il faisait partie du récit plus large de Microsoft pour l’administration à distance (WS-Man).
3. Kerberos est le chemin préféré dans les environnements de domaine. Beaucoup de « problèmes de sécurité » du remoting viennent en réalité d’un repli sur NTLM et de l’ignorance des contraintes du double-hop.
4. Le problème du « double-hop » est devenu célèbre parce que des admins ont essayé d’accéder à des ressources réseau depuis une session distante et ont rencontré les limites de délégation d’authentification.
5. Le transport HTTPS s’est répandu hors domaine car il évite certaines gymnastiques de confiance nécessaires quand Kerberos n’est pas disponible.
6. JEA (Just Enough Administration) est arrivé à l’ère WMF 5.0 pour apporter le moindre privilège et des endpoints basés sur les rôles à PowerShell, pas comme une réflexion après coup.
7. La transcription PowerShell et le script block logging ont évolué en grande partie en réponse aux abus réels : les défenseurs avaient besoin de visibilité sur ce qui a été exécuté, pas seulement sur les noms de processus.
8. Windows Remote Management utilise SOAP en coulisses. Ce n’est pas « moderne », mais c’est durable — et la durabilité compte en ops plus que la mode.
9. PowerShell 7+ utilise une pile de remoting différente (SSH est commun), mais le remoting Windows PowerShell via WinRM reste l’outil de travail sur de nombreux parcs.

Modèle de sécurité : identité, transport, autorisation et audit

Identité : qui êtes-vous ?

Dans un domaine, visez Kerberos. Il fournit une authentification mutuelle et réduit le risque de rejeu des identifiants. Hors domaine, vous utiliserez typiquement des comptes locaux (acceptable mais imparfait), une authentification par certificat (mieux), ou le remoting SSH si vous standardisez sur PowerShell 7+ et pouvez opérer des clefs SSH.

Règle pratique : si vous pouvez faire Kerberos, faites Kerberos. Sinon, utilisez HTTPS avec des certificats et verrouillez qui peut se connecter.

Transport : comment le trafic est-il protégé ?

WinRM peut fonctionner sur HTTP (port 5985) ou HTTPS (port 5986). Dans un scénario de domaine Kerberos, HTTP n’est pas automatiquement « en clair et condamné ». Le chiffrement au niveau du message est assuré par la couche d’authentification (Kerberos). Pourtant, HTTPS offre un modèle mental plus simple, une meilleure compatibilité à travers les frontières de confiance et moins de débats « est-ce vraiment chiffré ? » avec les auditeurs.

Ne passez pas à HTTPS comme simple case cochée. Si vous déployez mal les certificats, vous aurez simplement déplacé le problème vers la gestion du cycle de vie des certificats — là où les services oubliés viennent mourir.

Autorisation : que pouvez-vous faire ?

Il y a trois niveaux de « pouvoir » auxquels vous devriez prêter attention :

• Pouvez-vous vous connecter du tout ? Contrôlé par la configuration du listener WinRM, les règles de pare-feu et l’appartenance à des groupes (par ex. le groupe local « Remote Management Users »).
• Que pouvez-vous exécuter une fois connecté ? Contrôlé par la configuration de l’endpoint, les configurations de session et les capacités de rôle JEA.
• Que peuvent toucher les commandes ? Moindre privilège dans l’OS : ACL de fichiers, permissions de services, droits de registre, etc.

La plupart des organisations s’arrêtent à « peut se connecter ». C’est comme installer une serrure sur la porte et laisser le coffre-fort ouvert.

Audit : pouvez-vous prouver ce qui s’est passé ?

L’audit n’est pas seulement pour la conformité. C’est pour la réponse aux incidents et pour les postmortems quand quelque chose casse et que tout le monde jure qu’il n’y a pas touché. Activez :

• La transcription PowerShell (capture les flux d’entrée/sortie dans des fichiers).
• Le script block logging (enregistre le contenu désobfusqué des scripts dans les journaux d’événements).
• Le module logging pour les modules clés dans les environnements sensibles.
• La collecte centrale (SIEM / agent de remontée). Les journaux locaux, c’est là où les preuves ont tendance à être « accidentellement effacées ».

Une idée paraphrasée d’un ingénieur orienté fiabilité : idée paraphrasée « Si vous ne pouvez pas le mesurer, vous ne pouvez pas le gérer » — souvent attribué à Peter Drucker (paraphrase). En termes d’ops : si vous ne pouvez pas le journaliser, vous ne pouvez pas le défendre.

Configuration de base : WinRM, pare-feu et paramètres sensés

Il y a deux questions séparées : « Puis-je techniquement me connecter ?» et « Dois-je considérer ceci comme un plan de gestion supporté ? » La baseline ci-dessous suppose que vous construisez ce dernier.

Recommandations de base (opinionnées)

• Utilisez la GPO pour le démarrage du service WinRM, la configuration des listeners et les règles de pare-feu. Des endpoints « snowflake » sont la cause des pages d’alerte.
• Restreignez l’entrée WinRM aux sous-réseaux de gestion / jump hosts. « Toute source sur le LAN » n’est pas un modèle de menace.
• Utilisez des comptes d’administration dédiés (séparés de l’identité quotidienne). Si vous administrez depuis votre compte e-mail, vous êtes à un phishing d’un trimestre misérable.
• Commencez par Kerberos en domaine. Ajoutez HTTPS là où c’est utile (endpoints workgroup, contraintes inter-forêts, auditeurs, ou réseaux non fiables).
• Prévoyez JEA tôt si le helpdesk utilisera le remoting. Il est plus facile de concevoir le moindre privilège que de le rétrofiter.

Blague #1 : Activer WinRM pour tout le monde et appeler ça « gestion à distance » revient à laisser les clés de la voiture dans le contact pour améliorer la « découvrabilité des clés ».

WinRM via HTTPS : quand le faire et comment

HTTPS vaut le coup quand l’une des situations suivantes est vraie :

• Vous gérez des machines hors domaine (workgroup, DMZ, filiales acquises, laboratoires).
• Vous devez traverser des réseaux dont vous ne faites pas confiance aux intermédiaires (Wi‑Fi invité, réseaux partenaires, segments VPN compliqués).
• Vous devez satisfaire des examinateurs de sécurité qui pensent que « HTTP » signifie « non chiffré ». Parfois vous gagnez cet argument. Parfois vous déployez HTTPS et passez à autre chose.

Deux avertissements pratiques :

• L’identité du certificat doit correspondre à l’hôte. Si vous liez un certificat au mauvais nom, les clients échoueront d’une manière qui ressemble à des « instabilités WinRM aléatoires ».
• Le cycle de vie des certificats compte. Les certificats expirés ne lancent pas un avertissement doux ; ils font échouer votre automatisation à grande échelle.

JEA : donner du pouvoir au helpdesk sans lui donner le royaume

Just Enough Administration (JEA) est la manière d’arrêter la spirale « tout le monde est admin local » sans entraver le support. Avec JEA, vous publiez un endpoint contraint (une configuration de session PowerShell) qui :

• N’autorise que des commandes spécifiques (ou des fonctions que vous définissez).
• S’exécute sous un compte virtuel ou un compte géré aux droits limités.
• Journalise ce qui a été exécuté.

Opérationnellement, JEA n’est pas tant une RBAC parfaite qu’une réduction du rayon d’impact. Si les identifiants d’un technicien helpdesk sont compromis, l’attaquant reçoit un marteau jouet au lieu de la clé maîtresse.

Blague #2 : JEA, c’est comme donner à quelqu’un un couteau suisse sans la lame — étonnamment efficace, et personne ne devient Domain Admin « accidentellement ».

Tâches pratiques (avec commandes, sorties et décisions)

Voici des tâches réelles que vous pouvez exécuter depuis une machine de gestion. Les commandes sont montrées comme si elles étaient lancées sur un hôte d’administration Linux en utilisant PowerShell 7 (pwsh). C’est volontaire : en 2026, beaucoup de SRE exécutent leur plan de contrôle sur Linux, même si les endpoints sont Windows. La cible de remoting reste WinRM.

Hypothèses pour les exemples :

• La machine de gestion a pwsh installé.
• Les cibles sont pc-014, pc-022, etc.
• Environnement de domaine sauf indication contraire.

Tâche 1 : Vérifier la reachabilité réseau de base (ne sautez pas cette étape)

cr0x@server:~$ pwsh -NoProfile -Command "Test-Connection -ComputerName pc-014 -Count 2 | Format-Table Address,ResponseTime,StatusCode"
Address       ResponseTime StatusCode
-------       ------------ ----------
10.40.12.14            3          0
10.40.12.14            2          0

Ce que la sortie signifie : L’hôte répond au ICMP et la latence est faible. StatusCode 0 indique le succès.

Décision : Si le ping échoue, ne discutez pas encore de WinRM. Vérifiez le routage/VPN, si le point final est en veille, ou le pare‑feu de l’hôte qui bloque l’ICMP. Si votre organisation bloque l’ICMP, passez aux tests de port à la place.

Tâche 2 : Vérifier que les ports WinRM sont atteignables (5985/5986)

cr0x@server:~$ pwsh -NoProfile -Command "Test-NetConnection -ComputerName pc-014 -Port 5985 | Select-Object ComputerName,RemotePort,TcpTestSucceeded"
ComputerName RemotePort TcpTestSucceeded
------------ ---------- ---------------
pc-014             5985            True

Ce que cela signifie : La connectivité TCP fonctionne vers le port 5985.

Décision : Si False, vous avez un problème de chemin pare‑feu (pare‑feu de l’hôte ou ACL réseau). Corrigez cela avant de toucher aux identifiants ou à la configuration WinRM.

Tâche 3 : Confirmer l’état du service WinRM à distance (quand vous ne pouvez pas encore remoter)

Si WinRM n’est pas démarré, vous ne pouvez pas utiliser WinRM pour vérifier WinRM. Utilisez tout canal hors bande dont vous disposez : conformité GPO, gestion d’endpoint, ou au minimum demandez un contrôle local. Dans une flotte gérée, vous devriez interroger via votre outil d’endpoint. Mais si vous pouvez vous connecter à un autre service (comme SMB), vous pouvez utiliser WMI/DCOM dans certains environnements — bien que ce soit une autre conversation de sécurité.

La conclusion opérationnelle : construisez un reporting de conformité pour que ce ne soit pas un mystère à 2 heures du matin.

Tâche 4 : Créer une session distante et exécuter une commande simple

cr0x@server:~$ pwsh -NoProfile -Command "$s = New-PSSession -ComputerName pc-014; Invoke-Command -Session $s -ScriptBlock { hostname; whoami }; Remove-PSSession $s"
PC-014
CORP\svc-ops-admin

Ce que cela signifie : Le remoting fonctionne et vous exécutez sous l’identité attendue.

Décision : Si l’identité est incorrecte (par ex. vous attendiez un compte privilégié), arrêtez‑vous et corrigez l’utilisation des identifiants. Ne « réessayez juste » pas avec des comptes aléatoires jusqu’à ce que ça marche.

Tâche 5 : Vérifier le mécanisme d’authentification (Kerberos vs NTLM)

cr0x@server:~$ pwsh -NoProfile -Command "Test-WSMan -ComputerName pc-014 | Select-Object ProductVendor,ProductVersion"
ProductVendor ProductVersion
------------- --------------
Microsoft Corporation OS: 10.0.19045 SP: 0.0 Stack: 3.0

Ce que cela signifie : WSMan répond. Cela ne montre pas explicitement Kerberos/NTLM, mais c’est un contrôle de santé pour la pile WSMan.

Décision : Si Test-WSMan échoue avec des erreurs d’authentification, vérifiez les SPN, le décalage horaire et la confiance de domaine. S’il échoue avec des erreurs de transport, vérifiez les listeners et le pare‑feu.

Tâche 6 : Vérifier la configuration du listener sur la cible

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { winrm enumerate winrm/config/Listener }"
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.40.12.14, 127.0.0.1

Ce que cela signifie : L’endpoint écoute uniquement sur HTTP.

Décision : En domaine avec un chemin réseau restreint, HTTP peut suffire. Si cette machine est dans un segment moins fiable, prévoyez HTTPS et des restrictions d’IP source.

Tâche 7 : Activer le remoting PowerShell (pour un labo ou bootstrap initial)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Enable-PSRemoting -Force; Get-Service WinRM | Select-Object Status,StartType,Name }"
Status  StartType Name
------  --------- ----
Running Automatic WinRM

Ce que cela signifie : WinRM est activé et en cours d’exécution.

Décision : En production, préférez GPO/MDM pour éviter la dérive. L’activation ad hoc mène à des règles de pare‑feu différentes sur chaque machine.

Tâche 8 : Restreindre qui peut se connecter (Remote Management Users)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { net localgroup 'Remote Management Users' }"
Alias name     Remote Management Users
Comment        Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.

Members

-------------------------------------------------------------------------------
CORP\GG-Helpdesk-RemoteMgmt
The command completed successfully.

Ce que cela signifie : Seul le groupe spécifié a les droits de gestion à distance (à condition que vous n’ayez pas accordé séparément des droits d’admin).

Décision : Gardez ce groupe restreint. Si vous voyez « Domain Users » dedans, vous avez une défaillance de politique, pas un problème technique.

Tâche 9 : Vérifier les règles de pare‑feu effectives pour WinRM

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' | Select-Object DisplayName,Enabled,Profile,Direction,Action | Format-Table -Auto }"
DisplayName                                  Enabled Profile  Direction Action
-----------                                  ------- -------  --------- ------
Windows Remote Management (HTTP-In)           True    Domain   Inbound   Allow
Windows Remote Management (HTTP-In)           False   Private  Inbound   Allow
Windows Remote Management (HTTP-In)           False   Public   Inbound   Allow

Ce que cela signifie : WinRM est autorisé en entrée sur le profil Domaine seulement. C’est une bonne base pour des portables d’entreprise.

Décision : Si vous le voyez activé sur Public, corrigez‑le. L’exposition au profil Public est la façon dont le Wi‑Fi d’un café devient un incident.

Tâche 10 : Vérifier le niveau de patch et le dernier redémarrage (triage 101)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 3 HotFixID,InstalledOn; (Get-CimInstance Win32_OperatingSystem).LastBootUpTime }"
HotFixID  InstalledOn
-------   -----------
KB5034765 1/18/2026 12:00:00 AM
KB5034122 12/12/2025 12:00:00 AM
KB5033375 11/14/2025 12:00:00 AM

Friday, January 31, 2026 8:14:22 AM

Ce que cela signifie : La machine a des patchs récents et la date du dernier démarrage est visible.

Décision : Si des patchs manquent, planifiez la remédiation. Si le dernier démarrage remonte loin, attendez‑vous à des mises à jour en attente, des fuites mémoire et des comportements de pilotes étranges. Les fenêtres de redémarrage relèvent de la politique, pas des préférences personnelles.

Tâche 11 : Vérifier la pression disque et décider si vous êtes en situation de pagination

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-PSDrive -PSProvider FileSystem | Select-Object Name,Used,Free | Format-Table -Auto }"
Name Used         Free
---- ----         ----
C    210.34 GB    8.12 GB

Ce que cela signifie : C: a ~8 GB libres. Sur Windows moderne, c’est flirté avec le problème (mises à jour, fichiers temporaires, croissance du fichier d’échange).

Décision : Si l’espace libre est <10–15 GB sur des builds d’entreprise typiques, vous devriez le traiter comme un précurseur d’incident. Nettoyez les caches, supprimez le superflu ou étendez le volume si possible.

Tâche 12 : Identifier ce qui consomme le disque (rapide, pas parfait)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-ChildItem C:\Users -Directory | ForEach-Object { $size = (Get-ChildItem $_.FullName -Recurse -Force -ErrorAction SilentlyContinue | Measure-Object Length -Sum).Sum; [pscustomobject]@{User=$_.Name;GB=[math]::Round($size/1GB,2)} } | Sort-Object GB -Descending | Select-Object -First 5 }"
User     GB
----     --
susan    48.12
public    2.05
default   0.76

Ce que cela signifie : Tailles des profils utilisateur. Susan stocke probablement beaucoup de choses — Downloads, cache OneDrive ou fichiers PST locaux.

Décision : Si un profil est énorme, choisissez entre une politique de nettoyage (Known Folder Move, Storage Sense) ou un nettoyage ciblé avec approbation utilisateur. Faites attention en supprimant des fichiers ; soyez encore plus prudent avec les PST.

Tâche 13 : Vérifier l’état d’un service (exemple : Windows Update)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-Service wuauserv | Select-Object Name,Status,StartType }"
Name     Status  StartType
----     ------  ---------
wuauserv Running Manual

Ce que cela signifie : Le service Windows Update fonctionne et est en type de démarrage Manual (valeur par défaut courante).

Décision : S’il est Disabled, c’est souvent un « quelqu’un l’a optimisé ». Réactivez via politique et vérifiez qui a décidé que les patchs étaient optionnels.

Tâche 14 : Récupérer les erreurs récentes du journal d’événements pour une application défaillante

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2; StartTime=(Get-Date).AddHours(-6)} -MaxEvents 5 | Select-Object TimeCreated,ProviderName,Id,Message | Format-List }"
TimeCreated  : 2/5/2026 9:12:33 AM
ProviderName : Application Error
Id           : 1000
Message      : Faulting application name: OUTLOOK.EXE, version: 16.0.17328.20174, time stamp: 0x00000000 ...

Ce que cela signifie : Vous avez une signature de crash réelle (event ID 1000) et une fenêtre temporelle.

Décision : Si les crashes corrèlent avec une mise à jour, isolez la build, vérifiez les add-ins et validez la voie de remédiation. Ne « réinstallez Office » pas en première réponse ; c’est cher et bruyant.

Tâche 15 : Vérifier la pression CPU/mémoire et les principaux coupables

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-Process | Sort-Object CPU -Descending | Select-Object -First 5 Name,Id,CPU,WS | Format-Table -Auto }"
Name       Id    CPU        WS
----       --    ---        --
Teams    8420  1520.34  812345344
chrome   5124   980.12  623214592
MsMpEng  2140   301.88  315654144

Ce que cela signifie : Le temps CPU et le working set montrent les processus lourds.

Décision : Si un processus est hors de contrôle, décidez de l’arrêter, de le mettre à jour ou de l’escalader vers l’ingénierie endpoint. Pour les applications côté utilisateur, coordonnez‑vous avant de tuer des processus.

Tâche 16 : Vérifier les options de durcissement de la configuration WinRM

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { winrm get winrm/config/service }"
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;SY)...
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerateTimeoutms = 240000
    AllowUnencrypted = false
    Auth
        Basic = false
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false

Ce que cela signifie : AllowUnencrypted est désactivé, Basic est désactivé, Kerberos/Negotiate sont activés. CredSSP est désactivé (bien, sauf si vous en avez besoin intentionnellement).

Décision : Si AllowUnencrypted=true ou Basic=true en production, considérez‑le comme une violation de politique. Corrigez via GPO et enquêtez sur l’origine.

Tâche 17 : Activer la transcription PowerShell et le script block logging (extrait d’exemple)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription' -Name EnableTranscripting -Type DWord -Value 1; Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription' -Name OutputDirectory -Type String -Value 'C:\ProgramData\PSTranscripts'; New-Item -Path 'C:\ProgramData\PSTranscripts' -ItemType Directory -Force | Out-Null; New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging' -Name EnableScriptBlockLogging -Type DWord -Value 1; 'OK' }"
OK

Ce que cela signifie : Les politiques sont définies localement pour activer la transcription et le script block logging. Dans de vrais parcs, faites‑le via GPO/MDM.

Décision : Si vous activez la transcription, pensez aussi au stockage (rétention, permissions, remontée). Des journaux que n’importe qui peut modifier ne sont pas des journaux d’audit ; ce sont des journaux personnels.

Tâche 18 : Créer un endpoint contraint (vérification conceptuelle)

cr0x@server:~$ pwsh -NoProfile -Command "Invoke-Command -ComputerName pc-014 -ScriptBlock { Get-PSSessionConfiguration | Select-Object Name,Permission | Format-Table -Auto }"
Name          Permission
----          ----------
Microsoft.PowerShell NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed

Ce que cela signifie : Seul l’endpoint par défaut est présent (typique). Les endpoints JEA montreraient des configurations nommées supplémentaires.

Décision : Si le helpdesk utilise le remoting, créez un endpoint JEA et refusez‑leur l’endpoint complet. La « confiance » n’est pas un contrôle.

Playbook de diagnostic rapide

Quand le remoting échoue, vous pouvez passer une heure à discuter des messages d’erreur, ou trier comme si vous étiez sérieux. Voici l’ordre qui trouve le goulot le plus vite.

Premier niveau : chemin réseau et ports

• Pouvez‑vous atteindre l’hôte ? Ping ou vérification de route. Si le endpoint est sur VPN, confirmez qu’il est réellement connecté.
• Le port 5985/5986 est‑il atteignable ? Utilisez Test-NetConnection. Si le TCP échoue, c’est un pare‑feu/NACL, pas PowerShell.
• L’hôte est‑il dans le bon profil réseau ? Si le portable pense être en « Public », votre règle pare‑feu Domain only ne s’appliquera pas.

Second niveau : service WinRM et listener

• WinRM tourne‑t‑il ? Dans les environnements gérés, vérifiez via la conformité. Si vous pouvez remoter, interrogez Get-Service WinRM.
• Y a‑t‑il un listener ? Vérifiez winrm enumerate winrm/config/Listener. Pas de listener, pas de partie.
• HTTPS est‑il attendu ? Si votre client cible 5986 et que l’hôte n’écoute que sur 5985, vous aurez du bruit « c’est en panne ».

Troisième niveau : authentification et autorisation

• Problèmes Kerberos : vérifiez le décalage horaire, les SPN bizarres et la confiance de domaine. Confirmez aussi l’utilisation du FQDN quand nécessaire.
• Comptes locaux / restrictions UAC à distance : l’admin local peut ne pas se comporter comme vous l’imaginez sur le réseau sans changements de politique. Préférez les comptes de domaine.
• Appartenance aux groupes : confirmez « Remote Management Users » (ou admin) et les permissions des endpoints JEA.

Quatrième niveau : politique et options de durcissement

• Paramètres d’auth : Basic/unencrypted doivent être désactivés. S’ils sont activés, vous pouvez avoir des politiques contradictoires.
• Problèmes TLS/certificats (HTTPS) : nom de certificat non correspondant ou certificat expiré provoque des échecs opaques.
• Interférence des protections endpoint : certains jeux de règles EDR peuvent bloquer WinRM en « containment mode ». Confirmez avec les opérations sécurité.

Erreurs courantes : symptômes → cause racine → correction

1) « Le client ne peut pas se connecter à la destination spécifiée dans la requête »

Symptôme : Enter-PSSession échoue immédiatement ; Test-WSMan expire.

Cause racine : Port bloqué (pare‑feu de l’hôte, ACL réseau), ou WinRM qui n’écoute pas.

Correction : Validez avec Test-NetConnection -Port 5985/5986. Assurez‑vous que le listener WinRM existe et que les règles de pare‑feu sont activées sur le profil correct.

2) « Accès refusé » avec des identifiants valides

Symptôme : L’authentification répond puis refuse la création de session.

Cause racine : Le compte n’est pas dans les admins locaux ni dans « Remote Management Users », ou permissions d’endpoint JEA manquantes.

Correction : Ajoutez l’appartenance aux groupes via GPO/politique locale. Si vous utilisez JEA, accordez explicitement les permissions d’endpoint et testez avec le rôle exact.

3) Marche en LAN, échoue en VPN

Symptôme : Même machine joignable au bureau, injoignable à distance.

Cause racine : Split tunneling, problèmes DNS sur VPN, ou profil réseau différent déclenché (Public vs Domain).

Correction : Confirmez la résolution de noms sur le VPN, forcez le profil réseau correct et autorisez WinRM seulement depuis les réseaux/jump hosts de gestion routés via le VPN.

4) HTTPS échoue avec des erreurs de certificat

Symptôme : Port 5986 atteignable mais erreurs de connexion mentionnant SSL/TLS ou confiance.

Cause racine : CN/SAN incorrect, certificat expiré, ou intermédiaire CA manquant sur le client.

Correction : Réémettez le certificat avec les SAN corrects, assurez‑vous que le client fait confiance à la chaîne CA, automatisez le renouvellement et tenez à jour le binding par empreinte (thumbprint).

5) Le « double hop » casse l’accès aux partages depuis une session distante

Symptôme : Vous remotez sur la machine A puis tentez d’accéder à un partage sur le Serveur B ; l’auth échoue.

Cause racine : La délégation n’est pas autorisée avec la méthode d’auth utilisée ; la délégation Kerberos / CredSSP n’est pas configurée.

Correction : Évitez les flux d’administration hop‑par‑hop. Exécutez la commande directement contre la ressource (Serveur B) ou utilisez la délégation contrainte quand approprié. Utilisez CredSSP seulement si vous comprenez et acceptez le risque.

6) Les sessions sont lentes et instables sous charge

Symptôme : Le remoting fonctionne mais met 30–60 secondes, parfois échoue, surtout lors d’opérations massives.

Cause racine : Limites de concurrence, pression CPU sur l’endpoint, latence DNS, ou jump host surchargé.

Correction : Ajoutez du throttling (-ThrottleLimit), améliorez le DNS et dimensionnez les hôtes de gestion. Ne fan‑out pas vers 2000 portables depuis une petite VM et ne soyez pas surpris.

Listes de contrôle / plan étape par étape

Phase 1 : Établir un plan de gestion sûr (semaine 1)

1. Définir les sources de gestion : choisissez des jump hosts ou un sous‑réseau de gestion. Rendez‑le explicite.
2. Activer WinRM via GPO/MDM : démarrer le service WinRM automatiquement ; créer les listeners ; configurer les règles de pare‑feu.
3. Définir la politique d’authentification : Kerberos/Negotiate activés ; Basic désactivé ; AllowUnencrypted désactivé.
4. Verrouiller la portée d’entrée : n’autorisez que les sources de gestion. Si vous ne pouvez pas restreindre la source, vous n’avez pas fini.
5. Définir les groupes : séparez les groupes « peut remoter » et « peut administrer ». Placez des humains dans des groupes, pas des machines en exception.

Phase 2 : Rendre tout auditable (semaine 2)

1. Activer la journalisation PowerShell : transcription + script block logging.
2. Forwarder les journaux : Windows Event Forwarding ou votre agent SIEM. Assurez‑vous de la rétention et des contrôles d’accès.
3. Tagger et alerter : alertes pour motifs suspects (commandes encodées, kill massif de processus, désactivation de Defender).

Phase 3 : Mettre en place le moindre privilège (semaines 3–4)

1. Concevoir les rôles JEA : ex. « Redémarrer des services approuvés », « Collecter des diagnostics », « Installer un package de drivers d’imprimante ».
2. Créer les endpoints JEA : publier des configurations de session avec des capacités de rôle restreintes.
3. Déployer progressivement : pilotez auprès du helpdesk, itérez sur les commandes, puis étendez.
4. Supprimer l’admin local quand possible : utilisez LAPS/Windows LAPS pour le break‑glass, pas pour les opérations quotidiennes.

Phase 4 : Opérationnaliser à l’échelle (en continu)

1. Créer des runbooks standard : vérification des patchs, nettoyage disque, récupération de services, vérifications de renouvellement de certificats.
2. Écrire des scripts idempotents : sûrs à exécuter deux fois ; sûrs à exécuter à 2 heures du matin ; sûrs pour quelqu’un de nouveau.
3. Tester en ring canari : les premiers 1–5 % des appareils reçoivent les changements tôt ; vous regardez ; vous apprenez.

Trois mini-récits d’entreprise venus du terrain

Incident causé par une mauvaise hypothèse : « HTTP signifie texte clair » (et la panique qui a suivi)

Une entreprise de taille moyenne a déployé WinRM pour l’automatisation du helpdesk. Quelqu’un a vu le port 5985 dans une demande de modification de pare‑feu et a escaladé : « On envoie des commandes admin non chiffrées en HTTP. » La direction sécurité a imaginé des mots de passe voguer sur le réseau comme cartes postales.

La réaction immédiate fut… énergique. Le remoting a été mis en pause, des scripts à moitié terminés abandonnés, et l’organisation est revenue aux sessions de contrôle interactif « pour la sécurité ». Ce qui était ironiquement moins auditable et plus privilégié. Mais bon, ça avait une icône de cadenas dans l’interface.

Quand la poussière est retombée, nous avons examiné le transport réel. En domaine, WinRM en HTTP avec Kerberos assure le chiffrement au niveau du message. Les identifiants ne sont pas envoyés en Basic, et le trafic n’est pas lisible dans une capture de paquets occasionnelle. Le vrai risque n’était pas « HTTP » ; c’était « une portée d’entrée trop large ». La règle pare‑feu autorisait WinRM depuis n’importe où sur le LAN, pas seulement depuis les hôtes de gestion.

La correction n’a pas été une croisade pour HTTPS partout. La correction a été la segmentation : restreindre WinRM aux jump boxes et postes admin, appliquer Kerberos et activer l’audit. Nous avons ajouté HTTPS pour quelques segments spéciaux (machines de labo hors domaine), mais c’était une décision d’ingénierie ciblée, pas une superstition.

La leçon : ne combattez pas les étiquettes. Combattez les modèles de menace. Si quelqu’un dit « HTTP c’est mauvais », demandez « depuis où, authentifié comment, journalisé où et avec quel rayon d’impact ? »

Une optimisation qui a mal tourné : des scripts de fan‑out ont fait fondre le jump host du helpdesk

Une autre organisation a décidé de « moderniser » et de remplacer le dépannage manuel par PowerShell à distance en parallèle. Bonne intention. Le premier script était magnifique : vérifier le disque, collecter les logs, redémarrer un service et vérifier l’état des patchs sur toute la flotte.

Ils l’ont lancé un lundi matin contre plusieurs milliers d’endpoints avec un throttle par défaut généreux. Le CPU du jump host est monté en plafond. Le DNS a été saturé. Les sessions WinRM se sont empilées. Les endpoints déjà fragiles sont devenus plus lents, ce qui a provoqué des retries du script, qui a chauffé encore plus le jump host. Un petit déni de service auto‑infligé, politiquement étiqueté « automation ».

Le postmortem était douloureusement banal : pas de bug exotique, pas de problème fournisseur. Juste une concurrence non bornée et aucune pression inverse. Le script supposait que si une session distante est bonne, 3000 sessions distantes sont meilleures.

Nous avons corrigé cela en traitant le remoting comme tout système distribué : limites de throttle, jitter, batching par OU/site, et un garde‑fou explicite « stop quand le taux d’échec dépasse X % ». Nous avons aussi séparé les diagnostics en lecture des actions en écriture. Collectez d’abord, puis remédiez seulement aux machines qui en ont besoin.

La leçon : les opérations, c’est de la théorie des files appliquée. Si vous ne construisez pas de limites, l’environnement vous les appliquera, généralement pendant les heures ouvrables.

La pratique ennuyeuse mais correcte qui a sauvé la mise : logs, rôles et piste papier

Une société de services financiers avait une politique stricte : personne n’utilise le remoting admin complet pour le support courant. Le helpdesk utilise un endpoint JEA. Toute la transcription PowerShell va dans un répertoire protégé et est remontée centralement. C’était considéré universellement comme « beaucoup de processus ».

Puis un incident est survenu : un ensemble de postes de travail a commencé à perdre ses paramètres réseau. Les utilisateurs ne pouvaient plus accéder aux applications internes. La ronde habituelle des accusés a commencé — équipe réseau, équipe endpoint, « peut‑être Windows update », « peut‑être le client VPN ». Pendant ce temps, le business voulait un coupable et une solution.

Les journaux ont raconté l’histoire rapidement. Un contractuel récent avait utilisé l’endpoint JEA pour exécuter de manière répétée une fonction « network reset » autorisée, en ne comprenant pas ce qu’elle faisait. La fonction était permise (par conception) mais avait besoin de garde‑fous : confirmations, limites de portée et noms plus explicites. Comme JEA avait contraint l’ensemble d’actions, nous avons pu prouver qu’il n’avait rien fait d’autre. Comme la transcription existait, nous avions les paramètres et le timing exacts.

La correction n’a pas été punitive. Nous avons amélioré la fonction, ajouté un mode « dry run », et mis à jour le runbook. Nous avons aussi ajouté une alerte pour des réinitialisations répétées depuis un même compte opérateur. Le business a eu la traçabilité sans drame, et les ops ont eu un outil plus sûr.

La leçon : les contrôles ennuyeux coûtent moins cher que des incidents excitants.

FAQ

1) Ai‑je besoin de WinRM via HTTPS dans un domaine ?

Pas toujours. Avec Kerberos, WinRM sur HTTP fournit toujours une communication chiffrée. Utilisez HTTPS lorsque vous avez besoin d’un modèle de confiance plus simple à travers des frontières, pour la gestion workgroup, ou pour la clarté auprès d’auditeurs.

2) Puis‑je remplacer complètement TeamViewer ?

Non. Certains problèmes nécessitent de voir l’interface utilisateur. Mais vous pouvez remplacer 80–95 % des cas de « se connecter et cliquer » par des diagnostics scriptés et des actions ciblées, et réserver le contrôle à distance pour le reste.

3) Quelle est la base minimale sûre ?

Restreindre WinRM entrant aux sources de gestion, désactiver Basic et le trafic non chiffré, utiliser Kerberos quand c’est possible, et activer la journalisation PowerShell avec remontée centrale.

4) Pourquoi le remoting marche en admin mais échoue pour les utilisateurs helpdesk ?

Parce que « peut se connecter » et « peut faire des actions utiles » sont différents. Donnez au helpdesk un endpoint JEA et des permissions explicites ; ne leur donnez pas l’admin local en espérant que tout ira bien.

5) Qu’est‑ce que le « double‑hop » en termes simples ?

Vous vous remotez sur une machine puis tentez d’accéder à une seconde ressource réseau depuis cette session distante. L’authentification ne se délègue souvent pas par défaut, donc le second saut échoue. Concevez des workflows pour éviter l’empilement de hops.

6) Activer CredSSP est‑il la bonne solution pour le double‑hop ?

Parfois, mais traitez‑le comme une substance contrôlée. Il peut exposer des identifiants à l’hôte distant. Préférez la refonte (exécuter les commandes directement sur la ressource cible) ou la délégation contrainte quand approprié.

7) Comment gérer en sécurité des portables hors domaine ?

Utilisez WinRM via HTTPS avec authentification par certificat ou envisagez PowerShell sur SSH (PowerShell 7+). Dans tous les cas, restreignez les IP source et exigez des contrôles d’identité robustes.

8) Comment éviter que cela ne devienne un autre « snowflake config » ?

Utilisez GPO/MDM pour la configuration, gardez un petit nombre d’endpoints standardisés et mesurez la conformité en continu. Les setups manuels par machine ne s’échelonnent pas.

9) Que dois‑je journaliser pour la réponse aux incidents ?

Transcription PowerShell, script block logging, et journaux Windows pertinents (WinRM/Operational, Security). Remontez centralement avec rétention et contrôles d’accès anti‑altération.

10) PowerShell 7 change‑t‑il tout ça ?

Il offre de meilleures options cross‑platform (notamment le remoting SSH), mais WinRM reste profondément intégré à la gestion Windows. Beaucoup de flottes fonctionneront en hybride : WinRM pour les opérations natives Windows, SSH là où cela convient.

Conclusion : étapes pratiques suivantes

Si vous utilisez encore par défaut des outils de contrôle à distance pour les opérations routinières sur postes, vous payez une taxe en temps, en auditabilité et en risque. PowerShell à distance est l’alternative mature : automatisable, journalisable et compatible avec le moindre privilège — si vous le construisez correctement.

Faites ceci ensuite, dans l’ordre :

1. Choisissez vos sources de gestion (jump hosts / postes admin) et restreignez WinRM entrant à celles‑ci.
2. Standardisez WinRM via politique (service, listeners, pare‑feu, auth). Éliminez la dérive.
3. Activez la journalisation et centralisez‑la avant d’en avoir besoin pour une enquête.
4. Déployez JEA pour le helpdesk et les workflows courants. Réduisez le rayon d’impact.
5. Rédigez des runbooks qui produisent des décisions, pas juste des sorties. « Disque faible » est une observation. « Libre < 10 GB déclenche nettoyage + ticket » est un système opérationnel.

L’accès à distance devrait être ennuyeux. Ennuyeux signifie prévisible. Prévisible signifie que vous pouvez dormir.