Étape 2 : Planifier l’infrastructure multisite

2023-04-11
S’applique à: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Windows 11, ✅ Windows 10

L’étape suivante du déploiement de l’accès à distance dans une topologie multisite consiste à terminer la planification de l’infrastructure multisite ; y compris Active Directory, les groupes de sécurité et les objets de stratégie de groupe.

2.1 Planifier Active Directory

Un déploiement multisite d’accès à distance peut être configuré dans un certain nombre de topologies :

Site Active Directory unique, points d’entrée multiples. Dans cette topologie, vous disposez d’un site Active Directory unique pour l’ensemble de votre organisation avec des liens intranet rapides dans tout le site, mais plusieurs serveurs d’accès à distance sont déployés au sein de votre organisation, chacun agissant comme point d’entrée. Un exemple géographique de cette topologie est la présence d’un seul site Active Directory pour les États-Unis avec des points d’entrée sur la côte Est et la côte Ouest.
Plusieurs sites Active Directory, plusieurs points d’entrée. Dans cette topologie, vous avez deux sites Active Directory ou plus avec un serveur d’accès à distance déployé comme point d’entrée pour chaque site. Chaque serveur d’accès à distance est associé au contrôleur de domaine Active Directory pour le site. Un exemple géographique de cette topologie est la présence d’un site Active Directory pour les États-Unis et d’un site pour l’Europe avec un point d’entrée unique pour chaque site. Notez que si vous avez plusieurs sites Active Directory, vous n’avez pas besoin d’avoir un point d’entrée associé à chaque site. En outre, plusieurs sites Active Directory peuvent être associés à plusieurs points d’entrée.

Dans un point d’entrée multisite, vous pouvez configurer un seul serveur d’accès à distance, plusieurs serveurs d’accès à distance ou un cluster de serveurs d’accès à distance.

Meilleures pratiques et recommandations relatives à Active Directory

Notez les recommandations et contraintes suivantes pour le déploiement d’Active Directory dans un scénario multisite :

Chaque site Active Directory peut contenir un ou plusieurs serveurs d’accès à distance, ou un cluster de serveurs, fonctionnant comme des points d’entrée multisite pour les ordinateurs clients. Toutefois, un site Active Directory n’est pas obligé d’avoir un point d’entrée.
Un point d’entrée multisite ne peut être associé qu’à un seul site Active Directory. Lorsque les ordinateurs clients exécutant Windows 8 se connectent à un point d’entrée spécifique, ils sont considérés comme appartenant au site Active Directory associé à ce point d’entrée.
Il est recommandé que chaque site Active Directory dispose d’un contrôleur de domaine. Le contrôleur de domaine peut être en lecture seule.
Si chaque site Active Directory contient un contrôleur de domaine, l’objet de stratégie de groupe d’un serveur dans le point d’entrée est géré par l’un des contrôleurs de domaine du site Active Directory associé au point de terminaison. S’il n’existe aucun contrôleur de domaine avec option d’écriture dans ce site, l’objet de stratégie de groupe d’un serveur est géré sur le contrôleur de domaine avec option d’écriture qui se trouve le plus proche du premier serveur d’accès à distance configuré dans le point d’entrée. Le contrôleur le plus proche est déterminé par un calcul de coût de liaison. Notez que dans ce scénario, après avoir apporté des modifications de configuration, il peut y avoir un retard lors de la réplication entre le contrôleur de domaine qui gère l’objet de stratégie de groupe et le contrôleur de domaine en lecture seule dans le site Active Directory du serveur.
Les objets de stratégie de groupe client et les objets de stratégie de groupe de serveur d’applications facultatifs sont gérés sur le contrôleur de domaine s’exécutant en tant qu’émulateur PDC (contrôleur de domaine principal). Cela signifie que les objets de stratégie de groupe clients ne sont pas nécessairement gérés dans le site Active Directory contenant le point d’entrée auquel les clients se connectent.
Si le contrôleur de domaine d’un site Active Directory n’est pas accessible, le serveur d’accès à distance se connecte à un autre contrôleur de domaine dans le site (si disponible). Si ce n’est pas le cas, il se connecte au contrôleur de domaine pour un autre site afin de récupérer un objet de stratégie de groupe mis à jour et d’authentifier les clients. Dans les deux cas, la console de gestion de l’accès à distance et les cmdlets PowerShell ne peuvent pas être utilisées pour récupérer ou modifier les paramètres de configuration tant que le contrôleur de domaine n’est pas disponible. Notez les points suivants :
1. Si le serveur qui s’exécute en tant qu’émulateur PDC n’est pas disponible, vous devez désigner un contrôleur de domaine disponible qui a mis à jour des objets de stratégie de groupe en tant qu’émulateur PDC.
2. Si le contrôleur de domaine qui gère un objet de stratégie de groupe de serveur n’est pas disponible, utilisez la cmdlet PowerShell Set-DAEntryPointDC pour associer un nouveau contrôleur de domaine au point d’entrée. Le nouveau contrôleur de domaine doit avoir des objets de stratégie de groupe à jour avant d’exécuter la cmdlet.

