MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Activer WinRM par GPO pour Windows Admin Center (WAC) : bonnes pratiques Kerberos, HTTPS et pare‑feu

Activer WinRM par GPO pour Windows Admin Center (WAC) : bonnes pratiques Kerberos, HTTPS et pare‑feu

Windows Server

Après l’installation de Windows Admin Center (WAC), beaucoup activent WinRM via GPO et tombent dans un piège : restreindre « Filtres IPv4 autorisés » au serveur WAC coupe l’écoute locale. Voici une méthode sûre pour n’autoriser **que** WAC sans perdre la connectivité.

Sommaire

Vue d’ensemble de la question

Après l’installation de Windows Admin Center (WAC), l’administrateur souhaite activer WinRM sur tous les postes via une stratégie de groupe. Lorsque l’adresse IP du serveur WAC est inscrite dans le paramètre Filtres IPv4 autorisés de la stratégie Service WinRM, la connexion échoue ; avec « * », elle réussit. Comment restreindre la configuration au seul serveur WAC sans perdre la connectivité ?

Réponse & solutions

Comprendre les deux paramètres clés

Élément GPORôleValeur recommandée
Service WinRM → Autoriser la gestion à distance du serveur via WinRM → Filtres IPv4 autorisésDéfinit sur quelles adresses du poste géré WinRM écoute (liaison locale).Laisser « * » (ou 0.0.0.0) pour écouter sur toutes les interfaces locales.
Client WinRM → Autoriser les hôtes approuvésDésigne les hôtes (IP/FQDN) auxquels le poste peut se connecter en WinRM si Kerberos n’est pas disponible.Saisir l’IP ou le FQDN de(s) cible(s) lorsque vous devez administrer des hôtes non joints au domaine ou joignables par IP.

Point d’attention important : Filtres IPv4 autorisés contrôle l’écoute locale (sur quelles IP du poste la socket WinRM s’attache), pas les hôtes distants autorisés. Y mettre l’IP de WAC casse l’écoute car cette IP n’appartient pas à la machine locale. La véritable restriction « seul WAC peut joindre les postes » se fait côté pare‑feu Windows (port 5985/5986, IP distante autorisée) ou via IPsec. Le paramètre Client WinRM → Hôtes approuvés s’applique à la machine qui initie la connexion ; dans le scénario WAC→postes, c’est le serveur WAC qui joue le rôle de client WinRM.

Chemins de configuration

  • Service WinRM
    Configuration ordinateur → Stratégies → Modèles d’administration → Composants Windows → Gestion à distance Windows (WinRM) → Service WinRM → Autoriser la gestion à distance du serveur via WinRM
    • État : Activé
    • Filtres IPv4 : *
    • Filtres IPv6 : * (si IPv6 utilisé)
  • Client WinRM (utilisé sur le serveur WAC si vous administrez des hôtes hors domaine ou par IP)
    Configuration ordinateur → Stratégies → Modèles d’administration → Composants Windows → Gestion à distance Windows (WinRM) → Client WinRM → Autoriser les hôtes approuvés
    • État : Activé
    • Valeur : PC01.contoso.local,10.10.10.25 (exemples)

Vérifications réseau et sécurité essentielles

  • Ouvrir les ports TCP 5985 (HTTP) et/ou 5986 (HTTPS) sur le pare‑feu des postes cibles.
  • Type de démarrage du service WinRM : Automatique.
  • Tester depuis WAC (ou un poste d’admin) : Test-WSMan <NomPoste>
  • Privilégier Kerberos (machines jointes au domaine, usage du FQDN). À défaut, basculer en HTTPS avec certificat serveur pour éviter NTLM + TrustedHosts.

Bonnes pratiques complémentaires

  • Appliquer la GPO uniquement aux OU contenant les machines gérées.
  • Créer un groupe AD « WAC‑Servers » pour gérer plusieurs WAC.
  • Accélérer le déploiement : gpupdate /force ou redémarrage.
  • Diagnostics : Observateur d’événements → Microsoft‑Windows‑WinRM/Operational.

Architecture de sécurité : « Écouter partout, autoriser peu »

Le modèle recommandé est simple : laisser WinRM écouter sur toutes les interfaces locales (« * ») mais restreindre l’origine des paquets via le pare‑feu (ou le réseau). Ainsi, seules les IP du ou des serveurs WAC (ou un sous‑réseau d’outils d’administration) peuvent initier une session WS‑Man vers les postes.

Restreindre au(x) serveur(s) WAC via le pare‑feu Windows

  1. Éditeur de gestion des stratégies de sécurité avancées :
    Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Pare-feu Microsoft Defender avec fonctions avancées de sécurité → Règles de trafic entrant
  2. Créer une nouvelle règle :
    • Type : Port → TCP → Ports locaux : 5985 (et/ou 5986 pour HTTPS)
    • Action : Autoriser la connexion
    • Profils : sélectionner ceux utilisés (Domaine/Privé/Entreprise)
    • Nom : WinRM‑HTTP‑In (restreint‑WAC)
    • Onglet Portée → Adresse IP distante → Ces adresses IP → ajouter l’IP ou le subnet de WAC (ex. 10.20.30.40 ou 10.20.30.0/24).
  3. Désactiver les règles « Windows Remote Management (HTTP‑In) » par défaut pour éviter une ouverture globale, ou bien conserver ces règles mais avec une portée distante restreinte identique.

