Étape 1 : Planifier l’infrastructure d’accès à distance

Remarque

Windows Server 2016 associe DirectAccess et le service Routage et accès distant (RRAS) dans un rôle Accès à distance unique.

Ce sujet décrit les étapes de planification d’une infrastructure que vous pouvez utiliser pour configurer un serveur d’accès à distance unique pour la gestion à distance des clients DirectAccess. Le tableau suivant répertorie les étapes, mais ces tâches de planification n’ont pas besoin d’être effectuées dans un ordre spécifique.

Tâche	Descriptif
Planifier la topologie réseau et les paramètres du serveur	Décidez où placer le serveur d'accès à distance (à la périphérie, ou derrière un pare-feu ou un périphérique de traduction d'adresses réseau (NAT)), et planifiez l'adressage IP et le routage.
Planifier les exigences en matière de pare-feu	Planifiez l'autorisation de l'accès à distance via des pare-feu de périmètre.
Planifier les exigences de certificat	Déterminez si vous souhaitez utiliser un protocole Kerberos ou des certificats pour l'authentification client, et planifiez vos certificats de site web. IP-HTTPS est un protocole de transition utilisé par les clients DirectAccess pour transférer le trafic IPv6 via des réseaux IPv4. Décidez d'authentifier IP-HTTPS pour le serveur à l'aide d'un certificat émis par une autorité de certification ou d'un certificat auto-signé émis automatiquement par le serveur d’accès à distance.
Planifier les exigences DNS	Planifiez les paramètres DNS (Domain Name System) pour le serveur d’accès à distance, les serveurs d'infrastructure, les options de résolution de noms locale et la connectivité client.
Planifier la configuration du serveur d’emplacement réseau	Décidez où placer le site web du serveur Emplacement réseau dans votre organisation (sur le serveur d’accès à distance ou sur un autre serveur) et planifiez les certificats requis si le serveur Emplacement réseau se trouve sur le serveur d’accès à distance. Note: Le serveur d’emplacement réseau est utilisé par les clients DirectAccess pour déterminer s’ils se trouvent sur le réseau interne.
Planifier les configurations des serveurs d’administration	Planifiez les serveurs d’administration (tels que les serveurs de mise à jour) utilisés lors de l’administration à distance des clients. Note: Les administrateurs peuvent gérer à distance les ordinateurs clients DirectAccess situés en dehors du réseau d’entreprise à l’aide d’Internet.
Planifier les exigences d’Active Directory	Planifiez vos contrôleurs de domaine, la configuration Active Directory requise, l'authentification client et plusieurs structures de domaines.
Planification de la création d’objets de stratégie de groupe	Déterminez quels objets de stratégie de groupe sont requis dans votre organisation et comment les créer ou les modifier.

Planifier la topologie et les paramètres réseau

Lorsque vous planifiez votre réseau, vous devez prendre en compte la topologie de carte réseau, les paramètres de l’adressage IP et les exigences pour ISATAP.

Planifier les cartes réseau et l'adressage IP

1. Identifiez la topologie des cartes réseau à utiliser. L'accès à distance peut être configuré de l'une des manières suivantes :

   • Avec deux cartes réseau : le serveur d’accès à distance est installé à la périphérie avec une carte réseau connectée à Internet et l’autre au réseau interne.

   • Avec deux cartes réseau : le serveur d’accès à distance est installé derrière un périphérique NAT, un pare-feu ou un routeur, avec une carte réseau connectée à un réseau de périmètre et l’autre au réseau interne.

   • Avec une carte réseau : le serveur d'accès à distance est installé derrière un périphérique NAT et l'unique carte réseau est connectée au réseau interne.

2. Identifiez vos exigences en matière d'adressage IP :

   DirectAccess utilise IPv6 avec IPsec pour créer une connexion sécurisée entre les ordinateurs clients DirectAccess et le réseau d'entreprise interne. Pourtant, DirectAccess ne requiert pas systématiquement une connectivité Internet IPv6 ni une prise en charge IPv6 native sur les réseaux internes. Au lieu de cela, il configure et utilise automatiquement des technologies de transition IPv6 pour canaliser le trafic IPv6 sur Internet IPv4 (6to4, Teredo, IP-HTTPS) et sur votre intranet IPv4 uniquement (NAT64 ou ISATAP). Pour obtenir une vue d'ensemble de ces technologies de transition, consultez les ressources suivantes :

   • IPv6 Transition Technologies

   • Spécification du protocole de tunnelingIP-HTTPS

3. Configurez les cartes et l'adressage requis selon le tableau suivant. Pour les déploiements qui se trouvent derrière un appareil NAT utilisant une seule carte réseau, configurez vos adresses IP en utilisant uniquement la colonne de carte réseau interne.

   Descriptif	Carte réseau externe	Carte réseau interne1, ci-dessus	Configuration requise du routage
   Internet IPv4 et intranet IPv4	Configurez ce qui suit : - Deux adresses IPv4 publiques statiques, consécutives avec les masques de sous-réseau appropriés (requis pour Teredo uniquement). – Adresse IPv4 de la passerelle par défaut de votre pare-feu Internet ou du routeur de votre fournisseur de services Internet local. Note: Le serveur d’accès à distance nécessite deux adresses IPv4 publiques consécutives afin qu’elle puisse agir en tant que serveur Teredo et les clients Teredo windows peuvent utiliser le serveur d’accès à distance pour détecter le type d’appareil NAT.	Configurez ce qui suit : – Adresse intranet IPv4 avec le masque de sous-réseau approprié. – Suffixe DNS spécifique à la connexion de votre espace de noms intranet. Vous devez également configurer un serveur DNS sur l'interface interne. Prudence: Ne configurez pas de passerelle par défaut sur les interfaces intranet.	Pour configurer le serveur d'accès à distance afin d'atteindre tous les sous-réseaux du réseau IPv4 interne, procédez comme suit : - Répertoriez les espaces d'adressage IPv4 pour tous les emplacements sur votre intranet. - Utilisez les commandes route add -p ou netsh interface ipv4 add route pour ajouter les espaces d'adressage IPv4 en tant qu'itinéraires statiques dans la table de routage IPv4 du serveur d'accès à distance.
   Internet IPv6 et intranet IPv6	Configurez ce qui suit : – Utilisez la configuration d’adresses automatique fournie par votre fournisseur de services Internet. – Utilisez la commande route print pour vous assurer qu’il existe bien un itinéraire IPv6 par défaut qui pointe vers le routeur du fournisseur de services Interne dans la table de routage IPv6. – Déterminez si le fournisseur de services Internet et les routeurs intranet utilisent les préférences de routeur par défaut décrites dans le document RFC 4191 et s’ils utilisent une préférence par défaut supérieure à vos routeurs intranet locaux. Si vous avez répondu par l'affirmative dans les deux cas, aucune autre configuration n'est requise pour l'itinéraire par défaut. Une préférence plus élevée pour le routeur ISP permet de s'assurer que l'itinéraire IPv6 par défaut actif du serveur d'accès à distance pointe vers Internet IPv6. Étant donné que le serveur d'accès à distance est un routeur IPv6, si vous disposez d'une infrastructure IPv6 native, l'interface Internet peut également atteindre les contrôleurs de domaine sur l'intranet. Dans ce cas, ajoutez des filtres de paquets au contrôleur de domaine dans le réseau de périmètre pour empêcher la connectivité IPv6 de l'interface Internet du serveur d'accès à distance.	Configurez ce qui suit : Si vous n'utilisez pas les niveaux de préférence par défaut, vous pouvez configurer vos interfaces intranet à l'aide de la commande netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled. Cette commande vérifie que les itinéraires par défaut supplémentaires qui pointent vers les routeurs intranet ne seront pas ajoutés à la table de routage IPv6. Vous pouvez obtenir l'information InterfaceIndex de vos interfaces intranet dans l'affichage de la commande netsh interface show interface.	Si vous avez un intranet IPv6, procédez comme suit pour configurer le serveur d'accès à distance afin d'atteindre tous les emplacements IPv6 : - Répertoriez les espaces d'adressage IPv6 pour tous les emplacements sur votre intranet. - Utilisez la commande netsh interface ipv6 add route pour ajouter les espaces d'adressage IPv6 en tant qu'itinéraires statiques dans la table de routage IPv6 du serveur d’accès à distance.
   Internet IPv4 et intranet IPv6	Le serveur d'accès à distance transfère le trafic de l'itinéraire IPv6 par défaut à l'aide de l'interface de carte Microsoft 6to4 à un relais 6to4 sur Internet IPv4. Quand IPv6 natif n’est pas déployé dans le réseau d’entreprise, vous pouvez utiliser la commande suivante pour configurer un serveur d’accès à distance pour l’adresse IPv4 du relais Microsoft 6to4 sur l’Internet IPv4 : netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

   Remarque

   • Si une adresse IPv4 publique a été attribuée au client DirectAccess, il utilisera la technologie de relai 6to4 pour se connecter à l'intranet. Si une adresse IPv4 privée a été attribuée au client, il utilisera Teredo. Si le client DirectAccess ne peut pas se connecter au serveur DirectAccess avec 6to4 ou Teredo, il utilisera IP-HTTPS.
   • Pour utiliser Teredo, vous devez configurer deux adresses IP consécutives sur la carte réseau tournée vers l'extérieur.
   • Vous ne pouvez pas utiliser Teredo si le serveur d’accès à distance possède une seule carte réseau.
   • Les ordinateurs clients IPv6 natif se connectent au serveur d'accès à distance via IPv6 natif et aucune technologie de transition n'est requise.