2.2 Planifier les groupes de sécurité

Lors du déploiement d’un serveur unique avec des paramètres avancés, tous les ordinateurs clients accédant au réseau interne via DirectAccess ont été regroupés dans un groupe de sécurité. Dans un déploiement multisite, ce groupe de sécurité est utilisé uniquement pour les ordinateurs clients Windows 8. Pour un déploiement multisite, les ordinateurs clients Windows 7 sont regroupés en groupes de sécurité distincts pour chaque point d’entrée dans le déploiement multisite. Par exemple, si vous avez précédemment regroupé tous les ordinateurs clients du groupe DA_Clients, vous devez maintenant supprimer tous les ordinateurs Windows 7 de ce groupe et les placer dans un autre groupe de sécurité. Par exemple, dans la topologie avec plusieurs sites Active Directory et plusieurs points d’entrée, vous créez un groupe de sécurité pour le point d’entrée États-Unis (DA_Clients_US) et un groupe pour le point d’entrée Europe (DA_Clients_Europe). Placez les ordinateurs clients Windows 7 situés aux États-Unis dans le groupe DA_Clients_US et tous les ordinateurs situés en Europe dans le groupe DA_Clients_Europe. Si vous n’avez pas d’ordinateurs clients Windows 7, vous n’avez pas besoin de planifier des groupes de sécurité pour les ordinateurs Windows 7.

Les groupes de sécurité requis sont les suivants :

Un groupe de sécurité pour tous les ordinateurs clients Windows 8. Il est recommandé de créer un groupe de sécurité unique pour ces clients pour chaque domaine.
Groupe de sécurité unique contenant des ordinateurs clients Windows 7 pour chaque point d’entrée. Il est recommandé de créer un groupe unique pour chaque domaine. Par exemple : Domain1\DA_Clients_Europe ; Domain2\DA_Clients_Europe ; Domain1\DA_Clients_US ; Domain2\DA_Clients_US.

2.3 Planifier les objets de stratégie de groupe

Les paramètres DirectAccess configurés quand lors du déploiement de l’accès à distance sont rassemblés dans des GPO. Votre déploiement de serveur unique utilise déjà des objets de stratégie de groupe pour les clients DirectAccess, le serveur d’accès à distance et éventuellement pour les serveurs d’applications. Un déploiement multisite nécessite les objets de stratégie de groupe suivants :

Objet de stratégie de groupe de serveur pour chaque point d’entrée.
Objet de stratégie de groupe pour chaque domaine contenant des ordinateurs clients exécutant Windows 8.
Objet de stratégie de groupe pour chaque point d’entrée et chaque domaine contenant des ordinateurs clients Windows 7.

Les objets de stratégie de groupe peuvent être configurés comme suit :

Automatiquement : vous pouvez spécifier que les objets de stratégie de groupe sont créés automatiquement par l’accès à distance. Un nom par défaut est spécifié pour chaque objet de stratégie de groupe et peut être modifié.
Manuellement : Vous pouvez utiliser des GPO créés manuellement par l’administrateur Active Directory.

