Déploiement d’Active Directory Federation Services dans Azure

AD FS simplifie et sécurise la fédération des identités et l’authentification unique (SSO) sur le web. La fédération avec AD Azure ou O365 permet aux utilisateurs de s’authentifier à l’aide de leurs informations d’identification locales et d’accéder à toutes les ressources du cloud. Par conséquent, il est important de disposer d’une infrastructure AD FS hautement disponible pour garantir l’accès aux ressources locales et dans le cloud. Le déploiement d’AD FS dans Azure peut contribuer à bénéficier d’une haute disponibilité avec un minimum d’efforts. Le déploiement d’AD FS dans Azure présente toute une série d’avantages, notamment :

  • Haute disponibilité : la puissance des groupes à haute disponibilité Azure vous garantit une infrastructure hautement disponible.
  • Simplicité de mise à l’échelle : besoin de meilleures performances ? Migrez facilement vers des ordinateurs plus puissants en seulement quelques clics dans Azure
  • Géo-redondance inter-région : la redondance géographique Azure garantit une haute disponibilité de votre infrastructure dans le monde entier
  • Facilité de gestion : le portail Azure propose des options de gestion extrêmement simplifiées, conçues pour faciliter et automatiser la gestion de votre infrastructure

Principes de conception

Conception du déploiement

Le schéma ci-dessus présente la topologie de base recommandée pour amorcer le déploiement de votre infrastructure AD FS dans Azure. Vous trouverez ci-dessous les principes qui sous-tendent les différents composants de cette topologie :

  • Serveurs DC/AD FS: Si vous avez moins de 1 000 utilisateurs, vous pouvez simplement installer AD FS rôle sur vos contrôleurs de domaine. Si vous ne souhaitez aucun impact sur les performances de vos contrôleurs de domaine ou si vous gérez plus de 1 000 utilisateurs, vous pouvez déployer AD FS sur des serveurs distincts.
  • Serveur WAP : il est nécessaire de déployer des serveurs Web Application Proxy afin que les utilisateurs puissent également accéder à AD FS lorsqu’ils se trouvent en dehors du réseau d’entreprise.
  • DMZ: les serveurs Web Application Proxy seront placés dans la zone DMZ et SEUL un accès TCP/443 sera autorisé entre la zone DMZ et le sous-réseau interne.
  • Équilibreurs de charge: pour garantir une haute disponibilité du serveur AD FS et des serveurs Web Application Proxy, nous vous recommandons d’utiliser un équilibreur de charge interne pour les serveurs AD FS et de préférer l’utilisation d’Azure Load Balancer pour les serveurs Web Application Proxy.
  • Groupes à haute disponibilité: pour apporter une redondance à votre déploiement AD FS, nous vous recommandons de regrouper plusieurs machines virtuelles dans un groupe à haute disponibilité pour des charges de travail similaires. Dans une telle configuration, vous avez la garantie qu’au moins une des machines virtuelles sera disponible pendant un événement de maintenance planifié ou non planifié.
  • Comptes de stockage: il est recommandé de disposer de deux comptes de stockage. L’utilisation d’un seul compte de stockage peut entraîner la création d’un point de défaillance unique et provoquer une indisponibilité du déploiement dans l’éventualité (peu probable) où le compte de stockage serait inutilisable. Le choix de deux comptes de stockage permet d’associer un compte de stockage pour chaque ligne d’erreur.
  • Ségrégation du réseau: les serveurs proxy d’application Web doivent être déployés dans un réseau DMZ distinct. Vous pouvez diviser un réseau virtuel en deux sous-réseaux, puis déployer le ou les serveurs Web Application Proxy dans un sous-réseau isolé. Vous pouvez simplement configurer les paramètres du groupe de sécurité réseau pour chaque sous-réseau et autoriser uniquement les communications requises entre les deux sous-réseaux. Voir les détails ci-dessous en fonction du scénario de déploiement

Procédure de déploiement d’AD FS dans Azure

Les étapes indiquées dans cette section expliquent comment déployer dans Azure l’infrastructure AD FS représentée ci-dessous.

