[RDS Windows Server 2019] Pensez à déployer vos Services/Serveurs RDS en mode « Core »

 

S’applique à : RDS Windows Server 2016 et RDS Windows Server 2019

Introduction

Pour réduire la surface d’attaque sur certains rôles/serveurs RDS, il est fortement recommandé de les déployer sur une infrastructure Windows Server en mode « Core » plutôt qu’en mode « GUI ». Cela vous permet aussi de réduire vos efforts en terme de maintien et exploitabilité de la plateforme (moins d’Updates, moins de config post-déploiement…).

 

Services de rôles RDS pris en charge par Windows Server Core 2016 et 2019

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2016 et 2019 en mode Core:

Service de rôle RDS	Supporté sur Server Core
RDCB
RDLS
RDSH
RDVH
RDWA
RDG

pris en charge

 

non pris en charge

 

En outre, Windows Server 2019 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

 

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 et 2019 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2012 /2012 R2, 2016 ou encore 2019).

Depuis un Serveur d’Administration

Depuis une Session Windows Server (2012 ou ultérieur), lancez Windows PowerShell en tant qu’Administrateur et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

Enjoy :).

Publicité

[TSE & RDS Licensing] Matrice d’Interopérabilité : s’applique à Windows Server 2008 à 2019

J’avais publié dans le passé un post décrivant la matrice d’interopérabilité des Licences TSE/RDS Windows Server 2000 à 2016.

Note : le post est disponible directement depuis ce lien.

 

J’expliquais à travers cet article quand et comment pouvez-vous ré-utiliser vos Licences (CAL) TSE/RDS 2000 à 2016 sur les différentes plateformes Windows Server 2000 à 2016.

Aujourd’hui, je vais partager avec vous la nouvelle Matrice d’interopérabilité des Licences/CAL RDS à partir de 2012 à 2019.
Windows Server 2003 & 2008/2008 R2 étant Obsolètes, nous allons principalement nous focaliser sur les versions d’OS Server pouvant être utilisées en Production.

 

Comme vous le savez, Windows Server 2008 et 2008 R2 ne sont plus supportés depuis le 14 Janvier 2020. Consultez ce post pour en savoir plus.

 

Je vais plus précisément répondre aux questions suivantes :

• Puis-je réutiliser mes anciennes CAL RDS et les réinstaller sur un nouveau serveur exécutant une version d’OS Windows Server différente à celle du serveur « Source/existant »?
• Puis-je utiliser mes CAL TSE/RDS existantes pour autoriser mes utilisateurs RDS à se connecter à des serveurs Hôtes de Session (RDSH) exécutant des versions Windows Server différentes ?

 

Ma réponse sera « Splitée » en deux parties :

• Compatibilité des CAL TSE/RDS pour les serveurs de Licence RDS (RDLS)
• Comptabilité des CAL TSE/RDS pour les serveurs Hôte de Session (RDSH)

 

Note importante : les informations détaillées ci-dessous s’applique à vos serveurs de Licence RDS et RDSH hébergés OnPrem mais aussi ceux qui tournent sous forme de VM IaaS Azure (ou AWS, GCP, AliBabaCloud…Etc)

 

#R1 : Compatibilité des CAL RDS avec les serveurs de Licences RDS (RD Licensing Server)

Le tableau ci-dessous vous montre les CAL RDS pouvant être installées/utilisées sur chaque version d’OS Windows Server hébergeant le service de Licensing RDS (RDLS : Remote Desktop Licensing Server) :

 

#R2 : Compatibilité des CAL RDS avec les serveurs Hôtes de Session RDS (RD Session Host Server)

Le tableau ci-dessous vous montre les CAL RDS pouvant être installées/utilisées pour autoriser vos utilisateurs distants à se connecter aux serveurs RDSH en fonction de la version d’OS Windows Server qui exécutent :

Ce qu’il faut retenir

Vous ne pouvez pas utiliser vos anciennes CAL RDS pour accéder aux nouvelles versions de Windows Server (RD Session Server), mais vous pouvez utiliser des nouvelles CAL RDS pour accéder aux anciennes versions de Windows Server (RD Session Host). Les serveurs de licences RDS peuvent héberger toutes les CAL RDS ayant la même version de l’OS qu’il exécute ou ultérieur (eg : un RD Licensing Server 2016 peut héberger des CAL RDS 2016 et 2019).

Pour vous aider à mieux comprendre le tableau, je vous détaillerai un vrai « Use Case »:

Supposons qu’un Client (Société) X dispose déjà d’un Pack de Licences RDS 2012 R2 et est sur le point de dé-commissionner son infrastructure RDS 2012 R2 pour en déployer une nouvelle sous 2016 ou 2019. Comme indiqué dans le tableau ci-dessus, les CAL « RDS 2012 R2 » peuvent être installées sur les OS Windows Server suivants : 2012, 2012 R2, 2016 et 2019. Cette société pourra donc continuer à utiliser (en réinstallant) les Licences RDS 2012 R2 sur tout futur serveur de Licence RDS exécutant Windows Server 2012 R2 à 2019.