Avantage : la restriction est inbound (côté poste géré) et empêche tout autre hôte que WAC de se connecter, même si WinRM écoute sur 0.0.0.0.

Quand utiliser « Client WinRM → Hôtes approuvés » ?

  • Sur le serveur WAC : si vous gérez des postes hors domaine ou n’utilisez pas Kerberos (connexion par IP), ajoutez les postes dans TrustedHosts du client (WAC). # À exécuter sur le serveur WAC Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "PC01,10.10.10.25" -Concatenate -Force Get-Item -Path WSMan:\localhost\Client\TrustedHosts
  • Sur les postes gérés : inutile dans un scénario WAC→postes (cette clé ne filtre pas les connexions entrantes).

Kerberos : les règles d’or

  • Utilisez le FQDN du poste cible dans WAC (évitez l’IP pour que Kerberos fonctionne).
  • Synchronisez l’heure (écart < 5 min) et assurez l’enregistrement DNS.
  • Aucun besoin d’ajouter d’SPN : WinRM utilise le service HTTP/hostname du compte machine, déjà présent.

HTTPS (5986) : chiffrer et authentifier sans NTLM

Si vous devez gérer des postes hors domaine sans ouvrir TrustedHosts en grand, déployez un listener HTTPS avec un certificat « Server Authentication » émis pour le nom du poste :

  1. Déployez un modèle de certificat (Ordinateur ou Serveur Web) avec l’EKU « Server Authentication » et activez l’auto‑inscription des machines via GPO.
  2. Script de démarrage (GPO) pour créer le listener : $thumb = (Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } | Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint if ($thumb) { winrm delete winrm/config/Listener?Address=*+Transport=HTTPS 2>$null winrm create winrm/config/Listener?Address=*+Transport=HTTPS "@{Hostname='$env:COMPUTERNAME'; CertificateThumbprint='$thumb'}" }
  3. Ouvrez le pare‑feu sur 5986 (mêmes restrictions d’IP distantes que pour 5985).

Procédure pas à pas (déploiement recommandé)

  1. GPO #1 — Service WinRM (écoute)
    • Activer Autoriser la gestion à distance du serveur via WinRM, IPv4/IPv6 : *.
  2. GPO #2 — Pare‑feu (restriction aux IP WAC)
    • Créer des règles entrantes TCP 5985 et/ou 5986 avec Adresse IP distante limitée à l’IP ou au subnet d’administration (les serveurs WAC).
    • Désactiver les règles WinRM par défaut ou adapter leur portée pour correspondre.
  3. GPO #3 (optionnel) — Client WinRM sur WAC
    • Si hôtes hors domaine : activer Autoriser les hôtes approuvés et lister les FQDN/IP des cibles.
    • Forcer AllowUnencryptedTraffic = 0 et AllowBasic = 0 (sauf nécessité).
  4. GPO #4 (optionnel) — HTTPS
    • Déployer un certificat machine et le script de listener HTTPS.
  5. Validation
    • gpupdate /force → Test-WSMan PC01 depuis WAC.
    • winrm enumerate winrm/config/listener sur le poste.
    • Get-NetFirewallRule -DisplayName '*WinRM*' | Get-NetFirewallAddressFilter (vérifier la portée distante).

Clés de registre de référence (lecture seule)

EmplacementClé / ValeurCommentaire
HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\ServiceAllowAutoConfig (DWORD)=1Autorise la configuration auto de l’écoute WinRM via GPO.
HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\ServiceIPv4Filter=* / IPv6Filter=*« * » = toutes les IP locales. Surtout ne pas mettre l’IP de WAC ici.
HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\ClientTrustedHosts=listeÀ configurer sur le client WinRM (serveur WAC) si Kerberos indisponible.
HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\ClientAllowBasic=0 / AllowUnencryptedTraffic=0Désactive les flux non chiffrés et l’authentification Basic (sauf besoin ciblé).

Scénarios & choix rapides

ScénarioAuthentificationParamétrage cléRestriction au(x) WAC
Tout le monde joint au domaineKerberosService WinRM : IPv4/IPv6 = *Pare‑feu : 5985 (et/ou 5986) autorisé uniquement depuis IP WAC
Postes hors domaineHTTPS ou NTLMWAC : TrustedHosts vers les cibles (si IP/NTLM)Pare‑feu : restriction par IP + listener HTTPS recommandé
Connexions par IPNTLM ou HTTPSÉviter IP si possible ; sinon TrustedHosts (côté WAC)Pare‑feu : scoper sur IP WAC / subnet d’admin