1. déploiement du réseau

Comme indiqué ci-dessus, vous pouvez soit créer deux sous-réseaux dans un même réseau virtuel, soit créer deux réseaux virtuels totalement différents. Cet article se concentre sur le déploiement d’un seul réseau virtuel subdivisé en deux sous-réseaux. Cette approche est actuellement plus abordable dans la mesure où l’utilisation de deux réseaux virtuels distincts nécessiterait une passerelle de réseau virtuel à réseau virtuel pour l’établissement des communications.

1.1 Création d’un réseau virtuel

Création d’un réseau virtuel

Dans le portail Azure, sélectionnez le réseau virtuel de votre choix. D’un simple clic, vous pouvez dès lors déployer immédiatement le réseau virtuel et un sous-réseau. Un sous-réseau INT est également défini et prêt à recevoir des machines virtuelles. L’étape suivante consiste à ajouter un autre sous-réseau au réseau, c’est-à-dire le sous-réseau DMZ. Pour créer le sous-réseau DMZ, procédez simplement comme suit :

  • Sélectionnez le réseau que vous venez de créer
  • Dans les propriétés, sélectionnez le sous-réseau
  • Dans le panneau Sous-réseau, cliquez sur le bouton Ajouter
  • Indiquez le nom du sous-réseau et les informations relatives à l’espace d’adresse pour créer le sous-réseau

Sous-réseau

DMZ de sous-réseau

1.2. Création des groupes de sécurité réseau

Un groupe de sécurité réseau (NSG) contient une liste des règles de liste de contrôle d’accès (ACL) qui autorise ou rejette les instances de machine virtuelle dans un réseau virtuel. Vous pouvez associer des groupes de sécurité réseau à des sous-réseaux ou à des instances de machine virtuelle individuelles au sein de ce sous-réseau. Quand un groupe de sécurité réseau est associé à un sous-réseau, les règles ACL s’appliquent à toutes les instances de machine virtuelle de ce sous-réseau. Dans cet article, nous allons créer deux groupes de sécurité réseau : un pour un réseau interne, l’autre pour la zone DMZ. Ces groupes seront respectivement nommés NSG_INT et NSG_DMZ.

Création d’un groupe de sécurité réseau

Une fois le groupe de sécurité réseau créé, il n’y a aucune règle de trafic entrant ni aucune règle de trafic sortant. Une fois que les rôles sont installés et opérationnels sur les serveurs concernés, les règles de trafics entrant et sortant peuvent être modulées selon le niveau de sécurité souhaité.

Initialisation d’un groupe de sécurité réseau

Une fois les groupes de sécurité réseau créés, associez NSG_INT au sous-réseau INT et NSG_DMZ à la zone DMZ du sous-réseau. Exemple de capture d’écran :

Configuration d’un groupe de sécurité réseau

  • Cliquez sur Sous-réseaux pour ouvrir le panneau correspondant
  • Sélectionnez le sous-réseau à associer au groupe de sécurité réseau

Après la configuration, le panneau Sous-réseaux doit se présenter comme suit :

Sous-réseaux après un groupe de sécurité réseau

1.3. Création d’une connexion en local

Nous avons besoin d’une connexion en local afin de déployer le contrôleur de domaine (DC) dans Azure. Azure propose différentes options de connectivité permettant de connecter votre infrastructure locale à votre infrastructure Azure.

  • Point à site
  • Réseau virtuel de site à site
  • ExpressRoute

Nous vous recommandons d’utiliser ExpressRoute. ExpressRoute vous permet de créer des connexions privées entre les centres de gestion et l’infrastructure Azure qui se trouvent dans votre environnement local ou dans un environnement de colocalisation. Les connexions ExpressRoute ne sont pas établies par le biais de l'Internet public. Elles offrent davantage de fiabilité, des vitesses supérieures, des latences inférieures et une sécurité renforcée par rapport aux connexions classiques sur Internet. Bien qu’il soit recommandé d’utiliser ExpressRoute, vous pouvez choisir n’importe quelle méthode de connexion qui vous semble la plus adaptée à votre organisation. Pour en savoir plus sur ExpressRoute et sur les différentes options de connectivité basées sur ExpressRoute, consultez l’article Présentation technique d’ExpressRoute.