Planifier les exigences ISATAP

ISATAP est requis pour la gestion à distance de DirectAccessclients, afin que les serveurs d’administration DirectAccess puissent se connecter aux clients DirectAccess situés sur Internet. ISATAP n'est pas requis pour prendre en charge les connexions initiées par les ordinateurs clients DirectAccess aux ressources IPv4 sur le réseau de votre entreprise. NAT64/DNS64 est utilisé à ces fins. Si votre déploiement nécessite ISATAP, utilisez le tableau suivant pour identifier vos besoins.

Scénario de déploiement ISATAP	Configuration requise
Intranet IPv6 natif existant (aucun ISATAP n’est requis)	Avec une infrastructure IPv6 native existante, vous spécifiez le préfixe de l’organisation pendant le déploiement de l’accès à distance et le serveur d’accès à distance ne se configure pas en tant que routeur ISATAP. Effectuez les actions suivantes : 1. Pour vérifier que les clients DirectAccess sont accessibles depuis l'intranet, vous devrez modifier votre routage IPv6 afin que le trafic de l'itinéraire par défaut soit envoyé au serveur d’accès à distance. Si votre espace d’adressage IPv6 intranet utilise une adresse autre qu’un seul préfixe d’adresse IPv6 48 bits, vous devez spécifier le préfixe IPv6 d’organisation approprié pendant le déploiement. 2. Si vous êtes connecté actuellement à Internet IPv6, vous devez configurer le trafic de l'itinéraire par défaut afin qu'il soit envoyé au serveur d’accès à distance, puis configurer les connexions appropriées et les itinéraires sur le serveur d’accès à distance afin que le trafic de l'itinéraire par défaut soit envoyé au périphérique connecté à Internet IPv6.
Déploiement ISATAP existant	Si vous disposez d’une infrastructure ISATAP existante, pendant le déploiement, vous êtes invité à entrer le préfixe 48 bits de l’organisation et le serveur d’accès à distance ne se configure pas comme routeur ISATAP. Pour vérifier que les clients DirectAccess sont accessibles depuis l'intranet, vous devrez modifier votre infrastructure de routage IPv6 afin que le trafic de l'itinéraire par défaut soit envoyé au serveur DirectAccess. Cette modification doit être effectuée sur le routeur ISATAP existant vers lequel les clients intranet doivent déjà transférer le trafic par défaut.
Aucune connectivité IPv6	Lorsque l’Assistant Installation de l’accès à distance détecte que le serveur n’a pas de connectivité IPv6 native ou ISATAP, il dérive automatiquement un préfixe 48 bits basé sur 6to4 pour l’intranet et configure le serveur d’accès à distance en tant que routeur ISATAP pour fournir une connectivité IPv6 aux hôtes ISATAP sur votre intranet. (Un préfixe basé sur 6to4 est utilisé uniquement si le serveur a des adresses publiques. Autrement, le préfixe est généré automatiquement à partir d’une plage d’adresses locale unique.) Pour utiliser ISATAP, procédez comme suit : 1. Inscrivez le nom ISATAP sur un serveur DNS pour chaque domaine sur lequel vous souhaitez activer la connectivité basée sur ISATAP, afin que le nom ISATAP soit résolu par le serveur DNS interne à l’adresse IPv4 interne du serveur d’accès à distance. 2. Par défaut, les serveurs DNS exécutant Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, ou la résolution de blocs Windows Server 2003 du nom ISATAP à l’aide de la liste globale des blocs de requête. Pour activer ISATAP, vous devez supprimer le nom ISATAP de la liste de blocage. Pour plus d’informations, consultez Supprimer ISATAP de la liste de blocs de requêtes globales DNS. Les hôtes ISATAP basés sur Windows qui peuvent résoudre le nom ISATAP configurent automatiquement une adresse avec le serveur d’accès à distance comme suit : 1. Adresse IPv6 basée sur ISATAP sur une interface de tunneling ISATAP 2. Itinéraire 64 bits qui fournit la connectivité aux autres hôtes ISATAP sur l'intranet 3. Itinéraire IPv6 par défaut qui pointe sur le serveur d’accès à distance. L'itinéraire par défaut vérifie que les hôtes ISATAP intranet peuvent atteindre les clients DirectAccess Lorsque vos hôtes ISATAP basés sur Windows obtiennent une adresse IPv6 ISATAP, ils commencent à utiliser le trafic encapsulé par ISATAP pour communiquer si la destination correspond également à un hôte ISATAP. Étant donné qu'ISATAP utilise un sous-réseau 64 bits unique pour votre intranet entier, la communication passe d'un modèle de communication segmenté IPv4 à un modèle de communication de sous-réseau unique avec IPv6. Cela peut affecter le comportement des services AD DS et d'autres applications qui reposent sur la configuration de votre composant Sites et Services Active Directory. Par exemple, si vous avez utilisé le composant logiciel enfichable Sites et Services Active Directory pour configurer des sites, des sous-réseaux IPv4 et des transports inter-sites pour le transfert de demandes aux serveurs dans des sites, cette configuration n'est pas utilisée par les hôtes ISATAP. Pour configurer des sites et services Active Directory pour le transfert dans des sites pour les hôtes ISATAP, pour chaque objet de sous-réseau IPv4, vous devez configurer un objet de sous-réseau IPv6 équivalent, dans lequel le préfixe d'adresse IPv6 pour le sous-réseau exprime la même plage d'adresses hôtes ISATAP que le sous-réseau IPv4. Par exemple, pour le sous-réseau IPv4 192.168.99.0/24 et le préfixe d’adresse ISATAP 64 bits 2002:836b:1:8000::/64, le préfixe d’adresse IPv6 équivalent pour l’objet de sous-réseau IPv6 est 2002:836b:1:8000:0:5efe:192.168.99.0/120. Pour une longueur de préfixe IPv4 arbitraire (définie sur 24 dans l’exemple), vous pouvez déterminer la longueur de préfixe IPv6 correspondante de la formule 96 + IPv4PrefixLength. Pour les adresses IPv6 de clients DirectAccess, ajoutez ce qui suit : Pour les clients DirectAccess basés sur Teredo : un sous-réseau IPv6 pour la plage 2001:0:WWXX:YYZZ::/64, dans laquelle WWXX:YYZZ correspond à la version hexadécimale utilisant le signe deux-points comme séparateur de la première adresse IPv4 accessible sur Internet du serveur d’accès à distance. . Pour les clients DirectAccess basés sur IP-HTTPS : un sous-réseau IPv6 de la plage 2002:WWXX:YYZZ:8100::/56, dans lequel WWXX:YYZZ est la version hexadécimale utilisant le signe deux-points comme séparateur de la première adresse IPv4 accessible sur Internet (w.x.y.z) du serveur d’accès à distance. . Pour les clients DirectAccess basés sur 6to4 : une série de préfixes IPv6 6to4 qui commencent par 2002: et représente les préfixes d'adresses IPv4 régionales, publiques qui sont administrés par l'autorité IANA (Internet Assigned Numbers Authority) et les registres régionaux. Le préfixe 6to4 d'une adresse IPv4 publique w.x.y.z/n est 2002:WWXX:YYZZ::/[16 +n], dans lequel WWXX:YYZZ correspond à la version hexadécimale de w.x.y.z utilisant le signe deux-points comme séparateur. Par exemple, la plage 7.0.0.0/8 est administrée par le registre ARIN (American Registry for Internet Numbers) pour l'Amérique du Nord. Le préfixe basés sur 6to4 correspondant à cette plage d’adresse IPv6 publique est 2002:700::/24. Pour plus d’informations sur l’espace d’adressage public IPv4, consultez IANA IPv4 Address Space Registry. .

