Windows Server 2025 / Activer le Bureau à distance et vérifier le pare-feu

L’accès par le protocole RDP (Remote Desktop Protocol) à Windows Server 2025 exige que le Bureau à distance soit activé, que le compte ait le droit de connexion et que le réseau et le pare-feu autorisent ce trafic. Pour ce laboratoire d'administration, utilisez un réseau interne de confiance et gardez l'Authentification au niveau du réseau (NLA) activée.

Séparez le Bureau à distance des autres outils de gestion

Le Bureau à distance ouvre une session serveur interactive. Le Gestionnaire de serveur (Server Manager), Windows Admin Center et la communication à distance PowerShell utilisent leurs propres chemins de communication et d'authentification. Activer l'un n'active pas tous les autres.

Cet exercice concerne l'accès administratif, et non le déploiement d'une application Remote Desktop Services (RDS) multi-utilisateur. N'installez pas le rôle RDS complet uniquement pour administrer un serveur. Une session Core reste également un environnement de gestion Core plutôt que d'acquérir le bureau standard. Connectez FS1 et CLIENT1 au même réseau isolé.

Activez l'accès au serveur tout en conservant NLA

  1. À la console de FS1, connectez-vous avec un compte administrateur, puis ouvrez le Gestionnaire de serveur → Serveur local → Bureau à distance.
  2. Autorisez les connexions à distance tout en conservant l'exigence NLA. Sur Core, utilisez le paramètre Bureau à distance dans SConfig.
  3. Choisissez le compte autorisé et le privilège requis. Ajoutez un utilisateur ordinaire aux utilisateurs autorisés lorsque cela est approprié, sans appartenance inutile aux Administrateurs.
  4. Enregistrez et inspectez le profil réseau actif ainsi que les règles entrantes du Bureau à distance.

NLA authentifie un utilisateur avant d'établir la session complète. Les recommandations de Microsoft pour le Bureau à distance le préconisent pour les clients pris en charge. Ne commencez pas le dépannage en désactivant NLA ou le pare-feu complet.

Vérifiez les profils et les plages d'adresses autorisées

Ouvrez wf.msc et inspectez les règles entrantes du Bureau à distance. Les noms peuvent être localisés, vérifiez donc aussi le protocole, le port local et le profil. TCP 3389 est le port par défaut du protocole Bureau à distance (RDP) ; utilisez le port réel s'il a été modifié.

  1. Identifiez si le profil réseau actif est Domaine, Privé ou Public.
  2. Vérifiez que la règle prévue s'applique à ce profil au lieu de permettre à tous les profils de manière indiscriminée.
  3. Envisagez de restreindre les adresses distantes au PC de gestion ou au sous-réseau de gestion.
  4. Recherchez d'autres règles autorisant le même port de manière plus générale. Une nouvelle règle restreinte ne supprime pas une règle d'autorisation générale existante.

Ne requalifiez pas un réseau non fiable comme Privé ou ne masquez pas un problème d'authentification de domaine simplement pour qu'une règle s'applique. Vérifiez le contexte réseau réel et la connectivité DNS du domaine.

Connectez-vous depuis le client

Sur CLIENT1, testez le chemin TCP par défaut, puis ouvrez l'outil de connexion. TcpTestSucceeded étant True ne prouve pas que les identifiants ou les droits de connexion sont valides.

Test-NetConnection -ComputerName 172.24.50.20 -Port 3389
mstsc
  1. Entrez l'adresse IP ou le nom résolvable de FS1 dans Connexion Bureau à distance.
  2. Avant de rejoindre le domaine, distinguez un compte local avec FS1\labuser. Après l’adhésion au domaine, sélectionnez l'identité de domaine prévue.
  3. En cas d'avertissement concernant un certificat inconnu, vérifiez la destination et le certificat au lieu d'accepter aveuglément un serveur inconnu.
  4. Après la connexion, exécutez hostname et whoami pour confirmer à la fois le serveur et le compte.

Fermer la fenêtre RDP peut interrompre la connexion sans fermer la session Windows. Enregistrez votre travail et fermez votre session lorsque vous avez terminé ; ne sauvegardez pas les identifiants sur un ordinateur partagé.

Utilisez l’erreur pour choisir la vérification suivante

Symptôme Premières vérifications
Seule la connexion basée sur le nom échoue Réponse DNS et nom de destination
Échec de la connexion TCP Alimentation de la machine virtuelle, commutateur, adressage, service et portée du pare-feu
Erreur d'identifiant Identité locale/domaine, mot de passe, heure et connectivité au domaine
Connexion non autorisée Utilisateurs autorisés et droit de connexion selon la politique

Si l'accès n'est plus nécessaire, désactivez-le depuis la console et annulez les modifications des utilisateurs et des règles spécifiques au laboratoire. Pour l'administration externe, prévoyez un réseau privé virtuel (VPN) ou une passerelle de gestion contrôlée plutôt que d'exposer directement le port 3389 du routeur sur Internet.