Cette même société souhaite savoir s’elle peut réutiliser ses licences RDS 2012 R2 pour permettre l’accès à des hôtes de session RDSH 2016 ou 2019, comme indiqué dans le tableau ci-haut, les CAL RDS 2012 R2 ne permettent l’accès qu’à des RDSH Servers exécutant la même versions que les CAL ou antérieur, donc des hôtes de sessions sous Windows Server 2012 R2, 2012, 2008 R2 ou 2008.

 

Référence documentation

Pour en savoir plus sur le Licensing RDS et la compatibilité des CAL RDS entre les différentes versions d’OS Windows Server, je vous invite à consulter la documentation officielle Microsoft disponible directement depuis ce lien.

A bientôt, et soyez forts pendant cette crise sanitaire (covid-19), tout va rapidement rentrer dans l’ordre :).

#ProtegezVous #RestezVous #SoyezForts

 

Microsoft abandonne l’outil RDCMan suite à une faille de sécurité !

Microsoft a abandonné cette semaine son free tool RDCMan (Remote Desktop Connection Manager suite à la découverte d’une faille de sécurité.

Le lien de téléchargement de RDCMan affiche désormais le message suivant :

Ce téléchargement n’est plus disponible !

Pour rappel, RDCMan vous permet d’établir plusieurs connexions Bureau à distance (Remote Desktop) depuis une console centrale.

Il permet également d’organiser les Connexions Remote Desktop via des groupes (catégories) et surveiller le statut de chaque connexion : Connectée, Déconnectée, Fermée…

L’outil s’appuie sur le protocole RDP (Remote Desktop Protocol), fourni nativement avec les plateformes/OS Windows Client & Server.

RDCMan a été développé par l’équipe Windows Live Experience de Microsoft pour un usage interne seulement. Il a ensuite été proposé publiquement à la fin des années 2000.

L’outil a connu un grand succès auprès des IT Admin dans les années 2000 et 2010.

MS l’a toujours maintenu à jour jusqu’à 2014, la dernière version stable proposée par l’éditeur est la 2.7

 

Suppression de RDCMan avec le Security Patch de Mars 2020 !

Avec la publication du patch de Mars 2020, la suppression officielle de RDCMan a été prononcée. Microsoft a déclaré avoir reçu un rapport sur un nouveau Bug dans RDCMan qui pourrait permettre à un Hacker de récupérer des données sur la machine qui héberge et exécute RDCMan.

 

RDCMan : quelle faille de sécurité ?!

Microsoft a déclaré dans un avis de sécurité (CVE-2020-0765)

< Pour exploiter la vulnérabilité, un attaquant pourrait créer un fichier RDG contenant un contenu XML spécialement conçu et convaincre un utilisateur authentifié d’ouvrir le fichier >

 

Au lieu de corriger la faille, Microsoft a décidé de mettre RDCMan à la retraite, ne voyant aucune raison de faire revivre une application qui a reçu sa dernière mise à jour il y a près de six ans. Les utilisateurs qui continuent à utiliser l’application doivent savoir qu’ils ne doivent pas ouvrir les fichiers RDCMan connection configuration (RDG) qu’ils reçoivent de manière non sollicitée ou de sources inconnues.

 

Note importante : il est recommandé de remplacer RDCMan par un autre Remote Desktop Manager, la faille est critique, et pourrait être une porte d’entrée à un Hacker à votre S.I

Pensez « Security First » 🙂

A bientôt :).

[RDS – Free Training] Lesson1 : Security Risks & Best Practices You Should Know

Introduction

RDP (Remote Desktop Protocol) est (par défaut) considéré comme un protocole vulnérable qui peut exposer votre infrastructure (voire tout votre S.I) à des risques assez importants, notamment :

• Brute-Force Attack
• DoS (Denial-of-Service) Attack
• Encryption Attack
• Man-in-The-Middle (MiTM) Attack
• …

 

Vous exposerez également votre S.I à un risque de sécurité si vous êtes consommateur (Cloud Consumer) d’une solution/Application Cloud hébergée sur une infrastructure RDS distante : Multi-tenancy Risk.

Plusieurs Cloud Providers proposant des applications SaaS (Software-as-a-Service) virtualisées et distribuées (RemoteApp) via des Portail RD Web Access personnalisés. Ces Apps sont souvent hébergées sur des infrastructures RDS « Partagées /Shared », cela veut dire que plusieurs clients, se connectent et consomment les mêmes Apps Cloud RDS depuis le même environnement. Pour des raisons de réduction de coût, plusieurs Cloud Providers déploient des RD Session Host en mode « Shared », et proposent rarement des infrastructures RDS dédiées (Collections de Session RDS dédiées par client/app).

Malheureusement la plupart des clients ne pensent pas à poser la question et se contentent de signer un contrat désignant les responsabilités de chacun (SLA) : en mode SaaS vous êtes uniquement responsable de vos données, les couches infra/storage/middleware sont gérées par le CP, seul ce dernier est responsable de la gestion, maintenance, patching… de l’environnement Cloud.