Important

Vérifiez que vous n’avez pas d’adresses IP publiques sur l’interface interne du serveur DirectAccess. Si vous disposez d’une adresse IP publique sur l’interface interne, la connectivité via ISATAP peut échouer.

Planifier la configuration requise pour le pare-feu

Si le serveur d'accès à distance se trouve derrière un pare-feu de périmètre, les exceptions suivantes sont requises pour le trafic d'accès à distance quand le serveur d'accès à distance est sur Internet IPv4 :

• Pour IP-HTTPS : port TCP de destination 443 et port TCP source 443 sortant.

• Pour le trafic Teredo : port UDP de destination 3544 entrant et port UDP source 3544 sortant.

• Pour le trafic 6to4 : protocole IP 41 entrant et sortant.

  Remarque

  Pour les trafics Teredo et 6to4, ces exceptions doivent être appliquées pour les deux adresses IPv4 publiques consécutives côté Internet sur le serveur d’accès à distance.

  Pour IP-HTTPS, les exceptions doivent être appliquées sur l'adresse enregistrée sur le serveur DNS public.

• Si vous déployez l'accès à distance avec une seule carte réseau, puis que vous installez le serveur d'emplacement réseau sur le serveur d'accès à distance, port TCP 62000.

  Remarque

  Cette exemption est sur le serveur d’accès à distance et toutes les autres exemptions sont sur le pare-feu de périmètre.

Les exceptions suivantes sont requises pour le trafic d'accès à distance que le serveur d'accès à distance est sur Internet IPv6 :

• Protocole IP 50

• Port UDP de destination 500 entrant et port UDP source 500 sortant.

• Trafic entrant et sortant ICMPv6 (uniquement lors de l’utilisation de Teredo).

Lorsque vous utilisez des pare-feu supplémentaires, appliquez les exceptions de pare-feu de réseau interne suivantes pour le trafic d’accès à distance :

• Pour ISATAP : Protocole 41 entrant et sortant

• Pour tout le trafic IPv4/IPv6 : TCP/UD

• Pour Teredo : ICMP pour tout le trafic IPv4/IPv6

Planifier les exigences en matière de certificats

Il existe trois scénarios qui requièrent des certificats lorsque vous déployez un serveur d’accès à distance unique.

• Authentification IPsec : les exigences de certificat pour IPsec incluent un certificat d’ordinateur utilisé par les ordinateurs clients DirectAccess lorsqu’ils établissent la connexion IPsec avec le serveur d’accès à distance et un certificat d’ordinateur utilisé par les serveurs d’accès à distance pour établir des connexions IPsec avec les clients DirectAccess.

  Pour DirectAccess dans Windows Server 2012, l’utilisation de ces certificats IPsec n’est pas obligatoire. Autrement, le serveur d’accès à distance peut servir de proxy pour l’authentification Kerberos sans nécessiter de certificats. Si l’authentification Kerberos est utilisé, elle fonctionne via SSL et le protocole Kerberos utilise le certificat configuré pour IP-HTTPS. Certains scénarios d'entreprise (y compris l'authentification client par déploiement multisite et mot de passe à usage unique) requièrent l'utilisation de l'authentification par certificat et non pas de l’authentification Kerberos.

• IP-HTTPS serveur : lorsque vous configurez l’accès à distance, le serveur d’accès à distance est automatiquement configuré pour agir comme écouteur web IP-HTTPS. Le site IP-HTTPS requiert un certificat de site web. Les ordinateurs clients doivent être en mesure de contacter le site de la liste de révocation de certificats correspondant.

• Serveur d’emplacement réseau : le serveur d’emplacement réseau est un site web utilisé pour détecter si les ordinateurs clients se trouvent dans le réseau d’entreprise. Le serveur emplacement réseau requiert un certificat de site Web. Pour ce certificat, les clients DirectAccess doivent pouvoir contacter le site contenant la liste de révocation de certificats.

