Ce que protège le certificat
TLS chiffre le transport RDP et permet au client de vérifier quel serveur il a atteint. Il ne remplace pas les fort identifiants Windows, MFA, la politique de pare-feu, ou patching en temps opportun.
La validation du certificat est basée sur le nom utilisé par le client. Un certificat pour rdp.example.com ne valide pas une connexion effectuée à un pseudonyme différent ou directement à une adresse IP à moins que cet identifiant ne soit explicitement inclus et supporté.
1. Définissez le nom du point de terminaison RDP
- Choisissez un nom DNS stable pour chaque paramètre RDP public ou interne.
- Pointez DNS et toute règle inverse de proxy ou de transfert de port sur le serveur prévu.
- Mettre à jour les profils RDP enregistrés pour utiliser le même nom.
- Évitez de vous fier à la modification des adresses IP publiques en tant qu'identité de l'utilisateur.
2. Choisissez un modèle de confiance
- Une autorité de certification publique telle que Let's Encrypt est appropriée lorsque le nom du point de terminaison est publiquement délégué et que la validation ACME peut être effectuée.
- Une CA interne est appropriée pour les noms privés et les appareils gérés lorsque le certificat racine est distribué par le biais de la politique de groupe, du MDM ou d'un autre canal contrôlé.
- Un certificat auto-signé ne convient que pour des tests limités, car chaque client doit établir la confiance séparément.
Lira peut automatiser l'émission et le renouvellement de l'ACME, mais une délégation DNS permanente pour le défi ACME doit être configurée correctement.
3. Validez avant de lier
- Sujet Nom alternatif contient chaque nom de connexion pris en charge.
- L'utilisation de la clé améliorée permet l'authentification du serveur.
- Le certificat est dans sa période de validité et la chaîne se construit sans erreur.
- La clé privée est installée sur le serveur cible et n'est exportable que si la politique l'exige explicitement.
- La liaison actuelle de l'auditeur est capturée pour le retour.
4. Déployer via une fenêtre de maintenance
- Gardez une session administrative existante et un chemin de récupération de console disponible.
- Déployez le certificat sur un serveur pilote.
- Permettre à Lira d'appliquer l'empreinte du pouce de l'auditeur et la politique de sécurité RDP requise.
- Si Remote Desktop Services doit redémarrer, attendez que l'agent retourne en ligne.
- Connectez-vous à partir d'un client distinct en utilisant le nom DNS de production et consultez le certificat présenté.
- Élargir le déploiement seulement après le succès du pilote.
Publication et renouvellement automatisés
Pour l'automatisation de Let, Lira crée ou utilise le workflow de défi ACME DNS requis, suit l'expiration, demande le renouvellement avant que le certificat ne devienne dangereux, déploie le certificat renouvelé et vérifie la liaison RDP résultante.
La délégation du DNS doit rester permanente. Enlever le CNAME délégué après la délivrance initiale empêche le renouvellement sans surveillance et provoque des avertissements de certificat répétés.
- Surveillez l'état d'expiration et de renouvellement du certificat dans le portail.
- Ne retirez pas la délégation de contestation de l'ACME après sa délivrance.
- Renouvellement d'essai sur un paramètre non critique avant une utilisation générale de la production.
- Garder à jour les destinataires d'alerte et intensifier la propriété.
Récupération et renversement
- Utilisez un accès console ou une session existante si les nouvelles connexions RDP échouent.
- Restaurer l'empreinte du pouce du certificat d'écoute.
- Vérifier les permissions des clés privées et redémarrer les services de bureau à distance seulement pendant la fenêtre de récupération approuvée.
- Reconnecter en utilisant le nom exact du DNS et inspecter la chaîne de certificats.
- Corriger les problèmes de SAN, DNS, de confiance ou de clé privée avant de tenter de nouveau le déploiement.