Notes

Une fois que DirectAccess a été configuré pour utiliser des objets de stratégie de groupe spécifiques, il ne peut plus être configuré pour en utiliser d’autres.

2.3.1 Objets de stratégie de groupe créés automatiquement

Notez les points suivants quand vous utilisez des objets de stratégie de groupe créés automatiquement :

Les objets de stratégie de groupe créés automatiquement sont appliqués en fonction du paramètre d'emplacement et du paramètre de cible du lien, de la façon suivante :
- Pour l’objet de stratégie de groupe Serveur, les paramètres de l’emplacement et du lien pointent tous les deux vers le domaine qui contient le serveur d’accès à distance.
- Pour les objets de stratégie de groupe clients, la cible du lien est définie à la racine du domaine dans lequel l’objet de stratégie de groupe a été créé. Un objet de stratégie de groupe est créé pour chaque domaine qui contient des ordinateurs clients, et il est lié à la racine de chaque domaine. .
Pour les objets de stratégie de groupe créés automatiquement, pour appliquer les paramètres DirectAccess, l’administrateur du serveur d’accès à distance requiert les autorisations suivantes :
- Les objets de stratégie de groupe créent des autorisations pour les domaines requis.
- Autorisations de lien pour toutes les racines de domaine client sélectionnées.
- L’autorisation de créer le filtre WMI pour les objets de stratégie de groupe est requise si DirectAccess a été configuré pour fonctionner uniquement sur des ordinateurs mobiles.
- Autorisations de liaison pour les racines des domaines associés aux points d’entrée (domaines des objets de stratégie de groupe de serveur)
- Nous recommandons à l'administrateur de l'accès à distance de posséder des autorisations de lecture des objets de stratégie de groupe pour chaque domaine requis. Ainsi, l’accès à distance peut vérifier qu’il n’existe pas de doublons de noms d’objets de stratégie de groupe lors de la création de ces derniers pour le déploiement multisite.
- Autorisations de réplication Active Directory sur les domaines associés aux points d’entrée. En effet, lors de l’ajout initial de points d’entrée, l’objet de stratégie de groupe du serveur pour le point d’entrée est créé sur le contrôleur de domaine le plus proche de ce point d’entrée. Toutefois, étant donné que la création de lien est prise en charge uniquement sur l’émulateur PDC, l’objet de stratégie de groupe doit être répliqué à partir du contrôleur de domaine sur lequel il a été créé vers le contrôleur de domaine s’exécutant en tant qu’émulateur PDC avant de créer le lien.

Notez que si les autorisations adéquates pour la réplication et la liaison des objets de stratégie de groupe n’existent pas, un avertissement est émis. L’accès à distance continue de fonctionner mais aucune réplication ou liaison ne se produit. Si un avertissement de lien est émis, les liens ne sont pas créés automatiquement, même après la mise en place des autorisations. L'administrateur doit alors créer les liens manuellement.

2.3.2 Objets de stratégie de groupe créés manuellement

Notez les points suivants quand vous utilisez des objets de stratégie de groupe créés manuellement :

