Articles Tagués ‘Hicham KADIRI’

 

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

Publicités

 

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 :

Hello Azure Guys,

Greeeet News !!!!

L’équipe Azure Backup a annoncé aujourd’hui l’intégration d’Azure Backup dans l’assistant de création de Machine Virtuelle (VM) Azure.

Vous pouvez donc configurer la sauvegarde (Backup) de votre VM au moment de sa création, cela permet une protection de votre infrastructure Azure IaaS dès son déploiement.

HowTO : Configurer Azure Backup lors de la création d’une VM

Lors de la création d’une nouvelle VM Azure, plus précisément à l’étape « 3 – Paramètres » de l’assistant, vous êtes invité à configurer (Activer ou Désactiver) la sauvegarde de celle-ci. Comme illustré dans l’image ci-dessous, il suffit de sélectionner « Activé » pour configurer le Backup de la VM dès sa création :

Vous pouvez utiliser un Coffre Recovery Services (Backup Vault) existant ou en créer un nouveau.

Idem pour le groupe de ressource qui hébergera le Coffre RS (Choisir un existant ou créer un nouveau groupe de Ressource dédié).

Enfin, vous devez définir (Créer) une nouvelle Stratégie de Sauvegarde (Backup Policy) avec les options de rétention qui correspondent à votre besoin :

Liens utiles 

En savoir plus sur Azure Backup

Documentation sur Azure Backup 

Introduction : Sysinternals Tools

Sysinternals Tools est une suite d’outils regroupant plusieurs dizaines de « Free Utilities » proposés gratuitement par Microsoft.

Ces outils vous permettent de gérer, diagnostiquer et troubeshooter plusieurs composants de Windows (Client & Server), à savoir : Disk/Volume, Active Directory, Hyper-V, Prof/Perfs…

Au moment de la rédaction de ce post, la suite Sysinternals est composée des outils listés ci-dessous (76 tools au total) :

AdExplorer | AdInsight | AdRestore | | Autologon | Autoruns | BgInfo | BlueScreen | CacheSet | | ClockRes | Contig | Coreinfo | Ctrl2Cap | DebugView | | Desktops | Disk2vhd | DiskExt | DiskMon | DiskView | | Disk Usage (DU) | EFSDump | FileMon | FindLinks | Handle | | Hex2dec | Junction | LDMDump | ListDLLs | LiveKd | | LoadOrder | LogonSessions | MoveFile | NewSid | NotMyFault | | NTFSInfo | PageDefrag | PendMoves | PipeList | PortMon | | ProcDump | Process Explorer | ProcFeatures | Process Monitor | PsExec | | PsFile | PsGetSid | PsInfo | PsKill | PsList | | PsLoggedOn | PsLogList | PsPasswd | PsPing | PsService | | PsShutdown | PsSuspend | PsTools | RAMMap | RegDelNull | | RegHide | RegJump | RegMon | Rootkit Revealer | Registry Usage (RU) | | SDelete | ShareEnum | ShellRunas | Sigcheck | Streams | | Strings | Sync | Sysmon | TCPView | VMMap | | VolumeID | WhoIs | WinObj | ZoomIt

Télécharger les Sysinternals Tools 

Commencez par télécharger le package complet « Sysinternals » pour pouvoir réaliser les instructions techniques détaillées dans la section suivante.

 

Sysinternals Tools pour Active Directory

La suite Sysinternals comprend trois outils dédiés à la gestion et troubleshooting d’Active Directory.

Ces outils sont :

AdExplorer

AdInsight

AdRestore

Je vous présenterai donc à travers cet article ces trois outils et dans quel contexte vous pouvez l’utilisez.

#1. AdExplorer

AdExplorer (ou Active Directory Explorer) est un outil très puissant qui vous permet d’éditer votre base Active Directory et visualiser/modifier son contenu (e.g : Attributs).

Active Directory Explorer présente des fonctionnalités similaires que celles disponibles sur l’éditeur ADSIEdit (outil natif), fourni par défaut avec le rôle Windows Server ADDS (Active Directory Domain Services), en revanche il fourni plus de fonctionnalités et reste plus simple et facile à utiliser.

Vous pouvez utiliser AdExplorer pour naviguer et parcourir votre base de données AD (NTDS.dit database), visualiser les attributs d’objets AD de manière simple et rapide sans avoir besoin d’éditer les propriétés de l’objet et ouvrir la boite de dialogue « Propriétés ». Il peut également être utilisé pour :

Editer les permissions d’objets AD

Définir vos emplacements « Favoris »

Exécuter des recherches pertinentes et « sophistiquées » mais aussi les enregistrer pour une utilisation utérieure.

