Cet article compare les options disponibles pour intégrer votre environnement Active Directory (AD) local avec un réseau Azure. Pour chaque option, une architecture de référence plus détaillée est disponible.
De nombreuses organisations utilisent les services Active Directory Domain Services (AD DS) pour authentifier les identités associées aux utilisateurs, aux ordinateurs, aux applications ou aux autres ressources incluses dans un périmètre de sécurité donné. Les services de répertoire et d’identité sont généralement hébergés localement, mais si votre application est hébergée à la fois localement et dans Azure, il peut y avoir un certain temps de latence lors de l’envoi de requêtes d’authentification à partir d’Azure vers l’environnement local. L’implémentation des services de répertoire et d’identité dans Azure peut réduire cette latence.
Azure offre deux solutions pour implémenter les services de répertoire et d’identité dans Azure :
Utilisez Microsoft Entra ID pour créer un domaine Active Directory dans le cloud et le connecter à votre domaine Active Directory local. Microsoft Entra Connect intègre vos répertoires locaux à Microsoft Entra ID.
Étendez votre infrastructure Active Directory locale dans Azure en déployant une machine virtuelle dans Azure qui exécute les services AD DS en tant que contrôleur de domaine. Cette architecture est couramment utilisée quand le réseau local et le réseau virtuel Azure (VNet) sont connectés par une connexion VPN ou ExpressRoute. Il existe plusieurs variantes de cette architecture :
- Créez un domaine dans Azure et associez-le à votre forêt AD locale.
- Créez une forêt distincte dans Azure qui est approuvée par des domaines de votre forêt locale.
- Répliquez un déploiement Active Directory Federation Services (AD FS) dans Azure.
Les sections suivantes décrivent chacune de ces options plus en détails.
Intégrer vos domaines locaux à Microsoft Entra ID
Utilisez Microsoft Entra ID pour créer un domaine dans Azure et le lier à un domaine AD local.
Le répertoire Microsoft Entra n’est pas une extension d’un répertoire local. Il s’agit en réalité d’une copie qui contient les mêmes objets et identités. Les modifications apportées à ces éléments locaux sont copiées vers Microsoft Entra ID, mais les modifications apportées dans Microsoft Entra ID ne sont pas répliquées sur le domaine local.
Vous pouvez également utiliser Microsoft Entra ID sans utiliser un répertoire local. Dans ce cas, Microsoft Entra ID agit comme la source principale de toutes les informations d’identité, au lieu de contenir des données répliquées d’un répertoire local.
Avantages
- Vous n’avez pas besoin de gérer une infrastructure AD dans le cloud. Microsoft Entra ID est entièrement géré et mis à jour par Microsoft.
- Microsoft Entra ID fournit les mêmes informations d’identité que celles disponibles localement.
- L’authentification peut s’effectuer dans Azure, ce qui évite aux utilisateurs et applications externes d’avoir à contacter le domaine local.
Défis
- Vous devez configurer la connectivité à votre domaine local pour assurer la synchronisation du répertoire Microsoft Entra.
- Les applications devront peut-être être réécrites pour activer l’authentification via Microsoft Entra ID.
- Si vous souhaitez authentifier les comptes de service et d’ordinateur, vous devez également déployer Microsoft Entra Domain Services.
Architecture de référence
Services AD DS dans Azure associés à une forêt locale
Déployer des serveurs AD Domain Services (AD DS) dans Azure. Créez un domaine dans Azure et associez-le à votre forêt AD locale.
Envisagez cette option si vous avez besoin d’utiliser des fonctionnalités AD DS qui ne sont pas actuellement disponibles dans Microsoft Entra ID.
Avantages
- Cette méthode fournit les mêmes informations d’identité que celles disponibles localement.
- Vous pouvez authentifier les comptes d’utilisateur, de service et d’ordinateur localement et dans Azure.
- Vous n’avez pas besoin de gérer une autre forêt Active Directory. Le domaine dans Azure peut appartenir à la forêt locale.
- Vous pouvez appliquer la stratégie de groupe définie par les objets de stratégie de groupe locale au domaine dans Azure.
Défis
- Vous devez déployer et gérer vos propres domaine et serveurs AD DS dans le cloud.
- Il peut y avoir une certaine latence au niveau de la synchronisation entre les serveurs de domaine dans le cloud et les serveurs exécutés localement.
Architecture de référence
Services AD DS dans Azure avec une forêt distincte
Déployez des serveurs AD Domain Services (AD DS) dans Azure, mais créez une forêt Active Directory séparée de la forêt locale. Cette forêt est approuvée par les domaines de votre forêt locale.
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.
Avantages
- Vous pouvez implémenter des identités locales, ainsi que des identités Azure distinctes.
- Vous n’avez pas besoin de répliquer les données de la forêt Active Directory locale vers Azure.
Défis
- Dans Azure, l’authentification des identités locales nécessite des tronçons réseaux supplémentaires vers les serveurs Active Directory locaux.
- Vous devez déployer vos propres forêt et serveurs AD DS dans le cloud et établir les relations d’approbation appropriées entre les forêts.
Architecture de référence
Étendre AD FS à Azure
Répliquez un déploiement Active Directory Federation Services (AD FS) dans Azure afin de permettre l’authentification et l’autorisation fédérées des composants en cours d’exécution dans Azure.
Utilisations courantes de cette architecture :
- Authentifier et autoriser les utilisateurs des organisations partenaires.
- Permettre aux utilisateurs de s’authentifier à partir de navigateurs web s’exécutant en dehors du pare-feu de l’organisation.
- Permettre aux utilisateurs de se connecter à partir d’appareils externes autorisés tels que des appareils mobiles.
Avantages
- Vous pouvez utiliser des applications prenant en charge les revendications.
- Vous pouvez approuver des partenaires externes pour l’authentification.
- Cette méthode est compatible avec un large éventail de protocoles d’authentification.
Défis
- Vous devez déployer vos propres serveurs proxy d’application web AD FS, AD DS et AD FS dans Azure.
- Cette architecture peut être difficile à configurer.
Architecture de référence