2. créer des comptes de stockage

Pour maintenir une haute disponibilité et éviter toute dépendance à un seul compte de stockage, vous pouvez créer deux comptes de stockage. Répartissez en deux groupes les machines virtuelles de chaque groupe à haute disponibilité, puis affectez chaque groupe à un compte de stockage distinct.

Créer des comptes de stockage

3. créer des groupes à haute disponibilité

Pour chaque rôle (contrôleur de domaine/AD FS et WAP), créez des groupes à haute disponibilité qui contiendront au minimum deux machines virtuelles, ce afin de garantir une meilleure disponibilité pour chaque rôle. Lorsque vous créez des groupes à haute disponibilité, vous devez impérativement étudier les aspects suivants :

  • Domaines d’erreur: les machines virtuelles du même domaine d’erreur partagent la même source d’alimentation et le même commutateur réseau physique. Il est recommandé d’utiliser au moins 2 domaines d’erreur. Vous pouvez utiliser la valeur par défaut (3) pour les besoins de ce déploiement
  • Domaines de mise à jour: les machines attachées au même domaine de mise à jour seront redémarrées simultanément pendant une mise à jour. Vous devez disposer d’au moins 2 domaines de mise à jour. Vous pouvez utiliser la valeur par défaut (5) pour les besoins de ce déploiement

Groupes à haute disponibilité

Créez les groupes à haute disponibilité suivants :

Groupe à haute disponibilité Role Domaines d’erreur Domaines de mise à jour
contosodcset DC/AD FS 3 5
contosowapset WAP 3 5

4. déployer des machines virtuelles

L’étape suivante consiste à déployer les machines virtuelles qui hébergeront les différents rôles de votre infrastructure. Nous vous recommandons d’affecter au moins deux machines virtuelles à chaque groupe à haute disponibilité. Créez quatre machines virtuelles dans le cadre du déploiement de base.

Machine Role Subnet Groupe à haute disponibilité Compte de stockage Adresse IP
contosodc1 DC/AD FS INT contosodcset contososac1 statique
contosodc2 DC/AD FS INT contosodcset contososac2 statique
contosowap1 WAP DMZ contosowapset contososac1 statique
contosowap2 WAP DMZ contosowapset contososac2 statique

Comme vous l’avez peut-être remarqué, aucun groupe de sécurité réseau n’a été spécifié, car Azure vous autorise à utiliser un groupe de sécurité réseau au niveau du sous-réseau. Vous pouvez dès lors contrôler le trafic réseau de la machine à l’aide du groupe de sécurité réseau précisément associé au sous-réseau ou à l’objet de carte réseau. Pour en savoir plus, consultez l’article Présentation du groupe de sécurité réseau. Nous vous recommandons d’utiliser une adresse IP statique si vous gérez le serveur DNS. Vous pouvez aussi utiliser Azure DNS et, au lieu des enregistrements DNS de votre domaine, référencer les nouvelles machines virtuelles par leurs noms de domaine complets Azure. Une fois le déploiement terminé, le volet de votre machine virtuelle devrait ressembler à ce qui suit :

Machines virtuelles déployées

5. Configuration du contrôleur de domaine/des serveurs de AD FS

Afin d’authentifier les demandes entrantes, AD FS doit pouvoir contacter le contrôleur de domaine. Pour éviter un transfert coûteux entre Azure et le contrôleur de domaine local dans le cadre de l’authentification, il est recommandé de déployer un réplica du contrôleur de domaine dans Azure. Pour bénéficier d’une haute disponibilité, il est recommandé de créer un groupe à haute disponibilité comprenant au moins 2 contrôleurs de domaine.

Contrôleur de domaine Role Compte de stockage
contosodc1 Réplica contososac1
contosodc2 Réplica contososac2
  • Déployez les deux serveurs en tant que réplicas de contrôleurs de domaine avec DNS
  • Configurez les serveurs AD FS en installant le rôle AD FS à l’aide du gestionnaire de serveurs.

