Articles Tagués ‘RemoteApp’

rds2016_bg

RDS (Remote Desktop Services) Windows Server 2016 apporte un lot conséquent de nouveautés et d’améliorations qui répondent à plusieurs problématiques et besoins clients en matière de Virtualisation d’Apps et Postes de travail, notamment :

Compatibilité d’Apps [Windows Server 2016 et Windows 10]

Conçu et développé sur la même base de Windows 10, Windows Server 2016 présente le même look et expérience utilisateur que ce dernier. En outre, plusieurs mêmes Applications  sont fournies par défaut sur les deux OS Client et Server. Ce qui permet aux utilisateurs distants de retrouver « presque » le même environnement /espace de travail sur le serveur Bureau à distance.

Azure SQL Database pour la mise en HA de votre service RDCB

Parmi les « Big » News de RDS 2016 est la prise en charge du service Azure SQL pour la mise en haute disponibilité du service Broker (RDCB : Remote Desktop Connection Broker).

Vous pouvez désormais « Bypasser » le déploiement d’une infrastructure SQL OnPrem complexe et envisagez un scénario « Hybride » en utilisant Azure SQL.

En hébergeant la base de données RDS HA sur Azure SQL, vous bénéficiez de la puissance du Cloud Microsoft tout en réduisant le coût de votre projet RDS 2016.

Pour en savoir plus, consultez l’article suivant :

https://blogs.technet.microsoft.com/enterprisemobility/2016/05/03/new-windows-server-2016-capability-use-azure-sql-db-for-your-remote-desktop-connection-broker-high-availability-environment/

MultiPoint Services

Il s’agit d’un nouveau rôle, désormais natif dans Windows Server 2016.

Le rôle MultiPoint Services a pour but de permettre à des postes clients économiques et à des clients légers de se connecter à un serveur via USB ou via Ethernet pour proposer à plusieurs utilisateurs des sessions individualisées sur un même serveur. L’idée est de fournir un bureau Windows 10 à de multiples utilisateurs sur un seul et même serveur Windows.

L’ancienne solution Windows MultiPoint Server, la version multi-utilisateurs de Windows, disparaît donc avec Windows Server 2016 pour devenir qu’un simple rôle natif du nouvel OS Server.

Notez que le service de rôle RDSH (Hôte de Session Bureau à distance) est installé automatiquement avec l’installation du rôle MultiPoint Services.

Enfin, MPS peut être installé via l’option « Installation des Services Bureau à distance »

1

Nouvelles Cmd-Lets PowerShell

6 nouvelles Cmd-Lets ont été ajoutées au Module PowerShell « RemoteDesktop », voir la liste ci-après:

Export-RDPersonalSessionDesktopAssignment

Get-RDPersonalSessionDesktopAssignment

Import-RDPersonalSessionDesktopAssignment

Remove-RDDatabaseConnectionString

Remove-RDPersonalSessionDesktopAssignment

Set-RDPersonalSessionDesktopAssignment

Nouveau mode « Personal Desktop Session »

Un nouveau mode de déploiement a été introduit avec RDS 2016 : Personal Desktop Session.

Ce nouveau mode de déploiement RDS combine les deux modes de déploiement disponibles avec RDS 2012 /2012 R2 (Déploiement basé sur une Session & VM), ce qui veut dire qu’avec un déploiement RDS 2016 en mode Personal Session Desktops (ou Server Based Personal Desktop), vous pouvez mettre en place une infrastructure VDI sans utilisation d’OS Client :).
Le principe est simple, chaque utilisateur distant disposera d’un Serveur Hôte de Session dédié, ce dernier fera office d’un poste de travail virtuel comme dans une infrastructure VDI classique.

Je vous invite à consulter les deux articles suivants pour en savoir plus:

https://hichamkadiri.wordpress.com/2016/05/26/part1-nouveau-mode-de-deploiement-sous-rds-2016-personal-session-desktops-part1/

https://hichamkadiri.wordpress.com/2016/05/30/part2-nouveau-mode-de-deploiement-sous-rds-2016-personal-session-desktops/

Prise en charge des Apps OpenGL par RemoteFX vGPU

Avec RDS 2016, RemoteFX vGPU prend désormais en charge les Applications OpenGL.

Les clients qui utilisent des applications graphiques nécessitant des capacités de mémoire vidéo élevées peuvent désormais virtualiser leurs Apps sur un environnement RDS sous Windows Server 2016.

Consultez l’article suivant pour en savoir plus :
https://blogs.technet.microsoft.com/enterprisemobility/2014/11/05/remotefx-vgpu-updates-in-windows-server-next/

Nouvelles capacités et améliorations du service Broker

