[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é

[RDS – Tip Of The Week] HowTo : Transférer des fichiers volumineux (+2 GB) via RDP

Bonjour tout le monde,

Voici notre « RDS Tip of The Week » :

Comment transférer des fichiers/données de plus de 2GB via RDP

 

Description de la limitation /problème

Il existe une limitation relative au protocole RDP quand il s’agit de transférer des données/fichiers volumineux via une Session Bureau à distance.

Si vous avez déjà essayez de transférer des fichiers volumineux (+ 2 GB), le message d’erreur suivant vous est retourné (Error Copying File or Folder « Unspecified Error« ):

 

Solution (HowToFix)

Il existe deux techniques permettant de contourner ce problème :

• Transférer vos données via la « la Redirection de disque local » mappé directement sur votre Session Bureau à distance
• Transférer vos données via un Partage UNC (\\tsclient\C$)

 

Perso, j’utilise la redirection de mes disques locaux vers la Session Bureau à distance pour transférer des données volumineuses, par XP, je trouve que c’est plus stable & fiable.

Si votre infra RDS se trouve en Back-end derrière une Gateway RDS, tout le traffic RDP est encapsulé over HTTPS, il s’agit du même principe qu’un service STaaS (STorage-as-a–Service) tel que OneDrive ou Dropbox. Les protocoles de partages réseaux (eg : SMB/445 TCP) ne sont jamais exposés à Internet, tout le traffic passe à travers le canal HTTPS.

De plus, accéder à un \tsclient\c$ nécessite des privilèges « LocAdmin », si des utilisateurs standards doivent transférer des données via RDP, il suffit de configurer (autoriser) la Redirection de disque local sur la machine cible, aucun privilège « Admin » n’est requis, ils doivent simplement appartenir au groupe local « Remote Desktop Users » sur la machine cible.

Voyons comment ça marche.

Depuis la machine qui héberge les données/fichiers à transférer, lancez l’outil MSTSC.exe, depuis « Ressources locales« , > « Autres » > « Lecteurs » > cochez le lecteur/disque contenant vos données à transférer pour le rediriger vers la Session RDS (C: dans l’exemple suivant) :

Une fois connecté sur votre session Bureau à distance, ouvrez Windows Explorer (Drapeau+E) et vérifiez que votre ou vos lecteurs locaux ont bien été redirigés :

Enfin, cliquez sur votre lecteur redirigé et copiez/collez vos données sur le Windows Desktop de la session RDS (ou Documents..etc) :

Et voilà le tour est joué :).

A bientôt,

#HK

 

[Remote Desktop Client – What’s New] Le Client Web Remote Desktop « HTML5 » bientôt disponible !

Le Remote Desktop est une technologie utilisée aujourd’hui par la quasi-totalité des entreprises, que ce soit pour du support technique (Session Shadowing pour les end-users) ou pour permettre aux téléworkers d’accéder aux applications d’entreprise.

Microsoft propose depuis plusieurs années déjà, une application « Lourde » nommée Microsoft Remote Desktop pour différentes plateformes (Cross-Platform Remote Desktop Client) :

Mac OS

Télécharger Microsoft Remote Desktop pour MacOS X

Android

Télécharger Microsoft Remote Desktop pour Android

iOS

Télécharger Microsoft Remote Desktop pour iOS

Avec l’arrivé du Cloud, la vision (à court terme) de plusieurs décideurs informatique, est de proposer à leur End-users un environnement « Full Cloudisé » et uniquement un client léger (e.g : Chrome Book) pour l’accès aux applications hébergées dans le Cloud (SaaS Apps : Software-as-a-Service Applications).

Avec cette vision, aucun client « Lourd » ou application locale ne doit être installée sur le poste client (Thin Client). L’accès se fait principalement depuis un Web Browser.

Pour répondre à ce type de besoin (ou d’architecture), Microsoft a introduit le nouveau Remote Desktop Web nommé « RD Web Client ». Ce client Web est basé sur HTML5 et prend en charge la plupart des navigateurs Web (Edge, IE, Chrome, Firefox, etc.).

Selon les informations communiquées par l’équipe Remote Desktop Services Corp, RD Web Client ne prend malheureusement pas en charge les Clients « Mobile ».

RD Web Client est disponible (au moment de la rédaction du présent post) en Preview et supporte déjà les fonctionnalités classiques de l’outil RDC (Remote Desktop Connection : MSTSC.exe) telles que :

