Partager via

Déployer AD DS dans un réseau virtuel Azure

Microsoft Entra
Réseau virtuel Azure

Cette architecture montre comment étendre un domaine Active Directory local à Azure pour fournir des services d’authentification distribués.

Architecture

Diagramme montrant une architecture réseau hybride sécurisée qui utilise Active Directory.

Téléchargez un fichier Visio de cette architecture.

Cette architecture étend l’architecture réseau hybride indiquée dans Connecter un réseau local à Azure à l’aide d’une passerelle VPN.

Flux de travail

Le workflow suivant correspond au diagramme précédent :

  • Réseau local : Le réseau local inclut des serveurs Active Directory locaux qui peuvent effectuer l’authentification et l’autorisation pour les composants situés localement.

  • Serveurs Active Directory : Ces serveurs sont des contrôleurs de domaine qui implémentent des services d’annuaire qui s’exécutent en tant que machines virtuelles dans le cloud. Ils peuvent fournir l’authentification des composants qui s’exécutent dans votre réseau virtuel Azure.

  • Sous-réseau Active Directory : Les serveurs Active Directory Domain Services (AD DS) sont hébergés dans un sous-réseau distinct. Les règles de groupe de sécurité réseau (NSG) aident à protéger les serveurs AD DS et à fournir un pare-feu contre le trafic provenant de sources inattendues.

  • Passerelle VPN Azure et synchronisation Active Directory : La passerelle VPN fournit une connexion entre le réseau local et le réseau virtuel Azure. Il peut s’agir d’une connexion VPN ou via Azure ExpressRoute. Toutes les demandes de synchronisation entre les serveurs Active Directory dans le cloud et dans l’environnement local passent par la passerelle. Les itinéraires définis par l’utilisateur gèrent le routage pour le trafic local qui passe à Azure.

Composants

  • Microsoft Entra ID est un service d’identité d’entreprise qui fournit l’authentification unique, l’authentification multifacteur et l’accès conditionnel Microsoft Entra. Dans cette architecture, Microsoft Entra ID fournit un accès plus sécurisé aux applications et services cloud.

  • La passerelle VPN est un service qui utilise des passerelles de réseau virtuel pour envoyer le trafic chiffré entre un réseau virtuel Azure et des emplacements locaux via l’Internet public. Dans cette architecture, la passerelle VPN permet au trafic de synchronisation Active Directory de circuler de manière plus sécurisée entre les environnements.

  • ExpressRoute est un service que vous pouvez utiliser pour étendre vos réseaux locaux dans le cloud Microsoft via une connexion privée avec l’aide d’un fournisseur de connectivité. Dans cette architecture, ExpressRoute est une alternative aux connexions VPN pour les scénarios nécessitant une bande passante plus élevée et une latence inférieure.

  • Réseau virtuel est le bloc de construction fondamental des réseaux privés sur Azure. Vous pouvez l’utiliser pour permettre aux ressources Azure, telles que les machines virtuelles, de communiquer entre elles, d’internet et de réseaux locaux. Dans cette architecture, le réseau virtuel prend en charge la réplication et l’authentification de domaine.

Détails du scénario

Si votre application est hébergée en partie localement et en partie dans Azure, la réplication d’AD DS dans Azure peut être plus efficace. Cette réplication peut réduire la latence causée par l’envoi de demandes d’authentification du cloud à des instances AD DS qui s’exécutent localement.

Cas d’usage potentiels

Cette architecture est couramment utilisée lorsqu’une connexion VPN ou ExpressRoute connecte les réseaux virtuels locaux et Azure. Cette architecture prend également en charge la réplication bidirectionnelle, ce qui signifie que les modifications peuvent être apportées localement ou dans le cloud, et les deux sources sont cohérentes. Les utilisations courantes de cette architecture incluent des applications hybrides dans lesquelles les fonctionnalités sont distribuées entre des applications et des applications et des services locaux et Azure qui effectuent l’authentification à l’aide d’Active Directory.

Recommandations

Vous pouvez appliquer les recommandations suivantes à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Recommandations pour les machines virtuelles

