MAVMRA, qu’est-ce que c’est ?

Si vous souhaitez migrer vos Machines Virtuelles OnPrem vers Azure, vous devez d’abord auditer l’existant pour pouvoir sizer vos Machines Virtuelles Azure et pouvoir répondre à la question suivante :

Quelles Machines Virtuelles Azure aurais-je besoin pour telle ou telle VM OnPrem.

Si vous documentez bien vos environnements et que vous disposez d’une solution de Monitoring/Inventory existante, cela peut vous aider à collecter des informations sur votre infrastructure existante, en revanche, si vous avez aucune visibilité sur l’existant, eh bien l’outil MAVMRA peut vous aider à partir du bon pied quand il s’agit de migrer des Workload from vos Datanceters OnPrem vers Azure.

MAVMRA (pour Microsoft Azure Virtual Machine Readiness Assessment) est un outil qui vous permet de réaliser une évaluation de la configuration de vos VMs existantes et détecter d’éventuels problèmes de configuration à corriger avant migration vers Azure.

 

Technologies/Services pris en charge par MAVMRA

MAVMRA vous permet de réaliser un assessment complet des serveurs/technologies suivantes :

Windows Server Active Directory : Contrôleur de domaine AD (DC : Domain Controller)

Microsoft SharePoint : Serveur SharePoint

Microsoft SQL Server : Serveur SQL

 

MAVMRA : Prérequis

Je vous invite à télécharger le document PDF suivant et prendre connaissance de tous les prérequis avant d’installer l’outil MAVMRA :

Note importante : La machine (Physique ou Virtuelle) qui servira de serveur MAVMRA, doit obligatoirement être jointe à un domaine AD pour pouvoir exécuter à distance les différents tests d’assessment et de collecte d’informations sur votre infrastructure système Windows Server existante.

 

How To : Installer MAVMRA

Bon, l’installation de MAVMRA est assez simple, choisissez un emplacement d’installation (%PROGRAMFILES% par défaut), et cliquez sur « Install » pour démarrer l’installation :

Une fois installé, cliquez sur « Close » pour lancez l’assistant de configuration :

Note : laissez la case à cocher « Launch Microsoft Azure Virtual Machine Readiness Assessment » cochée

 

How To : Configurer MAVMRA

L’assistant de configuration MAVMRA suivant apparaît, il est composé de 6 volets.

Sélectionnez le type de service/technologie pour le(la) quel(le) effectuer l’Assessment.

Danns l’exemple suivant, nous allons évaluer la configuration des Contrôleurs de domaine, Active Directory est donc sélectionnée comme option :

Les prérequis suivants doivent être OK pour que MAVMRA puisse réaliser son Assessment :

L’assistant MAVMRA comprend 13 questions auxquelles vous devez répondre pour une meilleure évaluation de votre infrastructure Windows Server existante :

Question 1/13 de l’assistant de configuration MAVMRA :

Quand vous aurez répondu à toutes les questions, l’évaluation de votre infrastructure (AD dans notre exemple) démarre :

Dès que l’évaluation/collecte de données est terminée, deux rapports vous sont proposés. Cliquez sur « View Reports » pour afficher leur emplacement :

Les deux rapports automatiquement générés par MAVMRA sont les suivants :

Le premier document « DOCx file » : représente le rapport complet détaillant toutes les Steps pour réussir la migration de vos Workload vers Azure

 

La second document (XLS file) : regroupe tous les problèmes (Issues) détectés pouvant empêcher la migration de vos VMs vers Azure. Cela vous permet d’avoir un Overview sur toutes les corrections/plan de remédiation à mettre en place pour réussir votre migration vers Azure.

 

Télécharger Microsoft Azure Virtual Machine Readiness Assessment

L’outil Microsoft Azure Virtual Machine Readiness Assessment peut être téléchargé gratuitement depuis le bouton ci-dessous.

 

 

A bientôt

#HK

Publicités

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

Hi Azure Guys,

Microsoft a récemment publié un guide complet détaillant toutes les bonnes pratiques liées à la Sécurité Azure, cela comprend :

 

Je vous invite à consulter les liens ci-dessus et prendre connaissance de toutes les Security considerations & options lors de la phase « Design » de votre projet Cloud Azure.

Source : https://docs.microsoft.com/en-us/azure/security/security-best-practices-and-patterns

Aujourd’hui, je vais vous parler d’u outil qui va vous faciliter la vie quand il s’agit d’auditer, et documenter from end-to-end un environnement Azure : Azure Dockit.

Azure Dockit a été conçu et développé par la société (Canadienne) UMAknow inc. Il est commercialisé sous forme de SaaS App (Software-as-a-Service Application) et est disponible depuis le Marketplace Azure.

Il vous permet de générer de manière « Full automated » une documentation complète sur votre environnement Azure.

