Tailwind Traders utilise Active Directory Domain Services (AD DS) comme fournisseur d’identité sur son réseau local depuis sa migration depuis Windows NT 4.0 au début des années 2000. De nombreuses applications existantes chez Tailwind Traders dépendent d’Active Directory. Certaines ont une dépendance simple en tant que fournisseur d’identité, tandis que d’autres ont des dépendances plus complexes, comme des exigences de stratégie de groupe, des partitions de domaine personnalisées et des extensions de schéma personnalisées.

Alors que Tailwind Traders commence à déplacer certaines ressources et à développer de nouvelles applications dans Azure, l’entreprise souhaite éviter de créer une solution d’identité parallèle. Elle ne veut pas que les utilisateurs aient à gérer des informations de connexion distinctes pour les ressources locales et celles dans le cloud.

Dans cette unité, vous allez découvrir les différentes façons de mettre en œuvre une identité hybride.

Déploiement de contrôleurs de domaine dans Azure

La manière la plus simple de fournir le même environnement AD DS dans Azure que celui utilisé sur site consiste à :

• Déployer une paire de contrôleurs de domaine AD DS sur un sous-réseau d’un réseau virtuel Azure.
• Connecter ce réseau virtuel au réseau local.
• Configurer ce sous-réseau comme un nouveau site AD DS, comme illustré dans l’image suivante.

Une autre option consiste à configurer le domaine AD DS hébergé dans le cloud comme un domaine enfant de la forêt du domaine sur site.

Une autre possibilité est de configurer les contrôleurs de domaine AD DS exécutés dans le cloud comme une forêt distincte, qui entretient une relation d’approbation (trust) avec la forêt sur site.

L’image suivante montre cette topologie de forêt de ressources.

Déploiement de contrôleurs de domaine dans Azure

Les organisations qui déploient des contrôleurs de domaine sur des machines virtuelles (VM) dans Azure peuvent ensuite déployer des charges de travail qui nécessitent une visibilité directe sur un contrôleur de domaine. Ce déploiement est possible tant que les charges de travail se trouvent sur le même sous-réseau du réseau virtuel Azure que les VM des contrôleurs de domaine.

Ce modèle de cloud hybride est conceptuellement simple pour de nombreuses organisations, car les centres de données Azure sont considérés comme un site Active Directory distant.

Pour Tailwind Traders, étendre son domaine ou sa forêt Active Directory sur site vers Azure peut être suffisant, selon les exigences des applications.
L’inconvénient de cette option est que les VM qui doivent fonctionner en continu, comme les contrôleurs de domaine, génèrent des coûts permanents.

Qu’est-ce que Microsoft Entra Connect ?

Microsoft Entra Connect (anciennement Azure AD Connect) permet aux organisations de synchroniser les identités présentes dans leur instance Active Directory sur site vers Microsoft Entra ID (anciennement Azure AD).

Cette méthode permet d’utiliser la même identité pour les ressources cloud et les ressources sur site. Microsoft Entra Connect est souvent utilisé lorsque les organisations adoptent Microsoft 365. Il permet à des applications comme Microsoft SharePoint et Exchange, exécutées dans le cloud, d’être accessibles via des applications sur site.

Si Tailwind Traders prévoit d’adopter des technologies Microsoft 365 comme Exchange Online ou Microsoft Teams, elle devra configurer Microsoft Entra Connect pour répliquer les identités de son environnement AD DS sur site vers Azure.

Si l’entreprise souhaite également utiliser les identités sur site avec des applications dans Azure, mais ne veut pas déployer de contrôleurs de domaine AD DS sur des VM, elle devra également déployer Microsoft Entra Connect.

Qu’est-ce que Microsoft Entra Domain Services ?

Vous pouvez utiliser Microsoft Entra Domain Services pour projeter un domaine Microsoft Entra sur un sous-réseau virtuel Azure. Avec cette configuration, des services comme :

• l’adhésion au domaine,
• les stratégies de groupe (Group Policy),
• le protocole LDAP,
• l’authentification Kerberos et NTLM

deviennent disponibles pour toute VM déployée sur ce sous-réseau.

Microsoft Entra Domain Services permet d’avoir un environnement Active Directory géré de base disponible pour les VM, sans avoir à gérer, maintenir ou payer pour les VM qui agissent comme contrôleurs de domaine.

Il permet également d’utiliser les identités sur site via Microsoft Entra Connect pour interagir avec les VM exécutées sur un sous-réseau Azure spécialement configuré.

Limites de Microsoft Entra Domain Services

Un inconvénient de Microsoft Entra Domain Services est que la mise en œuvre des stratégies de groupe est basique. Elle comprend un ensemble fixe de stratégies et n’offre pas la possibilité de créer des objets de stratégie de groupe (GPO).

Même si les identités utilisées sur site sont disponibles dans Azure, les stratégies configurées sur site ne sont pas disponibles.

Pour Tailwind Traders, Microsoft Entra Domain Services représente un bon compromis pour les charges de travail hybrides. Il permet l’utilisation d’identités jointes au domaine et une configuration substantielle des stratégies de groupe.

Cependant, il ne prend pas en charge les applications qui nécessitent des fonctionnalités Active Directory complexes, comme les partitions de domaine personnalisées et les extensions de schéma.