Déterminez la taille de machine virtuelle requise en fonction du volume attendu de requêtes d’authentification. Utilisez les spécifications des machines qui hébergent AD DS localement comme point de départ et les correspondent aux tailles de machine virtuelle Azure. Après avoir déployé votre application, surveillez l’utilisation et effectuez un scale-up ou un scale-down en fonction de la charge réelle sur les machines virtuelles. Pour plus d’informations, consultez Planification de la capacité pour AD DS.

Créez un disque de données virtuel distinct pour stocker la base de données, les journaux et le dossier sysvol (system volume) pour Active Directory. Ne stockez pas ces éléments sur le même disque que le système d’exploitation. Par défaut, les disques de données sont attachés à une machine virtuelle à l’aide de la mise en cache en écriture. Toutefois, cette forme de mise en cache peut entrer en conflit avec les exigences d’AD DS. Vous devez donc, sur le disque de données, définir le paramètre Préférences de cache d’hôte sur Aucun.

Déployez au moins deux machines virtuelles qui exécutent AD DS en tant que contrôleurs de domaine et ajoutez-les à différentes zones de disponibilité. Si les zones de disponibilité ne sont pas disponibles dans la région, déployez les machines virtuelles dans un groupe à haute disponibilité.

Recommandations pour la mise en réseau

Configurez l’interface réseau de machine virtuelle pour chaque contrôleur de domaine avec une adresse IP privée statique au lieu d’utiliser le protocole DHCP (Dynamic Host Configuration Protocol). En affectant une adresse IP statique directement à la machine virtuelle, les clients peuvent continuer à contacter le contrôleur de domaine même si le service DHCP n’est pas disponible. Pour plus d’informations, consultez Créer une machine virtuelle qui utilise une adresse IP privée statique.

Notes

Ne configurez pas la carte réseau de machine virtuelle pour ad DS à l’aide d’une adresse IP publique. Pour plus d’informations, consultez Considérations relatives à la sécurité.

Le groupe de sécurité réseau du sous-réseau Active Directory requiert des règles pour autoriser le trafic entrant à partir de l’environnement local et le trafic sortant vers l’environnement local. Pour plus d’informations, consultez Configurer un pare-feu pour les domaines et approbations Active Directory.

Si les nouvelles machines virtuelles du contrôleur de domaine ont également le rôle des serveurs DNS (Domain Name System), nous vous recommandons de les configurer en tant que serveurs DNS personnalisés au niveau du réseau virtuel, comme expliqué dans Modifier les serveurs DNS. Vous devez appliquer cette configuration pour le réseau virtuel qui héberge les nouveaux contrôleurs de domaine et les réseaux appairés où d’autres machines virtuelles doivent résoudre les noms de domaine Active Directory. Pour plus d’informations, consultez Résolution de noms pour les ressources dans les réseaux virtuels Azure.

Pour la configuration initiale, vous devrez peut-être ajuster la carte réseau de l’un de vos contrôleurs de domaine dans Azure pour qu’elle pointe vers un contrôleur de domaine local comme source DNS principale.

L’inclusion de son adresse IP dans la liste des serveurs DNS améliore les performances et augmente la disponibilité des serveurs DNS. Toutefois, un délai de démarrage peut se produire si le serveur DNS est également un contrôleur de domaine et pointe uniquement vers lui-même ou pointe vers lui-même pour la résolution de noms.

Pour cette raison, soyez prudent lorsque vous configurez l’adresse de bouclage sur une carte si le serveur est également un contrôleur de domaine. Vous devrez peut-être remplacer les paramètres DNS de la carte réseau dans Azure pour pointer vers un autre contrôleur de domaine hébergé dans Azure ou localement pour le serveur DNS principal. L’adresse de bouclage doit être configurée uniquement en tant que serveur DNS secondaire ou tertiaire sur un contrôleur de domaine.

Site Active Directory

Dans AD DS, un site représente un emplacement physique, un réseau ou une collection d’appareils. Utilisez des sites AD DS pour gérer la réplication de base de données AD DS en regroupant des objets AD DS situés à proximité et connectés par un réseau à grande vitesse. AD DS inclut la logique qui assure la sélection de la meilleure stratégie de réplication de la base de données AD DS entre les sites.