C’est Must-Have Tool pour tout auditeur Cloud Azure désirant cartographier les environnements Azure de ses clients, comprenant tous les services Cloud implémentés ainsi que les « Links & Dependencies » entre eux.

Une fois exécuté, Azure Dockit se connecte à votre Tenant Azure, collecte, analyse et documente de manière automatique toutes les données liées aux services exécutés.

Azure Dockit génére deux output files :

Documentation complète de votre environnement Azure

Diagram Visio sous forme de Big Picture illustrant tous les services mis en place et leur dépendances.

 

Azure Dockit est un outil payant, disponible en quatre Edition, à savoir :

Je vous invite à consulter cette page pour en savoir plus sur le niveau de Pricing/Edition d’Azure Dockit.

L’éditeur propose une version Trial et je vous invite à en profiter pour découvrir la puissante de cet Azure auditing tool.

Comment ça marche ?

C’est simple comme bonjour :).

Rendez-vous à la page Marketplace Azure « Dockit », cliquez sur « FREE TRIAL » et renseignez un compte Azure disposant les droits nécessaires pour audit et collecter les informations depuis votre abonnement Azure.

Sélectionnez ensuite l’abonnement (Subscription) à auditer et cliquez sur « Gontinue »

Faites le tour de la plateforme Azure Dockit, sélectionnez les options qui vous intéressent, et cliquez ensuite sur « Generate Trial Documentation » :

Just Click & Enjoy, et laisser Azure Dockit s’occuper du reste 🙂

Livrables Azure Dockit ?

Une fois l’audit Azure Dockit est terminée, un mail vous est envoyé automatiquement avec les deux livrables suivants :

  • Documentation complète au format Word
  • Une Big Picture de tout l’environnement audit au format Visio

Ci-après un extrait du Digram Visio de mon environnement (LAB) généré par Azure Dockit :

Notez qu’Azure Dockit vous fournit également des documents Templates (Samples Documents) que vous pouvez utiliser pour personnaliser le rapport d’audit final avant présentation à votre client/direction.

Echo « Hi Azure Guys »,

Great News !

Microsoft a annoncé Mardi dernier (27 Février) l’intégration d’Azure Backup avec Azure Files (Service Cloud offrant des Partage de fichiers « Fully-Managed » et accessibles via SMB) en « Public Preview ».

Vous pouvez désormais inclure les Partages Azure Files dans votre stratégie Azure Backup pour les sauvegarder de manière automatique, et pouvoir restaurer vos données (Files Share) en cas de problème.

Comment ça marche ?

C’est assez simple !

Créez un nouveau Coffre Recovery Services (Recovery Services Vault) ou utilisez un existant, cliquez ensuite sur « Sauvegardes« , volet disponible depuis le volet Gauche du Blade « Coffres Recovery Services », enfin sélectionnez « Partage de fichiers Azure » comme valeur du paramètre « Que souhaitez-vous sauvegarder » ?

 

Dans l’exemple suivant, mon compte de stockage Azure hébergeant mon files share nommé « hk-demo-fileshare1 » est sélectionné :

Enfin, créez une stratégie de sauvegarde pour vos partages de fichiers Azure, et cliquez sur « OK » pour terminer :

Useful information

Je vous invite à consulter ce post pour en savoir plus.

A bientôt

#HK

 

Suite à la réalisation de plusieurs audits Azure chez différents clients grand comptes (Banques, Assurances, …etc), j’ai pu constaté que la plupart de leurs DC (Domain Controllers AD) hébergés dans le Cloud Azure (sous forme de VM Azure : mode Infra-as-aService), n’ont pas été Setupés, configurés et protégés correctement.

Plusieurs « Best Practices » relatives à l’exécution des Domain Controllers sur Azure (VM) sont souvent « oubliés » et rarement pris en considération lors de la phase « Build/Implementation ».

Si vous avez décidé d’étendre votre infrastructure AD vers Azure, je vous invite à prendre connaissance des items détaillés ci-dessous avant de vous lancer dans la création/build de VMs DCs.

Note : Le terme « Étendre » ici fait référence à un nouveau site distant (Site Active Directory) qui sera simplement le VNET/Subnet Azure et non pas la synchronisation d’annuaires : AD to AAD (Azure AD).

 