Les objets de stratégie de groupe suivants doivent être créés manuellement pour le déploiement multisite :
- Objet de stratégie de groupe de serveur- Objet de stratégie de groupe de serveur pour chaque point d’entrée (dans le domaine dans lequel se trouve le point d’entrée). Cet objet de stratégie de groupe sera appliqué sur chaque serveur d’accès à distance dans le point d’entrée.
- Objet de stratégie de groupe client (Windows 7)- Objet de stratégie de groupe pour chaque point d’entrée et chaque domaine contenant des ordinateurs clients Windows 7 qui se connecteront aux points d’entrée dans le déploiement multisite. Par exemple, Domain1\DA_W7_Clients_GPO_Europe ; Domain2\DA_W7_Clients_GPO_Europe ; Domain1\DA_W7_Clients_GPO_US ; Domain2\DA_W7_Clients_GPO_US. Si aucun ordinateur client Windows 7 ne se connecte à des points d’entrée, les objets de stratégie de groupe ne sont pas obligatoires.
Il n’est pas nécessaire de créer des objets de stratégie de groupe supplémentaires pour les ordinateurs clients Windows 8. Un objet de stratégie de groupe pour chaque domaine contenant des ordinateurs clients a déjà été créé lorsque le serveur d’accès à distance unique a été déployé. Dans un déploiement multisite, ces objets de stratégie de groupe client fonctionnent comme les objets de stratégie de groupe pour les clients Windows 8.
Les objets de stratégie de groupe doivent exister avant de cliquer sur le bouton Valider dans les Assistants de déploiement multisite.
De plus, une recherche de lien vers l'objet de stratégie de groupe est effectuée dans tout le domaine. Si l'objet de stratégie de groupe n'est pas lié dans le domaine, alors un lien est automatiquement créé à la racine du domaine. Si les autorisations requises pour créer le lien ne sont pas disponibles, un avertissement est émis.
Quand vous utilisez des objets de stratégie de groupe créés manuellement, pour appliquer les paramètres DirectAccess, l’administrateur de serveur d’accès à distance requiert des autorisations complètes (modification, suppression, modification de la sécurité) sur les objets de stratégie de groupe créés manuellement.

2.3.3 Gérer les objets de stratégie de groupe dans un environnement à plusieurs contrôleurs de domaine

Chaque objet de stratégie de groupe est administré par un contrôleur de domaine spécifique, comme suit :

L’objet de stratégie de groupe de serveur est géré par l’un des contrôleurs de domaine dans le site Active Directory associé au serveur, ou si les contrôleurs de domaine de ce site sont en lecture seule, par le contrôleur de domaine activé en écriture le plus proche du premier serveur dans le point d’entrée.
Les objets de stratégie de groupe client sont gérés par le contrôleur de domaine exécuté en tant qu’émulateur PDC.

Pour modifier manuellement les paramètres des objets de stratégie de groupe, notez les points suivants :

Pour les objets de stratégie de groupe de serveur, pour identifier le contrôleur de domaine associé à un point d’entrée spécifique, exécutez la cmdlet PowerShell Get-DAEntryPointDC -EntryPointName <name of entry point>.
Par défaut, quand vous apportez des modifications à l’aide d’applets de commande PowerShell de gestion de réseau ou à partir de la console de gestion des stratégies de groupe, le contrôleur de domaine qui agit en tant qu’émulateur de contrôleur de domaine principal est utilisé.
Si vous modifiez les paramètres sur un contrôleur de domaine qui n’est pas le contrôleur de domaine associé au point d’entrée (pour les GPO de serveurs) ou à l’émulateur de contrôleur de domaine principal (pour les GPO de clients), notez ce qui suit :
1. Avant de modifier les paramètres, assurez-vous que le contrôleur de domaine est répliqué avec un objet de stratégie de groupe à jour et sauvegardez vos paramètres GPO avant d’y apporter des modifications. Si l’objet de stratégie de groupe n’est pas mis à jour, des conflits de fusion peuvent survenir durant la réplication, ce qui entraîne une configuration incorrecte de l’accès à distance.
2. Une fois que vous avez modifié les paramètres, vous devez attendre la réplication des modifications sur les contrôleurs de domaine associés aux objets de stratégie de groupe. N’apportez pas de modifications supplémentaires via la console de gestion de l’accès à distance ou à l’aide d’applets de commande PowerShell pour l’accès à distance tant que la réplication n’est pas terminée. Si un objet de stratégie de groupe est modifié sur deux contrôleurs de domaine différents avant la fin de la réplication, des conflits de fusion peuvent survenir et entraîner une configuration incorrecte
Vous pouvez également modifier le paramètre par défaut en utilisant la boîte de dialogue Modifier le contrôleur de domaine de la console de gestion des stratégies de groupe ou en utilisant l’applet de commande Windows PowerShell Open-NetGPO, afin que les modifications apportées avec la console ou les cmdlets de mise en réseau utilisent le contrôleur de domaine que vous spécifiez.
1. Pour effectuer cette opération dans la console de gestion des stratégies de groupe, cliquez avec le bouton droit sur le domaine ou le conteneur Sites, et cliquez sur Modifier le contrôleur de domaine.
2. Pour effectuer cette opération dans PowerShell, spécifiez le paramètre DomainController pour l’applet de commande Open-NetGPO. Par exemple, pour activer les profils privé et public dans le Pare-feu Windows sur un objet de stratégie de groupe nommé domain1\DA_Server_GPO _Europe en utilisant un contrôleur de domaine nommé europe-dc.corp.contoso.com, entrez le code suivant :
```
$gpoSession = Open-NetGPO -PolicyStore "domain1\DA_Server_GPO _Europe" -DomainController "europe-dc.corp.contoso.com"
Set-NetFirewallProfile -GpoSession $gpoSession -Name @("Private","Public") -Enabled True
Save-NetGPO -GpoSession $gpoSession
```