Nous vous recommandons de créer un site AD DS, y compris les sous-réseaux définis pour votre application dans Azure. Ensuite, vous pouvez configurer un lien de site entre vos sites AD DS locaux. AD DS effectue automatiquement la réplication de base de données la plus efficace possible. Cette réplication de base de données ne nécessite pas beaucoup de travail au-delà de la configuration initiale.

Maître d’opérations Active Directory

Vous pouvez affecter le rôle principal des opérations aux contrôleurs de domaine AD DS pour prendre en charge la cohérence lorsqu’ils vérifient entre les instances des bases de données AD DS répliquées. Les cinq rôles principaux d’opérations sont le maître de schéma, le maître d’affectation de noms de domaine, le maître d’identificateur relatif, l’émulateur principal du contrôleur de domaine principal et le maître d’infrastructure. Pour plus d’informations, consultez Plan Operations Master Role Placement.

Nous vous recommandons également de donner au moins deux des nouveaux contrôleurs de domaine Azure au rôle de catalogue global (GC). Pour plus d’informations, consultez Planifier l’emplacement du serveur GC.

Supervision

Surveillez les ressources des machines virtuelles du contrôleur de domaine et ad DS et créez un plan pour corriger rapidement les problèmes. Pour plus d’informations, consultez Surveiller Active Directory. Vous pouvez également installer des outils tels que Microsoft Systems Center sur le serveur de surveillance pour vous aider à effectuer ces tâches.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

Déployez les machines virtuelles qui exécutent AD DS dans au moins deux zones de disponibilité. Si les zones de disponibilité ne sont pas disponibles dans la région, utilisez des groupes à haute disponibilité. En outre, envisagez d’attribuer le rôle de maître des opérations de secours à au moins un serveur ou plusieurs, en fonction de vos besoins. Un maître d’opérations en attente est une copie active du maître d’opérations qui remplace le serveur maître d’opérations principal au cours du basculement.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

Les serveurs AD DS fournissent des services d’authentification et sont une cible attrayante pour les attaques. Pour les sécuriser, empêchez la connectivité Internet directe en plaçant les serveurs AD DS dans un sous-réseau distinct avec un groupe de sécurité réseau en tant que pare-feu. Fermez tous les ports sur les serveurs AD DS, à l’exception des ports nécessaires pour l’authentification, l’autorisation et la synchronisation du serveur. Pour plus d’informations, consultez Configurer un pare-feu pour les domaines et approbations Active Directory.

Utilisez BitLocker ou Azure Disk Encryption pour chiffrer le disque qui héberge la base de données AD DS.

Azure DDoS Protection, combiné aux meilleures pratiques de conception d’application, fournit des fonctionnalités d’atténuation DDoS améliorées pour vous protéger contre les attaques DDoS. Vous devez activer la protection DDoS sur n’importe quel réseau virtuel de périmètre.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Utiliser la calculatrice de prix Azure pour estimer les coûts. D’autres considérations sont décrites dans la section Optimisation des coûts dans Well-Architected Framework.

Les sections suivantes décrivent les considérations relatives aux coûts pour les services que cette architecture utilise.

Services de domaine Microsoft Entra

Envisagez d’avoir Microsoft Entra Domain Services en tant que service partagé consommé par plusieurs charges de travail pour réduire les coûts. Pour plus d’informations, consultez la tarification des services de domaine.

Passerelle VPN

La passerelle VPN est le composant principal de cette architecture. Vous êtes facturé en fonction de l’heure à laquelle la passerelle est provisionnée et disponible.

Tout le trafic entrant est gratuit. Tout le trafic sortant est facturé. Les coûts de la bande passante Internet sont appliqués au trafic VPN sortant.

Pour plus d’informations, consultez Tarification Passerelle VPN.

Réseau virtuel

Le service Réseau virtuel est gratuit. Chaque abonnement est autorisé à créer jusqu’à 1,000 réseaux virtuels dans toutes les régions. Tout le trafic dans les limites d’un réseau virtuel est gratuit, de sorte que la communication entre deux machines virtuelles dans le même réseau virtuel est gratuite.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

  • Utilisez l’infrastructure en tant que pratiques de code pour approvisionner et configurer l’infrastructure réseau et de sécurité. Une autre option consiste à utiliser des modèles Azure Resource Manager.

  • Isolez les charges de travail pour permettre à DevOps d'effectuer une intégration et une livraison continues (CI/CD), car chaque charge de travail est associée et gérée par l'équipe DevOps correspondante.

