Considérations relatives à la conception du réseau virtuel et options de configuration pour Microsoft Entra Domain Services
Microsoft Entra Domain Services fournit des services d’authentification et de gestion à d’autres applications et charges de travail. La connectivité réseau est une composante clé. Sans ressources de réseau virtuel correctement configurées, les applications et les charges de travail ne peuvent pas communiquer avec les fonctionnalités fournies par Domain Services. ni les utiliser. Planifiez les exigences de votre réseau virtuel pour vous assurer que Domain Services puisse servir vos applications et vos charges si nécessaire.
Cet article décrit les exigences et les conditions à prendre en compte lors de la conception pour qu’un réseau virtuel Azure prenne en charge Domain Services.
Conception du réseau virtuel Azure
Pour assurer la connectivité réseau et autoriser les applications et les services à s’authentifier auprès d’un domaine managé par Domain Services, vous devez utiliser un réseau virtuel et un sous-réseau Azure. Dans l’idéal, le domaine managé doit être déployé dans son propre réseau virtuel.
Vous pouvez inclure un sous-réseau d’application distinct dans le même réseau virtuel pour héberger votre machine virtuelle de gestion ou vos charges de travail pour les petites applications. Un réseau virtuel distinct pour les charges de travail d’application plus volumineuses ou complexes homologuées au réseau virtuel Domain Services, est généralement la conception la plus appropriée.
Si vous respectez les conditions décrites dans les sections suivantes pour le réseau virtuel et le sous-réseau, vous pouvez choisir d’autres conceptions.
Tout au long de votre conception du réseau virtuel pour Domain Services, les considérations suivantes s’appliquent :
- Domain Services doit être déployé dans la même région Azure que votre réseau virtuel.
- À ce stade, vous ne pouvez déployer qu’un seul domaine managé par tenant Microsoft Entra. Le domaine managé est déployé sur une seule région. Assurez-vous de créer ou de sélectionner un réseau virtuel dans une région qui prend en charge Domain Services.
- Tenez compte de la proximité des autres régions Azure et des réseaux virtuels qui hébergent les charges de travail de votre application.
- Pour réduire la latence, gardez vos applications principales à proximité du sous-réseau du réseau virtuel, à dans la même région que celui-ci, pour votre domaine managé. Vous pouvez utiliser le peering du réseau virtuel ou les connexions de réseau privé virtuel (VPN) entre les réseaux virtuels Azure. Ces options de connexion sont présentées dans une prochaine section.
- Le réseau virtuel ne peut pas s’appuyer sur des services DNS autres que ceux fournis par le domaine managé.
- Domain Services fournit son propre service DNS. Le réseau virtuel doit être configuré pour utiliser ces adresses de service DNS. La résolution de noms pour des espaces de noms supplémentaires peut être accomplie à l’aide de redirecteurs conditionnels.
- Vous ne pouvez pas utiliser les paramètres de serveur DNS personnalisés pour diriger des requêtes en provenance d’autres serveurs DNS, y compris sur des machines virtuelles. Les ressources du réseau virtuel doivent utiliser le service DNS fourni par le domaine managé.
Important
Vous ne pouvez pas déplacer Domain Services vers un autre réseau virtuel une fois le service activé.
Un domaine managé se connecte à un sous-réseau dans un réseau virtuel Azure. Concevez ce sous-réseau pour Domain Services en prenant en compte les considérations suivantes :
Un domaine managé doit être déployé dans son propre sous-réseau. L’utilisation d’un sous-réseau, d’un sous-réseau de passerelle ou de passerelles distantes dans l’appairage de réseaux virtuels n’est pas prise en charge.
Un groupe de sécurité réseau est créé pendant le déploiement d’un domaine managé. Ce groupe de sécurité réseau contient les règles requises pour permettre une communication de service appropriée.
- Ne créez et n’utilisez pas un groupe de sécurité réseau existant avec vos propres règles personnalisées.
Un domaine managé requiert de 3 à 5 adresses IP. Assurez-vous que la plage d’adresses IP de votre sous-réseau peut fournir ce nombre d’adresses.
- La restriction des adresses IP disponibles peut empêcher Ale domaine managé de gérer deux contrôleurs de domaine.
Remarque
Vous ne devez pas utiliser d'adresses IP publiques pour les réseaux virtuels et leurs sous-réseaux en raison des problèmes suivants :
Rareté de l'adresse IP : Les adresses IP publiques IPv4 sont limitées, et leur demande dépasse souvent l'offre disponible. En outre, il existe un chevauchement potentiel d'adresses IP avec des points de terminaison publics.
Risques de sécurité : L'utilisation d'adresses IP publiques pour les réseaux virtuels expose vos appareils directement à Internet, ce qui augmente le risque d'accès non autorisé et d'attaques potentielles. Sans mesures de sécurité appropriées, vos appareils peuvent devenir vulnérables à diverses menaces.
Complexité : La gestion d'un réseau virtuel avec des adresses IP publiques peut être plus complexe que l'utilisation d'adresses IP privées, car cela nécessite de gérer des plages d'adresses IP externes et d'assurer une segmentation et une sécurité appropriées du réseau.
Il est fortement recommandé d'utiliser des adresses IP privées. Si vous utilisez une adresse IP publique, assurez-vous que vous êtes le propriétaire/utilisateur dédié des adresses IP choisies dans la plage publique que vous avez choisie.
L’exemple de diagramme suivant présente une conception valide dans laquelle le domaine managé possède son propre sous-réseau. Le sous-réseau de passerelle pour la connectivité externe et les charges de travail d’application sont dans un sous-réseau connecté du réseau virtuel :
Connexions au réseau virtuel de Domain Services
Comme indiqué dans la section précédente, vous pouvez uniquement créer un domaine managé dans un réseau virtuel unique dans Azure et un seul domaine managé par tenant Microsoft Entra. Si l’on se base sur cette architecture, vous devrez peut-être connecter un ou plusieurs réseaux virtuels qui hébergent les charges de travail de votre application sur votre réseau virtuel de domaine managé.
Vous pouvez connecter des charges de travail d’application hébergées sur d’autres réseaux virtuels Azure en utilisant l’une des méthodes suivantes :
- Peering de réseau virtuel
- Réseau privé virtuel (VPN)
Peering de réseau virtuel
L’appairage de réseaux virtuels est un mécanisme qui connecte deux réseaux virtuels via le réseau principal Azure, ce qui permet à des ressources telles que les machines virtuelles de communiquer les unes avec les autres directement à l’aide d’adresses IP privées. L’appairage de réseaux virtuels prend en charge l’appairage régional, qui connecte des réseaux virtuels au sein de la même région Azure, et l’appairage de réseaux virtuels mondial, qui connecte des réseaux virtuels entre différentes régions Azure. Cette flexibilité vous permet de déployer un domaine managé avec vos charges de travail d’application sur plusieurs réseaux virtuels, quel que soit leur emplacement régional.
Pour plus d’informations, consultez la page Vue d’ensemble du peering du réseau virtuel Azure.
Réseau privé virtuel (VPN)
Vous pouvez connecter deux réseaux virtuels (connexion de réseau virtuel à réseau virtuel) de la même manière que vous pouvez configurer un réseau virtuel à un emplacement de site local. Ces deux connexions font appel à une passerelle VPN pour créer un tunnel sécurisé utilisant Ipsec/IKE. Ce modèle de connexion vous permet de déployer le domaine managé dans un réseau virtuel Azure, puis de connecter des emplacements locaux ou d’autres clouds.
Pour plus d’informations sur l’utilisation de réseaux privés virtuels, consultez la page Configurer une connexion de passerelle VPN de réseau virtuel à réseau virtuel à l’aide du centre d’administration Microsoft Entra.
Résolution de noms lors de la connexion de réseaux virtuels
Les réseaux virtuels connectés au réseau virtuel du domaine managé disposent généralement de leurs propres paramètres DNS. Lorsque vous connectez des réseaux virtuels, cela ne permet pas de configurer automatiquement la résolution de noms du réseau virtuel en cours de connectés afin de résoudre les services fournis par le domaine managé. La résolution de noms de réseaux virtuels en cours de connexion doit être configurée pour permettre aux charges de travail d’application de localiser le domaine managé.
Vous pouvez activer la résolution de noms à l’aide de redirecteurs DNS conditionnels sur le serveur DNS qui prend en charge les réseaux virtuels connectés, ou en utilisant les adresses IP DNS du réseau virtuel du domaine managé.
Ressources réseau utilisées par Domain Services
Un domaine managé crée des ressources réseau au cours du déploiement. Ces ressources sont nécessaires au bon fonctionnement et à la bonne gestion du domaine managé et ne doivent pas être configurées manuellement.
Ne verrouillez pas les ressources de mise en réseau utilisées par Domain Services. Si les ressources de mise en réseau sont verrouillées, elles ne peuvent pas être supprimées. Lorsque les contrôleurs de domaine doivent être reconstruits dans ce cas, de nouvelles ressources de mise en réseau avec des adresses IP différentes doivent être créées.
| Ressource Azure | Description |
|---|---|
| Cartes d'interface réseau | Domain Services héberge le domaine managé sur deux contrôleurs de domaine (DC) qui s’exécutent sur Windows Server en tant que machines virtuelles Azure. Chaque machine virtuelle dispose d’une interface réseau virtuelle qui se connecte à votre sous-réseau de réseau virtuel. |
| Adresse IP publique standard dynamique | Domain Services communique avec le service de synchronisation et de gestion à l’aide d’une adresse IP publique de référence SKU Standard. Pour plus d’informations sur les adresse IP publique, consultez la page Types d’adresses IP et méthodes d’allocation dans Azure. |
| Azure Standard Load Balancer | Domain Services utilise un équilibreur de charge de référence SKU Standard pour la traduction d’adresses réseau (NAT) et l’équilibrage de charge (en cas d’utilisation avec le protocole LDAP sécurisé). Pour plus d’informations sur les équilibreurs de charge Azure, consultez Qu’est-ce que Azure Load Balancer ? |
| Règles de traduction d’adresses réseau (NAT) | Domain Services crée et utilise deux règles NAT de trafic entrant sur l’équilibreur de charge pour une communication à distance PowerShell sécurisée. Si un équilibreur de charge de référence SKU standard est utilisé, il aura également une règle NAT sortante. Pour l’équilibreur de charge de référence SKU de base, aucune règle NAT sortante n’est requise. |
| Règles d'équilibrage de charge | Quand un domaine managé est configuré pour le LDAP sécurisé sur le port TCP 636, trois règles sont créées et utilisées sur un équilibreur de charge pour répartir le trafic. |
Avertissement
Ne supprimez et ne modifiez aucune des ressources réseau créées par Domain Services, telles que la configuration manuelle de l’équilibreur de charge ou des règles. Si vous supprimez ou modifiez l’une des ressources réseau, le service Domain Services peut être interrompu.
Groupes de sécurité réseau et ports requis
Un groupe de sécurité réseau (NSG) contient une liste des règles qui autorisent ou refusent le trafic réseau vers un réseau virtuel Azure. Lorsque vous déployez un domaine managé, un groupe de sécurité réseau est créé avec un ensemble de règles permettant au service de fournir des fonctions d’authentification et de gestion. Ce groupe de sécurité réseau par défaut est associé au sous-réseau de réseau virtuel dans lequel votre domaine managé est déployé.
Les sections suivantes traitent des groupes de sécurité réseau et des exigences relatives aux ports entrants et sortants.
Connectivité entrante
Les règles entrantes de groupe de sécurité réseau suivantes sont requises pour permettre au domaine managé de fournir des services d’authentification et de gestion. Ne modifiez pas et ne supprimez pas ces règles de groupe de sécurité réseau pour le sous-réseau de réseau virtuel pour votre domaine managé.
| Source | Balise du service source | Source port ranges | Destination | Service | Plages de ports de destination | Protocol | Action | Obligatoire | Objectif |
|---|---|---|---|---|---|---|---|---|---|
| Balise du service | AzureActiveDirectoryDomainServices | * | Quelconque | WinRM | 5986 | TCP | Allow | Oui | Gestion de votre domaine. |
| Balise du service | CorpNetSaw | * | Quelconque | RDP | 3389 | TCP | Allow | Facultatif | Débogage pour la prise en charge |
Notez que l’étiquette de service CorpNetSaw n’est pas disponible à l’aide du centre d’administration Microsoft Entra, et que la règle de groupe de sécurité réseau pour CorpNetSaw doit être ajoutée à l’aide de PowerShell.
Domain Services s’appuie également sur les règles de sécurité par défaut AllowVnetInBound et AllowAzureLoadBalancerInBound.
La règle AllowVnetInBound autorise tout le trafic au sein du réseau virtuel qui permet aux contrôleurs de domaine de communiquer et de répliquer correctement, ainsi que d’autoriser la jonction de domaine et d’autres services de domaine aux membres du domaine. Pour plus d'informations sur les ports requis pour Windows, consultez la Vue d'ensemble des services et exigences de ports réseau pour Windows.
La règle AllowAzureLoadBalancerInBound est également requise afin que le service puisse communiquer correctement sur l’équilibreur de charge pour gérer les contrôleurs de domaine. Ce groupe de sécurité réseau, qui sécurise Domain Services, est nécessaire pour que le domaine managé fonctionne correctement. Ne supprimez pas ce groupe de sécurité réseau. L’équilibreur de charge ne fonctionnera pas correctement sans ce groupe.
Si nécessaire, vous pouvez créer le groupe de sécurité réseau et les règles requis à l’aide d’Azure PowerShell.
Avertissement
Lorsque vous associez un groupe de sécurité réseau mal configuré ou une table d’itinéraire définie par l’utilisateur au sous-réseau dans lequel le domaine managé est déployé, vous risquez de perturber la capacité de Microsoft à traiter et à gérer le domaine. La synchronisation entre votre tenant Microsoft Entra et votre domaine managé est également interrompue. Suivez toutes les exigences répertoriées pour éviter une configuration non prise en charge qui risque de perturber la synchronisation, les mises à jour correctives ou la gestion.
Si vous utilisez le protocole LDAP sécurisé, vous pouvez ajouter la règle de port TCP 636 requise pour autoriser le trafic externe, si nécessaire. L’ajout de cette règle ne place pas vos règles de groupe de sécurité réseau dans un état non pris en charge. Pour plus d’informations, consultez Verrouiller l’accès LDAP sécurisé via Internet.
Le SLA Azure ne s’applique pas aux déploiements qui sont bloqués pour les mises à jour ou la gestion par un groupe de sécurité réseau mal configuré ou par une table de routage définie par l’utilisateur. Une configuration réseau rompue peut également empêcher l’application des correctifs de sécurité.
Connectivité sortante
Pour une connectivité entrante, vous pouvez conserver AllowVnetOutbound et AllowInternetOutBound ou restreindre le trafic sortant en utilisant les ServiceTags répertoriés dans le tableau suivant. Si vous utilisez l’analytique des journaux d’activité, ajoutez EventHub aux destinations sortantes.
Assurez-vous qu’aucun autre groupe de sécurité réseau ayant une priorité plus élevée ne refuse la connectivité sortante. Si la connectivité sortante est refusée, la réplication ne fonctionnera pas entre réplica ensembles.
| Numéro de port sortant | Protocol | Source | Destination | Action | Obligatoire | Objectif |
|---|---|---|---|---|---|---|
| 443 | TCP | Quelconque | AzureActiveDirectoryDomainServices | Allow | Oui | Communication avec le service de gestion Microsoft Entra Domain Services. |
| 443 | TCP | Quelconque | AzureMonitor | Allow | Oui | Analyse des machines virtuelles. |
| 443 | TCP | Quelconque | Stockage | Allow | Oui | Communication avec le stockage Azure. |
| 443 | TCP | Tout | Microsoft Entra ID | Autoriser | Oui | Communication avec Microsoft Entra ID. |
| 443 | TCP | Quelconque | GuestAndHybridManagement | Allow | Oui | Gestion automatisée des correctifs de sécurité. |
Remarque
Les étiquettes AzureUpdateDelivery et AzureFrontDoor.FirstParty sont déconseillées depuis le 1er juillet 2024. Microsoft Entra Domain Services gère WindowsUpdate indépendamment, ce qui élimine la nécessité de recourir à ces étiquettes. Les ajustements de NSG ne sont pas nécessaires, avec ou sans étiquettes déconseillées.
Port 5986 – gestion à l’aide de la communication à distance PowerShell
- Utilisé pour effectuer des tâches de gestion à l’aide de la communication à distance PowerShell sur votre domaine managé.
- Sans accès à ce port, votre domaine managé ne peut pas être mis à jour, configuré, sauvegardé ou surveillé.
- Vous pouvez limiter l'accès entrant à ce port avec l’étiquette de service AzureActiveDirectoryDomainServices.
Port 3389 – gestion à l’aide du bureau à distance
- Utilisé pour les connexions Bureau à distance aux contrôleurs de domaine de votre domaine managé, ce port ne peut pas être modifié ou encapsulé dans un autre port.
- La règle de groupe de sécurité réseau par défaut utilise la étiquette de service CorpNetSaw pour restreindre davantage le trafic.
- Cette balise de service autorise uniquement les stations de travail à accès sécurisé sur le réseau d’entreprise Microsoft à utiliser le bureau à distance pour le domaine managé.
- L’accès est autorisé uniquement avec la justification métier, par exemple pour les scénarios de gestion ou de résolution des problèmes.
- Cette règle peut être définie sur Refuser et définie uniquement sur Autoriser quand cela est nécessaire. La plupart des tâches de gestion et de surveillance sont effectuées à l’aide de la communication à distance PowerShell. Le RDP n'est utilisé que dans les rares cas où Microsoft a besoin de se connecter à distance à votre domaine managé pour une résolution des problèmes avancée.
Vous ne pouvez pas sélectionner manuellement la balise de service CorpNetSaw dans le portail si vous essayez de modifier cette règle de groupe de sécurité réseau. Vous devez utiliser Azure PowerShell ou Azure CLI pour configurer manuellement une règle qui utilise la balise de service CorpNetSaw.
Par exemple, vous pouvez utiliser le script suivant pour créer une règle autorisant le protocole RDP :
Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange "3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup
Itinéraires définis par l’utilisateur
Les itinéraires définis par l’utilisateur ne sont pas créés par défaut et ne sont pas nécessaires au bon fonctionnement de Domain Services. Si vous devez utiliser des tables d’itinéraire, évitez de modifier l’itinéraire 0.0.0.0. Les modifications apportées à cet itinéraire perturbent Domain Services et place le domaine managé dans un état non pris en charge.
Vous devez également acheminer le trafic entrant à partir des adresses IP incluses dans les balises de service Azure respectives vers le sous-réseau du domaine managé. Pour plus d’informations sur les balises de service et leur adresse IP associée , consultez la page Plages et balises de service Azure IP – Cloud public.
Attention
Ces plages IP de centre de données Azure peuvent être modifiées sans préavis. Vérifiez que vous disposez des processus vous permettant de valider que vous disposez des dernières adresses IP.
Étapes suivantes
Pour plus d’informations sur certaines ressources réseau et options de connexion utilisées par Domain Services, consultez les articles suivants :