La gestion de connexions Bureau à distance par le service RDCB a été amélioré d’une manière considérable. En effet, un serveur Broker peut désormais gérer jusqu’à 10.000 demandes de connexions simultanées.

En savoir plus : https://blogs.technet.microsoft.com/enterprisemobility/2015/12/15/improved-remote-desktop-connection-broker-performance-with-windows-server-2016-and-windows-server-2012-r2-hotfix-kb3091411/ 

Prise en charge de Microsoft Edge & Office 2016

Le nouveau navigateur Web de Microsoft « Edge » est pris en charge dans un environnement RDS 2016 et peut être publié (sur un serveur RDSH) et distribué comme n’importe quel Programme RemoteApp aux utilisateurs distants. C’est le cas aussi pour la suite Microsoft Office 2016. Une version prenant en charge les services Bureau à distance 2016 est désormais disponible dans le store /plateforme MSDN.

Prise en charge des « VMs Génération 2 »

Vous pouvez désormais utiliser des VMs Génération 2 comme des « Images Templates » pour créer des Pools de VMs ou VM Personal au sein de votre infrastructure RDS VDI 2016.

Aucune configuration supplémentaire n’est requise.

Just deploy and enjoy :).

Nouvelle version du protocole RDP

La version 10 du protocole RDP utilise désormais le codec H.264/AVC 444, ce qui permet une optimisation maximale des vidéos et texte sur un environnement Bureau à distance.

Pour en savoir plus sur ces améliorations, je vous invite à consulter le lien ci-après :

https://blogs.technet.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/

RDP Planning Poster

L’équipe Remote Desktop Services a publié un nouveau Poster qui vous aidera à préparer, concevoir et déployer votre infrastructure RDS sous Windows Server 2016.

Voir la Big-Picture ci-après :

rds-planning-poster

 

Publicités

rds2012r2secuhardening_cover

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 :

Amazon_logo

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

Logo_BecomeITExpert

 

 

S’applique à : Windows Vista > Windows 10 | Windows Server 2008 > Windows Server 2016

Par défaut, une machine Windows (Client ou Server) sur laquelle les connexions Bureau à distance ont été activées /autorisées, écoute sur le port 3389 (TCP), ce dernier correspond au protocole RDP (Remote Desktop Protocole).

Pour le constater, ouvrez une Session (locale) sur une machine (Physique ou Virtuelle) ayant le RDP activé, lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez NetStat -a, enfin notez l’existence du port d’écoute 3389

1

 

Protocole RDP : Vulnérabilité 

L’utilisation du port par défaut (3389 :: TCP) présente plusieurs vulnérabilités au sein d’un S.I et offre aux Hackers la possibilité d’effectuer plusieurs types d’attaques, notamment :

  • Attaque par Brute-Force
  • Attaque par DoS (Denial of Service)

En effet, tous les hackers qui s’en prennent aux connexions RDP s’appuient sur le port 3389 pour provoquer un DoS ou brute-forcer une machine Windows.

A l’aide de n’importe quel Network Sniffer, un Hacker peut capturer les RDP Data et facilement localiser la(es) machine(s) écoutant sur le port TCP 3389.

Prenons l’exemple de la vulnérabilité MS12-020, celle-ci a été détectée dans le protocole RDP et permettant un déni de service, et ce via l’utilisation du port 3389.

Comme le montre la vidéo ci-après, à l’aide d’un simple outil de Hacking (MSF « MetaSploit Framework » fourni avec KALI Linux), vous pouvez provoquer un DoS, et rendre (en quelques secondes…) un serveur RDSH (Remote Desktop Session Host) ou une Machine d’Administration écoutant sur le port 3389 indisponible :

 

Recommendations

Il est fortement recommandé de changer le port RDP par défaut [TCP : 3389] et en définir un autre « Personnalisé ».

Vous pouvez utiliser un numéro de port situé entre 1025 et 65535

Dans l’exemple suivant, le port 9933 sera configuré.

 

HowTo : Changer le port RDP par défaut

Le port RDP par défaut peut être changé via :

Le Registre (BDR : Base De Registre)

Lancez l’outil RegEdit.exe (depuis le menu Démarré /Exécuté ou Welcome Screen)

Naviguez jusqu’au : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Localisez et éditez la clé DWORD « PortNumber »

Définissez un nouveau port (Base > Décimale)

2

 

GPO (Group Policy Objects)

Créez une nouvelle GPO ou éditez une GPO existante, naviguez ensuite jusqu’au : Configuration Ordinateur | Préférences | Paramètres Windows

Faites un clic-droit sur « Registre » et sélectionnez « Elements Registre »