Clipboard (Copier/Coller)

Redirection d’imprimante

Remote Audio

 

Prerequis à prendre en considération 

Pour pouvoir déployer le Client Web Remote Desktop, votre infrastructure RDS cible doit remplir les conditions suivantes :

Tous les serveurs RDS du déploiement (RDCB, RDSH, RDWA et RDG) doivent exécuter Windows Server 2016.

Votre déploiement RDS ne doit pas être configuré avec des CAL RDS « Per-Device /Par-Périphérique »

La  KB4025334 doit être installée sur votre serveur RDG (Remote Desktop Gateway).

Les serveurs RD Web Access et Gateway doivent utiliser des certificats SSL signés par une CA (Certification Authority) Publique.

Enfin, côté client, il faut bien évidemment utiliser des Web Browsers prenant en charge de la HTML5. IE11, Edge, Chrome, Firefox et Safari le sont, donc all is Ok :).

 

Installation du RD Web Client

Je détaillerai l’installation du Client Web Remote Desktop lors d’un prochain post, comme expliqué précédemment, il est aujourd’hui en « Preview Version ». Je publierai un HowTo détaillé directement sur la Finale Preview ^_^.

Ce que vous devez savoir, c’est que le RD Web Client est simplement une Extension à ajouter au niveau du service de rôle « RD Web Access ».

L’équipe RDS Corp travaillent sur une nouvelle Cmd-let qui permettra de faciliter le déploiement de ce client : Install-RDWebClientPackage

L’affichage des ressources RDS déportées directement sur le RD Web Client ressemble à l’image ci-dessous :

Je vous en dirais pas plus :),

Keep in touch

#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 :

[OS Hardening] Checklist que vous devez connaître pour mieux sécuriser votre infrastructure Windows Server 2016

Avant de déployer vos serveurs Windows Server 2016, je vous invite à consulter la Checklist ci-dessous.

Celle-ci contient + de 70 paramètres de sécurité & hardening Windows vous permettant de mieux protéger et sécuriser vos plateformes Windows Server 2016.

Note : 90% des paramètres /options listés ci-après d’applique également à Windows Server 2012 R2/2012 mais aussi 2008 R2/2008.

 

Informations techniques

Nom du serveur
Adresse MAC
Adresse IP
Masque de sous-réseau
Passerelle par défaut
Serveur DNS #1
Serveur DNS #2
Compte Administrateur local
VM (Oui /Non)		Si Physique, Asset TAG :
RAM
CPU
Nombre de Disques /vDisques
Configuration RAID
LAN /VLAN
Date

Checklist

Etape	Action	Statut	Commentaire
	Préparation & Installation
1	Si nouvelle installation, isoler le serveur du réseau jusqu’à ce qu’il soit protégé et sécurisé (voir sections suivantes)
2	Utiliser l’Assistant Configuration de la Sécurité (SCW : Security Configuration Wizard) pour créer et configurer une stratégie de sécurité à appliquer sur le serveur.
	Services Packs & Correctifs
3	Installer les derniers Services Packs et correctifs depuis Microsoft Windows Update (ou WSUS : Windows Server Update Services)
4	Configurer les notifications automatiques de la disponibilité des mises à jour et correctifs
	Stratégies de comptes utilisateurs
5	Définir une longueur minimale du mot de passe
6	Définir les exigences de complexité du mot de passe
7	Ne pas enregistrer les mots de passe en utilisant un chiffrement réversible
8	Définir un seuil et une durée de verrouillage des comptes
	Attribution des droits utilisateurs
9	Autoriser l’accès au serveur à partir du réseau aux administrateurs et aux utilisateurs authentifiés uniquement
10	Ne pas attribuer le droit « Agir en tant que partie du système d’exploitation » aux utilisateurs standards
11	Autoriser l’ouverture de session locale aux Administrateurs uniquement
12	Refuser le droit « Ouvrir une session en tant que Service » aux utilisateurs invités, et ce localement ou à distance via Connexion Bureau à distance.
	Paramètres de sécurité