En revanche, vous avez la responsabilité de s’assurer du niveau de sécurité offert à travers ces applis Cloud qui souvent font parties de votre IT globale car les devices clients depuis lesquels vos users se connectent sont souvent intégrés dans votre AD local et connectés au niveau de votre Coporate Network.

 

Guide de Sécurité RDS : Liste des Risques, Menaces et Bonnes Pratiques que vous connaître 

Je viens de publier sur Slideshare un Guide de sécurité RDS assez complet (en Anglais) traitant ce sujet.

Il décrit et détaille toutes les Security Risks, menaces ainsi que les bonnes pratiques que vous devez prendre en considération lors de la phase « Design » de tout projet RDS (de 2008 R2 à 2019).

Il vous liste également les Risks/Menaces liées à des infrastructures RDS Offsites (hébergées chez un Cloud Provider), si vous êtes Cloud Customer d’une ou plusieurs Apps Cloud, vous pouvez toujours challenger l’éditeur/Cloud Provider en posant les questions listées dans ce Slide.

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

[RDS /Remote Desktop Services] Lesson 1 : Security Risks & Best Practices You Should Know from ☁ Hicham KADIRI ☁

Si vous souhaitez être accompagné, n’hésitez pas à me Ping via MP pour planifier un call et discuter plus en détail de votre projet.

Bonne lecture à tous,

#HK

Installer le Client R(emote) D(esktop) Web HTML5 sur RDS Windows Server 2016

Introduction

Vous devez sûrement connaître le fameux client « Connection Bureau à distance » fourni nativement avec les OS Windows (Client & Server). Cette Windows Desktop App fait simplement appel à l’outil MSTSC.exe qui est, aujourd’hui utilisé par la quasi totalité des Admins devant gérer et administrer (à distance) des plateformes Windows Server.

 

Note : Petit reminder, l’outil MSTSC.exe est (par défaut) placé dans : C:\Windows\System32\mstsc.exe

 

En outre, Microsoft propose depuis quelques années un client lourd « Multi-Platforme** » appelé « Remote Desktop« . Cette App est en effet disponible pour :

• Mac OS X (depuis Mac Apple Store)
• iOS (depuis Apple Store)
• Android (depuis Google Play Store)

 

** Vous trouverez ci-dessous les liens de téléchargement de l’App « Remote Desktop », pour les différentes plateformes :

• Télécharger Remote Desktop pour Mac OS X
• Télécharger Remote Desktop pour Android
• Télécharger Remote Desktop pour iOS

 

Session Bureau à distance « Windows 7 » sur un Smartphone « Samsung »

 

Après avoir sorti cette App « Cross-Platform », Microsoft a commencé à travailler sur son client Web HTML5, appelé RD (Remote Desktop) Web Client 🙂

Ce client est proposé depuis RDS Windows Server 2016 sous forme d’extension/plug-in du service RD Web Access.

Nous allons découvrir à travers cet article comment installer et configurer ce nouveau client RD Web sous RDS 2016.

Let’s Do It !

 

Prérequis

Le déploiement du client RD Web nécessite un certain nombre de prérequis, à savoir :

• Votre (ou vos) Serveur(s) RD Web Access doit exécuter (à minima) Windows Server 2016 (ou 2019)
• Votre déploiement RDS 2016 doit comporter (au moins) une Passerelle RDS
• Les CAL RDS installées doit être de type « Par-Utilisateur« 
• Les certificats SSL configurés pour la Passerelle RDS et le Serveur RD Web Access doit être délivrés et signés par une CA (Certification Authority) valide Publique : les certs SSL auto-signés empêchent l’utilisation du client RD Web
• Seuls les connexions provenant des OS Suivants seront acceptés par le Client RD Web :
  • Windows 10
  • Windows Server 2008 R2 (ou ultérieur)

 

HowTo : Installer le client RD Web HTML5 sur un déploiement RDS 2016

Suivez les instructions suivantes pour installer correctement le client RD Web HTML5 au niveau de votre déploiement RDS 2016 :

• Tout d’abord, ouvrez une Session Windows sur le serveur RD Web Access
• Lancez Windows PowerShell en tant qu’Administrateur
• Saisissez la commande suivante pour mettre à jour le module « PowerShellGet« 

Install-Module -Name PowerShellGet –Force

Note : Saisissez Y (comme Yes) pour confirmer l’exécution de la commande

• Fermez la console PowerShell, et ré-ouvrez une nouvelle instance pour que l’Update du module PowerShellGet soit prise en compte
• Exécutez la commande suivante pour installer le Module de Gestion du client RD Web :

Install-Module -Name RDWebClientManagement

• Vous êtes invités à accepter les termes du contrat de Licence, saisissez A comme [All] et validez en cliquant sur Entrée :

• Vous devez ensuite exécuter la commande suivante pour installer la dernière version du client RD (Remote Desktop) Web :

Install-RDWebClientPackage

• Une fois le Package du Client RD Web installé, exécutez la commande suivante et notez le résultat :

Get-RDWebClientPackage

Maintenant, vous devez exporter le certificat SSL utilisé par votre service Broker. Ouvrez une Session Windows sur le Serveur Broker et lancez la console (snap-in) MMC > Ajouter « Certificats » > pour le « Compte d’Ordinateur » > Développez « Personal >> Certificats »