6. déploiement d’Load Balancer internes (ILB)

6.1. Création de l’équilibreur de charge interne

Pour déployer un équilibreur de charge interne, sélectionnez Équilibreurs de charge dans le portail Azure, puis cliquez sur Ajouter (+).

Notes

Si vous ne voyez pas l’option de menu Équilibreurs de charge, cliquez sur Parcourir en bas à gauche du portail, puis faites défiler jusqu’à Équilibreurs de charge. Cliquez ensuite sur l’étoile jaune pour ajouter l’option à votre menu. Sélectionnez maintenant la nouvelle icône d’équilibreur de charge pour ouvrir le panneau qui vous permettra de configurer l’équilibreur de charge.

Rechercher un équilibreur de charge

  • Nom: attribuez un nom approprié à l’équilibreur de charge
  • Schéma: dans la mesure où cet équilibreur de charge sera placé devant les serveurs AD FS et est destiné uniquement aux connexions réseau internes, sélectionnez « interne ».
  • Réseau virtuel: choisissez le réseau virtuel dans lequel vous allez déployer vos services AD FS
  • Sous-réseau: sélectionnez ici votre sous-réseau interne
  • Attribution d’adresse IP: statique

Équilibreur de charge interne

Cliquez sur Créer pour déployer l’équilibreur de charge interne ; celui-ci doit normalement apparaître dans la liste des équilibreurs de charge :

Équilibreurs de charge après équilibreur de charge interne

L’étape suivante consiste à configurer le pool principal et la sonde principale.

6.2. Configuration du pool principal de l’équilibreur de charge interne

Dans le panneau Équilibreurs de charge, sélectionnez l’équilibreur de charge interne que vous venez de créer. Vous accédez au panneau Paramètres.

  1. Sélectionnez les pools principaux à partir du panneau Paramètres
  2. Dans le panneau Ajouter un pool principal, cliquez sur Ajouter une machine virtuelle
  3. Dans le panneau qui s’affiche, vous pouvez choisir votre groupe à haute disponibilité
  4. Choisissez le groupe à haute disponibilité AD FS

Configurer le pool backend ILB

6.3. Configuration de la sonde

Dans le panneau Équilibreurs de charge internes, sélectionnez Sondes d’intégrité.

  1. Cliquez sur Ajouter
  2. Indiquez les détails de la sonde a. Nom : nom de la sonde b. Protocole : HTTP c. Port : 80 (HTTP) d. Chemin d’accès : /adfs/probe e. Intervalle : 5 (valeur par défaut) : il s’agit de l’intervalle auquel l’équilibreur de charge interne interrogera les machines virtuelles du pool principal f. Seuil de défaillance d’intégrité : 2 (valeur par défaut) : il s’agit du seuil limite de défaillances consécutives de la sonde au-delà duquel l’équilibreur de charge interne considérera une machine du pool principal comme non réactive et cessera de lui envoyer du trafic.

Nous utilisons le point de terminaison /adfs/probe qui a été créé explicitement pour les contrôles d’intégrité dans un environnement AD FS où il est impossible de vérifier l’intégralité du chemin d’accès HTTPS. Cette méthode est de meilleure qualité qu’une vérification de base du port 443, qui ne reflète pas exactement l’état d’un déploiement AD FS moderne. Des informations supplémentaires sur ce point sont disponibles ici : https://blogs.technet.microsoft.com/applicationproxyblog/2014/10/17/hardware-load-balancer-health-checks-and-web-application-proxy-ad-fs-2012-r2/.

6,4. Créer des règles d’équilibrage de charge