Dépannage : erreurs fréquentes et correctifs

  • « WinRM cannot process the request » : vérifier le pare‑feu (port/portée), l’écoute (winrm e winrm/config/listener), et la résolution DNS.
  • « The WinRM client cannot process the request… Kerberos » : utilisez le FQDN, vérifiez l’heure et le SPN HTTP/<hostname> (normalement géré par le compte machine).
  • Erreur 0x80338126 (pare‑feu) : la règle WinRM est désactivée ou la portée distante ne contient pas l’IP de WAC.
  • Connexion en IP mais échec Kerberos : c’est normal. Kerberos exige un nom. Choisir FQDN ou basculer vers HTTPS.
  • Double‑hop (copie de fichiers, modules qui ré‑accèdent à un tiers) : utiliser Kerberos (délégation contrainte) ou CredSSP de manière contrôlée.

Scripts utiles (administrateur)

Vérifier l’état WinRM d’un lot de machines

$computers = Get-Content .\postes.txt
$results = foreach ($c in $computers) {
  try {
    $ws = Test-WSMan -ComputerName $c -ErrorAction Stop
    [pscustomobject]@{ Computer=$c; WSMan=$true; Product=$ws.ProductVendor; Protocol=$ws.ProtocolVersion }
  } catch {
    [pscustomobject]@{ Computer=$c; WSMan=$false; Product=$null; Protocol=$null }
  }
}
$results | Format-Table -Auto

Activer WinRM localement (poste pilote)

Enable-PSRemoting -Force
Set-Service WinRM -StartupType Automatic
# Pare-feu restreint à WAC
$wacIPs = @('10.20.30.40','10.20.30.41')
Set-NetFirewallRule -DisplayGroup 'Windows Remote Management' -Enabled True | Out-Null
Get-NetFirewallRule -DisplayName 'Windows Remote Management (HTTP-In)' | Set-NetFirewallAddressFilter -RemoteAddress $wacIPs
# HTTPS optionnel
# New-Item WSMan:\Localhost\Listener\ -ErrorAction SilentlyContinue | Out-Null

Checklist de mise en production

  • GPO Service WinRM : Activé + IPv4/IPv6 : *.
  • Pare‑feu : règles 5985/5986 actives, **portée distante** limitée à l’IP/subnet de WAC.
  • WAC joint au domaine, DNS OK, horloge synchronisée.
  • (Hors domaine/IP) : TrustedHosts configuré sur WAC et listener HTTPS opérationnel.
  • Tests Test-WSMan et journal WinRM/Operational sans erreurs.

FAQ rapide

Q : Pourquoi « * » dans Filtres IPv4 n’est‑il pas dangereux ?
R : Parce que cela n’ouvre pas le réseau ; cela ne fait qu’autoriser l’écoute locale. La **vraie surface d’attaque** se borne par le pare‑feu (adresse IP distante) et l’authentification (Kerberos/HTTPS).

Q : Puis‑je mettre le FQDN de WAC dans Filtres IPv4 ?
R : Non. Ce paramètre attend des adresses locales. Un FQDN ou une IP qui ne sont pas assignés au poste empêchent l’écoute et donc toute connexion.

Q : Où configurer TrustedHosts ?
R : Sur la machine qui **initie** la connexion WinRM. Dans un scénario WAC→postes, c’est le **serveur WAC** (et non les postes gérés).

Q : Dois‑je utiliser 5985 ou 5986 ?
R : 5985 (HTTP) suffit avec Kerberos sur un réseau de confiance. 5986 (HTTPS) est recommandé quand Kerberos n’est pas possible (workgroup, IP, accès distant) ou pour une défense en profondeur.

Conclusion

Pour activer WinRM par GPO en toute sécurité avec Windows Admin Center, retenez la règle : écouter sur « * » côté Service WinRM, et restreindre les IP distantes aux seuls serveurs WAC via le pare‑feu (ou IPsec). Si vous gérez des hôtes hors domaine ou par IP, ajoutez les cibles dans TrustedHosts mais sur WAC, et privilégiez un listener HTTPS. Cette séparation des responsabilités (écoute locale / contrôle réseau / mode d’authentification) supprime le blocage observé tout en minimisant la surface d’exposition.

Annexe : commandes de contrôle rapide

# Sur un poste géré
winrm quickconfig
winrm enumerate winrm/config/listener
Get-NetFirewallRule -DisplayGroup 'Windows Remote Management' | Format-Table DisplayName,Enabled,Profile
# Depuis WAC ou un poste d'admin
Test-WSMan PC01.contoso.local
Enter-PSSession -ComputerName PC01.contoso.local -Authentication Kerberos

En résumé : conservez « * » dans le filtre IPv4 du Service WinRM (écoute locale) et faites la restriction au(x) serveur(s) WAC par le **pare‑feu** (portée IP distante). Si Kerberos n’est pas disponible, utilisez un listener **HTTPS** et, côté WAC, complétez avec **TrustedHosts**.

Windows Server
PowerShell Kerberos HTTPS GPO WinRM Windows Admin Center
Sommaire