Modifier

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 l’architecture réseau hybride sécurisée avec Active Directory.

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

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

Workflow

  • Réseau local. Le réseau local comprend des serveurs Active Directory locaux qui peuvent effectuer l’authentification et l’autorisation pour les composants situés dans l’environnement local.
  • Serveurs Active Directory. Ces serveurs sont des contrôleurs de domaine qui implémentent des services d’annuaire (AD DS) s’exécutant en tant que machines virtuelles dans le cloud. Ils peuvent assurer l’authentification des composants s’exécutant dans votre réseau virtuel Azure.
  • Sous-réseau Active Directory. Les Active Directory Domain Services (AD DS) sont hébergés dans un sous-réseau distinct. Des règles de groupe de sécurité réseau (NSG) protègent les serveurs AD DS et fournissent un pare-feu contre le trafic en provenance de sources inconnues.
  • Synchronisation Active Directory et passerelle VPN Azure. 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 du trafic local vers Azure.

Composants

  • Microsoft Entra ID est un service d'identité d'entreprise qui fournit une authentification unique, une authentification multifacteur et un accès conditionnel.
  • La passerelle VPN est un service qui utilise une passerelle de réseau virtuel pour envoyer du trafic chiffré entre un réseau virtuel Azure et un emplacement local sur l’Internet public.
  • ExpressRoute vous permet d’étendre vos réseaux locaux dans le cloud Microsoft via une connexion privée avec l’aide d’un fournisseur de connectivité.
  • Réseau virtuel est le bloc de construction fondamental des réseaux privés sur Azure. Vous pouvez l’utiliser pour permettre à des ressources Azure telles que des machines virtuelles de communiquer entre elles, avec Internet et avec des réseaux locaux.

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. La réplication peut réduire la latence provoquée par l’envoi des requêtes d’authentification depuis le cloud vers les services AD DS exécutés localement.

Pour plus d'informations, consultez Choisir une solution pour intégrer l'environnement Active Directory local à Azure.

Cas d’usage potentiels

Cette architecture est couramment utilisée lorsqu’une connexion VPN ou ExpressRoute connecte les réseaux virtuels locaux et Azure. De plus, cette architecture prend en charge la réplication bidirectionnelle : si des modifications sont effectuées localement ou dans le cloud, les deux sources restent cohérentes. Parmi les utilisations courantes de cette architecture, citons les applications hybrides dans lesquelles la fonctionnalité est répartie entre l’environnement local et Azure, et les applications et services qui effectuent l’authentification à l’aide d’Active Directory.

Recommandations

Les recommandations suivantes s’appliquent à 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 hébergeant AD DS localement comme point de départ et mettez-les en correspondance avec les tailles des machines virtuelles Azure. Une fois le déploiement effectué, surveillez l’utilisation et procédez à un ajustement d’échelle en fonction de la charge réelle qui pèse sur les machines virtuelles. Pour plus d’informations sur le dimensionnement des contrôleurs de domaine AD DS, consultez Planification de la capacité pour Active Directory Domain Services.

Créez un disque de données virtuel distinct pour le stockage de la base de données, des journaux d’activité et du dossier sysvol 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 d’un cache à double é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 exécutant AD DS en tant que contrôleurs de domaine et ajoutez-les à différentes zones de disponibilité. Si cela n’est pas disponible dans la région, déployez dans un groupe à haute disponibilité.

Recommandations pour la mise en réseau

Configurez l’interface réseau de machine virtuelle pour chaque serveur AD DS avec une adresse IP privée statique pour la prise en charge complète du service de noms de domaine (DNS). Pour plus d’informations, consultez Définition d’une adresse IP privée statique dans le portail Azure.

Notes

Ne configurez pas l’interface réseau de machine virtuelle pour un serveur AD DS avec 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 sur les ports utilisés par AD DS, consultez Exigences de port pour Active Directory et Active Directory Domain Services.

Si les nouvelles machines virtuelles de contrôleur de domaine ont également le rôle de serveurs DNS, 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 le faire pour le réseau virtuel hébergeant les nouveaux contrôleurs de domaine et réseaux appairés où d’autres machines virtuelles doivent résoudre les noms de domaine Active Directory. Pour plus d’informations sur la configuration de la résolution de noms DNS hybride, consultez Résolution de noms pour les ressources dans les réseaux virtuels Azure.

Pour la configuration initiale, vous devrez peut-être ajuster l’interface réseau de l’un de vos contrôleurs de domaine dans Azure pour pointer 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 retard 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 en premier pour la résolution de noms. Pour cette raison, soyez prudent lors de la configuration de l’adresse de bouclage sur une carte si le serveur est également un contrôleur de domaine.

Cela peut signifier le remplacement des paramètres DNS de l’interface réseau dans Azure pour pointer vers un autre contrôleur de domaine hébergé dans Azure ou local 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. Les sites AD DS permettent de gérer la réplication de la base de données AD DS en regroupant les objets AD DS qui sont situés à proximité les uns des autres et qui sont connectés par un réseau haut débit. 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 incluant 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, afin qu’AD DS effectue automatiquement la réplication de base de données la plus efficace possible. Cette réplication de base de données nécessite peu de tâches de configuration en plus de la configuration initiale.

Maître d’opérations Active Directory

