Se connecter à PowerShell Remoting (WinRM) depuis votre Mac

Mis à jour le 29 juin 2026

Bifrost communique avec Windows via WinRM (Windows Remote Management) — le même protocole qu’Enter-PSSession et le gestionnaire Hyper-V. Si une connexion PowerShell ou Hyper-V affiche « Échec de connexion », c’est presque toujours une des étapes ci-dessous, côté Windows. Suivez-les dans l’ordre.

1. Activer WinRM sur la machine Windows

Sur l’hôte Windows visé, ouvrez PowerShell en administrateur et lancez :

Enable-PSRemoting -Force

Ça démarre le service WinRM et ajoute la règle de pare-feu. Sur la plupart des machines, c’est suffisant.

Si le remoting ne marche plus après un redémarrage, le service WinRM n’est peut-être pas revenu tout seul. Mettez-le en démarrage automatique (et revérifiez le profil réseau, qu’un reboot peut rebasculer en Public) :

Set-Service WinRM -StartupType Automatic
Start-Service WinRM
Get-NetConnectionProfile   # doit être Privé ou Domaine, pas Public

2. Vérifier que le profil réseau est Privé (ou Domaine)

Enable-PSRemoting refuse d’ouvrir le pare-feu tant qu’une carte réseau est sur le profil Public. Vérifiez et corrigez :

Get-NetConnectionProfile
# S'il affiche « Public », basculez-le :
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

(Utilisez l’InterfaceAlias renvoyé par la première commande.) Sur une machine jointe à un domaine, le profil est généralement DomainAuthenticated, ce qui convient.

3. Confirmer la règle de pare-feu et le port

WinRM écoute sur le TCP 5985 (HTTP). Vérifiez l’écouteur et que le port est ouvert :

winrm enumerate winrm/config/listener
Test-NetConnection -ComputerName localhost -Port 5985

Si Test-NetConnection échoue en local, l’écouteur ne tourne pas — relancez l’étape 1.

4. Identifiant et domaine

Le format le plus simple qui marche directement est DOMAINE\utilisateur saisi tel quel dans le champ Utilisateur — par exemple CONTOSO\jdupont. Vous n’avez pas besoin de remplir le champ Domaine séparé : DOMAINE\utilisateur dit déjà tout à Windows. C’est la configuration recommandée, et elle est très stable sur des sessions longues.

  • Compte de domaine : DOMAINE\utilisateur — utilisez le nom court (NetBIOS) du domaine, ex. CONTOSO\jdupont.
  • Compte local (workgroup / sans domaine) : .\utilisateur ou NOMMACHINE\utilisateur, ex. .\Administrateur.

Le champ Domaine séparé est optionnel — utile seulement si vous préférez saisir un utilisateur nu et fournir le realm à part (surtout pour Kerberos). Pour la plupart des cas, DOMAINE\utilisateur dans le champ Utilisateur suffit.

5. Méthode d’authentification

Bifrost ne bascule pas de protocole en silence — c’est le réglage Authentification qui décide, et vous pouvez le laisser sur la valeur héritée.

  • NTLM — fonctionne sur les machines de domaine et workgroup/autonomes, en HTTP simple. C’est un défaut fiable qui tient pendant des heures. Être sur un domaine ne force pas Kerberos.
  • Kerberos — pour les machines de domaine atteintes par leur FQDN (hote.domaine.lan) ; il doit localiser le contrôleur de domaine, donc il ne marche pas en connexion par IP. À utiliser uniquement si votre environnement l’impose.
  • Negotiate — laisse le client et le serveur s’accorder (Kerberos si les deux le supportent, sinon NTLM).
  • Basic — envoie l’identifiant/mot de passe directement, sans authentification Windows. Ne fonctionne que si l’écouteur WinRM est explicitement configuré pour (et, en HTTP simple, avec AllowUnencrypted — donc les identifiants ne sont pas protégés). À réserver à un hôte hors domaine configuré ainsi, idéalement en HTTPS. Pour tout le reste, préférez NTLM ou Negotiate.

Si une connexion marche avec la valeur héritée, laissez-la. NTLM sur un réseau de confiance convient — le protocole scelle (chiffre) quand même la charge utile.

6. HTTP ou HTTPS

Par défaut WinRM utilise HTTP sur 5985. Le trafic reste chiffré (Kerberos/NTLM scellent la charge utile), donc c’est sûr sur un réseau de confiance. Pour un réseau non maîtrisé, vous pouvez configurer un écouteur WinRM HTTPS sur 5986 et passer le Transport sur HTTPS dans Bifrost.

Dépannage

« No route to host » la toute première fois, puis ça marche au 2ᵉ essai. Sur macOS, la première connexion sur un réseau local peut être bloquée pendant que le système affiche (ou évalue en silence) l’autorisation Réseau local. Autorisez Bifrost dans Réglages Système → Confidentialité et sécurité → Réseau local, puis reconnectez. C’est une étape de permission macOS, pas un souci de pare-feu — macOS ne filtre que le trafic entrant.

Connexion refusée / délai dépassé. L’hôte est éteint, injoignable, ou WinRM ne tourne pas. Bifrost signale l’échec après ~30 s au lieu de rester figé. Vérifiez que l’hôte est allumé et que l’étape 1 est faite.

Ça se connecte mais une commande ne répond jamais. Assurez-vous que WinRM est bien activé (étape 1) et que vous êtes sur une version récente de Bifrost — d’anciennes versions pouvaient laisser une requête figée sur une connexion coupée. Ctrl-C puis relancer la commande débloque.

Le gestionnaire Hyper-V n’affiche rien / échoue. Hyper-V emprunte le même chemin WinRM que PowerShell. Connectez-vous avec un compte membre du groupe Administrateurs Hyper-V (ou Administrateurs local) sur l’hôte, et vérifiez que les étapes 1 à 4 passent.

Toujours bloqué ? Contactez-nous — joignez le texte exact de l’erreur affichée par Bifrost.

← Tous les guides