Les exigences liées à l'autorité de certification sont résumées pour chaque scénario dans le tableau ci-dessous.

Authentification IPsec	Serveur IP-HTTPS	Serveur Emplacement réseau
Une autorité de certification interne est requise pour émettre des certificats d'ordinateur pour le serveur et les clients d'accès à distance à des fins d'authentification IPsec quand vous n'utilisez pas le protocole Kerberos pour l'authentification.	Autorité de certification interne : vous pouvez utiliser une autorité de certification interne pour émettre le certificat IP-HTTPS ; toutefois, vous devez vérifier que le point de distribution de la liste de révocation de certificats est disponible en externe.	Autorité de certification interne : vous pouvez utiliser une autorité de certification interne pour émettre le certificat de site web du serveur d'emplacement réseau. Assurez-vous que le point de distribution de la liste de révocation de certificats est hautement disponible à partir du réseau interne.
	Certificat auto-signé : vous pouvez utiliser un certificat auto-signé pour le serveur IP-HTTPS. Un certificat auto-signé n'est pas utilisable dans un déploiement multisite.	Certificat auto-signé : vous pouvez utiliser un certificat auto-signé pour le site web du serveur d'emplacement réseau ; toutefois, vous ne pouvez pas en utiliser un dans un déploiement multisite.
	Autorité de certification publique : nous vous recommandons d'utiliser une autorité de certification publique pour émettre le certificat IP-HTTPS car elle garantit que le point de distribution de la liste de révocation de certificats est disponible en externe.

Planifier des certificats d'ordinateur pour l'authentification IPsec

Si vous utilisez l'authentification IPsec basée sur les certificats, le serveur et les clients d’accès à distance doivent obtenir un certificat d'ordinateur. La façon la plus simple d'installer les certificats est d’utiliser une stratégie de groupe pour configurer une inscription automatique pour les certificats d'ordinateur. Cela garantit que tous les membres du domaine obtiendront un certificat à partir d'une autorité de certification d'entreprise. Si vous n’avez pas d’autorité de certification d’entreprise configurée dans votre organisation, consultez Les services de certificats Active Directory.

Ce certificat présente les exigences suivantes :

• Le certificat doit bénéficier d'une utilisation améliorée de la clé d'authentification client.

• Le client et les certificats de serveur doivent être liés au même certificat racine. Ce certificat racine doit être sélectionné dans les paramètres de configuration DirectAccess.

Planifier des certificats pour IP-HTTPS

Le serveur d'accès à distance joue le rôle d'écouteur IP-HTTPS, et vous devez installer manuellement un certificat de site web HTTPS sur le serveur. Tenez compte des éléments suivants quand vous planifiez des certificats :

• Il est recommandé d'utiliser une autorité de certification publique, afin que les listes de révocation de certificats soient rapidement disponibles.

• Dans le champ Objet, spécifiez l'adresse IPv4 de la carte Internet du serveur d'accès à distance ou le nom de domaine complet (FQDN) de l'URL IP-HTTPS (l'adresse ConnectTo). Si le serveur d'accès à distance se trouve derrière un périphérique NAT, vous devez spécifier le nom public ou l'adresse du périphérique NAT.

• Le nom commun du certificat doit correspondre au nom du site IP-HTTPS.

• Pour le champ Utilisation améliorée de la clé , utilisez l’identificateur d’objet OID (Server Authentication Object Identifier).

• Pour le champ Points de distribution de CRL, spécifiez un point de distribution de listes de révocation de certificats (CRL) accessible par les clients DirectAccess lorsqu'ils sont connectés à Internet.

  Remarque

  Cela est requis uniquement pour les clients exécutant Windows 7.

• Le certificat IP-HTTPS doit avoir une clé privée.

• Le certificat IP-HTTPS doit être importé directement dans le magasin personnel.

• Les certificats IP-HTTPS peuvent utiliser des caractères génériques dans le nom.

Planifier des certificats de site web pour le serveur Emplacement réseau

Tenez compte des éléments suivants lorsque vous planifiez le site web du serveur d’emplacement réseau :

• Dans le champ Objet , spécifiez une adresse IP de l’interface intranet du serveur d’emplacement réseau ou du nom de domaine complet de l’URL d’emplacement réseau.

• Pour le champ Utilisation améliorée de la clé , utilisez l’OID d’authentification du serveur.

• Pour le champ Points de distribution CRL, utilisez un point de distribution CRL accessible par les clients DirectAccess connectés à l’intranet. Ce point de distribution de liste de révocation de certificats ne doit pas être accessible depuis l'extérieur du réseau interne.

Remarque

Assurez-vous que les certificats pour IP-HTTPS et le serveur d'emplacement réseau ont un nom de sujet. Si le certificat utilise un autre nom, il n’est pas accepté par l’Assistant Accès à distance.

Planifier la configuration DNS requise

Cette section explique la configuration DNS requise pour les clients et les serveurs dans un déploiement d'accès à distance.

Demandes des clients DirectAccess

DNS sert à résoudre les demandes des ordinateurs clients DirectAccess qui ne se trouvent pas sur le réseau interne. Les clients DirectAccess essaient de se connecter au serveur d'emplacement réseau DirectAccess afin de déterminer s'ils se situent sur Internet ou sur le réseau d'entreprise.

• Si la connexion réussit, c'est que les clients se situent sur l'intranet. DirectAccess n'est donc pas utilisé et les demandes des clients sont résolues à l'aide du serveur DNS configuré sur la carte réseau de l'ordinateur client.

• Si la connexion échoue, les clients sont considérés comme étant sur Internet. Les clients DirectAccess utilisent la table de stratégie de résolution de noms (NRPT) pour déterminer quel serveur DNS utiliser pour résoudre les demandes de noms. Vous pouvez préciser que les clients doivent utiliser DirectAccess DNS64 pour résoudre les noms, ou un autre serveur DNS interne.

Pendant la résolution des noms, la table NRPT est utilisée par les clients DirectAccess pour identifier la manière de traiter une demande. Les clients demandent un nom de domaine complet (FQDN) ou un nom en une partie comme <https://internal>. Si un nom en une partie est demandé, un suffixe DNS est ajouté pour créer un nom de domaine complet (FQDN). Si la requête DNS correspond à une entrée dans la NRPT, et que DNS4 ou un serveur DNS intranet est spécifié pour l'entrée, alors la requête est envoyée pour la résolution de noms à l'aide du serveur spécifié. S'il existe une correspondance alors qu'aucun serveur DNS n'est spécifié, une règle d'exemption et la résolution de noms habituelle est appliquée.

Lorsqu’un nouveau suffixe est ajouté à la NRPT dans la console de gestion de l’accès à distance, les serveurs DNS par défaut pour le suffixe peuvent être détectés automatiquement en cliquant sur le bouton Détecter . La détection automatique fonctionne comme suit :

• Si le réseau d'entreprise est basé sur IPv4 ou utilise IPv4 et IPv6, l'adresse par défaut correspond à l'adresse DNS64 de la carte interne sur le serveur d'accès à distance.