Vous pouvez affecter le rôle de maître d’opérations aux contrôleurs de domaine AD DS afin qu’ils prennent en charge le contrôle de la cohérence entre les instances des bases de données AD DS répliquées. Il existe cinq rôles de maître d’opérations (FSMO) : contrôleur de schéma, maître d’opérations des noms de domaine, maître d’identificateur relatif, émulateur maître de contrôleur de domaine principal et maître d’infrastructure. Pour plus d’informations sur ces rôles, consultez Planification de la sélection élective des rôles de maître d’opérations. Il est également recommandé de donner au moins à deux des nouveaux DC Azure le rôle Catalogue global (GC). Des informations supplémentaires sur le placement de GC sont disponibles ici.

Supervision

Supervisez les ressources des machines virtuelles de contrôleur de domaine et les services AD DS, et créez un plan pour corriger les problèmes rapidement. Pour plus d’informations, consultez Surveillance d’Active Directory. Vous pouvez également installer des outils tels que Microsoft Systems Center sur le serveur de surveillance (voir le diagramme de l’architecture) pour 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 Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Déployez les machines virtuelles exécutant 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é. De plus, envisagez d’attribuer le rôle de maître d’opérations en attente à un serveur, voire plus, selon 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é fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Les serveurs AD DS fournissent des services d’authentification, ce qui en fait une cible de choix pour les attaques. Pour les sécuriser, empêchez la connectivité Internet directe en les plaçant dans un sous-réseau distinct doté d’un groupe de sécurité réseau en guise de pare-feu. Fermez tous les ports sur les serveurs AD DS, à l’exception de ceux nécessaires à l’authentification, à l’autorisation et à la synchronisation des serveurs. Pour plus d’informations, consultez Exigences de port pour Active Directory et Active Directory Domain Services.

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

Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

  • Utilisez la pratique d’infrastructure en tant que code (IaC) 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 comprend les différents niveaux d'application, le jump box de gestion et les services Microsoft Entra Domain est identifié comme une seule charge de travail isolée.

Les machines virtuelles sont configurées à l’aide d’extensions de machine virtuelle ainsi que d’autres outils, tels que DSC (Desired State Configuration), utilisés pour configurer AD DS sur les machines virtuelles.

  • Envisagez d’automatiser vos déploiements à l’aide d’Azure DevOps ou de toute autre solution CI/CD. Azure Pipelines est le composant recommandé d’Azure DevOps Services et permet d’automatiser les builds et les déploiements de solution. Il est hautement intégré à l’écosystème Azure.

  • Utilisez Azure Monitor pour analyser les performances de votre infrastructure. Il vous permet de surveillez et de 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 de Microsoft Azure Well-Architected Framework.

Simplicité de gestion

Effectuez des sauvegardes régulières d’AD DS. Ne copiez pas les fichiers VHD des contrôleurs de domaine plutôt que d’effectuer des sauvegardes régulières. En effet, si le fichier de la base de données AD DS sur le disque dur virtuel est incohérent lors de la copie, il est impossible de redémarrer la base de données.

Il n’est pas recommandé d’arrêter une machine virtuelle de contrôleur de domaine avec le portail Azure. Au lieu de cela, arrêtez et redémarrez le système d’exploitation invité. L’arrêt de la machine virtuelle à partir du Portail Azure provoque la libération de la machine virtuelle, ce qui entraîne les effets suivants lorsque la VM du contrôleur de domaine est redémarrée :

  1. Réinitialisation de VM-GenerationID et de invocationID du référentiel Active Directory
  2. Abandon du pool d’identificateurs relatifs (RID) Active Directory actuel
  3. Identification du dossier sysvol comme ne faisant pas autorité

Le premier problème est relativement bénin. La réinitialisation répétée de invocationID entraîne une utilisation mineure supplémentaire de la bande passante lors de la réplication, mais ce n’est généralement pas significatif.

Le deuxième problème peut contribuer à l’épuisement du pool RID dans le domaine, en particulier si la taille du pool RID a été configurée pour être supérieure à la valeur par défaut. Si le domaine est trop vieux ou s’il est utilisé pour des workflows nécessitant une création et une suppression répétitives de comptes, il se peut que le domaine soit déjà proche de l’épuisement du pool RID. Une bonne pratique consiste à superviser le domaine pour les événements d’avertissement d’épuisement du pool RID : consultez l’article Gestion de l’émission RID.

Le troisième problème est relativement bénin tant qu’un contrôleur de domaine faisant autorité est disponible lors du redémarrage d’une machine virtuelle de contrôleur de domaine dans Azure. Si tous les contrôleurs de domaine dans un domaine s’exécutent dans Azure et s’ils sont tous arrêtés et désalloués simultanément, les contrôleurs de domaine ne parviennent pas à trouver un réplica faisant autorité au redémarrage. La résolution de cette condition nécessite une intervention manuelle : consultez l’article Comment forcer une synchronisation faisant autorité et ne faisant pas autorité pour la réplication sysvol répliqué par le service DFSR.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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. Vous devez simplement configurer les machines virtuelles exécutant AD DS avec la taille appropriée suivant les exigences de charge de votre réseau, superviser la charge sur les machines virtuelles et faire évoluer la configuration en fonction des besoins.

Optimisation des coûts

L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’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 Coûts de Microsoft Azure Well-Architected Framework.

Les considérations de coûts suivantes s'appliquent aux services utilisés dans cette architecture.

Services de domaine AD

Envisagez d’utiliser Active Directory Domain Services en tant que service partagé entre plusieurs charges de travail pour réduire les coûts. Pour plus d’informations, reportez-vous aux tarifs d’Active Directory Domain Services.

Passerelle VPN

Le composant principal de cette architecture est le service de passerelle VPN. Le coût facturé est calculé en fonction de la durée pendant laquelle la passerelle est configuré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.

Étapes suivantes