Faites un clic-droit sur le certificat utilisé par le service Broker. Dans l’exemple suivant, un seul certificat (rdgateway-hk.corp) a été utilisé pour signer tous les échanges Broker/RDWeb/RDG

• Le fichier .Cer a été exporté et placé dans C:\
• Le fichier .Cer exporté précédemment (C:\rdgateway-hk.cer) sera utilisé lors de la prochaine opération pour prendre en charge l’authentification SSO depuis le Client RD Web.
• Exécutez la commande suivante en spécifiant l’emplacement vers lequel le .Cer a été exporté et placé :

Import-RDWebClientBrokerCert C:\RDGateway-hk.cer

• Enfin, exécutez la commande PS suivante pour publier le nouveau client RD Web :

Publish-RDWebClientPackage -Type Production –Latest

Note importante : cette commande doit être exécutée si vous devez déployer le client RD Web dans un environnement de production, si vous souhaitez simplement « PoKé » le client RD Web sur un environnement de Test/Dev/Hom, exécutez plutôt la commande suivante :

Publish-RDWebClientPackage -Type Test –Latest

 

Let’s Test tout ça :).

Pour se connecter à votre client RD Web, la syntaxe de l’URL à utiliser est la suivante :

• Si Installation en Production (paramètre -Type Production)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient

• Si Installation en environnement de Test (paramètre -Type Test)

https://FQDN-de-votre-RDWebAccess.com/RDWeb/WebClient-Test

Dans l’exemple suivant, je me connecte sur mon portail RD Web Access hébergé dans Azure. Comme illustré dans la capture d’écran ci-dessous, je suis connecté sur https://rdgateway-hk.xxxxxxxx.com/RDweb/webclient :

Une fois authentifié sur le Portail, je retrouve toutes mes Applis publiées (RemoteApps) :

Je lance une RemoteApp (Server Manager dans l’exemple suivant) …. :

Une fois lancé, je retrouve ma RemoteApp (Server Manager) depuis mon client RD Web.

Comme vous pouvez le voir, le client « lourd » local (MSTSC.exe) n’est pas lancé/utilisé, et je suis dans un mode « Full Web » 🙂 :

J’ai aussi lancé une instance WordPad 🙂 :

N’hésitez pas à publier vos RemoteApps favorites et les tester depuis le client RD Web.

Enjoy :).

 

Note : Un nouvel article sur le RD Web Client sous RDS 2019 arrive bientôt. Stay connected.

#HK

[Remote Desktop Services sous Windows Server 2019] What’s New ?

Printf « Hello RDS Guys ^__^ »

Comme vous le savez, Windows Server 2019 est disponible (GA > Generally Available) depuis début Octobre.

Note : consultez cet article pour en savoir plus

Plusieurs améliorations ont été apportées au rôle R(remote) D(esktop) S(ervices) sous Windows Server 2019, cela concerne la partie Server (RD Servers), End-User (Experience Utilisateur) mais aussi la partie intégration avec le Cloud (Azure bien évidemment :)).

Je vous présenterai donc à travers cet article toutes les nouveautés introduites avec RDS Windows Server 2019 et ce qu’il faut retenir pour vos prochains projets de migration vers RDS 2019.

 

Les « Areas » de développement

L’équipe RDS Corp a focalisé sur efforts sur les axes de développement suivants :

• Simplifier la gestion d’une infrastructure RDS
• Améliorer l’expérience utilisateur
• Améliorer la sécurité des environnements RDS
• Faciliter l’intégration d’une infra RDS avec le Cloud (Azure)

 

Gestion simplifiée d’une infrastructure RDS

Deux améliorations majeures à noter :

• La première concerne le service RDLS (Remote Desktop Licensing Server)
• La deuxième est relative aux applications publiées (RemoteApp) jugées comme « Slow RemoteApp Experience« 

RD Licensing Server : HA & Mode Offline Active Directory

Enfinnnnnnnn du HA pour le RDLS :xD

Avec RDS 2019, vous pouvez désormais configurer le service RD Licensing dans un vrai mode « HA : High Availability ».

Avec les versions RDS 2016, 2012 R2 ou encore 2012, la seule possibilité permettant la redondance du service RDLS consistait à déployer deux serveurs RDLS (ou +) et y installer la même quantité de CAL pour permettre une continuité de service en cas de perte d’un des deux serveurs.

Avec RDS 2019, il est désormais possible de configurer le service de Licensing RDS en mode HA avec une Built-in Feature, similaire à celle du Broker. Vous aurez donc besoin d’une instance SQL pour héberger la base de données RDLS-HA qui stockera la configuration de la haute disponibilité du service RDLS.

En outre, une nouvelle amélioration pour le service RDLS a été introduite avec Windows Server 2019, il s’agit de la prise en charge d’un Mode « Offline Active Directory« .

Je m’explique :