13	Configurer un message d’avertissement à afficher lors de la tentative d’ouverture de Session. Celui-ci doit indiquer que l’accès au serveur est réservé aux personnes habilitées.
14	Ne pas autoriser les utilisateurs du réseau à créer et ouvrir une session à l’aide d’un compte Microsoft
15	Désactiver le compte « Invité »
16	Requérir la combinaison de touches Ctrl+Alt+Suppr pour les ouvertures de session interactives
17	Configurer la limite d’inactivité du serveur pour protéger les sessions interactives
18	Configurer le Client réseau Microsoft pour signer les communications numériquement (toujours)
19	Configurer le Client réseau Microsoft pour signer les communications numériquement (lorsque le serveur l’accepte)
20	Configurer le Serveur réseau Microsoft pour signer les communications numériquement (toujours)
21	Configurer le Serveur réseau Microsoft pour signer les communications numériquement (lorsque les clients l’acceptent)
22	Désactiver l’envoi de mots de passe non chiffrés à des serveurs SMB tiers
	Paramètres des journaux d’événements
23	Configurer une Taille maximale des journaux d’événements
24	Configurer une Méthode de conversation des journaux d’événements
25	Configurer une Durée de stockage des journaux d’événements
26	Configurer l’envoi de journaux
	Contrôles d’Accès au réseau
27	Désactiver la traduction de noms/SID anonymes
28	Ne pas autoriser l’énumération anonyme des comptes SAM et partages réseau
29	Ne pas attribuer et appliquer de permissions « Tout le monde » aux utilisateurs anonymes
30	Ne pas autoriser les canaux nommés qui sont accessibles de manière anonyme
31	Restreindre l’accès anonyme aux canaux nommés et partages
32	Ne pas autoriser l’accès aux partages réseau de manière anonyme
33	Requérir le partage « Classique » et Modèle de sécurité pour les comptes locaux
	Paramètres de Sécurité : Réseau
34	Autoriser « Système Local » à utiliser l’identité de l’ordinateur pour NTLM
35	Désactiver le recours session Local système NULL
36	Configurer les types de cryptage autorisés pour Kerberos
37	Ne pas stocker de valeurs de hachage de niveau LAN Manager
38	Configurer le niveau d’authentification LAN Manager pour autoriser NTLMv2 et refuser LM & NTLM
39	Activer le Pare-feu Windows sur les trois profils : Domaine – Privé – Public
40	Configurer le Pare-feu Windows pour bloquer tout traffic entrant sur les trois profils
	Paramètres de Sécurité : Connexions Bureau à distance
41	Activer l’authentification au niveau du réseau (NLA : Network Level Authentication)
42	Utiliser le niveau de chiffrement « Elevé » afin de protéger les données RDP à l’aide d’un chiffrement renforcé sur 128 bits
43	Configurer un certificat SSL sur le serveur et forcer l’utilisation de la couche de sécurité « SSL »
44	Toujours demander le mot de passe à la connexion
45	Configurer une Passerelle RDS pour gérer les accès depuis l’extérieur.
46	Si possible, forcer l’utilisation de l’authentification forte (e.i carte à puce)
47	Activer la fonctionnalité « Remote CredentialGuard »
	Paramètres de Sécurité : Serveur Membre du domaine AD
48	Chiffrer ou signer numériquement les données des canaux sécurisés (toujours)
49	Chiffrer numériquement les données des canaux sécurisés (lorsque cela est possible)
50	Signer numériquement les données des canaux sécurisés (lorsque cela est possible)
51	Exiger les clés de sessions fortes (Windows 2000 ou ultérieur)
52	Configurer le nombre de demandes d’ouverture de session précédentes à mettre en cache
	Paramètres de Stratégies d’Audit
53	Auditer les événements d’ouverture de session sur un compte
54	Auditer la gestion des comptes utilisateur
55	Auditer les ouvertures et fermetures de sessions
56	Auditer les changements de stratégie
57	Auditer l’utilisation des privilèges
	Paramètres de sécurité : OS
58	Si possible, convertir le serveur en mode « Core »
59	Désinstaller ou désactiver les services non utilisés
60	Désinstaller ou supprimer (binaires) tous les rôles et fonctionnalités non utilisés
61	Fermer tous les ports non utilisés
62	Supprimer ou désactiver les comptes utilisateurs non utilisés
63	Restreindre au maximum les droits aux utilisateurs du réseau
64	Vérifier que tous les volumes utilisent le système de fichier « NTFS »
65	Configurer les permissions au niveau du Registre
66	Si possible, désactiver l’accès distant au Registre
67	Installer et activer un anti-virus & anti-spyware
68	Configurer l’anti-virus & anti-spyware pour se mettre à jour automatiquement
69	Configurer la date & heure système, synchroniser ensuite l’horloge avec un serveur de temps (Serveur NTP : Network Time Protocol)
70	Si possible, activer le chiffrement de lecteur BitLocker
	Sécurité Physique
