• Sécuriser l'accès à votre infrastructure RDS
• Restreindre l'accès en bureau à distance

Lorsque vous mettez en place une infrastructure RDS (qui est basée sur le protocole RDP de Microsoft), il est important de la sécuriser au mieux pour éviter les attaques de pirates et/ou le vol de données confidentielles.
Pour cela, il est possible de sécuriser l'authentification du protocole RDP de différentes façons et notamment grâce à l'utilisation de certificats SSL.

En effet, sous Windows Server 2012 et 2012 R2, il est possible et recommandé d'utiliser la couche de sécurité SSL (TLS 1.0) qui permet d'authentifier le serveur avant l'envoi de données à ce serveur.
Ce qui veut dire que si un pirate essaie de duper l'utilisateur avec un faux serveur, le PC client sera en mesure de détecter cette tentative de phishing et il ne communiquera donc pas avec ce faux serveur.
Ce qui évitera à vos utilisateurs d'envoyer leurs identifiants (nom d'utilisateur / mot de passe) au serveur d'un pirate.

1. Activer l'authentification du serveur grâce au SSL (TLS 1.0)
   1. Utiliser le SSL (TLS 1.0) pour l'authentification du serveur (via GPO)
   2. Utiliser le SSL (TLS 1.0) pour l'authentification du serveur (via le gestionnaire de serveur)
2. Activer l'authentification au niveau du réseau (NLA)
   1. Activer l'authentification au niveau du réseau (NLA) via les GPO
   2. Activer l'authentification au niveau du réseau (NLA) via le gestionnaire de serveur
3. Vérification de la configuration du serveur

1. Activer l'authentification du serveur grâce au SSL (TLS 1.0)

1.1. Utiliser le SSL (TLS 1.0) pour l'authentification du serveur (via GPO)

Pour activer l'utilisation du SSL (TLS 1.0) pour l'authentification RDP sur vos serveurs hôtes de session, vous avez 2 possibilités :

• définir la stratégie de groupe adéquate via votre serveur Active Directory
• ou le faire sur chaque serveur hôte de session via le gestionnaire de serveur

Néanmoins, sachez que l'application de la stratégie à la priorité par rapport au paramètre disponible depuis le gestionnaire de serveur.

Sur votre serveur Active Directory, ouvrez la gestion des stratégies de groupe et allez dans : Configuration ordinateur -> Stratégies -> Modèles d'administration -> Composants Windows -> Services Bureau à distance -> Hôte de la session Bureau à distance -> Sécurité.

Ensuite, faites un double clic sur la stratégie "Nécessite l'utilisation d'une couche de sécurité spécifique pour les connexions distantes (RDP)".

Activez cette stratégie et sélectionnez "Couche de sécurité : SSL (TLS 1.0)".

Comme vous pouvez le voir, vous avez le choix entre 3 options :

• Négocier : qui correspond à l'option "Compatible client" qui permet de choisir la meilleure méthode en fonction de ce qui est supporté par le client et par le serveur.
  Cette option est utile pour la compatibilité, mais certains clients risquent de ne pas authentifier le serveur avant de s'y connecter et donc d'envoyer leurs identifiants à un serveur pirate.
• RDP : il s'agit de la méthode RDP classique qui utilise un chiffrement faible et qui n'authentifie pas le serveur
• SSL (TLS 1.0) : qui permet d'authentifier le serveur de manière sécurisée grâce à un certificat SSL et qui est supporté depuis Windows XP (comme indiqué sur la page "Support for SSL/TLS protocols on Windows" de Microsoft)

En production, étant donné que tous vos clients seront compatibles avec cette couche de sécurité SSL (TLS 1.0), nous vous recommandons fortement de l'activer.

Néanmoins, sachez que cela requiert l'utilisation d'un certificat valide que vous pouvez créer gratuitement grâce à une autorité de certification sous Windows Server et à l'importation du certificat généré, depuis le gestionnaire de serveur.

Une fois que vous aurez configuré cette stratégie de groupe, n'oubliez pas de mettre à jour la stratégie de sécurité de vos serveurs hôtes de session :

Batch

gpupdate /force

1.2. Utiliser le SSL (TLS 1.0) pour l'authentification du serveur (via le gestionnaire de serveur)