• Si le réseau d'entreprise est basé sur IPv6, l'adresse par défaut correspond à l'adresse IPv6 des serveurs DNS du réseau d'entreprise.

Serveurs d'infrastructure

• Serveur d’emplacement réseau

  Les clients DirectAccess essaient d'atteindre le serveur Emplacement réseau pour déterminer s'ils se situent sur le réseau interne. Les clients qui se trouvent sur le réseau interne doivent être en mesure de résoudre le nom du serveur Emplacement réseau, et il est impératif de les empêcher de le faire quand ils se situent sur Internet. Pour garantir cela, le nom de domaine complet (FQDN) du serveur Emplacement réseau est, par défaut, ajouté en tant que règle d'exemption à la table NRPT. De plus, quand vous configurez l'accès à distance, les règles suivantes sont automatiquement créées :

  • Règle de suffixe DNS pour le domaine racine ou le nom de domaine du serveur d'accès à distance et les adresses IPv6 qui correspondent aux serveurs DNS intranet configurés sur le serveur d'accès à distance. Par exemple, si le serveur d'accès à distance est membre du domaine corp.contoso.com, une règle est créée pour le suffixe DNS corp.contoso.com.

  • Règle d'exemption pour le nom de domaine complet du serveur d'emplacement réseau. Par exemple, si l’URL du serveur d’emplacement réseau est https://nls.corp.contoso.com, une règle d’exemption est créée pour le nom de domaine complet nls.corp.contoso.com.

• serveurIP-HTTPS

  Le serveur d'accès à distance joue le rôle d'écouteur IP-HTTPS et utilise son certificat de serveur pour s'authentifier auprès des clients IP-HTTPS. Les clients DirectAccess qui utilisent des serveurs DNS publics doivent être en mesure de résoudre le nom IP-HTTPS.

Vérificateurs de connectivité

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. Pour que la sonde fonctionne comme prévu, les noms suivants doivent être enregistrés manuellement dans DNS :

• 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.

• directaccess-corpconnectivityhost doit se résoudre en adresse de l’hôte local (bouclage). Vous devez créer des enregistrements A et AAAA. La valeur de l’enregistrement A est 127.0.0.1, et la valeur de l’enregistrement AAAA est construite à partir du préfixe NAT64 avec les 32 derniers bits comme 127.0.0.1. Le préfixe NAT64 peut être récupéré en exécutant l’applet de commande Windows PowerShell Get-netnatTransitionConfiguration .

  Remarque

  Cela n'est valide que dans des environnements IPv4 uniquement. Dans un environnement IPv4 plus IPv6 ou IPv6 uniquement, ne créez qu’un enregistrement AAAA avec l'adresse IP de bouclage ::1.

Vous pouvez créer d'autres vérificateurs de connectivité à l'aide d'autres adresses web sur HTTP ou PING. Pour chaque vérificateur de connectivité, une entrée DNS doit exister.

Configuration requise du serveur DNS

• Pour les clients DirectAccess, vous devez utiliser un serveur DNS exécutant Windows Server 2012 , Windows Server 2008 R2 , Windows Server 2008 , Windows Server 2003 ou tout serveur DNS prenant en charge IPv6.

• Vous devez utiliser un serveur DNS qui prend en charge les mises à jour dynamiques. Vous pouvez utiliser des serveurs DNS qui ne prennent pas en charge les mises à jour dynamiques, mais vous devez mettre à jour manuellement les entrées.

• Le FQDN de vos points de distribution de liste de révocation de certificats doit pouvoir être résolu à l'aide de serveurs DNS Internet. Par exemple, si l’URL https://crl.contoso.com/crld/corp-DC1-CA.crl se trouve dans le champ Points de distribution CRL du certificat IP-HTTPS du serveur d’accès à distance, vous devez vous assurer que le nom de domaine complet (FQDN) crld.contoso.com est résolvable à l’aide de serveurs DNS Internet.

Planifier la résolution de noms locale

Tenez compte des éléments suivants lorsque vous planifiez une résolution de noms locale :

Le

Vous devrez peut-être créer des règles de table de stratégie de résolution de noms (NRPT) supplémentaires dans les situations suivantes :

• Vous devez ajouter des suffixes DNS pour votre espace de noms intranet.

• Si les FQDN de vos points de distribution de liste de révocation de certificats sont basés sur votre espace de noms intranet, vous devez ajouter des règles d'exemption pour les noms de domaine complets des points de distribution de liste de révocation de certificats.

• Si vous avez un environnement DNS « split brain », vous devez ajouter des règles d'exemption pour les noms des ressources pour lesquelles vous souhaitez que les clients DirectAccess se trouvant sur Internet puissent accéder à la version Internet, plutôt qu'à la version intranet.

• Si vous redirigez le trafic vers un site web externe via vos serveurs proxy web intranet, le site web externe est disponible uniquement à partir de l'intranet. Il utilise les adresses de vos serveurs proxy web pour autoriser les demandes entrantes. Dans ce cas, ajoutez une règle d'exemption pour le nom de domaine complet du site web externe et spécifiez que la règle utilise votre serveur proxy web intranet, plutôt que les adresses IPv6 des serveurs DNS intranet.

  Par exemple, supposons que vous testez un site web externe nommé test.contoso.com. Ce nom ne peut pas être résolu via les serveurs DNS Internet, mais le serveur proxy web de Contoso sait comment résoudre le nom et diriger les demandes pour le site web vers le serveur web externe. Pour empêcher que les utilisateurs qui ne trouvent pas sur l'intranet Contoso puissent accéder au site, le site web externe autorise uniquement les demandes provenant de l'adresse Internet IPv4 du proxy web Contoso. Par conséquent, les utilisateurs de l'intranet peuvent accéder au site web car ils utilisent le proxy web Contoso, ce qui n'est pas le cas des utilisateurs DirectAccess. En configurant une règle d'exemption NRPT pour test.contoso.com qui utilise le proxy web Contoso, les demandes de page web pour test.contoso.com sont routées vers le serveur proxy web intranet via le réseau Internet IPv4.

Noms en une partie

Les noms en une partie, tels que <https://paycheck>, sont parfois utilisés pour les serveurs intranet. Si un nom en une partie est demandé et qu'une liste de recherche de suffixe DNS est configurée, les suffixes DNS de la liste sont ajoutés au nom en une partie. Par exemple, lorsqu'un utilisateur sur un ordinateur qui est un membre du domaine corp.contoso.com tape <https://paycheck> dans son navigateur web, le nom de domaine complet qui est construit est paycheck.corp.contoso.com. Par défaut, le suffixe ajouté est basé sur le suffixe DNS principal de l'ordinateur client.

Remarque

Dans un scénario d'espace de noms dissocié (où un ou plusieurs ordinateurs de domaine ont un suffixe DNS qui ne correspond pas au domaine Active Directory auquel les ordinateurs appartiennent), vous devez vous assurer que la liste de recherche est personnalisée pour inclure tous les suffixes requis. Par défaut, l'Assistant Accès à distance configure le nom DNS Active Directory comme suffixe DNS principal sur le client. Assurez-vous d'ajouter le suffixe DNS utilisé par les clients pour la résolution de noms.