Dans cette architecture, l’ensemble du réseau virtuel qui inclut les différents niveaux d’application, la zone de rebond de gestion et les services de domaine est identifié comme une charge de travail isolée unique.

Vous pouvez configurer AD DS sur des machines virtuelles à l’aide d’extensions de machine virtuelle et d’autres outils, tels que DSC (Desired State Configuration).

  • Envisagez d’automatiser vos déploiements à l’aide d’Azure DevOps ou d’autres solutions CI/CD. Azure Pipelines est le composant recommandé d’Azure DevOps Services. Il fournit une automatisation pour les builds et les déploiements de solutions et est hautement intégré à l’écosystème Azure.

  • Utilisez Azure Monitor pour analyser les performances de votre infrastructure. Vous pouvez également l’utiliser pour surveiller et diagnostiquer les problèmes réseau sans vous connecter à vos machines virtuelles. Application Insights fournit des métriques et des journaux enrichis pour vérifier l’état de votre infrastructure.

Pour plus d’informations, consultez la section DevOps dans Well-Architected Framework.

Simplicité de gestion

Effectuez des sauvegardes régulières d’AD DS. Ne copiez pas simplement les fichiers de disque dur virtuel (VHD) des contrôleurs de domaine, car le fichier de base de données AD DS sur le disque dur virtuel peut ne pas être cohérent lors de la copie, ce qui rend impossible le redémarrage de la base de données.

Nous vous déconseillons d’arrêter une machine virtuelle de contrôleur de domaine à l’aide du portail Azure. Au lieu de cela, arrêtez et redémarrez le système d’exploitation invité. Si vous arrêtez un contrôleur de domaine à l’aide du portail Azure, la machine virtuelle est libérée, ce qui entraîne les effets suivants lorsque vous redémarrez la machine virtuelle du contrôleur de domaine :

  • Il réinitialise le VM-GenerationID référentiel Active Directory et le invocationID référentiel Active Directory.
  • Il ignore le pool d’identificateurs relatifs Active Directory (RID) actuel.
  • Il marque le dossier sysvol comme non authentifié.

Le premier problème est relativement bénin. La réinitialisation répétée des causes de l’utilisation invocationID mineure de la bande passante pendant la réplication, mais cette utilisation n’est pas significative.

Le deuxième problème peut contribuer à l’épuisement du pool RID dans le domaine, en particulier si la taille du pool RID est configurée pour être supérieure à la valeur par défaut. Si le domaine existe depuis longtemps ou s’il est utilisé pour les flux de travail qui nécessitent la création et la suppression de comptes répétitifs, il peut déjà s’avérer proche de l’épuisement du pool RID. La surveillance du domaine pour les événements d’avertissement d’épuisement du pool RID est une bonne pratique. Pour plus d’informations, consultez Gérer l’émission RID.

Le troisième problème est relativement bénin tant qu’un contrôleur de domaine faisant autorité est disponible lorsqu’une machine virtuelle de contrôleur de domaine dans Azure est redémarrée. Si tous les contrôleurs de domaine d’un domaine s’exécutent dans Azure et qu’ils sont tous arrêtés et désalloués simultanément, chaque contrôleur de domaine ne trouve pas de réplica faisant autorité lorsque vous les redémarrez. La résolution de cette condition nécessite une intervention manuelle. Pour plus d’informations, consultez Forcer la synchronisation faisant autorité et non-authentifiée pour la réplication sysvol répliquée par DFSR.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

AD DS est conçu dans un souci de scalabilité. Vous n’avez pas besoin de configurer un équilibreur de charge ou un contrôleur de trafic pour diriger les demandes vers les contrôleurs de domaine AD DS. La seule considération de scalabilité consiste à configurer les machines virtuelles qui exécutent AD DS avec la taille appropriée pour vos besoins en charge réseau, à surveiller la charge sur les machines virtuelles et à effectuer un scale-up ou un scale-down si nécessaire.

Étapes suivantes