71	Protéger l’accès au BIOS à l’aide d’un mot de passe
72	Protéger l’accès aux consoles de gestion (e.i console iLO) à l’aide d’un mot de passe
73	Ne pas autoriser l’arrêt du système sans avoir ouvert de session Windows
74	Configurer l’ordre de boot pour éviter tout démarrage d’un média non autorisé
75	Configurer un écran de veille pour verrouiller l’écran (affichage) après un certain temps d’inactivité
	Informations additionnelles
76	Utiliser l’outil MBSA (Microsoft Baseline Security Analyzer) pour analyser et auditer la sécurité de votre serveur

 

Télécharger ce document (format PDF)

Cette Checklist est disponible (format PDF) en téléchargement gratuit depuis la Gallery TechNet.

Vous pouvez download le document ici.

Bonne lecture.

Vos feedbacks sont les bienvenus :).

#HK

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….. 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

[eBook /Book] RDS Windows Server 2016 – Déploiement et Administration en Entreprise [2ème Edition]

J’ai l’immense honneur de vous annoncer la disponibilité de la seconde Edition de mon « Best-selling » eBook : RDS Windows Server 2012 R2.

Cette nouvelle édition voit le jour suite au succès de la première Edition (+ de 1000 ventes réalisées :)), je tiens à remercier tous les abonnés /followers et surtout toute personne ayant acheté et participé au succès de la première édition

Merci encore :).

2ème Edition, What’s New ?

Cette deuxième édition traite toutes les nouveautés introduites avec RDS Windows Server 2016. e.g : l’utilisation de la solution RDS sur Azure (RDS VDI avec un Windows 10 as a Service :))

En outre, j’ai décidé de créer un nouveau chapitre dans lequel j’ai regroupé tous les « Trucs & Astuces » liés à RDS 2016.

Plusieurs chapitres et sous-chapitres ont été ajoutés à cette deuxième édition, à savoir :

• CHAPITRE 16. DEPLOYER VOTRE INFRASTRUCTURE RDS VDI SUR AZURE
• RDS Virtual Desktop Infrastructure et Azure
• HowTo : Déployer votre infrastructure RDS VDI 2016 sur Azure

 

• CHAPITRE 17. CONFIGURER RDS 2016 AVEC AZURE SQL
• Préparez votre « Bac à sable » sur Azure
• Création de la base de données Azure SQL pour le RDCB HA
• Configuration de l’équilibrage de la charge
• Installation des agents SQL Native Client sur chaque VM Azure RDCB Server
• Installation de Microsoft ODBC Driver 13.1 pour SQL Server sur chaque RDCB Server (VM Azure)
• Configurer la haute disponibilité du service RDCB sur Azure
• Sizing de la base de données SQL Azure

 

• CHAPITRE 18. PENSEZ A DEPLOYER VOS SERVEURS RDS EN MODE « CORE »
• Services de rôles RDS pris en charge par Windows Server Core 2016
• Gérer vos serveurs RDS Core à distance
• Depuis un Serveur d’Administration
• Depuis une machine cliente d’Administration

 

• CHAPITRE 20. TIPS & TRICKS RDS QUE VOUS DEVEZ CONNAITRE
• HowTo : Effacer l’historique des connexions Bureau à distance
• Méthode #N°1 : via RegEdit.exe (Edition de la BDR)
• Méthode #N°2 : via Script
• HowTo : Publier des RemoteApps et Bureaux Windows sur la même Collection de Session
• Méthode #N°1 : via les Propriétés de la Collection
• Méthode #N°2 : via RegEdit.exe (Edition de la BDR)
• Méthode #N°3 : via Script
• HowTo : Configurez l’Auto-Logon sur le Portail RD Web Access
• Pensez à utiliser l’outil RDCMan (Remote Desktop Connection Manager)

 

• CHAPITRE 21. LISTE DES SCRIPTS ET OUTILS RDS QUE VOUS DEVEZ AVOIR DANS VOTRE TOOLBOX
• Scripts pour le rôle « Remote Desktop Services »
• Outils de déploiement RDS : RDS-O-Matic
• Outils de gestion et administration RDS
• Outils de sécurisation RDS
• Outils de diagnostic et dépannage RDS

 