Si plusieurs domaines et Windows Internet Name Service (WINS) sont déployés dans votre organisation et que vous vous connectez à distance, les noms en une partie peuvent être résolus comme suit :

• Déployez une zone de recherche directe WINS dans DNS. Lorsque vous essayez de résoudre computername.dns.zone1.corp.contoso.com, la demande est dirigée vers le serveur WINS qui utilise uniquement le nom de l’ordinateur. Le client pense qu'il émet une demande d’enregistrement DNS A standard, mais il s'agit en fait d'une demande NetBIOS.

  Pour plus d’informations, consultez Gestion d’une zone de recherche directe.

• En ajoutant un suffixe DNS (par exemple, dns.zone1.corp.contoso.com) au GPO de domaine par défaut.

DNS Split-Brain

Le DNS « split brain » désigne l'utilisation du même domaine DNS pour la résolution des noms Internet et intranet.

Pour les déploiements DNS « split brain », vous devez répertorier les noms de domaine complets dupliqués sur Internet et l'intranet, et décider quelles ressources le client DirectAccess doit atteindre : la version intranet ou Internet. Lorsque vous souhaitez que les clients DirectAccess atteignent la version Internet, vous devez ajouter le FQDN correspondant en tant que règle d'exemption à la table NRPT pour chaque ressource.

Dans un environnement DNS « split brain », si vous souhaitez que les deux versions de la ressource soient disponibles, configurez vos ressources intranet avec d'autres noms qui ne sont pas des doublons des noms déjà utilisés sur Internet. Demandez ensuite à vos utilisateurs d’utiliser l’autre nom lorsqu’ils accèdent à la ressource sur l’intranet. Par exemple, configurez www.internal.contoso.com pour le nom interne de www.contoso.com.

Dans un environnement DNS non « split brain », l'espace de noms Internet est différent de l'espace de noms intranet. Par exemple, la société Contoso Corporation utilise contoso.com sur Internet et corp.contoso.com sur l'intranet. Étant donné que toutes les ressources intranet utilisent le suffixe DNS corp.contoso.com, la règle NRPT pour corp.contoso.com dirige toutes les requêtes de nom DNS pour les ressources intranet vers les serveurs DNS intranet. Les requêtes DNS pour les noms avec le suffixe contoso.com ne correspondent pas à la règle d'espace de noms intranet corp.contoso.com dans la table NRPT et sont envoyées aux serveurs DNS Internet. Avec un déploiement DNS non « split brain », étant donné qu'il n'y a aucune duplication de noms de domaines complets pour les ressources intranet et Internet, aucune configuration supplémentaire n'est requise pour la table NRPT. Les clients DirectAccess peuvent accéder à la fois aux ressources Internet et intranet de leur organisation.

Planifier le comportement de résolution de noms locale pour les clients DirectAccess

Si un nom ne peut pas être résolu avec le DNS, le service de client DNS dans Windows Server 2012 , Windows Server 8, Windows Server 2008 R2 et Windows 7 peut utiliser la résolution de noms locale, avec les protocoles LLMNR (Link-Local Multicast Name Resolution) et NetBIOS sur TCP/IP pour résoudre le nom sur le sous-réseau local. La résolution de noms locale est généralement nécessaire pour la connectivité de réseau pair à pair lorsque l'ordinateur se trouve sur des réseaux privés, tels que des réseaux domestiques à sous-réseau unique.

Lorsque le service Client DNS exécute la résolution de noms locale pour des noms de serveur intranet et que l'ordinateur est connecté sur Internet à un sous-réseau partagé, les utilisateurs malveillants peuvent capturer LLMNR et NetBIOS sur des messages TCP/IP afin de déterminer des noms de serveur intranet. Dans la page DNS de l'Assistant Installation du serveur d'infrastructure, vous pouvez configurez le comportement de résolution de noms locale en fonction des types de réponses reçus à partir des serveurs DNS intranet. Les options suivantes sont disponibles :

• Utilisez la résolution de noms locale si le nom n’existe pas dans DNS : cette option est la plus sécurisée, car le client DirectAccess effectue uniquement la résolution de noms locaux pour les noms de serveurs qui ne peuvent pas être résolus par les serveurs DNS intranet. Si les serveurs DNS intranet sont accessibles, les noms des serveurs intranet sont résolus. S'ils ne sont pas accessibles ou que d'autres types d'erreurs DNS surviennent, les noms de serveur intranet ne seront pas révélés sur le sous-réseau via la résolution de noms locale.

• Utilisez la résolution de noms locale si le nom n’existe pas dans DNS ou que les serveurs DNS ne sont pas accessibles lorsque l’ordinateur client se trouve sur un réseau privé (recommandé) : cette option est recommandée, car elle autorise l’utilisation de la résolution de noms locale sur un réseau privé uniquement lorsque les serveurs DNS intranet ne sont pas accessibles.

• Utilisez la résolution de noms locale pour n’importe quel type d’erreur de résolution DNS (moins sécurisée) : il s’agit de l’option la moins sécurisée, car les noms des serveurs réseau intranet peuvent être transmis au sous-réseau local via la résolution de noms locale.

Planifier la configuration du serveur Emplacement réseau

Le serveur Emplacement réseau est un site web utilisé pour détecter si les clients DirectAccess se trouvent dans le réseau d'entreprise. Les clients figurant sur le réseau d'entreprise n'utilisent pas DirectAccess pour atteindre les ressources internes mais se connectent directement.

Le site web du serveur Emplacement réseau peut être hébergé sur le serveur d’accès à distance ou sur un autre serveur dans votre organisation. Si vous hébergez le serveur Emplacement réseau sur le serveur d’accès à distance, le site web est créé automatiquement lorsque vous déployez l'accès à distance. Si vous hébergez le serveur Emplacement réseau ou un autre serveur exécutant un système d'exploitation Windows, vous devez vous assurer qu'Internet Information Services (IIS) est installé sur ce serveur et que le site web est créé. L’accès à distance ne configure pas les paramètres sur le serveur d’emplacement réseau.

Assurez-vous que le site web du serveur Emplacement réseau respecte les exigences suivantes :

• Possède un certificat de serveur HTTPS.

• Possède une haute disponibilité sur les ordinateurs du réseau interne.

• N’est pas accessible aux ordinateurs de clients DirectAccess figurant sur Internet.

En outre, tenez compte des exigences suivantes pour les clients lorsque vous configurez votre site web de serveur d’emplacement réseau :

• Les ordinateurs clients DirectAccess doivent faire confiance à l'autorité de certification qui a émis le certificat de serveur pour le site web du serveur Emplacement réseau.

• Les ordinateurs clients DirectAccess figurant sur le réseau interne doivent être en mesure de résoudre le nom du site du serveur Emplacement réseau.

Planifier des certificats pour le serveur Emplacement réseau

Quand vous obtenez le certificat de site web à utiliser pour le serveur Emplacement réseau, prenez en compte les éléments suivants :

• Dans le champ Objet , spécifiez l’adresse IP de l’interface intranet du serveur d’emplacement réseau ou le nom de domaine complet de l’URL d’emplacement réseau.