Réaliser des « Snapshots » de la base Active Directory pour une utilisation (visualisation) Offline.

Enfin, AdExplorer ouvre (automatiquement) tous les « Naming contexts » Active Directory détectés/trouvés, ce qui vous évite de vous connecter séparément à chaque contexte de nommage : « Configuration », « Schema », …Etc.

Tips #1 : AdExplorer vous permet d’afficher plusieurs domaines/sous-domaines AD ainsi que tout Snapshot AD enregistré sur la même console.

Dans l’exemple suivant, je vais me connecter à ma base AD en saisissant simplement le nom DNS de mon Root domain (HKRoot.lan) :

Dès que la connexion est établie, les informations suivantes sont collectées et affichées sur le volet gauche :

Maintenant, juste double-click and enjoy :).

Tips #2 : la boite de dialogue « Connect to Active Directory » s’affiche automatiquement lors du lancement d’AdExplorer, vous pouvez « bypasser » cette boite de dialogue en saisissant AdExplorer –noconnectprompt depuis l’Invite de commande (CMD.exe) :

Note importante : Vous pouvez utiliser l’outil AdExplorer avec différents types de Servies d’Annuaire, tels que Active Directory Domain Services (DS), Active Directory Lightweight Directory Services (LDS) et Active Directory Application Mode (ADAM).

#2. AdInsight

AdInsight est outil de monitoring LDAP « en temps réel » qui vous permet de surveiller et tracer tous les appels/requêtes LDAP effectuées par les applications clientes et API sur l’annuaire Active Directory.

C’est un tool très pratique que vous pouvez utiliser pour diagnostiquer et troubleshooter les problèmes de connexions/communication liées Apps clientes s’appuyant sur AD.

AdInsight utilise une technique d’injection de DLL pour intercepter les appels/requêtes effectuées par les applications dans la librairie Wldap32.dll, qui est la Librairie Windows Standard qui implémente toutes les fonctionnalités LDAP bas-niveau (Low-Level).

Capture de données à l’aide d’AdInsights, comment ça marche ?

Par défaut, l’outil AdInsight démarre en mode « Capture – On », si toutefois, si vous souhaite former/démarrer la « manuelle », utilisez le raccourci clavier (Ctrl+E) ou cliquez sur la première icone (à gauche) disponible sur la barre d’outil d’AdInsight :

#3. AdRestore

AdRestore est un outil en ligne de commande (CLI) qui vous permet de lister tous les objets AD supprimés et vous offre la possibilité de les restaurer sans passer par l’outil/snap-in ADAC (Active Directory Administrative Center).

Comment ça marche ?

Faites un Extract du fichier AdRestore.zip et placez le dossier AdRestore dans C:\, exécutez ensuite la commande suivante pour lister/visualiser tous les objets AD supprimés (Deleted Objects) :

C:\AdRestore\AdRestore.exe

Dans l’exemple suivant, deux objets AD (User) se trouvent dans la Corbeille AD (hk_admin_user & hk_std_user) :

Pour restaurer vos objets AD supprimés, saisissez la commande suivante :

C:\AdRestore\AdRestore.exe -R

Vous êtes invités à confirmer chaque restauration d’objet en saisissant Y (comme Yes) :

Notez que les objets AD restaurés sont désactivés l’opération de restauration, vous devez donc les réactiver pour les rendre « Actifs » à nouveau :

 

Microsoft vous propose un « Event » autour du Cloud Azure, ce 23 Janvier à Paris.

Vous assisterez à plusieurs Workshop, DEMOs et présentations animées par Scott Guthrie, VP Exécutif Cloud & Enterprise.

Scott Guthrie partagera en Live les services Cloud Microsoft, les workloads avancés, et toutes les fonctionnalités qui font la différence dans le quotidien d’un développeur.

Inscrivez-vous à cet Event ici.

A bientôt :).

 

Microsoft a publié un outil qui vous aide à identifier, analyser et résoudre des problèmes liés à la suite MS Office.

Il s’agit de « Microsoft Office Licensing Diagnostic Tool« .

Vous pouvez utiliser cet outil pour :

  • Lister toutes les licences installées sur vos machines Windows
  • Installer vos Licences MS Office (si bien évidemment vous disposez des clés de produit MS Office)
  • Désinstaller des Licences MS Office
  • Activer vos clés de produits MS Office
  • Collecter toutes les informations/logs liées à MS Office pour pouvoir debugger/troubleshooter en cas de problème spécifique.

Microsoft Office Licensing Diagnostic Tool est disponible en téléchargement gratuit ici.

Download & Enjoy :).