Remplissez les champs comme suit :

3

Liez votre GPO aux OUs contenant les objets AD « Ordinateurs » correspondant à vos serveurs RDSH ou Poste d’Admin.

Enfin, lancez un GpUpdate.exe depuis un serveur sur lequel la GPO a été linkée et enjoy the change :).

 

Script PowerShell

5

Un script PowerShell a été développé (par mes soins :)) et uploadé sur la Gallery TechNet > Scripts Center.

Il vous permet de changer le numéro de port RDP par défaut en deux clics, il suffit de l’exécuter, renseigner le nouveau numéro de port RDP et valider le changement en cliquant sur la touche « Entrée » du clavier.

6

Ce script est téléchargeable ici.

 

L’outil « RDP Port Configurator »

Je work actuellement sur outil GUI que j’ai nommé « RDP Port Configurator » basé sur le script PowerShell décrit ci-dessus.

Il sera disponible en téléchargement gratuit sur BecomeITExpert.com, so Keep in touch :).

L’outil RDP Port Configurator ressemble à l’image ci-après :

7

 

Note importante 

Downtime

Tout d’abord, il faut noter que le changement de port RDP par défaut nécessite un redémarrage de votre machine. S’il s’agit d’un changement sur une ou plusieurs machines de production, pensez à planifier ce changement et surtout le downtime qui aura lieu lors du reboot de la machine.

Nouvelle syntaxe de connexion RDP

Quand vous utilisez un port autre que le 3389 pour les connexions Bureau à distance, vous devez le spécifier après l’adresse (IP ou Hostname) de l’ordinateur distant, dans notre cas la connexion bureau à distance se fait sur Nom_Serveur_RDS:9933

4

 

Extrait de l’eBook [RDS 2012 R2 – Sécurisation et Hardening : Guide du Consultant]

Lors de plusieurs interventions chez différents clients, le besoin suivant m’a été exprimé :

Peut-on faire apparaître le nom d’utilisateur (AD) sur le portail RD Web Access ?

Tout d’abord, il faut savoir que par défaut, tout utilisateur authentifié sur le Portail RD Web (Remote Desktop Web Access) ne voit pas apparaître son nom d’utilisateur sur celui-ci, voir l’image ci-après :

1

Le coin supérieur droit de cette page (fichier Default.aspx) regroupe uniquement les deux boutons : Aide & Se déconnecter

Nous allons voir à travers cet article comment personnaliser le Portail RDWeb pour afficher le nom d’utilisateur connecté à côté du bouton « Se déconnecter ».

Par défaut, l’ensemble des fichiers correspondant au Portail RDWA sont stockés dans C:\windows\web\RDWeb\Pages

Donc commencez par faire une copie de ce dossier avant de suivre les instructions détaillées ci-après.

Le but étant d’avoir un moyen de rétablir le portail RDWA en cas de mauvaise manipulation /erreur de configuration.