• Pour le champ Utilisation améliorée de la clé , utilisez l’OID d’authentification du serveur.

• Le certificat de serveur d’emplacement réseau doit être vérifié par rapport à une liste de révocation de certificats (CRL). Pour le champ Points de distribution CRL, utilisez un point de distribution CRL accessible par les clients DirectAccess connectés à l’intranet. Ce point de distribution de liste de révocation de certificats ne doit pas être accessible depuis l'extérieur du réseau interne.

Planifier DNS pour le serveur Emplacement réseau

Les clients DirectAccess essaient d'atteindre le serveur Emplacement réseau pour déterminer s'ils se situent sur le réseau interne. Les clients qui se trouvent sur le réseau interne doivent être en mesure de résoudre le nom du serveur d'emplacement réseau, mais il est impératif de les empêcher de le faire quand ils se situent sur Internet. Pour le garantir, le nom de domaine complet (FQDN) du serveur d'emplacement réseau est, par défaut, ajouté en tant que règle d'exemption à la NRPT.

Planifier la configuration des serveurs d’administration

Les clients DirectAccess initient une communication avec les serveurs d'administration qui fournissent des services tels que Windows Update et les mises à jour d'antivirus. Les clients DirectAccess utilisent également le protocole Kerberos pour s’authentifier aux contrôleurs de domaine avant d'accéder au réseau interne. Au cours de l'administration distante des clients DirectAccess, les serveurs d'administration communiquent avec les ordinateurs clients pour exécuter des fonctions d'administration telles que l'évaluation de l'inventaire logiciel et matériel. L'accès à distance peut détecter automatiquement certains serveurs d'administration, dont notamment :

• Contrôleurs de domaine : la découverte automatique des contrôleurs de domaine est effectuée pour les domaines qui contiennent des ordinateurs clients et pour tous les domaines de la même forêt que le serveur d’accès à distance.

• Serveurs Microsoft Endpoint Configuration Manager

Les contrôleurs de domaine et les serveurs Configuration Manager sont détectés automatiquement la première fois que DirectAccess est configuré. Les contrôleurs de domaine détectés ne s’affichent pas dans la console, mais les cmdlet Windows PowerShell permettent de récupérer les paramètres. Si le contrôleur de domaine ou les serveurs Configuration Manager sont modifiés, cliquez sur Update Management Servers dans la console pour actualiser la liste des serveurs d’administration.

Configuration requise pour le serveur d’administration

• Les serveurs d'administration doivent être accessibles via le tunnel d’infrastructure. Lorsque vous configurez l'accès à distance, l'ajout de serveurs dans la liste des serveurs d'administration les rend accessibles via ce tunnel.

• Les serveurs d'administration qui établissent des connexions avec les clients DirectAccess doivent prendre entièrement en charge IPv6, en utilisant une adresse IPv6 native ou une adresse attribuée par ISATAP.

Planifier la configuration requise d'Active Directory

L'accès à distance utilise Active Directory comme suit :

• Authentification : le tunnel d’infrastructure utilise l’authentification NTLMv2 pour le compte d’ordinateur qui se connecte au serveur d’accès à distance, et le compte doit se trouver dans un domaine Active Directory. Le tunnel intranet utilise l'authentification Kerberos pour que l'utilisateur crée le tunnel de l’intranet.

• Objets de stratégie de groupe : l’accès à distance rassemble les paramètres de configuration dans les objets de stratégie de groupe (GPO), qui sont appliqués aux serveurs d’accès à distance, aux clients et aux serveurs d’applications internes.

• Groupes de sécurité : l’accès à distance utilise des groupes de sécurité pour collecter et identifier les ordinateurs clients DirectAccess. Les GPO sont appliqués au groupe de sécurité requis.

Lorsque vous planifiez un environnement Active Directory pour un déploiement d’accès à distance, tenez compte des exigences suivantes :

