4. Les contrôles RDP SolidPing : le Bureau à distance répond-il vraiment ?
DocumentationUn contrôle TCP sur le port 3389 prouve seulement qu'un port est ouvert. Le contrôle RDP effectue la poignée de main Remote Desktop qui précède l'authentification : une réponse valide prouve que le service a vraiment traité la requête.
Dans cette vidéo, vous créez un contrôle RDP, vous le lancez, vous lisez le protocole de sécurité négocié (TLS, NLA, etc.) et la date d'expiration du certificat du serveur, puis vous arrêtez le service pour voir le contrôle passer en panne et un incident s'ouvrir. Aucun identifiant n'est nécessaire et aucune session n'est ouverte, donc vos journaux d'événements Windows ne se remplissent pas d'échecs d'authentification.
Les hôtes RDP sont en général privés : lancez le contrôle depuis un worker ou un agent privé qui peut les atteindre.
Étapes
Créer un contrôle RDP
Cliquez sur « Nouveau contrôle » et choisissez le type RDP. Contrairement à un simple test du port 3389, il effectue la vraie négociation du protocole Bureau à distance.
Saisir l'hôte et le port
Renseignez l'hôte et le port 3389. Ni identifiant ni mot de passe : la négociation s'arrête avant toute authentification.
Lancer le contrôle
Cliquez sur « Lancer maintenant ». Une réponse valide prouve que le service Bureau à distance a compris la requête, et le résultat affiche le protocole de sécurité négocié, par exemple TLS ou NLA.
Lire le certificat
Avec TLS, le contrôle lit aussi le certificat du serveur et échoue s'il a expiré. La chaîne n'est pas validée, car les certificats RDP sont souvent auto-signés.
Détecter un service arrêté
Arrêtez le service sur le serveur et relancez. Le contrôle échoue et SolidPing ouvre un incident, là où un simple test de port aurait pu rester vert.
Choisir une région qui atteint l'hôte
Les hôtes RDP sont souvent privés : choisissez un worker ou un emplacement privé qui les atteint. Personne ne se connecte, donc vos journaux d'événements Windows restent propres.