Pour équilibrer au mieux le trafic, l’équilibreur de charge interne doit être configuré avec des règles d’équilibrage de charge. Pour créer une règle d’équilibrage de charge, procédez comme suit :

  1. Dans le panneau Paramètres de l’équilibreur de charge interne, sélectionnez Règle d’équilibrage de charge
  2. Cliquez sur Ajouter dans le panneau Règle d’équilibrage de charge
  3. Dans le panneau Ajouter une règle d’équilibrage de charge, renseignez les champs suivants : a. Nom : indiquez le nom de la règle b. Protocole : sélectionnez TCP c. Port : 443 d. Port principal : 443 e. Pool principal : sélectionnez le pool que vous avez précédemment créé pour le cluster AD FS f. Sonde: sélectionnez la sonde que vous avez précédemment créée pour les serveurs AD FS

Configuration des règles d’équilibrage de l’équilibreur de charge interne

6,5. Mise à jour du serveur DNS avec l’équilibreur de charge interne

À l’aide de votre serveur DNS interne, créez un enregistrement A pour le ILB. L’enregistrement A doit être destiné au service de Fédération avec l’adresse IP pointant vers l’adresse IP du ILB. Par exemple, si l’adresse IP ILB est 10.3.0.8 et que le service de Fédération installé est fs.contoso.com, créez un enregistrement A pour fs.contoso.com pointant vers 10.3.0.8. Cela permet de s’assurer que toutes les données Trasmitted à fs.contoso.com finissent au niveau du ILB et qu’elles sont correctement routées.

Avertissement

si vous utilisez le WID (Base de données interne Windows) pour votre base de données AD FS, cette valeur doit plutôt être temporairement définie pour pointer vers votre serveur de AD FS principal ou le Proxy d’Application Web échouera à l’inscription. Une fois que vous avez inscrit tous les serveurs proxy appplication Web, modifiez cette entrée DNS pour pointer vers l’équilibreur de charge.

Notes

Si votre déploiement utilise également IPv6, veillez à créer un enregistrement AAAA correspondant.

7. Configuration du serveur proxy d’application Web

7.1. Configuration des serveurs Web Application Proxy pour atteindre les serveurs AD FS

Pour faire en sorte que les serveurs Web Application Proxy soient en mesure d’atteindre les serveurs AD FS situés derrière l’équilibreur de charge interne, créez un enregistrement dans le répertoire %systemroot%\system32\drivers\etc\hosts de l’équilibreur de charge interne. Notez que le nom unique (DN) doit être le nom du service de fédération (par exemple fs.contoso.com). Et l’entrée IP doit être celle de l’adresse IP de ILB (10.3.0.8 comme dans l’exemple).

Avertissement

si vous utilisez le WID (Base de données interne Windows) pour votre base de données AD FS, cette valeur doit plutôt être temporairement définie pour pointer vers votre serveur de AD FS principal, ou le Proxy d’Application Web échouera. Une fois que vous avez inscrit tous les serveurs proxy appplication Web, modifiez cette entrée DNS pour pointer vers l’équilibreur de charge.

7.2. Installation du rôle Web Application Proxy

Après avoir vérifié que les serveurs Web Application Proxy sont bien en mesure d’atteindre les serveurs AD FS situés derrière l’équilibreur de charge interne, vous pouvez installer les serveurs Web Application Proxy. Les serveurs Web Application Proxy n’ont pas besoin d’être joints au domaine. Installez les rôles Web Application Proxy sur les deux serveurs Web Application Proxy en sélectionnant le rôle Accès à distance. Le gestionnaire de serveurs vous guide dans l’installation du serveur WAP. Pour plus d’informations sur le déploiement de WAP, consultez la page Installer et configurer le serveur proxy d’application web.

8. déploiement du Load Balancer accessible sur Internet (public)

8.1. Création d’un équilibreur de charge (public) accessible sur Internet

Dans le portail Azure, sélectionnez Équilibreurs de charge, puis cliquez sur Ajouter. Dans le panneau Créer un équilibreur de charge, entrez les informations suivantes :

  1. Nom: nom de l’équilibreur de charge
  2. Schéma: Public ; cette option indique à Azure que cet équilibreur de charge aura besoin d’une adresse publique.
  3. Adresse IP: créez une nouvelle adresse IP (dynamique)

Équilibreur de charge accessible sur Internet