Liste des « Best Practices » que vous devez connaître avant de déployer vos DCs sur Azure (VM)
  • #1 : Tout d’abord, bien lire le guide « Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines » proposé par MS. Ce document vous détaille et explique bien la différence entre le déploiement d’infrastructure AD OnPrem (Infra AD traditionnelle) et le déploiement des Contrôleurs de domaine sur Azure (sur VM, connectées à des VNET/Réseaux Virtuels Azure). Je vous invite à prendre le temps de lire et comprendre tous les items détaillés dans cet article.
  • #2 : Déployez au moins deux Contrôleurs de domaine AD (2 VMs Azure)
  • #3 : Créez un Groupe à Haute Disponibilité (Availability Set) et placez-y vos Contrôleurs de domaine (au moins 2 DCs) : consulter cet article pour en savoir plus.
  • #4 : Déployez des Contrôleurs de domaine en mode « Core » plutôt qu’en mode GUI (Graphical User Interface)
    • HK Recommendation : pensez à déployer des DCs en mode Core avec un full remote management (via RSAT depuis un Bastion Environnement). Si vous déployez encore des DC sous Windows Server 2012 ou 2012 R2, vous pouvez déployer des DCs en mode MSI (Core + Minimal Server Interface > All GUI Tools)
      • Note : je vous invite à consulter cet article pour en savoir plus sur les différents modes : GUI | MSI | Core
  • #5 : Déployez des RODC (Read-Only Domain Controller) plutôt que des WDC (Writable Domain Controller)
    • Note importante : avant de déployer des RODC, vérifiez que vous Applications (à intégrer dans l’AD) supportent bien ce type de DC. Si vos Apps ont besoin d’écrire dans la base AD, déployez plutôt des WDC. Je vous invite à consulter cet article si vous avez besoin de tester la comptabilité de vos applications avec le RODC.
  • #6 : Ensuite, (TRES, TRES IMPORTANT), configurez des @IP Statiques sur vos DCs, cela doit se faire via le Portail Azure, PowerShell ou Azure CLI (depuis les Propriétés de la NIC de la VM DC) et non pas via les propriétés TCP/IP v4 de la Guest NIC :
    • Tips : vous pouvez configurer l’adresse IP (Statique) sur vos DCs via :
      • Le Portail Azure : consulter cet article pour en savoir plus.
      • Windows PowerShell [Module PS Azure] : consulter cet article pour en savoir plus.
      • Azure CLI [commande az vm]: consulter cet article pour en savoir plus.
  • #7 : Créer/Utiliser un Compte de Stockage Azure dédié pour stocker les vDisks (VHD) des Domain Controllers
  • #8 : En plus du vDisk OS créé/attaché à la VM automatiquement lors de sa création/provisioning, il est important de créer/attacher un nouveau vDisk à la VM DC (Data Disk) pour y stocker/placer la base de données AD, Fichiers Logs,SYSVOL 
  • #9 NE JAMAIS configurer de « Host Cache Prerence », lors de l’ajout du nouveau vDisk DATA (Disque de données pour AD Database, Logs & SySVOL), choisissez « None » comme valeur.
  • #10 : Utiliser les fonctionnalités RBAC (Role-Based Access Control /Contrôle d’accès en fonction du rôle) pour limiter/contrôler QUI doit ACCEDER/GERER le compte de Stockage and les clés d’accès
  • #11 : Activer le chiffrement de disque Azure (Azure Disk Encryption) avec une clé de chiffrement (KEK : Key Encryption key) pour les disques systèmes (OS vDisk) mais aussi les disques de données (Data vDisk). Azure Key Vault sera utilisé pour stocker les clés, il doit être déployé/hébergé dans la même Région & Abonnement Azure
  • #12 : Même chose pour Le coffre Key Vault, pensez à définir/implémenter une stratégie RBAC pour limiter l’accès au Key Vault stockant vos clés.
  • #13 : A l’aide d’un NSG (Network Security Group), créez et configurer des règles pour :
    • Autoriser que le traffic « Entrant » requis (Ports requis) pour les Domain Controllers
    • Refuser tout autre traffic
  • #14 : Implémentez des règles AppLocker pour autoriser que les .EXE, scripts… requis/utilisés par les DCs
  • #15 : NE JAMAIS créer/définir une @IP public pour les VMs faisant office de Domain Controllers.
  • #16 : Et bien évidemment, ne jamais activer le RDP (Remote Desktop Protocol) sur les DCs, pour réduire la surface d’attaque, et puis, on est d’accord, ce sont des DCs et non pas des serveurs RDS ou Citrix XA :).
  • #17 : Déployer et configurer l’agent Antimalware (en suivant votre standard OnPrem)
  • #18 : Déployer et configurer l’agent de monitoring (en suivant votre standard OnPrem)
  • #19 : Si votre architecture réseau le permet, implémentez une IPSec Policy pour sécuriser les communications entre vos DCs OnPrem et ceux sur Azure.
  • #20 : Et enfin, veillez à bien documenter toutes les options/fonctionnalités de sécurité implémentées, ainsi que toute modification apportée, cela vous permettra d’identifier les effets de bord/impacts post-implémentation d’une ou plusieurs Security Features spécifiques. e.g : mauvaise implémentation d’IPSec peut avoir un impact sur toute la communication inter-site (deny any<>any by default).

A bientôt, Keep in touch :).

#HK | Another IT Guy

 

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