Cette architecture de référence montre comment créer, dans Azure, un domaine Active Directory distinct approuvé par les domaines de votre forêt AD locale.
Téléchargez un fichier Visio pour l’architecture « Forêt AD DS ».
Active Directory Domain Services (AD DS) stocke des informations d’identité dans une structure hiérarchique. Le nœud supérieur de la structure hiérarchique est appelé « forêt ». Une forêt contient des domaines, qui à leur tour contiennent d’autres types d’objets. Cette architecture de référence crée une forêt AD DS dans Azure avec une relation d’approbation à sens unique sortante avec un domaine local. La forêt dans Azure contient un domaine qui n’existe pas localement. En raison de la relation d’approbation, les ouvertures de session effectuées dans les domaines locaux peuvent être approuvées pour l’accès aux ressources dans le domaine Azure distinct.
Parmi les utilisations courantes de cette architecture figurent la conservation d’une séparation de sécurité pour les objets et les identités contenus dans le cloud et la migration de domaines individuels depuis l’environnement local vers le cloud.
Pour plus d'informations, consultez Choisir une solution pour intégrer l'environnement Active Directory local à Azure.
Architecture
L’architecture possède les composants suivants :
- Réseau local. Le réseau local contient ses propres forêt et domaines Active Directory.
- Serveurs Active Directory. Il s’agit de contrôleurs de domaine qui implémentent des services de domaine s’exécutant en tant que machines virtuelles dans le cloud. Ces serveurs hébergent une forêt qui contient un ou plusieurs domaines, distincts de ceux situés dans l’environnement local.
- Relation d’approbation à sens unique. L’exemple dans le diagramme montre une approbation à sens unique entre le domaine dans Azure et le domaine local. Cette relation permet aux utilisateurs locaux d’accéder aux ressources du domaine dans Azure, mais pas l’inverse.
- Sous-réseau Active Directory. Les serveurs 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.
- Passerelle Azure. La passerelle Azure fournit une connexion entre le réseau local et le réseau virtuel Azure. Il peut s’agir d’une connexion VPN ou d’Azure ExpressRoute. Pour plus d’informations, consultez Connecter un réseau local à Azure à l’aide d’une passerelle VPN.
Recommandations
Pour obtenir des recommandations spécifiques sur l’implémentation d’Active Directory dans Azure, consultez Extension d'Active Directory Domain Services (AD DS) à Azure.
Confiance
Les domaines locaux sont contenus dans une forêt différente des domaines dans le cloud. Pour activer l’authentification des utilisateurs locaux dans le cloud, les domaines dans Azure doivent faire confiance au domaine d’ouverture de session dans la forêt locale. De même, si le cloud fournit un domaine d’ouverture de session pour les utilisateurs externes, il peut être nécessaire que la forêt locale fasse confiance au domaine du cloud.
Vous pouvez établir des approbations au niveau forêt, en créant des approbations de forêt, ou au niveau domaine, en créant des approbations externes. Une approbation de niveau forêt crée une relation entre tous les domaines dans deux forêts. Une approbation de niveau domaine externe crée uniquement une relation entre deux domaines spécifiés. Vous devez uniquement créer des approbations de niveau domaine externe entre des domaines dans des forêts différentes.
Les approbations avec un Active Directory local sont uniquement unidirectionnelles (à sens unique). Une approbation à sens unique permet aux utilisateurs d’une forêt ou domaine (forêt ou domaine entrant) d’accéder aux ressources contenues dans une autre forêt ou domaine (forêt ou domaine sortant).
Le tableau suivant récapitule les configurations d’approbation pour certains scénarios simples :
| Scénario | Approbation locale | Approbation au niveau du cloud |
|---|---|---|
| Les utilisateurs locaux requièrent l’accès aux ressources dans le cloud, mais l’inverse n’est pas vrai. | À sens unique, entrante | À sens unique, sortante |
| Les utilisateurs dans le cloud requièrent l’accès aux ressources locales, mais l’inverse n’est pas vrai. | À sens unique, sortante | À sens unique, entrante |
Considérations relatives à l’extensibilité
Active Directory peut évoluer automatiquement pour les contrôleurs de domaine qui font partie du même domaine. Les demandes sont distribuées sur tous les contrôleurs d’un domaine. Vous pouvez ajouter un contrôleur de domaine, qui se synchronise alors automatiquement avec le domaine. Ne configurez pas d’équilibreur de charge distinct pour diriger le trafic vers des contrôleurs dans le domaine. Vérifiez que tous les contrôleurs de domaine disposent de suffisamment de ressources mémoire et de stockage pour gérer la base de données du domaine. Attribuez la même taille aux machines virtuelles de contrôleur de domaine.
Considérations relatives à la disponibilité
Provisionnez au moins deux contrôleurs de domaine par domaine. Cela permet une réplication automatique entre les serveurs. Créez un groupe à haute disponibilité pour les machines virtuelles faisant office de serveurs Active Directory chargés de gérer chaque domaine. Placez au moins deux serveurs dans ce groupe à haute disponibilité.
Envisagez également de désigner un ou plusieurs serveurs dans chaque domaine en tant que maîtres d’opérations en attente en cas d’échec de la connectivité à un serveur agissant en tant que rôle de FSMO (Flexible Single Master Operation).
Considérations relatives à la facilité de gestion
Pour plus d’informations sur les considérations relatives à la gestion et à la surveillance, consultez Extension d’Active Directory à Azure.
Pour plus d’informations, consultez Surveillance d’Active Directory. Vous pouvez installer des outils tels que Microsoft Systems Center sur un serveur de surveillance dans le sous-réseau de gestion pour effectuer ces tâches.
Considérations relatives à la sécurité
Les approbations de niveau forêt sont transitives. Si vous établissez une approbation de niveau forêt entre une forêt locale et une forêt dans le cloud, cette approbation est étendue aux autres domaines créés dans l’une ou l’autre des forêts. Si vous utilisez des domaines pour fournir une séparation à des fins de sécurité, envisagez de créer des approbations au niveau domaine uniquement. Les approbations de niveau domaine sont non transitives.
Pour connaître les considérations relatives à la sécurité propres à Active Directory, consultez la section sur les considérations relatives à la sécurité dans Extension d’Active Directory à Azure.
Considérations relatives à DevOps
Pour d’autres informations sur DevOps, consultez l’excellence opérationnelle dans Extension d’Active Directory Domain Services (AD DS) à Azure.
Considérations relatives au coût
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 Azure
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 une 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 Passerelle VPN Tarification.
Étapes suivantes
- Découvrez les bonnes pratiques pour étendre votre domaine AD DS local à Azure.
- Découvrez les bonnes pratiques pour créer une infrastructure AD FS dans Azure.