Après le déploiement, l’équilibreur de charge s’affiche dans la liste des équilibreurs de charge.

Liste des équilibreurs de charge

8.2. Attribution d’un nom DNS à l’adresse IP publique

Dans le panneau Équilibreurs de charge, cliquez sur la nouvelle entrée d’équilibreur de charge pour afficher le panneau de configuration. Suivez les étapes ci-dessous pour configurer le nom DNS pour l’adresse IP publique :

  1. Cliquez sur l’adresse IP publique. Vous accédez au panneau correspondant à l’adresse IP publique et à ses paramètres
  2. Cliquez sur Configuration
  3. Indiquez un nom DNS. Ce nom deviendra ensuite le nom DNS public auquel vous pouvez accéder depuis n’importe quel emplacement, par exemple contosofs.westus.cloudapp.azure.com. Vous pouvez ajouter une entrée dans le DNS externe pour le service de fédération (par exemple, fs.contoso.com) qui résout le nom DNS de l’équilibreur de charge externe (contosofs.westus.cloudapp.azure.com).

Configurer l’équilibreur de charge accessible sur Internet

Configuration de l’équilibreur de charge accessible sur Internet (DNS)

8.3. Configuration d’un pool principal pour l’équilibreur de charge (public) accessible sur Internet

Suivez les mêmes étapes que pour la création de l’équilibreur de charge interne afin de configurer le pool principal de l’équilibreur de charge (public) accessible sur Internet en tant que groupe à haute disponibilité pour les serveurs WAP. Par exemple, contosowapset.

Configuration d’un pool principal pour l’équilibreur de charge accessible sur Internet

8,4. Configurer une analyse

Suivez les mêmes étapes que pour la configuration de l’équilibreur de charge interne afin de configurer la sonde pour le pool principal de serveurs WAP.

Configuration de la sonde d’équilibreur de charge accessible sur Internet

8,5. Créer une ou plusieurs règles d’équilibrage de charge

Suivez les mêmes étapes que pour l’équilibreur de charge interne afin de configurer la règle d’équilibrage de charge pour le port TCP 443.

Configuration des règles d’équilibrage de l’équilibreur de charge accessible sur Internet

9. sécurisation du réseau

9.1. Sécurisation du sous-réseau interne

En général, vous devez appliquer les règles suivantes pour sécuriser efficacement votre sous-réseau interne (dans l’ordre indiqué ci-dessous)

Règle Description Flux
AllowHTTPSFromDMZ Autoriser la communication HTTPS à partir de la zone DMZ Trafic entrant
DenyInternetOutbound Aucun accès à Internet Règle de trafic sortant

Règles d’accès INT (entrant)

9.2. Sécurisation du sous-réseau DMZ

Règle Description Flux
AllowHTTPSFromInternet Autoriser le trafic HTTPS entre Internet et la zone DMZ Trafic entrant
DenyInternetOutbound Tout trafic est bloqué, à l’exception du trafic HTTPS vers Internet Règle de trafic sortant

Règles d’accès EXT (entrant)

Notes

Si l’authentification par certificat utilisateur client (authentification clientTLS à l’aide de certificats utilisateur X. 509) est requise, AD FS nécessite l’activation du port TCP 49443 pour l’accès entrant.

10. tester la connexion AD FS

Le moyen le plus simple consiste à tester AD FS à l’aide de la page IdpInitiatedSignon.aspx. Pour cela, vous devez activer l’authentification IdpInitiatedSignOn sur les propriétés AD FS. Suivez les étapes ci-dessous pour vérifier votre configuration AD FS

  1. À l’aide de PowerShell, exécutez l’applet de commande ci-dessous sur le serveur AD FS pour l’activer. Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
  2. Depuis n’importe quel ordinateur externe, accès https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx.
  3. Vous devriez accéder à la page AD FS ci-dessous :

Page de connexion de test

Si l’authentification aboutit, vous obtenez le message de confirmation ci-dessous :

Réussite du test

Modèle de déploiement d’AD FS dans Azure

Le modèle déploie une installation à 6 machines, 2 par contrôleur de domaine, AD FS et WAP.

