Cet article compare les options d’intégration de votre environnement Active Directory (AD) local à un réseau Azure. Pour chaque option, une architecture de référence plus détaillée est disponible.
De nombreuses organisations utilisent Active Directory Domain Services (AD DS) pour authentifier les identités associées aux utilisateurs, ordinateurs, applications ou autres ressources incluses dans une limite de sécurité. Les services d’annuaire et d’identité sont généralement hébergés localement, mais si votre application est hébergée en partie localement et en partie dans Azure, il peut y avoir une latence lors de l’envoi de demandes d’authentification d’Azure vers un site local. L’implémentation de services d’annuaire et d’identité dans Azure peut réduire cette latence.
Azure fournit deux solutions pour implémenter des services d’annuaire et d’identité dans Azure :
Utilisez 'ID Microsoft Entra 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 à l’ID Microsoft Entra.
Étendez votre infrastructure Active Directory locale existante à Azure en déployant une machine virtuelle dans Azure qui exécute AD DS en tant que contrôleur de domaine. Cette architecture est plus courante lorsque le réseau local et le réseau virtuel Azure sont connectés par une connexion VPN ou ExpressRoute. Plusieurs variantes de cette architecture sont possibles :
- Créez un domaine dans Azure et joignez-le à votre forêt AD locale.
- Créez une forêt distincte dans Azure approuvée par les domaines de votre forêt locale.
- Répliquez un déploiement des services de fédération Active Directory (AD FS) sur Azure.
Les sections suivantes décrivent chacune de ces options plus en détail.
Intégrer vos domaines locaux à l’ID Microsoft Entra
Utilisez l’ID Microsoft Entra 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 plutôt d’une copie qui contient les mêmes objets et identités. Les modifications apportées à ces éléments localement sont copiées vers l’ID Microsoft Entra, mais les modifications apportées dans l’ID Microsoft Entra ne sont pas répliquées dans le domaine local.
Vous pouvez également utiliser l’ID Microsoft Entra sans utiliser un répertoire local. Dans ce cas, Microsoft Entra ID agit comme la source principale de toutes les informations d’identité, plutôt que de contenir des données répliquées à partir 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 géré par Microsoft.
- Microsoft Entra ID fournit les mêmes informations d’identité que celles disponibles localement.
- L’authentification peut se produire dans Azure, ce qui réduit la nécessité pour les applications externes et les utilisateurs de contacter le domaine local.
Défis
- Vous devez configurer la connectivité avec votre domaine local pour que le répertoire Microsoft Entra soit synchronisé.
- Les applications peuvent avoir besoin d’être réécrites pour activer l’authentification via l’ID Microsoft Entra.
- Si vous souhaitez authentifier des comptes de service et d’ordinateur, vous devez également déployer Microsoft Entra Domain Services.
architecture de référence
AD DS dans Azure joint à une forêt locale
Déployez des serveurs AD Domain Services (AD DS) sur Azure. Créez un domaine dans Azure et joignez-le à votre forêt AD locale.
Envisagez cette option si vous devez utiliser des fonctionnalités AD DS qui ne sont pas actuellement implémentées par l’ID Microsoft Entra.
avantages
- Fournit l’accès aux mêmes informations d’identité disponibles localement.
- Vous pouvez authentifier des comptes d’utilisateur, de service et d’ordinateur localement et dans Azure.
- Vous n’avez pas besoin de gérer une forêt AD distincte. Le domaine dans Azure peut appartenir à la forêt locale.
- Vous pouvez appliquer une stratégie de groupe définie par des objets de stratégie de groupe locaux au domaine dans Azure.
Défis
- Vous devez déployer et gérer vos propres serveurs ET domaines AD DS dans le cloud.
- Il peut y avoir une latence de synchronisation entre les serveurs de domaine dans le cloud et les serveurs s’exécutant localement.
architecture de référence
AD DS dans Azure avec une forêt distincte
Déployez des serveurs AD Domain Services (AD DS) sur Azure, mais créez une forêt Active Directory distincte séparée de la forêt locale. Cette forêt est approuvée par les domaines de votre forêt locale.
Les utilisations classiques pour cette architecture incluent la gestion de la séparation de la sécurité pour les objets et les identités détenus dans le cloud, et la migration de domaines individuels d’un emplacement local vers le cloud.
avantages
- Vous pouvez implémenter des identités locales et séparer des identités Azure uniquement.
- Vous n’avez pas besoin de répliquer à partir de la forêt AD locale vers Azure.
Défis
- L’authentification dans Azure pour les identités locales nécessite des tronçons réseau supplémentaires vers les serveurs AD locaux.
- Vous devez déployer vos propres serveurs ET forêts 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 des services de fédération Active Directory (AD FS) sur Azure pour effectuer l’authentification et l’autorisation fédérées pour les composants s’exécutant dans Azure.
Utilisations classiques pour cette architecture :
- Authentifiez et autorisez les utilisateurs des organisations partenaires.
- Autoriser les utilisateurs à s’authentifier à partir de navigateurs web s’exécutant en dehors du pare-feu de l’organisation.
- Autoriser les utilisateurs à se connecter à partir d’appareils externes autorisés tels que les appareils mobiles.
avantages
- Vous pouvez tirer parti des applications prenant en charge les revendications.
- Permet de faire confiance aux partenaires externes pour l’authentification.
- Compatibilité avec un grand ensemble de protocoles d’authentification.
Défis
- Vous devez déployer vos propres serveurs proxy d’application web AD DS, AD FS et AD FS dans Azure.
- Cette architecture peut être complexe à configurer.
architecture de référence