Sur les anciennes versions RDS (2016 et antérieur), le rôle RDLS avait toujours besoin d’accéder aux services d’annuaires Active Directory (ADDS) et plus précisément d’une connectivité avec un Domain Controller pour mettre à jour certains attributs AD avec les informations relatives aux Licences Utilisateurs (CAL RDS Per-User), avec RDS 2019 cela n’est plus nécessaire. En effet, un RDLS supporte désormais un mode « AD Offline » et peux mettre à jour les informations de Licensing d’un user RDS sur ses propriétés AD sans avoir besoin de contacter un DC.

Nouvelle API PerfMon pour les « Slow RemoteApp »

Des nouveaux compteurs de performances ont été ajoutés pour RDS 2019 à travers une nouvelle PerfMon API (Application Programming Interface). Ces compteurs vous aideront à collecter les données/informations (metrics et autres) liées aux RemoteApp présentant des problèmes de stabilité et de performance pour diagnostiquer et améliorer l’expérience utilisateur.

 

Expérience Utilisateur améliorée

Toujours dans un souci d’amélioration de l’expérience utilisateur, Microsoft a bien travaillé la partie End-User Experience pour les environnements RDS 2019, résultats :

• Ajout de Notifications « Modernes » sur les Sessions Bureau à distance et plus précisément au niveau du « Centre de Notifications », le but étant d’améliorer l’utilisation des RemoteApp telles que Microsoft Outlook ou encore Teams.
• La redirection des « Caméras » intégrées ou externes (USB) vers une Session RDS est désormais possible : Vous pouvez rediriger jusqu’à 8 Caméras sur une Session Bureau à distance :

• Des nouvelles améliorations ont été apportées au niveau du DDA (Discrete Device Assignment) sous RDS 2019 pour augmenter le niveau de sécurité et assurer une meilleure isolation des VMs. Ces améliorations des technologies de virtualisation des GPU se traduiront par une réduction du trafic réseau et une lecture vidéo plus fluide.

• Enfin, l’utilisation du CPU et la Bande Passante sur le client Web et Serveur RDSH ont été réduites, cela permet une meilleure expérience des utilisateurs se connectant via le nouveau Client Web.

 

Plus de sécurité avec RDS 2019

L’équipe produit RDS a également concentré ses efforts sur l’aspect « Sécurité ».

La sécurité RDS a été amélioré à travers :

• L’Intégration avec « Windows Admin Center » : cela vous permet de regrouper tous les serveurs Remote Desktop locaux et distants (RD Broker, Web Access…) en une seule console et les gérer de manière centralisée
• L’Optimisation de Windows Defender pour prise en charge du Multi-Session et une meilleure sécurité des environnements Bureau à distance
• Le RD Web Client prend désormais en charge le SSO (Single Sign-On) pour simplifier le processus d’authentification et rendre l’expérience utilisateur meilleure pour les clients se connectant via le Client Web
• De nouvelles fonctionnalités de sécurité comme par exemple le chiffrement DTLS (Datagram Transport Layer Security) qui peut être activé facilement pour renforcer la sécurité au niveau de vos déploiements RDS.

 

RDS 2019 & Microsoft Azure

La vision de Microsoft depuis la sortie de Windows Server 2016 déjà, était de pousser ses clients à déployer RDS dans Azure.

En effet, avec RDS 2016, vous aviez déjà la possibilité de configurer le service Broker en mode HA en utilisant l’offre PaaS (Platform-as-a–Service) Azure qu’est Azure SQL Database.

L’utilisation du Cloud Azure offre plusieurs avantages par rapport à un hébergement traditionnel (dans un Datacenter OnPrem > sur du VMware vSphere ou Hyper-V Server) :

• Réduction des coûts : en utilisant le Cloud Azure, vous passez généralement du mode CAPEX (investissement dans le matériel & logiciel) au mode OPEX (consommation). Avec Azure, vous êtes généralement dans un mode « Pay-as-you-go », cela veut dire que vous payez uniquement les ressources Azure (Compute/VM, Stockage, Réseau…) quand celles-ci sont utilisées (eg : je consomme mes services RDS uniquement du Lundi au Vendredi de 8h à 18h).
• Tirer profit de la puissance de calcul du Cloud, de la scalabilité, flexibilité et agilité
  • Eg : vous pouvez configurer vos VM avec du scaling-out & down pour que vos serveurs RDS peuvent monter en charge (de manière automatique) quand des pics d’activité se présentent et redescendre à leur configuration initiale quand une baisse de charge a lieu. Dans un mode traditionnel, vous devez rajouter de la RAM, vCPU voire acheter un nouveau matériel (serveur, changer le type de la carte réseau…etc)
• Réduction MCO/Effort de gestion : Azure étant une plateforme de Cloud Publique, toute l’infrastructure physique Serveur/Storage/Network est gérée et maintenue par l’éditeur (MS), vous n’avez donc plus à vous soucier des pannes matérielles, maintenances à planifier …Etc
• …

Pour faciliter l’adoption du Cloud Azure, Microsoft a introduit un mode « RDS Hybride ». En effet, l’infrastructure RDS 2019 peut désormais être déployée en mode « Hybride », mode dans lequel les serveurs RD Connection Broker, Web Access et Gateway sont hébergés dans Azure et les Hôtes de Session hébergés dans votre Datacenter local.

 