Enfin, plusieurs « HowTo » vous permettant d’apporter une personnalisation complète sur votre Portail RD Web Access sont détaillées dans cet ouvrage. Cf « CHAPITRE 15. PERSONNALISER VOTRE PORTAIL RDWA »

N’attendez plus pour vous former sur RDS 2016, updatez vos Skills RDS et devenez un « Real RDS Expert » grace a cet eBook.

L’eBook est disponible sur BecomeITexpert.com, cliquez sur l’image ci-après pour en savoir plus :

OFFRE SPECIALE !

Pour tout achat avant la fin de l’année (au plus 30/12/2017), un ticket de support (par mail /tel /skype) vous est offert gracieusement :). Donc vous pouvez faire appel à moi pour vous aider dans le design, architecture, déploiement ou simplement troubleshooter votre infrastructure RDS 2016 (OnPrem ou Cloud).

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

 

S’applique à : RDS Windows Server 2012, RDS Windows Server 2012 R2 et RDS Windows Server 2016

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

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2012, 2012 R2 et 2016 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 2016 « 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 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 2008/2008, 2012 /2012 R2 ou encore 2016).

Depuis un Serveur d’Administration

Depuis Windows Server (2008 R2 ou ultérieur), lancez Windows PowerShell 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

 

A bientôt,

[eBook /Book] RDS 2012 R2 – Securisation et Hardening: Guide du Consultant [1ère Edition]

Ce guide pas à pas vous permet de planifier et mettre en place une politique de sécurisation et durcissement de votre infrastructure RDS sous Windows Server 2012 R2. Plus de 30 paramètres (Hardening) de stratégies de groupe sont détaillés dans ce guide. Les options de sécurisation telles que NLA, Certificat SSL, chiffrement RDP y sont également traitées. De plus, je vous liste à travers cet eBook tous les outils (GUI & CLI) de protection du rôle RDS et vous montre comment les utiliser, et quand les utiliser. Enfin, vous y trouverez toutes les bonnes pratiques liées à RDS ainsi que mes retours d’expériences.

Le livre est en Français 😀 ::: La version Anglaise est en cours de rédaction…

Le format :: Broché :: est disponible sur Amazon.fr et Amazon.com, cliquez sur l’image ci-après pour en savoir plus :

Le format :: eBook [PDF] :: est disponible sur BecomeITExpert.com, cliquez sur l’image ci-après pour en savoir plus :

 

HowTo : Activer le Mode « Restricted Admin » pour les Connexions Bureau à distance

S’applique à : RDS Windows Server 2012 R2, RDS Windows Server 2016, Windows 8(.1), Windows 10

Microsoft a apporté plusieurs améliorations en matière de sécurité au couple d’OS {Windows Server 2012 R2 & Windows 8.1} pour les protéger contre les attaques PtH (Pass-the-Hash). Les mots de passes des comptes utilisateurs ainsi que leur Hashes sont généralement stockés sur le Disque et la Mémoire du Poste de travail /Serveur, si votre machine est compromise, vos informations d’identification peuvent être réutilisées par un Hacker pour accéder à d’autres systèmes /plateformes /services critiques sans que vous soyez au courant.

Introduit avec Windows Server 2012 R2, la fonctionnalité « Restricted Admin Mode » ou « Mode d’Administration Restreinte » a été conçu pour protéger les comptes Administrateurs (locaux et du domaine) contre ce type d’attaque en s’assurant que les informations d’identification saisies lors d’une connexion Bureau à distance ne soient mémorisées et stockées dans la mémoire de la machine distante, qui peut potentiellement être compromise.

Quelques scénarios typiques

Equipe Help Desk utilisant un compte « Administrateur » pour effectuer du support N1/N2 à distance (via RDP) sur les machines des utilisateurs du réseau

Equipe IT Admins utilisant un compte « Administrateur du Domaine » pour effectuer du support N3 à distance (via RDP) sur des serveurs Membres.

Processus d’ouverture de Session RDP

Lorsque vous établissez une Connexion Bureau à distance sur une machine distante, vous êtes invités à vous authentifiez : Apparition de la fameuse boite de dialogue « Sécurité de Windows« :

L’authentification se fait dans un premier temps avec le service local RDP via le Process « Remote Interactive Logon ». Dans ce contexte, le mot « Interactive » signifie que l’utilisateur saisi « physiquement » son nom d’utilisateur et son mot de passe associé.