Modèle de déploiement d’AD FS dans Azure

Vous pouvez utiliser un réseau virtuel existant ou créer un nouveau réseau virtuel lors du déploiement de ce modèle. Les différents paramètres disponibles pour la personnalisation du déploiement sont répertoriés ci-dessous avec la description de l’utilisation du paramètre dans le processus de déploiement.

Paramètre Description
Emplacement Région dans laquelle déployer les ressources, par exemple, USA Est.
StorageAccountType Type de compte de stockage créé
VirtualNetworkUsage Indique si un réseau virtuel sera créé ou si un compte existant est utilisé
VirtualNetworkName Nom du réseau virtuel à créer, obligatoire lors de l’utilisation du réseau virtuel nouveau ou existant
VirtualNetworkResourceGroupName Spécifie le nom du groupe de ressources dans lequel réside le réseau virtuel existant. Lorsque vous utilisez un réseau virtuel existant, ce paramètre est obligatoire pour que le déploiement puisse trouver l’ID de réseau virtuel existant
VirtualNetworkAddressRange Plage d’adresses du nouveau réseau virtuel, obligatoire si vous créez un nouveau réseau virtuel
InternalSubnetName Nom du sous-réseau interne, obligatoire dans les deux options d’utilisation de réseau virtuel (nouveau ou existant)
InternalSubnetAddressRange La plage d’adresses du sous-réseau interne, qui contient les contrôleurs de domaine et les serveurs de AD FS, obligatoire si vous créez un nouveau réseau virtuel.
DMZSubnetAddressRange Plage d’adresses du sous-réseau dmz, qui contient les serveurs proxy d’application Windows, obligatoire si vous créez un nouveau réseau virtuel.
DMZSubnetName Nom du sous-réseau interne, obligatoire dans les deux options d’utilisation de réseau virtuel (nouveau ou existant).
ADDC01NICIPAddress Adresse IP interne du premier contrôleur de domaine, cette adresse IP est affectée de manière statique au contrôleur de domaine et doit être une adresse IP valide au sein du sous-réseau interne
ADDC02NICIPAddress Adresse IP interne du second contrôleur de domaine, cette adresse IP est affectée de manière statique au contrôleur de domaine et doit être une adresse IP valide au sein du sous-réseau interne
ADFS01NICIPAddress L’adresse IP interne du premier serveur de AD FS, cette adresse IP est affectée de manière statique au serveur AD FS et doit être une adresse IP valide au sein du sous-réseau interne
ADFS02NICIPAddress L’adresse IP interne du deuxième AD FS serveur, cette adresse IP est affectée de manière statique au serveur AD FS et doit être une adresse IP valide au sein du sous-réseau interne
WAP01NICIPAddress Adresse IP interne du premier serveur WAP, cette adresse IP est affectée de manière statique au serveur WAP et doit être une adresse IP valide au sein du sous-réseau DMZ
WAP02NICIPAddress Adresse IP interne du second serveur WAP, cette adresse IP est affectée de manière statique au serveur WAP et doit être une adresse IP valide au sein du sous-réseau DMZ
ADFSLoadBalancerPrivateIPAddress L’adresse IP interne de l’équilibreur de charge AD FS, cette adresse IP est affectée de manière statique à l’équilibreur de charge et doit être une adresse IP valide au sein du sous-réseau interne
ADDCVMNamePrefix Préfixe du nom de machine virtuelle pour les contrôleurs de domaine
ADFSVMNamePrefix Préfixe du nom de machine virtuelle pour les serveurs AD FS
WAPVMNamePrefix Préfixe du nom de machine virtuelle pour les serveurs WAP
ADDCVMSize Taille de la machine virtuelle des contrôleurs de domaine
ADFSVMSize Taille de la machine virtuelle des serveurs AD FS
WAPVMSize Taille de la machine virtuelle des serveurs WAP
AdminUserName Nom de l’administrateur local des machines virtuelles
AdminPassword Mot de passe du compte administrateur local des machines virtuelles

Ressources supplémentaires

Étapes suivantes