.png)
Annexe B : examen des concepts clés de DirectAccess
Mis à jour: mai 2011
S'applique à: Windows 7, Windows Server 2008 R2
 Important |
|---|
| Cette rubrique décrit des considérations de conception pour DirectAccess dans Windows Server 2008 R2. Pour des considérations de conception pour DirectAccess dans Microsoft Forefront Unified Access Gateway (UAG), consultez le Guide de conception de Forefront UAG DirectAccess (page éventuellement en anglais) (http://go.microsoft.com/fwlink/?LinkId=179988). |
La solution DirectAccess utilise à la fois connectivité de bout en bout IPv6, la protection de sécurité IPsec du trafic intranet, la séparation du trafic DNS avec la table de stratégie de résolution des noms (NRPT) et la détection d'emplacement réseau que les clients DirectAccess utilisent pour déterminer quand ils se trouvent sur l'intranet. Les sections suivantes décrivent le rôle de ces technologies pour l'accès transparent par les clients DirectAccess aux ressources intranet.
IPv6
IPv6 est la nouvelle version de la couche réseau de la pile de protocole TCP/IP conçue pour remplacer le protocole IPv4, qui est aujourd'hui largement utilisé sur intranet et Internet. IPv6 fournit un espace d'adressage suffisamment important pour prendre en charge l'adressage de nœuds de bout en bout sur Internet IPv6, et avec les technologies de transition IPv6, de nœuds sur Internet IPv4. DirectAccess utilise cette fonction pour fournir l'adressage de bout en bout de clients DirectAccess sur Internet IPv4 ou IPv6 vers les ordinateurs sur un intranet.
Étant donné que l'Internet actuel est basé sur IPv4 et que de nombreuses organisations n'ont pas déployé l'adressage et le routage IPv6 natif sur leurs intranets, DirectAccess utilise des technologies de transition IPv6 pour fournir la connectivité IPv6 sur ces réseaux IPv4 uniquement. Teredo, 6to4, IP-HTTPS et ISATAP sont des exemples de technologies de transition IPv6. Ces technologies vous permettent d'utiliser IPv6 sur Internet IPv4 et votre intranet IPv4 uniquement. Les technologies de transition IPv6 peuvent simplifier et réduire les coûts d'un déploiement IPv6.
Connectivité IPv6 via Internet IPv4
Pour envoyer des paquets IPv6 via Internet IPv4, un client DirectAccess peut utiliser 6to4, Teredo ou IP-HTTPS. Si une adresse IPv4 publique a été attribuée au client DirectAccess, il utilisera 6to4. Si une adresse IPv4 privée lui a été attribuée, il utilisera Teredo. Si le client DirectAccess ne peut pas se connecter au serveur DirectAccess avec 6to4 ou Teredo, il utilisera IP-HTTPS.
6to4
6to4, défini dans le document RFC 3056, est une technologie de transition IPv6 qui fournit la connectivité IPv6 sur Internet IPv4 pour les hôtes ou les sites disposant d'une adresse IPv4 publique. Pour plus d'informations, consultez Technologies de transition IPv6 (page éventuellement en anglais) (http://go.microsoft.com/fwlink/?Linkid=117205).
Teredo
Teredo, défini dans le document RFC 4380, est une technologie de transition IPv6 qui fournit la connectivité IPv6 sur Internet IPv4 pour les hôtes situés derrière un périphérique NAT (Network Address Translation) IPv4 et associés à une adresse IPv4 privée. Pour plus d'informations, consultez Présentation de Teredo (page éventuellement en anglais) (http://go.microsoft.com/fwlink/?Linkid=157322).
IP-HTTPS
IP-HTTPS est un nouveau protocole pour Windows 7 et Windows Server 2008 R2 qui permet aux hôtes se trouvant derrière un serveur proxy Web ou un pare-feu d'établir une connectivité par la transmission par tunnel de paquets IPv6 dans une session IPv4 HTTPS. HTTPS est utilisé à la place de HTTP pour que les serveurs proxy Web ne tentent pas d'examiner le flux de données et de mettre fin à la connexion. IP-HTTPS est généralement utilisé uniquement si le client ne peut pas se connecter au serveur DirectAccess à l'aide des autres méthodes de connectivité IPv6 ou si Forcer le mode tunneling a été configuré.
Pour plus d'informations sur IP-HTTPS, consultez Spécification du protocole de tunneling IP-HTTPS (page éventuellement en anglais) (http://go.microsoft.com/fwlink/?Linkid=157309).
|
Remarque |
|---|
| Le laboratoire de test DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) démontre la connectivité DirectAccess au travers d'un sous-réseau Internet simulé utilisant 6to4, Teredo et IP-HTTPS. |
Connectivité IPv6 via un intranet IPv4 uniquement
ISATAP, défini dans le document RFC 4214, est une technologie de transition IPv6 qui fournit une connectivité IPv6 entre des hôtes IPv6/IPv4 sur un intranet IPv4 uniquement. ISATAP peut être utilisé avec DirectAccess pour fournir la connectivité IPv6 aux hôtes ISATAP sur votre intranet.
Pour plus d'informations, consultez Technologies de transition IPv6 (page éventuellement en anglais) (http://go.microsoft.com/fwlink/?Linkid=117205).
|
Remarque |
|---|
| ISATAP peut également servir à fournir la connectivité IPv6 lorsque le client figure sur un site distant. Les déploiements ISATAP peuvent se connecter à Internet IPv6 ou utiliser 6to4 pour transférer le trafic IPv6 sur Internet IPv4. Le laboratoire de test DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) utilise ISATAP au travers de l'intranet simulé. |
IPsec
IPsec est une structure de normes ouvertes destinée à garantir la sécurité des communications privées sur les réseaux IP (Internet Protocol), au moyen de services de chiffrement. IPsec assure une protection renforcée contre les attaques grâce à une sécurité de bout en bout. Les seuls ordinateurs qui doivent être au courant de la protection IPsec sont l'émetteur et le destinataire de la communication. IPsec permet de protéger les communications entre les groupes de travail, les ordinateurs du réseau local, les clients et serveurs de domaine, les succursales (éventuellement distantes), les extranets et les clients itinérants.
La protection IPsec peut être utilisée selon deux modes différents : transport et tunnel. Le mode de transport est conçu pour protéger une charge utile du paquet IP. Le mode tunnel est conçu pour protéger un paquet IP entier. Pour plus d'informations, consultez Types de protocoles IPsec (http://go.microsoft.com/fwlink/?Linkid=157319).
DirectAccess utilise des paramètres IPsec sous la forme de règles de sécurité de connexion dans le composant logiciel enfichable Pare-feu Windows avec fonctions avancées de sécurité et le contexte de l'outil en ligne de commande d'environnement réseau (Netsh) advfirewall pour l'authentification d'homologue, l'intégrité des données et la confidentialité des données (chiffrement) de connexions DirectAccess. Plusieurs règles peuvent être appliquées simultanément au même ordinateur, chacune assurant une fonction différente. Le résultat de toutes ces règles qui fonctionnent ensemble aboutit à un client DirectAccess qui peut avoir des communications protégées avec le serveur DirectAccess et des serveurs intranet, en chiffrant le trafic envoyé sur Internet et éventuellement en protégeant le trafic de bout en bout.
|
Remarque |
|---|
| Windows Server 2003 et les versions précédentes de Windows Server ne prennent pas totalement en charge l'utilisation d'IPsec avec IPv6. Les ressources compatibles IPv6 sur les serveurs exécutant Windows Server 2003 sont disponibles uniquement aux clients DirectAccess si vous utilisez le modèle d'accès intranet complet. Les ressources IPv4 uniquement présentes sur les serveurs exécutant Windows Server 2003, y compris la plupart des applications et services système intégrés, nécessitent un traducteur IPv6/IPv4 et une passerelle DNS IPv6/IPv4 pour être disponibles auprès des clients DirectAccess. |
Chiffrement
Lorsqu'un client DirectAccess envoie des données sur l'intranet, le trafic est chiffré sur Internet. Pour les modèles d'accès aux serveurs sélectionnés et intranet complet, plusieurs règles de sécurité de connexion configurées sur le client DirectAccess définissent les paramètres IPsec en mode tunnel pour la communication entre le client DirectAccess et l'intranet :
-
La première règle pour le tunnel d'infrastructure exige l'authentification avec un certificat d'ordinateur et chiffre le trafic avec IPsec et le protocole ESP (Encapsulating Security Payload). Cette règle fournit une communication protégée avec les contrôleurs de domaine Active Directory, les serveurs DNS et d'autres ressources intranet avant l'ouverture d'une session utilisateur.
-
La deuxième règle pour le tunnel intranet exige l'authentification avec un certificat d'ordinateur et des informations d'identification Kerberos dépendantes de l'utilisateur. Cette règle fournit une communication protégée aux ressources intranet après l'ouverture d'une session utilisateur.
Pour les modèles d'accès aux serveurs sélectionnés et bout à bord, l'arrêt de tunnels IPsec entre le client DirectAccess et l'intranet s'effectue par le composant Passerelle IPsec sur le serveur DirectAccess. Ce composant peut se trouver sur un serveur séparé avec une carte réseau de déchargement IPsec afin d'augmenter les performances.
Intégrité des données
L'intégrité des données autorise l'homologue IPsec destinataire à vérifier par chiffrement que le paquet n'a pas été modifié en cours de transit. Lors du chiffrement des données avec IPsec, l'intégrité des données est également assurée. Il est possible de spécifier l'intégrité des données sans chiffrement. Cette solution peut s'avérer utile pour réduire le risque d'attaque par usurpation d'identité ou par interception et permet de s'assurer que les clients DirectAccess se connectent aux serveurs attendus.
|
Remarque |
|---|
| Lors de la transmission de données confidentielles, IPsec avec intégrité des données uniquement ne doit être utilisé que lorsqu'une autre forme de chiffrement est également implémentée. Il est possible de disposer d'une intégrité des données de bout en bout à l'aide de règles en mode de transport tout en utilisant le chiffrement de bout à bord pour les règles en mode tunnel, ce qui revient à savoir comment fonctionne le modèle d'accès aux serveurs sélectionnés. |
DirectAccess assure l'intégrité des données en utilisant les paramètres IPsec en mode de transport et tunnel. Ces paramètres peuvent être appliqués aux clients DirectAccess, aux serveurs DirectAccess ou aux serveurs d'applications et assurent l'intégrité des données en exigeant les protocoles ESP-NULL (recommandé) ou AH (Authentication Header) pour les communications protégées par IPsec. Il est possible que certains périphériques d'infrastructure réseau ou solutions de surveillance et d'inspection du trafic ne soient pas capables d'analyser les paquets avec un en-tête IPsec ESP ou AH. Dans ce cas, vous pouvez utiliser l'authentification avec encapsulation nulle pour exécuter l'authentification d'homologue IPsec, mais aucune intégrité des données par paquet.
Séparation du trafic DNS
Pour séparer le trafic Internet du trafic intranet pour DirectAccess, Windows 7 et Windows Server 2008 R2 incluent une table NRPT, une nouvelle fonctionnalité qui autorise les serveurs DNS à être définis par espace de noms DNS, plutôt que par interface. La table NRPT stocke une liste de règles. Chaque règle définit un espace de noms DNS et des paramètres de configuration qui définissent le comportement du client DNS pour cet espace de noms. Lorsqu'un client DirectAccess se trouve sur Internet, chaque demande de requête de nom est comparée aux règles d'espace de noms stockées dans la table NRPT. En cas de correspondance, la demande est traitée conformément aux paramètres de la règle NRPT. Les paramètres déterminent les serveurs DNS auxquels la demande sera envoyée.
Si une demande de requête de nom ne correspond pas à un espace de noms recensé dans la table NRPT, elle est envoyée aux serveurs DNS configurés dans les paramètres TCP/IP de l'interface réseau spécifiée. Pour un client distant, il s'agit en général des serveurs DNS Internet configurés par le fournisseur de services Internet. Pour un client DirectAccess sur l'intranet, il s'agit en général des serveurs DNS intranet, comme configurés via le protocole DHCP.
Les noms en une partie, tels que http://internal, sont en général suivis de suffixes de recherche DNS configurés avant leur vérification par rapport à la table NRPT. Si aucun suffixe de recherche DNS n'est configuré et que le nom en une partie ne correspond à aucune autre règle de la table NRPT, la demande est envoyée aux serveurs DNS spécifiés dans les paramètres TCP/IP du client.
Les espaces de noms tels que .internal.contoso.com sont ajoutés à la table NRPT et suivis des adresses IPv6 des serveurs DNS vers lesquels les demandes correspondant à cet espace de noms doivent être dirigées. Si une adresse IP est entrée pour le serveur DNS, toutes les demandes DNS sont envoyées directement au serveur DNS par la connexion DirectAccess. Il n'est pas nécessaire de spécifier une sécurité supplémentaire pour cette configuration.
Toutefois, si un nom est spécifié pour le serveur DNS (par exemple dns.contoso.com) dans la table NRPT, alors il doit pouvoir être résolu publiquement lorsque le client interroge les serveurs DNS spécifiés dans ses paramètres TCP/IP. Pour empêcher qu'un agresseur pirate la demande de requête de nom externe et y injecte une réponse malveillante, l'activation de la protection IPsec pour les échanges de messages DNS est fortement recommandée dans cette configuration.
La table NRPT permet aux clients DirectAccess d'utiliser les serveurs DNS intranet pour la résolution de noms (il n'est pas nécessaire que les serveurs DNS soient dédiés). DirectAccess est conçu pour éviter l'exposition de votre espace de noms intranet sur Internet.
Exemptions NRPT
Certains noms doivent être traités différemment des autres concernant la résolution de noms ; ces noms ne doivent pas être résolus avec les serveurs DNS intranet. Pour vérifier que ces noms sont résolus avec des serveurs DNS configurés par interface, vous devez les ajouter comme exemptions NRPT.
Si aucune adresse de serveur DNS n'est spécifiée dans la règle NRPT, cette dernière constitue une exemption. Si un nom DNS correspond à une règle NRPT ne contenant pas d'adresses de serveur DNS ou ne correspond à aucune règle NRPT, le client DirectAccess envoie la requête de nom aux serveurs DNS configurés par interface.
Si aucun des serveurs suivants ne possède de suffixe de nom correspondant à une règle NRPT pour l'espace de noms intranet, ce nom de serveur doit être une exemption NRPT :
-
Serveurs d'emplacement réseau
-
Points de distribution de liste de révocation de certificats intranet
-
Serveurs de mise à jour de l'intégrité du système
Ces serveurs doivent toujours être résolus avec les serveurs DNS configurés par interface.
|
Remarque |
|---|
| L'Assistant Installation DirectAccess du laboratoire de test DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) crée deux règles dans la table NRPT : une règle d'espace de noms pour corp.contoso.com avec l'adresse IPv6 du serveur DNS intranet et une règle d'exemption pour nls.corp.contoso.com. Vous pouvez consulter les règles NRPT configurées avec la stratégie de groupe de CLIENT1 en exécutant la commande netsh namespace show policy à une invite de commandes. Vous pouvez afficher les règles NRPT actives avec la commande netsh namespace show effectivepolicy. |
Détection d'emplacement réseau
Les clients DirectAccess utilisent la détection d'emplacement réseau pour déterminer s'ils se trouvent sur l'intranet en essayant d'accéder à un serveur d'emplacement réseau. Si le client DirectAccess peut accéder avec succès à une adresse Web (URL) HTTPS sur le serveur d'emplacement réseau, il détermine qu'il se trouve sur l'intranet et supprime les règles DirectAccess de la table NRPT.
Serveur d'emplacement réseau
Un serveur d'emplacement réseau est un serveur Web intranet qui héberge une URL (Uniform Resource Locator) HTTPS. Le serveur DirectAccess peut être le serveur d'emplacement réseau, mais un serveur Web distinct à haute disponibilité est fortement recommandé. Il n'est pas nécessaire que le serveur Web soit un serveur d'emplacement réseau dédié.
Comme le comportement du client DirectAccess dépend de la réponse du serveur d'emplacement réseau, il est essentiel de s'assurer que ce site Web est hautement disponible depuis chaque succursale distante. Les succursales peuvent avoir chacune besoin d'un site Web d'emplacement réseau dédié distinct pour que le site Web reste accessible même en cas de coupure de la liaison.
Fonctionnement de la détection d'emplacement réseau
Lorsqu'un client DirectAccess démarre ou rencontre un événement de changement de réseau (tel qu'une modification dans l'état de la liaison ou une nouvelle adresse IP), il ajoute des règles DirectAccess à la table NRPT. Le client DirectAccess essaie ensuite de résoudre le nom de domaine complet dans l'URL pour le serveur d'emplacement réseau, stocké dans le paramètre de stratégie de groupe Configuration ordinateur/Stratégies/Modèles d'administration/Réseau/Indicateur d'état de connectivité réseau/URL de détermination de l'emplacement du domaine. Étant donné que la table NRPT comporte des règles DirectAccess actives, ce nom de domaine complet doit correspondre à une règle d'exemption ou à aucune règle dans la table NRPT afin que le client DirectAccess puisse utiliser la résolution de noms normale et les serveurs DNS configurés par interface.
Après avoir résolu le nom de domaine complet, le client DirectAccess tente de se connecter à l'URL HTTPS du serveur d'emplacement réseau, ce qui inclut une authentification et vérification SSL (Secure Sockets Layer) du certificat du serveur d'emplacement réseau. Pour authentifier l'accès du client DirectAccess à l'URL, utilisez l'authentification anonyme. Le serveur d'emplacement réseau ne doit pas requérir n'importe quel type d'informations d'identification de l'utilisateur pour l'authentification ou l'autorisation. La vérification de certificat inclut la validation du certificat et la vérification qu'il n'a pas été révoqué en accédant à l'emplacement de liste de révocation de certificats défini dans le certificat SSL du serveur d'emplacement réseau. Lorsque le client DirectAccess accède correctement à l'URL HTTPS du serveur d'emplacement réseau, il détermine qu'il se trouve sur l'intranet. Le client DirectAccess supprime ensuite les règles NRPT DirectAccess de la table active et le client DirectAccess utilise les serveurs DNS configurés par interface pour résoudre tous les noms.
Pour plus d'informations, consultez Network Location Detection.
|
Remarque |
|---|
Tout comme l'URL du serveur d'emplacement réseau, le nom de domaine complet de l'URL ou le chemin de convention d'affectation des noms (UNC) du point de distribution de liste de révocation des certificats doit correspondre à une règle d'exemption ou à aucune règle de la table NRPT, de sorte que le client DirectAccess puisse utiliser les serveurs DNS intranet configurés par interface et la résolution de noms normale pour résoudre le nom. Si le client DirectAccess ne parvient pas à résoudre le nom de domaine complet pour le point de distribution de liste de révocation de certificats, la détection de l'emplacement intranet échoue.
Le laboratoire de test DirectAccess (http://go.microsoft.com/fwlink/?Linkid=150613) utilise APP1, un serveur d'applications distinct, comme serveur Emplacement réseau et l'URL d'emplacement réseau https://nls.corp.contoso.com. Le certificat SSL d'APP1 a le point de distribution de liste de révocation de certificats http://crl.contoso.com/crld/corp-DC1-CA.crl, qui, pour faciliter la configuration, est hébergé sur DA1, le serveur DirectAccess. Pour démontrer la détection d'emplacement réseau, procédez comme suit :
|