Si vous souhaitez modifier la couche de sécurité à utiliser sur chaque serveur hôte de session, ouvrez le gestionnaire de serveur et allez dans : Services Bureau à distance -> Collections -> [nom de la collection] -> Tâches -> Modifier les propriétés.

Dans la section "Sécurité", vous retrouverez les mêmes options :

• Couche de sécurité RDP : chiffrement faible et PAS d'authentification du serveur. Donc, possibilité d'envoyer ses identifiants à un serveur pirate sans le savoir.
• Négocier : ce qui pose un problème de sécurité, étant donné que le serveur distant risque de ne pas être authentifié et peut donc être remplacé par un serveur pirate sans que votre utilisateur ne le sache.
• SSL (TLS 1.0) : permet de sécuriser l'authentification RDP et d'authentifier le serveur distant pour éviter les serveurs pirates.

Sélectionnez "SSL (TLS 1.0)" et cliquez sur OK.

Important : cette couche de sécurité nécessite l'utilisation d'un certificat valide sur le serveur hôte de session. Comme expliqué dans notre tutoriel : RDS - Déployer une infrastructure RDS (bureaux basés sur des sessions)

2. Activer l'authentification au niveau du réseau (NLA)

Lorsque la NLA n'est pas activée, les sessions Terminal Server sont créées entièrement en arrière-plan dès que quelqu'un tente de se connecter sur un de vos serveurs hôtes de session.
Ce qui veut dire que si un pirate ou une personne mal intentionnée lance une attaque DDOS sur votre serveur avec une longue liste d'identifiants erronés, votre serveur va consommer beaucoup de ressources pour créer ses sessions Terminal Server en arrière-plan, et ce inutilement.
L'attaque DDOS risquera donc de rendre votre serveur inaccessible ou très lent, alors que les identifiants utilisés n'étaient même pas valables.

Pour éviter ce genre d'attaques, Microsoft a inventé la NLA qui consiste à vérifier les identifiants utilisés par l'utilisateur avant de créer la session en arrière-plan. Ainsi, si un pirate tente de se connecter avec de faux identifiants, la session ne sera pas créée en arrière-plan et sa tentative de connexion sera directement refusée.

2.1. Activer l'authentification au niveau du réseau (NLA) via les GPO

Pour activer l'authentification au niveau du réseau (NLA) via les stratégies de groupe, vous devez activer la stratégie : Requérir l'authentification utilisateur pour les connexions à distance à l'aide de l'authentification au niveau du réseau.
Cette stratégie est disponible dans : Configuration ordinateur -> Stratégies -> Modèles d'administration -> Composants Windows -> Services Bureau à distance -> Hôte de la session Bureau à distance -> Sécurité.

Activez la stratégie, puis quittez l'éditeur de stratégies de groupe et forcez la mise à jour de la stratégie de vos serveurs hôtes de sessions.

2.2. Activer l'authentification au niveau du réseau (NLA) via le gestionnaire de serveur

Si vous souhaitez activer l'authentification au niveau du réseau (NLA) via les propriétés de chaque collection, sachez que celle-ci est déjà activée par défaut.
Néanmoins, si vous cherchez ce paramètre, allez dans les propriétés de chaque collection.

Dans la section "Sécurité", vous verrez que la NLA est déjà activée par défaut grâce à la case "Autoriser les connexions uniquement pour les ordinateurs exécutant les services Bureau à distance avec authentification au niveau du réseau".

3. Vérification de la configuration du serveur

Depuis un poste client, accédez à un bureau de votre infrastructure RDS.

Une fois connecté, vous verrez un petit cadenas dans la barre bleue affichée en haut de l'écran.
En cliquant sur ce petit cadenas, vous verrez que l'identité de l'ordinateur distant a été vérifiée en utilisant un certificat de serveur et Kerberos.

Cliquez sur : Affcher le certificat.

Comme vous pouvez le voir, notre certificat :

• garantit l'identité d'un ordinateur distant (en l'occurrence : notre serveur hôte de session RDS)
• a été délivré à notre serveur : RDS.informatiweb.lan
• a été délivré par notre autorité de certification locale : InformatiWeb CA

Dans l'onglet Détails, vous constaterez que ce serveur est utilisé pour l'authentification du serveur.

Notez que ce certificat est considéré comme valide, car le certificat de notre autorité de certification fait partie des autorités de certification de confiance de nos postes clients.