Le Service RDP tente ensuite d’ouvrir une Session Réseau sur la machine distante pour vérifier si l’utilisateur est autorisé à s’y connecter/accéder ou pas. Lors de cette phase, aucune information d’identification n’est requise. En effet, le ticket Kerberos ou Hash NTLM ayant été créés lors de l’ouverture de session initiale peuvent être utilisés pour l’authentification via réseau.

Une fois authentifié par le service RDP de la machine distante, les informations d’identification de l’utilisateur sont envoyées à travers un canal sécurisé vers la machine distante, l’ouverture de session « Interactive » a lieu ce qui permet à l’utilisateur distant de voir et accéder au Bureau à distance.

Prérequis

La fonctionnalité « Restricted Admin Mode » est supportée uniquement par les OS suivants :

OS Server : Windows Server 2012 R2 et Windows Server 2016

OS Client : Windows 8.1 et Windows 10

Donc avant de lancez une Connexion Bureau à distance en mode « Restricted Admin », assurez-vous que celle-ci est établie depuis et vers un des OS cités ci-dessus.

Dois-je utiliser le mode « Restricted Admin » ?

Si vous souhaitez restreindre les accès Bureau à distance sur des machines pouvant présentées un problème (machine présentant des problèmes de stabilité, potentiellement compromise, infectées par des virus…), vous pouvez envisager l’activation du mode « RestrictedAdmin », car comme expliqué ci-haut, vous pouvez être sûre que vos infos d’identifications ne peuvent être réutilisées par un programme malveillant ou un Hacker pour s’introduire sur d’autres machines du réseau jugées « critiques » comme les DC, BDD, Filers …

Cependant, certaines « Best Practices » de l’éditeur soulignent une préférence pour le « Hardening d’OS » incluant la mise en place de stratégies de sécurité pour renforcer la sécurité des comptes Administrateurs (locaux et du domaine), comme par exemple :

Le compte « Administrateur du Domaine » doit uniquement être utilisé pour s’authentifier sur les DCs pour gérer et administrer l’infrastructure AD et JAMAIS pour administrer les serveurs membres, les machines des utilisateurs du réseau …

Chaque machine du réseau doit avoir un compte « Administrateur » et mot de passe unique pour les besoins de gestion, d’administration et support

…

Comment utiliser le mode « Restricted Admin » ?

Le mode « Restricted Admin » est représenté par un paramètre de l’outil MSTSC.exe (Application Cliente : Connexion Bureau à distance).

Cette fonctionnalité correspond au paramètre /RestrictedAdmin, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarré et constatez la disponibilité du mode « /RestrictedAdmin »:

Activer ou Désactiver le mode « Restricted Admin » 

Le Mode « Restricted Admin » est désactivé par défaut.

Pour activer cette fonctionnalité, une nouvelle clé doit être créée au niveau du BDR (Base de Registre), voir les paramètres suivants:

Chemin : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Vous pouvez également activer cette fonctionnalité d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Une fois activé, si vous établissez une Connexion Bureau à distance (en mode Normal sans le paramètre /RestrictedAdmin) sur un serveur distant, le message suivant apparaît:

Maintenant, essayez de vous connecter à votre machine distante via l’utilisation de la commande : MSTSC /RestrictedAdmin

Note : Cette commande peut être lancée depuis le Menu Démarrée ou l’Invite de commande (CMD.exe)

Comme illustré dans l’image ci-après, la connexion Bureau à distance avec le mode « RestrictedAdmin » renforcé permet l’ouverture de la Session Bureau à distance :

Limitations du mode « Restricted Admin »

Comme expliqué précédemment, quand le mode « Restricted Admin » est activé, l’utilisateur authentifié sur la machine distante n’a pas la possibilité de se connecter sur d’autres machines ni ressources du réseaux,
En effet, la délégation étant restreinte, les connections vers les autres machines s’effectuent via le compte d’ordinateur local.

Vous risquez (par exemple) de ne pas pouvoir vous connecter à un lecteur réseau depuis une Session Bureau à distance.

Dans l’exemple suivant, une Connexion Bureau à distance (en mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a échouée (pas de délégation d’informations d’identification):

Cette fois ci, une Connexion Bureau à distance (en mode normal : sans le Mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a réussie (délégation d’informations d’identification ):