Comment ça marche ?

  1. Editez le fichier C:\windows\web\RDWeb\Pages\Web.config
  2. Localisez la ligne 52 : <system.web>
  3. Copiez /collez le code suivant (en dessous de la ligne 52) :
    <compilation defaultLanguage="c#" debug="true">
      <assemblies>
        <add assembly="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </assemblies>
    </compilation>
  4. Le résultat doit ressembler à celui illustré dans l’image suivante:2
  5. Ce code a pour but d’indiquer au serveur RDWA que nous avons besoin d’insérer un code spécifique, et plus précisément un code (.NET) depuis la DLL « System.DirectoryServices.dll »
  6. Dès que le code est inséré, enregistrez et fermez le fichier Web.config
  7. Maintenant, éditez le fichier C:\windows\web\RDWeb\Pages\fr-FR\Default.aspx
  8. Localisez la ligne 225 : </script>
  9. Copiez /collez le code suivant (avant la ligne 225) :
    private static string GetDisplayName(string strUserName)
    {
      string strLDAPPath = "LDAP://dc=vLAB,dc=Lan";
      string strFilter = string.Empty;
      
      if(strUserName.Contains("\\")){strUserName = strUserName.Substring(1 + strUserName.IndexOf("\\"));}
      strFilter = "(SAMAccountName=" + strUserName + ")";
      if(strUserName.Contains("@")){strFilter = "(UserPrincipalName=" + strUserName + ")";}
      
      System.DirectoryServices.DirectoryEntry de = new System.DirectoryServices.DirectoryEntry(strLDAPPath);
      System.DirectoryServices.DirectorySearcher ds = new System.DirectoryServices.DirectorySearcher(de);
      ds.Filter = strFilter;
      ds.PropertiesToLoad.Add("DisplayName"); 
      System.DirectoryServices.SearchResultCollection results = ds.FindAll();
      
      return (results != null && results.Count > 0) ? Uri.EscapeDataString(results[0].Properties["DisplayName"][0].ToString()) : string.Empty;
    }
  10. Remplacer la valeur de LDAP://dc=vLAB,dc=Lan par le nom DNS de votre domaine AD
  11. Le résultat doit ressembler à celui illustré dans l’image suivante : 3
  12. Le code inséré occupe les lignes 224 > 240 sur mon fichier Default.aspx
  13. Localisez ensuite la ligne 248 : baseurl= »<%=SecurityElement.Escape(baseUrl.AbsoluteUri)%> »
  14. Insérez la ligne de code ci-après après la ligne 248 ‘baseurl…. » :
    userdisplayname="<%=GetDisplayName(strDomainUserName)%>"
  15. Le résultat doit ressembler à celui illustré dans l’image suivante : 4
  16. Les étapes ci-dessus permettent d’afficher le nom d’utilisateur sur la page Default.aspx uniquement. Pour faire la même chose sur les autres pages du Portail RDWA, le fichier Site.xsl doit également être modifié, pour ce faire éditez ce dernier qui se trouve dans C:\windows\web\RDWeb\Pages\Site.xsl 
  17. Localisez la ligne 15 (ligne vide) et insérez le code suivant juste en dessous :
    <xsl:variable name="userdisplayname" select="/RDWAPage/@userdisplayname"/>
  18. Enfin, localisez la ligne 322 (ou 323 selon la configuration du déploiement RDS 2012 /2012R2) : <xsl:value-of select= »$strings[@id = ‘SignOut’] »/>
  19. Copiez /collez le code suivant juste après cette ligne :
    <xsl:if test="$userdisplayname">(
    document.write(decodeURIComponent(''));)</xsl:if>
  20. Le résultat final doit ressembler à celui illustré dans l’image suivante :

5

Enregistrez et fermez le fichier Site.xsl et connectez-vous sur le Portail RDWA.

Enfin, constatez l’apparition du nom complet de l’utilisateur authentifié (Hicham KADIRI dans l’exemple suivant) :

6

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

C’est une technique pour les [RDS Advanced users only].

Toute mauvaise manip sur les fichiers Web.config /Default.aspx /Site.xsl peut entraîner un downtime du portail RDWA

Vérifiez que vous avez bien copié /sauvegardé le dossier C:\Windows\Web\RDWeb\Pages avant d’appliquer cette procédure sur vos serveurs RDWA de prod :).

Goodluck et à bientôt.

RDSUserSessionControl

RDS User Session Control est un outil graphique gratuit développé par [Ramon Bruin], il peut être exécuté d’une manière autonome sur n’importe quel serveur exécutant Windows Server 2012 et 2012 R2
RDS USer Session Control permet de localiser une ou plusieurs sessions Bureau à distance et de la fermer ou prendre le contrôle de celle-ci par la suite (Shadow Mode)

Cet outil est accompagné d’un fichier INI (settings.ini) qui contient le FQDN du serveur Broker à interroger.
Vous devez donc éditer ce fichier et spécifiez le FQDN de votre serveur Broker avant d’exécuter l’outil RDS User Session Control

Téléchargement

L’outil est disponible en téléchargement gratuit ici

Sidder_V2.0

Sidder un outil graphique gratuit développé par [Arjan Mensch], développé pour Framework .NET 4.5, il peut être exécuté d’une manière autonome sur n’importe quel serveur exécutant Windows Server 2012 et 2012 R2.
Sidder vous permet de lister et identifier les Disques de profils utilisateurs mappés pour chaque Utilisateur Bureau à distance.

Téléchargement

L’outil est disponible en téléchargement gratuit ici.

RDSSendMessageTool_ImgaLaUne

J’ai l’honneur de vous annoncer la mise en ligne de mon premier outil graphique, il s’agit de RDSSendMessage Tool, en version 1.0 (First Release), donc vos feedback sont les bienvenus :)).

RDSSendMessage est un outil graphique gratuit qui vous permet de lister les sessions Bureaux à distance hébergées sur un ou plusieurs Serveurs Hôtes de Session (RDSH :RD Session Host), et d’envoyer par la suite des messages via réseau aux différents utilisateurs Bureaux à distance. Aucune installation n’est requise, il s’agit en effet d’un exécutable que vous pouvez lancer depuis n’importe quel serveur RDS du déploiement ou depuis une machine d’administration ayant les outils RSAT installés.

Prérequis

Framework .NET 3.5

Téléchargement

L’outil est disponible en téléchargement gratuit ici.