Prise en charge  {Azure Key Vault} & {Azure SQL Database}

Une des améliorations majeure quant au déploiement du rôle RDS dans Azure est l’intégration avec le service « Azure Key Vault ».

Azure Key Vault est la solution de « Key Management » d’Azure qui vous permet de stocker de manière sécurisée vos clés de chiffrement, Codes/Secrets/Crédentials…etc

Dans le cadre d’un déploiement RDS, les certificats SSL utilisés pour chiffrer les différents échanges au niveau de la Gateway, Web Access et RD Publishing/SSO peuvent désormais être stockés dans un Azure Key Vault.

Note : je prépare un Step-by-step guide à travers lequel je vous détaillerai comment utiliser Azure Key Vault pour stocker les certificats SSL RDS, il sera bientôt publié sur mon Blog So Stay Connected :).

 

De plus, Azure SQL Database peut héberger vos bases de données RDCB et RDLS HA, cela vous évite le déploiement d’une infrastructure SQL OnPrem dédiée (et complexe :)).

Enfin, Microsoft promets un nouveau model de Licensing RDS sur Azure à travers le Programme CSP (Cloud Solution Provider), nous aurons plus d’informations sur le sujet bientôt, fin Octobre normalement.

 

Useful Informations /Documentations

Pour les personnes n’ayant peu ou pas de connaissance sur les services Azure cités plus haut, je vous invite à consulter les liens suivants :

• Documentation Azure SQL Database
• Documentation Azure Key Vault

Je suis en train de finaliser plusieurs articles autour de RDS 2019, abonnez-vous sur mon Blog (si ce n’est pas déjà fait :)) pour rester informé de tout nouvel article publié.

A bientôt

#HK

[Matrice de Flux pour vos infrastructures RDS (2008 Rx, 2012 Rx, 2016) sur Azure et OnPrem] Liste des ports que vous devez connaître pour vos services RDS en DMZ

 

Certains clients disposant d’une zone démilitarisée (ou DMZ pour Demilitarized Zone) et désirant déployer une infrastructure RDS avec une ou plusieurs Passerelles RDS (RDG : Remote Desktop Gateway) et serveurs RDWA (Remote Desktop Web Access) se posent souvent la question suivante :

Quels sont les (ports) requis à ouvrir pour permettre à tous les services de rôles RDS de communiquer correctement ?

Cette communication concerne principalement les serveurs RDG et RDWA placés en DMZ avec les autres services de rôles RDS en back-end, placés généralement sur le réseau interne de l’entreprise et se trouvant derrière un ou plusieurs Firewalls, notamment les serveurs Hôtes de Session (RDSH : Remote Desktop Session Host) et serveurs Broker (RDCB : Remote Desktop Connection Broker).

Vu que le serveur de Passerelle RDS doit être membre du domaine AD (Workgroup non supporté !), les flux avec les Contrôleurs de domaine AD (DC : Domain Controllers) sont nécessaires, et ce pour authentifier les utilisateurs distants (externes) et les autoriser à accéder aux ressources RDS internes.

Dans ce type d’architecture (scénario de déploiement), plusieurs ports sont à ouvrir pour permettre à la Passerelle RDS de remplir les fonctions suivantes:

• Authentifier les utilisateurs distants/externes RDS
• Autoriser les utilisateurs distants/externes RDS à accéder aux ressources internes publiées
• Résoudre les noms DNS des ressources RDS internes
• Forwarder (au Broker) les packets RDP envoyés par les clients distants.
• Obtenir la liste des Révocations de Certificats SSL
• Envoyer des requêtes RADIOS (si vous déployez un serveur NPS central)

 

Pour simplifier la compréhension de la matrice de flux « global », j’ai décidé de créer deux catégories de Flux, à savoir :

Flux entre « External Network » et la Passerelle RDS placée en DMZ : config au niveau du Firewall Externe

Flux entre la « Passerelle RDS » et les ressources internes (RDSH, RDCB, DC…) : config au niveau du Firewall Interne

Le diagramme Visio ci-dessous représente une architecture RDS classique avec RDG/RDWA en DMZ et le reste des services de rôles en interne

Flux entre « External Network » et la Passerelle RDS placée en DMZ : Pare-feu Externe

Déployer une Passerelle RDS vous évite d’exposer directement vos ressources RDS à Internet et les protéger contre plusieurs types attaques informatique (e.g DoS/DDoS Attack !).

La Passerelle RDS a besoin du serveur Web IIS (Internet Information Services) pour fonctionner.

Le WebSite RDG hébergé sur IIS nécessite une liaison « HTTPS », par conséquent le port de communication (d’écoute) utilisé par la RDG est le 443.

Vous aurez compris, pour autoriser le trafic HTTPS entrant et permettre une communication entre les clients externes et la Passerelle RDS placée en DMZ (derrière un Firewall Externe/Public), la règle suivant doit être créée/configurée :

Nom de la règle : External_to_RDG (nom de règle donné à titre d’exemple)

Port : 443/TCP

Protocol : HTTPS

Source : Internet