Modification de l’association de contrôleur de domaine

Pour assurer la cohérence de la configuration dans un déploiement multisite, il est important de veiller à ce que chaque objet de stratégie de groupe soit géré par un seul contrôleur de domaine. Dans certains scénarios, il peut être nécessaire d’affecter un contrôleur de domaine différent pour un objet de stratégie de groupe :

Maintenance et temps d’arrêt du contrôleur de domaine : lorsque le contrôleur de domaine qui gère un objet de stratégie de groupe n’est pas disponible, il peut être nécessaire de gérer l’objet de stratégie de groupe sur un autre contrôleur de domaine.
Optimisation de la distribution de la configuration : après modification de l’infrastructure réseau, il peut être nécessaire de gérer l’objet de stratégie de groupe serveur d’un point d’entrée sur un contrôleur de domaine dans le même site Active Directory que le point d’entrée.

2.4 Planifier DNS

Notez les points suivants lors de la planification de DNS pour un déploiement multisite :

Les ordinateurs clients utilisent l’adresse ConnectTo pour se connecter au serveur d’accès à distance. Chaque point d’entrée de votre déploiement nécessite une adresse ConnectTo différente. Chaque adresse ConnectTo de point d’entrée doit être disponible dans le DNS public, et l’adresse que vous choisissez doit correspondre au nom de l’objet du certificat IP-HTTPS que vous déployez pour la connexion IP-HTTPS.
En outre, l’accès à distance applique le routage symétrique ; par conséquent, seuls les clients Teredo et IP-HTTPS peuvent se connecter lorsqu’un déploiement multisite est activé. Pour permettre aux clients IPv6 natifs de se connecter, l’adresse ConnectTo (l’URL IP-HTTPS) doit être résolue en adresses IPv6 et IPv4 externes (accessibles sur Internet) sur le serveur d’accès à distance.
L'accès à distance crée une sonde web par défaut utilisée par les ordinateurs clients DirectAccess pour vérifier la connectivité au réseau interne. Pendant la configuration du serveur unique, les noms suivants doivent avoir été inscrits dans DNS :
1. directaccess-WebProbeHost : doit se résoudre en adresse IPv4 interne du serveur d’accès à distance, ou en adresse IPv6 dans un environnement IPv6 uniquement.
2. directaccess-CorpConnectivityHost - doit être résolu en une adresse localhost (bouclage) (::1 ou 127.0.0.1, selon qu’IPv6 est déployé ou non dans le réseau d’entreprise).
Dans un déploiement multisite, une entrée DNS supplémentaire pour directaccess-WebProbeHost doit être créée pour chaque point d’entrée. Lors de l’ajout d’un point d’entrée, l’accès à distance tente de créer automatiquement cette entrée directaccess-WebProbeHost supplémentaire. Toutefois, en cas d’échec, un avertissement s’affiche et vous devez créer l’entrée manuellement.

Notes

Lorsque le nettoyage DNS est activé dans votre infrastructure DNS, il est recommandé de désactiver le balayage sur les entrées DNS créées automatiquement par l’accès à distance.