• Au moins un contrôleur de domaine est installé sur le Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 ou sur le système d’exploitation Windows Server 2003.

  Si le contrôleur de domaine se trouve sur un réseau de périmètre (et est donc accessible depuis la carte réseau Internet du serveur d'accès à distance), empêchez le serveur d'accès à distance d'y accéder. Vous devez ajouter des filtres de paquets sur le contrôleur de domaine pour empêcher la connectivité à l’adresse IP de la carte Internet.

• Le serveur d’accès à distance doit être membre d’un domaine.

• Les clients DirectAccess doivent appartenir au domaine. Les clients peuvent appartenir :

  • à tout domaine inclus dans la même forêt que le serveur d'accès à distance ;

  • à tout domaine doté d'une approbation bidirectionnelle avec le domaine du serveur d'accès à distance ;

  • Tout domaine inclus dans une forêt dotée d'une approbation bidirectionnelle avec la forêt du serveur de domaine d’accès à distance.

Remarque

• Le serveur d'accès à distance ne peut pas être un contrôleur de domaine.
• Le contrôleur de domaine Active Directory utilisé pour l'accès à distance ne doit pas être accessible à partir de la carte Internet externe du serveur d'accès à distance (la carte ne doit pas figurer dans le profil de domaine du Pare-feu Windows).

Planifier l'authentification client

Dans l’accès à distance de Windows Server 2012, vous pouvez choisir entre utiliser l’authentification Kerberos intégrée, qui utilise des noms d’utilisateur et des mots de passe, ou utiliser des certificats pour l’authentification par ordinateur IPsec.

Authentification Kerberos : lorsque vous choisissez d’utiliser les informations d’identification Active Directory pour l’authentification, DirectAccess utilise d’abord l’authentification Kerberos pour l’ordinateur, puis utilise l’authentification Kerberos pour l’utilisateur. Quand vous utilisez ce mode pour l'authentification, DirectAccess utilise un tunnel de sécurité unique qui fournit l'accès au serveur DNS, au contrôleur de domaine et aux autres serveurs sur le réseau interne

Authentification IPsec : lorsque vous choisissez d’utiliser l’authentification à deux facteurs ou la protection d’accès réseau, DirectAccess utilise deux tunnels de sécurité. L’Assistant Configuration de l’accès à distance configure les règles de sécurité de connexion dans le Pare-feu Windows avec la sécurité avancée. Ces règles spécifient les informations d’identification suivantes lors de la négociation de la sécurité IPsec sur le serveur d’accès à distance :

• Le tunnel d'infrastructure utilise les informations d'identification du certificat d'ordinateur pour la première authentification et les informations d'identification de l’utilisateur (NTLMv2) pour la deuxième. Les informations d'identification de l’utilisateur forcent l'utilisation du protocole AuthIP (Authenticated Internet Protocol) et fournissent l'accès à un serveur DNS et contrôleur de domaine avant que le client DirectAccess puisse utiliser les informations d'identification Kerberos pour le tunnel intranet.

• Le tunnel intranet utilise les informations d'identification du certificat d'ordinateur pour la première authentification et de les informations d'identification de l'utilisateur (Kerberos V5) pour la deuxième.

Planifier plusieurs domaines

La liste des serveurs d'administration doit inclure les contrôleurs de domaine de tous les domaines qui contiennent des groupes de sécurité qui incluent des ordinateurs clients DirectAccess. Elle doit contenir tous les domaines qui contiennent des comptes d'utilisateur susceptibles d'utiliser les ordinateurs configurés en tant que clients DirectAccess. Cela garantit que des utilisateurs qui ne se trouvent pas dans le même domaine que l'ordinateur client qu'ils utilisent seront authentifiés auprès d'un contrôleur de domaine dans le domaine de l'utilisateur.

Cette authentification est automatique si les domaines sont dans la même forêt. S’il existe un groupe de sécurité avec des ordinateurs clients ou des serveurs d'applications dans d'autres forêts, les contrôleurs de domaine de ces forêts ne sont pas détectés automatiquement. Les forêts ne sont pas détectées automatiquement. Vous pouvez exécuter la tâche Update Management Servers dans la gestion des accès à distance pour détecter ces contrôleurs de domaine.

Dans la mesure du possible, les suffixes de noms de domaine communs doivent être ajoutés dans la table de stratégie de résolution de noms pendant le déploiement de l'accès à distance. Par exemple, si vous possédez deux domaines, domain1.corp.contoso.com et domain2.corp.contoso.com, au lieu d'ajouter deux entrées dans la table NRPT, vous pouvez ajouter une entrée de suffixe DNS commun, où le suffixe de nom de domaine est corp.contoso.com. Cela se produit automatiquement pour les domaines de la même racine. Les domaines n’étant pas de la même racine doivent être ajoutés manuellement.

Planifier la stratégie de groupe création d’objets

Lorsque vous configurez l’accès à distance, les paramètres DirectAccess sont collectés dans stratégie de groupe Objets (GPO). Deux objets de stratégie de groupe sont renseignés avec les paramètres DirectAccess, puis distribués comme suit :

• Objet de stratégie de groupe client DirectAccess : cet objet de stratégie de groupe contient des paramètres clients, notamment les paramètres de technologie de transition IPv6, les entrées NRPT et les règles de sécurité de connexion pour le Pare-feu Windows avec Advanced Security. Il est appliqué aux groupes de sécurité spécifiés pour les ordinateurs clients.

• Objet de stratégie de groupe de serveur DirectAccess : cet objet de stratégie de groupe contient les paramètres de configuration DirectAccess qui sont appliqués à n’importe quel serveur que vous avez configuré en tant que serveur d’accès à distance dans votre déploiement. Il contient également des règles de sécurité de connexion pour le Pare-feu Windows avec Advanced Security.

Remarque

La configuration des serveurs d’applications n’est pas prise en charge dans la gestion à distance des clients DirectAccess, car les clients ne peuvent pas accéder au réseau interne du serveur DirectAccess où résident les serveurs d’applications. L’étape 4 de l’écran de configuration du programme d’installation de l’accès à distance n’est pas disponible pour ce type de configuration.

Vous pouvez configurer des objets de stratégie de groupe automatiquement ou manuellement.

Automatiquement : lorsque vous spécifiez que les objets de stratégie de groupe sont créés automatiquement, un nom par défaut est spécifié pour chaque objet de stratégie de groupe.

Manuellement : vous pouvez utiliser des GPO prédéfinis par l’administrateur Active Directory.

Lorsque vous configurez vos objets de stratégie de groupe, tenez compte des avertissements suivants :

• 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.

• Utilisez la procédure suivante pour sauvegarder tous les objets de stratégie de groupe d'accès à distance avant d'exécuter des applets de commande DirectAccess :

  Sauvegarder et restaurer la configuration de l’accès à distance.

• Que vous utilisiez des objets de stratégie de groupe configurés automatiquement ou manuellement, vous devez ajouter une stratégie pour la détection des liaisons lentes si vos clients utilisent la 3G. Le chemin d’accès pour Stratégie : configurer la détection d’une liaison lente de stratégie de groupe est :

  Configuration ordinateur/Stratégies/Modèles d’administration/Système/Stratégie de groupe.

• Si les autorisations adéquates pour 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 liaison ne se produit. Si cet avertissement est émis, les liens ne sont pas créés automatiquement, même si les autorisations sont ajoutées plus tard. L'administrateur doit créer les liens manuellement.

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 de l'emplacement et du paramètre de cible du lien, de la façon suivante :

• Pour l'objet de stratégie de groupe serveur DirectAccess, l'emplacement et la cible du lien pointent tous les deux vers le domaine qui contient le serveur d'accès à distance.

• Quand les objets de stratégie de groupe de serveur d'applications et de client sont créés, l'emplacement est défini sur un domaine unique. Le nom de l'objet de stratégie de groupe est recherché dans chaque domaine, puis le domaine est complété avec les paramètres DirectAccess s'il existe.

• 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 ou des serveurs d'applications, et il est lié à la racine de son domaine respectif.

Quand vous utilisez des 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 :

• Autorisations pour créer des objets de stratégie de groupe pour chaque domaine.

• Autorisations de liaison à toutes les racines de domaine client sélectionnées.

• Autorisations de liaison vers les racines du domaine de l’objet de stratégie de groupe de serveur.

• Autorisations de sécurité pour créer, éditer, supprimer et modifier les objets de stratégie de groupe.

• Autorisation de lecture du GPO pour chaque domaine requis. Cette autorisation n’est pas obligatoire, mais elle est recommandée, car elle permet à l’accès à distance de vérifier que les objets de stratégie de groupe avec des noms en double n’existent pas lors de la création d’objets de stratégie de groupe.

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

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

• Les objets de stratégie de groupe doivent déjà exister quand vous exécutez l'Assistant Configuration de l'accès à distance.

• Pour appliquer les paramètres DirectAccess, l’administrateur du serveur d’accès à distance requiert des autorisations de sécurité complètes pour créer, éditer, supprimer et modifier les objets de stratégie de groupe créés manuellement.

• Un lien à l'objet de stratégie de groupe est recherché dans l'ensemble du domaine. Si l'objet de stratégie de groupe n'est pas lié dans le domaine, 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.

Récupération après la suppression d'un objet de stratégie de groupe

Si un objet de stratégie de groupe sur un serveur d’accès à distance, un client ou un serveur d’applications a été supprimé par accident, le message d’erreur suivant s’affiche : L’objet de stratégie de groupe (nom de l’objet de stratégie de groupe) est introuvable.

Si vous disposez d'une sauvegarde, vous pouvez restaurer l'objet de stratégie de groupe. Si aucune sauvegarde n’est disponible, vous devez supprimer les paramètres de configuration et les configurer à nouveau.

Pour supprimer les paramètres de configuration

1. Exécutez l’applet de commande Windows PowerShell Uninstall-RemoteAccess.

2. Ouvrez la gestion de l’accès à distance.

3. Un message d'erreur indique que l'objet de stratégie de groupe est introuvable. Cliquez sur Supprimer les paramètres de configuration. Une fois l’opération terminée, le serveur est restauré dans un état non configuré et vous pouvez reconfigurer les paramètres.