Destination : @IP de la Passerelle RDS placée en DMZ

 

Flux entre la « Passerelle RDS » placée en DMZ et les ressources internes (RDSH,RDCB,DC…) : Pare-feu Interne

Le Pare-feu Interne doit être configuré pour autoriser plusieurs types de communications (trafics) entre le ou les serveurs RDG placés en DMZ et vos ressources internes tels que les Domain Controller (pour authentification/autorisation), Serveurs Broker (redirection aux ressources RDS), Serveurs RDSH (accès aux ressources publiées).

Trafic lié à l’authentification  & autorisation via la Passerelle RDS

#Kerberos

La règle à mettre en place pour autoriser le trafic (Kerberos) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’authentifier les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 88/TCP

Protocol : Kerberos

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#Service RPC NT Directory Service (NTDS) 

Le serveur RDG a également besoin de communiquer avec le service RPC NTDS (NT Directory Services) lié à l’AD, ce dernier écoute généralement sur un numéro de port non utilisé et pris d’une plage de ports haute. Le serveur RDG n’ayant pas la capacité de connaitre ce numéro de port (dynamic port) utilisé par le service RPC NTDS, il contacte le Mappeur de point de terminaison RPC (RPC Endpoint Mapper) en utilisant le port 135, l’Endpoint Mapper indique ensuite au serveur RDG le port d’écoute pour le service demandé qu’est le RPC NTDS. Comme indiqué précédemment, ces numéros de ports sont attribués de manière dynamique (généralement compris entre 1024 et 65 535), notez qu’à l’aide d’une clé de Registre, vous pouvez configurer un port « Statique » pour le RPC NTDS si nécessaire. Je vous laisse consultez cet article pour en savoir plus.

Nom de la règle : RDG_to_RPCMapper (nom de règle donné à titre d’exemple)

Port : 135/TCP + Port d’écoute configuré pour le service RPC NTDS

Protocol :RPC Endpoint Mapper + RPC NTDS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#LDAP

La règle à mettre en place pour autoriser le trafic (LDAP) entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne afin d’autoriser les utilisateurs distants est la suivante :

Nom de la règle : RDG_to_InternalDC (nom de règle donné à titre d’exemple)

Port : 389/TCP et 389/UDP

Protocol : LDAP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs 

 

#DNS

La règle à mettre en place pour autoriser le trafic DNS entre la Passerelle RDS placée en DMZ et le(s) Contrôleur(s) de domaine interne et permettre la résoudre des noms DNS des ressources internes :

Nom de la règle : RDG_to_DNS (nom de règle donné à titre d’exemple)

Port : 53/TCP et 53/UDP

Protocol : DNS

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP du(es) DCs_ou un des serveurs DNS du réseau

 

#RDP

La règle à mettre en place pour autoriser le trafic RDP entre la Passerelle RDS placée en DMZ et les serveurs RDS internes pour forwarder les packets RDP reçus par les clients distants :

Nom de la règle : RDG_to_RDSHCB (nom de règle donné à titre d’exemple)

Port : 3389/TCP

Protocol : RDP

Source :@IP de la Passerelle RDS placée en DMZ

Destination : @IP des serveurs RDSH ainsi que RDCB

 

Note importante : si le port RDP par défaut, a été personnalisé/changé sur le déploiement RDS (e.g 33381 au lieu de 3389), le port 33381 doit être spécifié dans la règle ci-dessus.

Trafic entre le serveur RD Web Access et les serveurs RDSH internes

Si vous avez décidé de placer votre ou vos serveurs RD Web Access en DMZ (chose que je vous recommande d’ailleurs :)), notez qu’un seul flux est à ouvrir :

Nom de la règle : RDWA_to_RDCB (nom de règle donné à titre d’exemple)

Port : 5504/TCP

Protocol : RPC

Source :@IP du ou des serveurs RDWA placés en DMZ

Destination : @IP du(es) serveurs RDCB

 

J’espère que cet article pourra vous être utile lors du Design de votre infra RDS et/ou rédaction de votre document d’architecture technique/DAT/TAD (RDS Network Considerations Section).

Notez que des ports supplémentaires peuvent être requis si vous disposez d’une plateforme RADIUS, ou utilisez par exemple des solutions « Third-party » pour l’authentification/autorisation (dans ce cas, referez-vous à la documentation technique fournie par l’éditeur de solution pour en savoir plus).

Keep in touch,

A bientôt

#HK

[TSE & RDS Licensing] Matrice d’Interopérabilité : s’applique à Windows Server 2000 à 2016

Les questions suivantes m’ont souvent été posées par mes différents clients et partenaires :

Puis-je réutiliser mes anciennes CAL TSE/RDS et les réinstaller sur un nouveau serveur exécutant une version d’OS Windows Server différente à celle du serveur « Source/existant »?

Puis-je utiliser mes CAL TSE/RDS existantes pour autoriser mes utilisateurs RDS à se connecter à des serveurs TSE/Hôtes de Session (RDSH) exécutant des versions Windows Server différentes ?

J’ai donc décidé de rédiger ce post pour y répondre car cela pourrait intéresser plusieurs personnes se posant les mêmes questions :).

Ma réponse sera « Splitée » en deux parties :

• Compatibilité des CAL TSE/RDS pour les serveurs de Licence RDS (RDLS)
• Comptabilité des CAL TSE/RDS pour les serveurs Hôte de Session (RDSH

 

Note importante : les informations détaillées ci-dessous s’applique à vos serveurs de Licence RDS et RDSH hébergées dans vos Datacenters mais aussi ceux qui tournent sous forme de VM IaaS Azure (ou AWS, GCP, AliBabaCloud…Etc)

 

#R1 : Liste des CAL TSE/RDS pouvant être installées sur chaque version d’OS Windows Server 

Le tableau ci-dessous vous montre les CAL TSE et RDS pouvant être installées/utilisées sur chaque version d’OS Windows Server hébergeant le service de Licensing RDS (RDLS : Remote Desktop Licensing Server) :

Pour vous aider à mieux comprendre le tableau, je vous détaillerai un vrai « Use Case »:

Supposons qu’un Client (Société) X dispose déjà d’un Pack de Licences RDS 2008 R2 et est sur le point de dé-commissionner son infrastructure RDS 2008 R2 pour en déployer une nouvelle sous 2012 R2 ou 2016. Comme indiqué dans le tableau ci-dessus, les CAL RDS « 2008 et 2008 (R2) » peuvent être installées sur les OS Windows Server suivants : 2008, 2008 R2, 2012, 2012 R2 et 2016. Cette société pourra donc continuer à utiliser (en réinstallant) les Licences RDS 2008 R sur tout futur serveur de Licence RDS exécutant Windows Server 2008 à 2016.

#R2 : Liste des CAL TSE/RDS pouvant être utilisées pour autoriser vos utilisateurs RDS à se connecter sur un serveur RD Session Host

Le tableau ci-dessous vous montre les CAL TSE et RDS pouvant être installées/utilisées pour autoriser vos utilisateurs distants à se connecter aux serveurs TSE/RDSH en fonction de la version d’OS Windows Server qui exécutent :

[Remote Desktop Services] What’s New from Microsoft RDS Team : Améliorations et Upcoming Updates !

Scott Manchester, RDS PPM (Principal Program Manager) vous explique les Upcoming Updates pour RDS (Securité, Cloud, MFA, Scalability …Etc)

Watch & Enjoy 🙂

HowTo : Personnaliser le lien « Aide » du Portail RD Web Access 2012, 2012 R2 et 2016

 

Une question intéressante m’a été posée récemment par un de mes clients :

Est-il possible de modifier le lien du bouton « Aide » du Portail RD Web Access ?

Eh bien, la réponse est Oui 🙂

Vous pouvez presque tout modifier sur le Portail RD Web Access 2012, 2012 R2 mais aussi 2016.

What is The default Link déjà ?

Notez que par défaut, le lien programmé sur le bouton « Aide » est le suivant :

http://go.microsoft.com/fwlink/?LinkId=141038

Cette URL renvoie simplement vers une KB OnLine décrivant les RemoteApps et leur fonctionnement depuis le Portail RD Web Access, le lien de redirection est le suivant :

https://technet.microsoft.com/en-us/library/ff608240(WS.10).aspx?ocid=fwlink

Le besoin de mon client était de remplacer ce lien par l’URL de sa plateforme de Ticketing /Support (GLPI).

Solution ?

Le lien « Aide » a d’abord été renommé en « Support », cela permettra aux End Users rencontrant des problèmes (utilisation, fonctionnement) sur le Portail RD Web Access d’avoir un lien unique pour la création de ticket de support.

Maintenant, pour changer l’Hyperlink du bouton « Support » et spécifier une URL personnalisée, suivez les instructions suivants :

Note importante : je vous recommande de sauvegarder le dossier C:\Windows\Web\RDWeb avant d’apporter toute modification aux fichiers de configuration du Portail RD Web. Donc commencez par faire une copie /sauvegarde de ce dossier avant d’appliquer la procédure décrite ci-dessous :

• Ouvrez une Session Windows sur le serveur RD Web Access et naviguez jusqu’au : C:\Windows\Web\RDWeb\Pages\fr-FR (ou C:\Windows\Web\RDWeb\Pages\en-US si votre OS Server est en EN’glais)
• Editez le fichier Login.aspx (de préférence à l’aide de Notepad++)
• Allez à la ligne N° 91 (sHelpSourceServer = ….) et remplacez l’URL http://go.microsoft.com/fwlink&#8230;.. par votre URL.

• Dans l’exemple suivant, l’URL http://glpi.BecomeITExpert.com sera spécifiée. Enregistrez la modification (File > Save) et fermez le fichier Login.aspx
• Reconnectez-vous sur le portail RD Web Access et cliquez sur le Lien « Aide » (Support dans l’exemple suivant), et constatez la redirection vers l’URL spécifiée :

That’s All :).

J’espère que cette astuce pourra vous être utile.

D’autres RDS Tips & Tricks arrivent prochainement, so stay in touch

HK | Just Another IT Guy | Twitter | LinkedIn