Exporter (0) Imprimer
Développer tout

Vue d’ensemble de l’accès distant (DirectAccess, Routage et accès distant)

Publication: février 2012

Mis à jour: mars 2012

S'applique à: Windows Server 2012

Vue d’ensemble de la technologie d’accès à distance dans Windows Server 2012, ses fonctionnalités nouvelles et modifiées, et ses liens vers des ressources supplémentaires.

L’accès à distance combine deux services de mise en réseau en un rôle serveur unifié unique dans Windows Server 2012.

Windows Server 2008 R2 a introduit DirectAccess, une nouvelle fonctionnalité d’accès à distance permettant la connectivité aux ressources du réseau d’entreprise sans nécessiter de connexions VPN standard. DirectAccess fournit une prise en charge uniquement pour les clients Windows 7 Éditions Intégrale et Entreprise appartenant à un domaine. Le serveur de routage et d’accès distant (RRAS) Windows fournit une connectivité VPN standard pour les clients hérités, les clients n’appartenant pas à un domaine et les clients VPN tiers. RRAS fournit également des connexions de site à site entre serveurs. RRAS dans Windows Server 2008 R2 ne peut pas coexister avec DirectAccess sur le même serveur de périphérie, et il doit être déployé et géré séparément de DirectAccess.

Windows Server 2012 combine la fonctionnalité DirectAccess et le service de rôle RRAS en un nouveau rôle serveur unifié. Ce nouveau rôle de serveur d’accès à distance permet d’administrer, de configurer et de surveiller les services d’accès à distance DirectAccess et VPN de manière centralisée. En outre, DirectAccess dans Windows Server 2012 fournit plusieurs mises à jour et améliorations pour résoudre des bloqueurs de déploiement et simplifier la gestion.

DirectAccess est également disponible dans Windows Server 2012 Essentials et permet de la même manière une connectivité transparente au réseau de votre organisation à partir de tout emplacement distant équipé d’Internet sans avoir à établir de connexion de réseau privé virtuel (VPN).

Pour en savoir plus sur DirectAccess dans Windows Server 2012 Essentials, voir Configuration de DirectAccess dans Windows Server 2012 Essentials.

Le nouveau rôle de serveur unifié pour DirectAccess et RRAS fournit un point de configuration et de gestion unique pour le déploiement de serveur d’accès à distance. Windows Server 2012 présente les améliorations suivantes par rapport à DirectAccess et RRAS dans Windows 7.

  • Coexistence de DirectAcess et de RRAS

  • Déploiement simplifié de DirectAccess

  • Suppression du déploiement de l’infrastructure à clé publique (PKI) comme condition préalable à DirectAccess

  • Prise en charge intégrée de NAT64 et DNS64 pour l’accès aux ressources IPv4 uniquement

  • Prise en charge pour le serveur DirectAccess derrière un périphérique NAT

  • Stratégie de sécurité réseau simplifiée

  • Prise en charge de l’équilibrage de charge

  • Prise en charge de domaines multiples

  • Intégration NAP

  • Prise en charge du mot de passe à usage unique (authentification par jeton)

  • Prise en charge automatisée pour le tunneling forcé

  • Améliorations des performances et de l’interopérabilité IP-HTTPS

  • Prise en charge DirectAccess de la gestion sortante vers les clients

  • Prise en charge multisite

  • Prise en charge de l’installation minimale

  • Prise en charge de Windows PowerShell

  • Suivi des utilisateurs

  • État des opérations du serveur

  • Diagnostics

  • Gestion des comptes et création de rapport

  • VPN de site à site en mode de tunnel IPSec IKEv2

DirectAccess et RRAS implémentent des fonctionnalités de sécurité pour protéger le serveur contre le trafic entrant hostile. Auparavant, les paramètres de ces fonctionnalités de sécurité étaient en conflit les uns avec les autres si les services tentaient de s’exécuter sur le même serveur, empêchant DirectAccess ou RRAS de fonctionner comme prévu.

DirectAccess s’appuie sur les technologies de transition IPv6 (Internet Protocol version 6) pour établir des connexions clientes. RRAS implémente IPsec (Internet Protocol security) IKEv2 (Internet Key Exchange version 2) et configure les filtres de paquets entrants et sortants pour ignorer tous les paquets utilisant les technologies de transition. Cela entraîne le blocage du trafic DirectAccess si RRAS est installé et l’accès VPN est déployé avec IKEv2.

DirectAccess implémente la protection contre les attaques par déni de service IPsec pour protéger les ressources sur le réseau d’entreprise. La protection contre les attaques par déni de service ignore tout le trafic IPv4 et tout le trafic IPv6 qui n’est pas protégé par IPsec, à l’exception des paquets ICMPv6. Cela entraîne le blocage du transfert par RRAS de tous les paquets IPv4 et des paquets IPv6 non protégés par IPsec si DirectAccess est installé.

Le rôle de serveur unifié DirectAccess et RRAS dans Windows Server 2012 permet de résoudre ces problèmes en modifiant les stratégies IKEv2 afin d’autoriser le trafic de technologie de transition IPv6 et en modifiant IPsec DoSP afin d’autoriser le trafic VPN. Ces modifications permettent à DirectAccess et RRAS de coexister sur le même serveur.

Windows Server 2012 inclut des fonctionnalités facilitant le déploiement, en particulier pour les organisations de petite taille et de taille moyenne. Ces nouvelles fonctionnalités incluent une liste de prérequis simplifiée, la suppression de la nécessité d’un déploiement de l’infrastructure PKI complet, l’approvisionnement d’un certificat intégré ainsi que la suppression de la nécessité de deux adresses IPv4 publiques consécutives. Chacune de ces fonctionnalités est présentée plus en détail dans les sections suivantes.

Les administrateurs peuvent à présent déployer DirectAccess à l’aide d’un nouvel Assistant Mise en route, qui présente une procédure de configuration grandement simplifiée. L’Assistant Mise en route masque la complexité de DirectAccess et permet une configuration automatisée en quelques étapes simples. L’administrateur n’est plus tenu de comprendre les détails techniques des technologies de transition IPv6 et le déploiement du serveur Emplacement réseau (NLS).

Un bloqueur de déploiement majeur pour DirectAccess dans Windows 7 est la condition requise d’une infrastructure PKI pour l’authentification basée sur les certificats du serveur et du client. DirectAccess s’appuie sur les stratégies IPsec AuthIP pour authentifier et sécuriser le trafic provenant des clients connectés à Internet. Afin d’authentifier des ressources de domaine à l’aide de Kerberos, le client doit établir au préalable une connexion à des serveurs DNS et des contrôleurs de domaine.

DirectAccess dans Windows 7 permet cette connexion en implémentant deux méthodes d’authentification dans les stratégies AuthIP. Le tunnel IPsec d’infrastructure est établi à l’aide d’un certificat d’ordinateur dans la première méthode d’authentification et à l’aide d’une clé NTLM de l’utilisateur dans la seconde méthode. Une fois que ce tunnel a été établi et qu’un contrôleur de domaine est disponible, le client peut obtenir un jeton Kerberos et établir le tunnel IPsec d’intranet à l’aide d’un certificat d’ordinateur ou d’une clé Kerberos de l’utilisateur dans la première ou la seconde méthode d’authentification.

Cette implémentation requiert que le serveur DirectAccess et tous les clients soient approvisionnés avec des certificats d’ordinateur pour une authentification mutuelle. La gestion d’une infrastructure PKI interne est considérée comme étant difficile par de nombreuses petites et moyennes organisations. DirectAccess dans Windows Server 2012 rend le déploiement de l’infrastructure PKI facultatif pour simplifier la configuration et la gestion.

Cette fonctionnalité est obtenue en implémentant un proxy Kerberos basé sur HTTPS. Les demandes d’authentification client sont envoyées vers un service proxy Kerberos qui s’exécute sur le serveur DirectAccess. Le proxy Kerberos envoie alors les demandes Kerberos aux contrôleurs de domaine de la part du client.

Le nouvel Assistant Mise en route fournit une expérience en toute transparence pour l’administrateur en configurant automatiquement cette solution. Dans ce déploiement DirectAccess simplifié, les options de configuration de niveau utilisateur, comme le tunneling forcé, l’intégration de la protection d’accès réseau (NAP) et l’authentification à deux facteurs, ne sont pas disponibles. Ce déploiement requiert l’établissement d’un seul tunnel IPsec et présente les conditions requises suivantes :

  • Le serveur DirectAccess doit avoir le port TCP 443 ouvert sur son pare-feu.

  • Le serveur DirectAccess doit avoir un certificat d’authentification serveur pour TLS émis par une autorité de certification (CA) approuvée par les clients DirectAccess. Il peut s’agir d’une autorité de certification publique qui ne requiert pas le déploiement d’une infrastructure PKI interne. Si aucun certificat n’est disponible, le processus de configuration du serveur DirectAccess configure automatiquement le certificat proxy IP-HTTPS et KDC requis en tant que certificat auto-signé.

Pour autoriser l’accès aux ressources IPv4 uniquement internes, DirectAccess dans Windows Server 2012 inclut une prise en charge native pour une passerelle de traduction de protocole (NAT64) et de résolution des noms (DNS64) afin de convertir la communication IPv6 d’un client DirectAccess en IPv4 pour les serveurs internes. Les ordinateurs de l’intranet IPv4 uniquement ne peuvent pas initier de connexions aux clients DirectAccess pour la gestion à distance, car la traduction effectuée à l’aide de NAT64 est unidirectionnelle (pour le trafic initié par le client DirectAccess).

Il existe trois instances principales où DirectAccess IPv6 uniquement ne permet pas l’accès complet aux ressources de l’intranet d’entreprise :

  • les serveurs intranet qui ne sont pas entièrement compatibles avec IPv6 et qui prennent en charge uniquement IPv4, tels que les serveurs de fichiers Windows Server 2003 ;

  • les environnements où IPv6 a été désactivé administrativement sur le réseau ;

  • les applications qui s’exécutent sur des serveurs compatibles avec IPv6 (tels que Windows Server 2008) qui ne sont elles-mêmes pas compatibles avec IPv6 (telles que les applications qui ne sont pas capables d’être à l’écoute et de répondre au trafic sur l’interface IPv6).

Pour accéder à ces ressources via DirectAccess, la traduction de protocole doit être effectuée entre le serveur DirectAccess et les ressources internes IPv4 uniquement, avec une traduction ultérieure en retour vers IPv6 pour les réponses envoyées aux clients DirectAccess. NAT64 reçoit le trafic IPv6 en provenance du client et le convertit en trafic IPv4 vers l’intranet. NAT64 est utilisé en association avec DNS64. DNS64 intercepte les requêtes DNS provenant des clients et envoie les réponses après avoir converti les réponses IPv4 en mappages IPv6 associés sur NAT64.

noteRemarque
Avant DirectAccess dans Windows Server 2012, la seule méthode disponible pour fournir la traduction de protocole pour DirectAccess est par le déploiement de DirectAccess dans Microsoft Forefront Unified Access Gateway.

L’Assistant Installation de DirectAccess configure en toute transparence les composants de traduction de protocole en tant qu’opération en arrière-plan, sans requérir aucune interaction administrative. Aucune option de configuration n’est exposée à l’administrateur. L’Assistant Installation active automatiquement NAT64 et DNS64 si l’interface interne du serveur DirectAccess possède une adresse IPv4 attribuée. Pour prendre en charge cette fonctionnalité, l’Assistant Installation configure un préfixe réseau IPv6 pour NAT64. L’Assistant attribue le préfixe NAT64 automatiquement et l’applique à toutes les plages IPv4 dans l’entreprise.

Un serveur DirectAccess dans Windows Server 2008 R2 requiert deux interfaces réseau avec deux adresses IPv4 publiques consécutives attribuées à l’interface externe. Ceci est requis pour qu’il puisse agir en tant que serveur Teredo. Pour que les clients derrière un traducteur d’adresses réseau (NAT) déterminent le serveur Teredo et le type de périphérique NAT, le serveur Teredo requiert deux adresses IPv4 consécutives.

Cette condition présente une difficulté pour les petites et moyennes organisations qui n’ont pas accès à des adresses IPv4 publiques consécutives. À l’avenir, cela pourra devenir un bloqueur de déploiement lorsque l’espace d’adressage IPv4 disponible sera épuisé. DirectAccess dans Windows Server 2012 permet de déployer le serveur DirectAccess derrière un périphérique NAT, avec la prise en charge d’une seule interface réseau ou de plusieurs interfaces, et supprime la nécessité des adresses IPv4 publiques.

Lorsque l’Assistant Mise en route de l’installation des services d’accès à distance ou l’Assistant Configuration de l’accès à distance est exécuté, il vérifie l’état des interfaces réseau sur le serveur pour déterminer si le serveur DirectAccess se trouve derrière un périphérique NAT. Dans cette configuration, seul le protocole IP-HTTPS (IP sur HTTPS) est déployé. Le protocole IP-HTTPS est une technologie de transition IPv6 qui permet l’établissement d’un tunnel IP sécurisé à l’aide d’une connexion HTTP sécurisée.

DirectAccess dans Windows Server 2008 R2 utilise deux tunnels IPsec pour établir une connectivité au réseau de l’entreprise. Le client DirectAccess requiert le tunnel d’infrastructure pour accéder aux ressources d’infrastructure telles que les serveurs DNS, contrôleurs de domaine et d’administration. Ces serveurs d’infrastructure sont tous répertoriés comme points de terminaison dans la stratégie IPsec de tunnel d’infrastructure. Ensuite, le tunnel intranet fournit l’accès à toutes les autres ressources de l’intranet d’entreprise.

Les points de terminaison répertoriés dans la stratégie de tunnel d’infrastructure requièrent des mises à jour périodiques lorsque l’infrastructure change, comme par exemple lorsque des serveurs DNS ou des contrôleurs de domaine sont ajoutés ou supprimés dans le réseau de production. Les clients peuvent perdre leur connexion au domaine lorsque leurs stratégies IPsec ne sont pas mises à jour pour refléter les points de terminaison actuels des serveurs de l’infrastructure, et cette perte de connectivité les empêchera de recevoir les mises à jour des stratégies de groupe destinées à corriger l’échec.

Dans Windows Server 2012, le modèle DirectAccess simplifié propose un moyen de déployer DirectAccess sur un seul tunnel IPsec, ce qui permet de résoudre ce problème. Toutefois, le modèle DirectAccess simplifié ne prend pas en charge certaines aptitudes, qui s’appuient sur l’authentification basée sur les certificats. L’authentification à deux facteurs avec des cartes à puce, le multisite et l’intégration de la protection d’accès réseau (NAP) en sont des exemples. Les entreprises qui requièrent des fonctionnalités DirectAccess complètes devront encore déployer le modèle à deux tunnels.

Si le modèle à deux tunnels est requis pour bénéficier de fonctionnalités complètes, des fonctionnalités supplémentaires qui permettent aux administrateurs d’actualiser la liste des serveurs rendus accessibles via le tunnel d’infrastructure sont disponibles. De nouveaux contrôleurs de domaine et serveurs System Center Configuration Manager sont découverts et ajoutés à la liste. Les serveurs qui n’existent plus sont supprimés de la liste et les entrées correspondant aux serveurs dont les adresses IP ont changé sont mises à jour.

DirectAccess dans Windows Server 2008 R2 ne fournit pas une solution à haute disponibilité complète et se limite aux déploiements sur un serveur unique. Pour fournir une redondance matérielle limitée, DirectAccess peut être configuré à l’intérieur d’un cluster de basculement Hyper-V configuré pour la migration dynamique d’Hyper-V. Toutefois, un seul nœud de serveur peut être en ligne à la fois.

Les déploiements de DirectAccess ont rapidement évolué au-delà du point où un serveur unique peut fournir une puissance de traitement adéquate. Les entreprises ont besoin d’une flexibilité leur permettant de déployer des serveurs supplémentaires rapidement et de façon transparente pour répondre aux exigences liées à une charge changeante. De plus, le serveur Emplacement réseau utilisé pour la détection Intérieur/Extérieur doit être hautement disponible pour empêcher des pannes majeures touchant les clients DirectAccess connectés à l’intranet.

DirectAccess dans Windows Server 2012 permet de résoudre ces problèmes par le biais d’une prise en charge intégrée de l’équilibrage de la charge réseau Windows afin d’obtenir un niveau de hautes disponibilité et évolutivité pour DirectAccess et le VPN RRAS. La configuration de l’équilibrage de la charge réseau est simple à définir et automatiser par le biais de la nouvelle interface de l’Assistant Déploiement. Le processus de configuration fournit également une prise en charge intégrée de solutions matérielles tierces d’équilibrage de charge externes.

ImportantImportant
DirectAccess dans Windows Server 2012 fournit une solution de basculement élémentaire utilisant l’équilibrage de la charge réseau pour un maximum de huit nœuds. Bien que la charge des serveurs doive être partagée entre tous les nœuds d’équilibrage de la charge réseau, les connexions existantes ne sont pas transférées automatiquement vers les autres serveurs lorsqu’un seul serveur cesse d’être disponible.

L’Assistant Installation DirectAccess dans Windows Server 2008 R2 permet de configurer DirectAccess seulement pour un domaine unique. Cela signifie que les clients distants issus d’un autre domaine que le serveur DirectAccess ne sont pas en mesure d’utiliser DirectAccess. En outre, si les serveurs d’application sont dans un domaine différent, les clients distants ne peuvent pas y accéder à distance via DirectAccess.

Bien que les administrateurs puissent configurer manuellement la prise en charge de plusieurs domaines dans Windows Server 2008 R2, le déploiement requiert la modification manuelle des stratégies DirectAccess une fois l’installation terminée. DirectAccess dans Windows Server 2012 fournit une prise en charge intégrée de plusieurs domaines pour permettre l’accès des clients distants à des ressources d’entreprise situées dans des domaines différents.

DirectAccess dans Windows Server 2008 R2 prenait en charge l’intégration de la protection d’accès réseau (NAP) en exigeant un certificat d’intégrité pour l’authentification d’homologue IPsec du tunnel intranet. Un certificat d’intégrité est un certificat présentant l’identificateur d’objet (OID) d’intégrité du système. Un client NAP ne peut obtenir un certificat d’intégrité d’une autorité HRA (Health Registration Authority) que s’il se conforme aux spécifications d’intégrité de système, telles que configurées sur un serveur de la stratégie de contrôle d’intégrité NAP.

Pour intégrer NAP avec DirectAccess dans Windows Server 2008 R2, l’administrateur doit modifier manuellement les objets de stratégie de groupe et les stratégies créées par l’Assistant Installation DirectAccess après le déploiement de DirectAccess. DirectAccess dans Windows Server 2012 permet de configurer une vérification d’intégrité NAP directement par le biais de l’interface utilisateur d’installation. Cette fonctionnalité automatise les modifications des stratégies et des objets de stratégie de groupe requises pour l’intégration NAP. La contrainte d’une vérification d’intégrité NAP peut être activée dans l’Assistant Configuration de l’accès à distance.

noteRemarque
Bien que le nouvel Assistant de configuration simplifie l’intégration NAP avec DirectAccess, il n’automatise pas le déploiement NAP lui-même. Un administrateur doit configurer la contrainte de mise en conformité IPSec NAP et l’infrastructure HRA indépendamment.

Pour renforcer la sécurité de connexion, de nombreuses organisations ont déployé une authentification à deux facteurs à mot de passe à usage unique et imposent son utilisation pour les connexions d’accès à distance. DirectAccess dans Windows Server 2008 R2 fournissait une prise en charge de l’authentification à deux facteurs à l’aide de cartes à puce, mais n’était pas en mesure d’intégrer les solutions des fournisseurs de mots de passe à usage unique, tels que RSA SecurID. Cela empêchait le déploiement de DirectAccess dans les organisations exigeant ce niveau de sécurité.

DirectAccess dans Windows Server 2012 prend en charge l’authentification à deux facteurs utilisant des cartes à puce ou des solutions basées sur des jetons à mot de passe à usage unique. Cette fonctionnalité requiert le déploiement d’une infrastructure PKI de sorte que, si l’option est sélectionnée dans l’Assistant Installation DirectAccess, l’option Utiliser les certificats d’ordinateur est automatiquement sélectionnée et appliquée.

Outre la prise en charge de l’authentification par carte à puce standard, DirectAccess peut utiliser les capacités de carte à puce virtuelle basées sur le module de plateforme sécurisée (TPM), disponibles dans Windows Server 2012. Le module de plateforme sécurisée des ordinateurs clients peut agir en tant que carte à puce virtuelle pour l’authentification à deux facteurs, supprimant ainsi la charge et les coûts induits dans le déploiement de carte à puce.

Par défaut, les clients DirectAccess peuvent accéder simultanément à Internet, à l’intranet d’entreprise et aux ressources LAN locales. Étant donné que seules les connexions établies avec l’intranet d’entreprise sont envoyées via les tunnels IPsec DirectAccess, il s’agit d’une configuration de tunneling fractionné. Le tunneling fractionné fournit une expérience utilisateur optimale lors de l’accès à des ressources sur Internet, tout en continuant à fournir une sécurité forte pour le trafic destiné à l’intranet.

Même si le tunneling fractionné ne représente pas un risque pour la sécurité, certaines organisations exigent la transmission de l’ensemble du trafic via un proxy de l’entreprise afin de pouvoir l’inspecter. Avec les connexions VPN héritées, il est possible que des utilisateurs effectuent un pontage du trafic entre différents réseaux, tels que le réseau domestique et le réseau d’entreprise, se servant du client comme d’un routeur. Pour cette raison, il est courant que les administrateurs désactivent le tunneling fractionné pour les connexions VPN, forçant le routage de l’ensemble du trafic réseau via la connexion VPN. Cela entraîne une diminution des performances lors de l’accès à des ressources Internet, étant donné que tout le trafic doit traverser le tunnel VPN puis être sorti par proxy vers Internet. Cela consomme également une bande passante supplémentaire importante sur le réseau d’entreprise.

Le risque de sécurité perçu du tunneling fractionné n’est pas valide dans un scénario DirectAccess, puisque les règles IPsec qui mettent en jeu DirectAccess requièrent une authentification par le point de terminaison client. Si un autre point de terminaison tente de router le trafic via le client DirectAccess, ce ne sera pas une source authentifiée et IPsec empêchera la connexion. Toutefois, comme certaines organisations exigent la transmission de l’ensemble du trafic via le serveur proxy de l’entreprise afin de pouvoir l’inspecter, l’option DirectAccess Forcer le mode tunneling permet cette procédure.

L’option Forcer le mode tunneling était proposée dans DirectAccess dans Windows Server 2008 R2, mais nécessitait des étapes manuelles pour son activation via un paramètre de stratégie de groupe. DirectAccess dans Windows Server 2012 intègre l’option Forcer le mode tunneling dans l’Assistant Installation et l’interface utilisateur de gestion pour automatiser les paramètres requis. L’activation de l’option Forcer le mode tunneling limite le client DirectAccess à utiliser uniquement le protocole IP-HTTPS pour se connecter et utilise par défaut le serveur DirectAccess comme serveur NAT64/DNS64 pour traduire les ressources IPv6 à envoyer au serveur proxy IPv4.

Sur certains réseaux, les paramètres de pare-feu Internet peuvent empêcher les clients de se connecter correctement en utilisant les technologies de transition IPv6 6to4 ou Teredo. IP-HTTPS est une technologie de transition IPv6 introduite dans Windows 7 pour garantir que les clients DirectAccess peuvent se connecter au réseau d’entreprise même lorsque toutes les autres technologies de transition IPv6 échouent. IP-HTTPS attribue une adresse IPv6 unique de routage global à un hôte IPv4, encapsule les paquets IPv6 dans IPv4 pour leur transmission via un tunnel HTTPS et dirige le trafic IPv6 entre l’hôte et d’autres nœuds IPv6 de routage global.

Windows Server 2012 fournit plusieurs améliorations à l’implémentation d’IP-HTTPS. Les modifications apportées à la technologie permettent aux clients IP-HTTPS d’obtenir des informations de configuration du proxy et de s’authentifier auprès d’un proxy HTTP si l’authentification est requise. La condition requise de Windows 7 de déployer des certificats clients vers chaque client IP-HTTPS a été supprimée.

IP-HTTPS fonctionne en créant une connexion SSL/TLS entre le client et le serveur, puis en transférant le trafic IP via cette connexion. Ces données sont chiffrées par IPsec, ce qui signifie qu’elles sont chiffrées deux fois, en premier par IPsec puis de nouveau par SSL. Il en résulte des performances médiocres et une expérience utilisateur négative par rapport aux autres technologies de transition IPv6 6to4 et Teredo, et l’évolutivité du serveur DirectAccess est limitée.

DirectAccess dans Windows Server 2012 inclut plusieurs améliorations de performances pour IP-HTTPS afin d’améliorer l’évolutivité et de réduire la charge associée à cette méthode de connexion. Ces optimisations incluent des modifications du comportement d’envoi par lot et des tampons de réception, une contention de verrouillage réduite et l’option permettant d’implémenter SSL avec un chiffrement NULL.

IP-HTTPS s’exécute dans un contexte système plutôt que dans un contexte utilisateur. Ce contexte peut entraîner des problèmes de connexion. Par exemple, si un ordinateur client DirectAccess se trouve dans le réseau d’une société partenaire qui utilise un proxy pour l’accès Internet et que la détection automatique WPAD n’est pas utilisée, l’utilisateur doit configurer manuellement les paramètres de proxy afin d’accéder à Internet. Ces paramètres sont configurés dans Internet Explorer au niveau de chaque utilisateur et ils ne peuvent pas être récupérés d’une manière intuitive de la part d’IP-HTTPS. De plus, si le proxy requiert une authentification, le client fournit les informations d’identification pour l’accès Internet, mais IP-HTTPS ne fournit pas les informations d’identification requises pour s’authentifier auprès de DirectAccess. Dans Windows Server 2012, une nouvelle fonctionnalité résout ces problèmes. Spécifiquement, l’utilisateur peut configurer IP-HTTPS pour fonctionner lorsqu’il se trouve derrière un proxy qui n’est pas configuré à l’aide de WPAD et IP-HTTPS demande et fournit les informations d’identification du proxy requises à la demande IP-HTTPS authentifiée, et les relaie au serveur DirectAccess.

Lorsque vous configurez IP-HTTPS dans DirectAccess sur le serveur, vous pouvez utiliser un certificat émis par une autorité de certification (CA) ou vous pouvez spécifier que DirectAccess doit générer automatiquement un certificat auto-signé.

Les clients DirectAccess établissent la connectivité avec l’intranet d’entreprise dès qu’une connexion Internet est disponible, même si aucun utilisateur n’est connecté. Cela permet aux administrateurs de gérer les ordinateurs distants pour l’application des correctifs et de la conformité, même lorsqu’ils ne sont pas à leur bureau. Certains clients y voient l’avantage principal de DirectAccess et décident de garder en place leur solution d’accès à distance existante pour la connectivité utilisateur, tout en utilisant DirectAccess simplement pour la gestion à distance.

DirectAccess dans Windows Server 2008 R2 ne fournit pas une méthode automatisée pour limiter le déploiement à la gestion sortante uniquement et les administrateurs doivent modifier manuellement les stratégies créées par l’Assistant Installation. DirectAccess dans Windows Server 2012 offre la prise en charge d’une configuration de gestion sortante uniquement par le biais d’une option de l’Assistant Déploiement qui limite la création de stratégies à celles nécessaires pour la gestion à distance des ordinateurs clients. Dans ce déploiement, les options de configuration de niveau utilisateur, comme le tunneling forcé, l’intégration de la protection d’accès réseau (NAP) et l’authentification à deux facteurs, ne sont pas disponibles.

noteRemarque
La prise en charge de la gestion sortante nécessite des serveurs de gestion ou de déploiement ISATAP avec des adresses v6.

Les serveurs DirectAccess peuvent être déployés dans plusieurs sites pour augmenter la capacité et fournir un accès plus efficace au point d’entrée le plus proche pour les ressources intranet. Cela fonctionne bien si les clients restent dans leurs sites respectifs et n’ont pas besoin de se rendre dans des sites différents au sein de l’entreprise. Toutefois, la configuration multisite de DirectAccess requiert une planification et une conception soignées si les clients doivent se déplacer entre les sites, afin de garantir qu’ils se connecteront via les serveurs DirectAccess conformément à l’itinéraire le plus efficace.

De nombreux défis sont à considérer dans un environnement multisite, comme s’assurer que le client localise le serveur IP-HTTPS, le serveur Teredo, le serveur DNS et le contrôleur de domaine les plus proches. DirectAccess dans Windows Server 2012 fournit une solution qui permet le déploiement de plusieurs points d’entrée DirectAccess à des emplacements géographiques différents et qui permet aux clients, quel que soit leur emplacement physique, d’accéder aux ressources dans Corpnet d’une manière efficace.

Les serveurs DirectAccess dans Windows Server 2012 peuvent être configurés dans un déploiement multisite qui permet aux utilisateurs distants situés dans des emplacements géographiques disparates de se connecter au point d’entrée multisite le plus proche. Pour les ordinateurs clients qui exécutent Windows 8, les points d’entrée peuvent être attribués automatiquement ou sélectionnés manuellement par le client. Pour les ordinateurs clients Windows 7, les points d’entrée peuvent être alloués statiquement. Les clients Windows 7 peuvent également bénéficier de la sélection automatique des points d’entrée si l’organisation déploie une solution d’équilibrage global de charge du serveur (GSLB). Le trafic au sein du déploiement multisite peut être distribué et équilibré à l’aide d’un équilibrage de charge global externe.

L’installation minimale est une option d’installation serveur minimale conçue pour réduire les conditions requises d’espace disque, de service et de gestion, et diminuer la surface d’attaque du système d’exploitation. Le système d’installation minimale ne prend pas en charge d’interface graphique utilisateur et les administrateurs doivent utiliser des outils de ligne de commande ou de gestion à distance pour accomplir toutes les tâches de configuration nécessaires.

Une installation minimale prend en charge uniquement un sous-ensemble limité des fonctionnalités disponibles dans une installation complète de Windows Server et n’inclut actuellement pas de prise en charge de la fonctionnalité DirectAccess ni du rôle de serveur d’accès à distance. Une installation minimale de Windows Server 2012 inclut la prise en charge du rôle de serveur unifié pour DirectAccess et RRAS.

Le nouveau rôle de serveur d’accès à distance dispose d’une prise en charge complète de Windows PowerShell dans Windows Server 2012, qui peut être utilisée pour l’installation, la configuration et l’analyse. Le rôle de serveur d’accès à distance peut également être configuré par le biais de la gestion de serveur à distance.

Il manque à DirectAccess dans Windows Server 2008 R2 une interface de script et de ligne de commande complète pour les options de configuration. Windows Server 2012 fournit une prise en charge complète de Windows PowerShell pour l’installation, la configuration, la gestion, l’analyse et le dépannage du rôle de serveur d’accès à distance.

Les capacités d’analyse et de diagnostics du serveur RRAS et de DirectAccess sont limitées dans Windows Server 2008 R2. Pour DirectAccess, les capacités d’analyse incluent uniquement le contrôle d’intégrité élémentaire de DirectAccess et de ses composants. Les statistiques et les données d’analyse disponibles sont d’une importance ou d’une pertinence réduite pour les administrateurs.

Le contrôle d’intégrité utilisateur et serveur introduit dans Windows Server 2012 permet à l’administrateur de comprendre le comportement des clients et connexions DirectAccess. La console d’analyse permet d’effectuer le suivi de la charge sur le serveur DirectAccess, de l’activité utilisateur et de l’utilisation actuelle des ressources. L’administrateur utilise ces informations pour identifier les utilisations potentiellement indésirables ou inappropriées. Le suivi de diagnostic peut également être activé à partir de la console d’analyse.

Suivi des utilisateurs

Les administrateurs des solutions d’accès à distance doivent pouvoir analyser non seulement quels utilisateurs sont connectés, mais aussi à quelles ressources ils accèdent. Si des utilisateurs se plaignent qu’un serveur ou un partage de fichiers particulier est inaccessible à distance, l’administrateur n’a actuellement aucun moyen de déterminer si d’autres utilisateurs accèdent correctement à la ressource à partir de la console d’accès à distance. Plusieurs outils et applications sont normalement nécessaires pour résoudre des problèmes tels qu’une consommation excessive de bande passante par des utilisateurs particuliers.

L’accès au tableau de bord s’effectue à partir de la nouvelle console de gestion du serveur d’accès à distance en sélectionnant l’onglet Tableau de bord dans le volet de navigation. Le tableau de bord affiche l’état opérationnel global ainsi que l’état et l’activité des clients distants. L’administrateur peut également consulter des rapports rapides directement à partir du tableau de bord.

Le tableau de bord de suivi montre un résumé de l’état de connexion des clients distants pour les éléments répertoriés ci-dessous. Ces informations sont générées à partir des compteurs de l’Analyseur de performances et des données de gestion des comptes appropriés.

  • Nombre total de clients distants actifs connectés : inclut les clients distants VPN et DirectAccess.

  • Nombre total de clients DirectAccess actifs connectés : seulement le nombre total de clients connectés à l’aide de DirectAccess

  • Nombre total de clients VPN actifs connectés : seulement le nombre total de clients connectés via un réseau VPN

  • Nombre total d’utilisateurs uniques connectés : inclut les utilisateurs DirectAccess et VPN, en fonction des connexions actives.

  • Nombre total cumulé de connexions : nombre total de connexions servies par le serveur d’accès à distance depuis le dernier redémarrage du serveur

  • Nombre maximal de clients distants connecté : nombre maximal d’utilisateurs distants simultanés connectés au serveur d’accès à distance depuis le dernier redémarrage du serveur

  • Totalité des données transférées : totalité du trafic entrant et sortant du serveur d’accès à distance pour DirectAccess et VPN depuis le dernier redémarrage du serveur

    1. Trafic entrant : trafic total/nombre total d’octets entrant dans le serveur d’accès à distance/la passerelle

    2. Trafic sortant : trafic total/nombre total d’octets sortant du serveur d’accès à distance/de la passerelle

Dans un déploiement de cluster, le résumé de l’état et de l’activité des clients distants sur le tableau de bord des accès distants affiche les valeurs totales pour tous les nœuds du cluster.

Les administrateurs peuvent consulter la liste de tous les utilisateurs distants actuellement connectés et peuvent afficher la liste de toutes les ressources auxquelles il est possible d’accéder en cliquant sur un utilisateur distant particulier. Les administrateurs peuvent afficher les statistiques des utilisateurs distants en sélectionnant le lien Statut du client distant dans la console de gestion de l’accès à distance. Les statistiques utilisateur peuvent être filtrées en fonction de critères sélectionnés à l’aide des champs suivants :

 

Nom du champ

Valeur

Nom de l’utilisateur

Nom de l’utilisateur ou alias de l’utilisateur distant. Des caractères génériques peuvent être utilisés pour sélectionner un groupe d’utilisateurs, tel que contoso\* ou *\administrator. Si aucun domaine n’est spécifié, *\username est utilisé par défaut.

Nom de l’hôte

Nom du compte d’ordinateur de l’utilisateur distant. Une adresse IPv4 ou IPv6 peut être spécifiée également.

Type

DirectAccess ou VPN. Si DirectAccess est sélectionné, tous les utilisateurs distants qui se connectent à l’aide de DirectAccess sont répertoriés. Si VPN est sélectionné, tous les utilisateurs distants qui se connectent via un réseau VPN sont répertoriés.

Adresse FAI

Adresse IPv4 ou IPv6 de l’utilisateur distant

Adresse IPv4

Adresse IPv4 interne du tunnel connectant l’utilisateur distant au réseau d’entreprise

Adresse IPv6

Adresse IPv6 interne du tunnel connectant l’utilisateur distant au réseau d’entreprise

Protocole/Tunnel

Technologie de transition utilisée par le client distant : Teredo, 6to4 ou IP-HTTPS dans le cas d’utilisateurs DirectAccess et PPTP, L2TP, SSTP ou IKEv2 dans le cas d’utilisateurs VPN

Ressource ayant fait l’objet d’un accès

Tous les utilisateurs accédant à un point de terminaison particulier ou à une ressource d’entreprise particulière. La valeur correspondant à ce champ est le nom d’hôte/l’adresse IP du serveur/point de terminaison.

Serveur

Serveur d’accès à distance auquel les clients sont connectés. Convient uniquement pour les déploiements de cluster et multisites.

Cette fonctionnalité permet aux administrateurs de gérer et suivre l’état des déploiements de l’accès à distance à partir d’une console d’analyse centralisée. Elle alerte les administrateurs chaque fois qu’un problème nécessitant leur attention est détecté. L’interface affiche des informations de diagnostic détaillées avec la procédure de résolution.

Le nœud Tableau de bord de l’arborescence de la console indique l’état du serveur d’accès à distance, y compris l’état de l’infrastructure d’accès à distance et des composants associés, et si la configuration est correctement répartie entre les points d’entrée.

Le nœud État des opérations du serveur de l’arborescence de la console indique l’état du serveur d’accès à distance, y compris l’état de l’infrastructure d’accès à distance et des composants associés. En cliquant sur un composant particulier, les administrateurs peuvent voir l’état, l’historique des modifications et les détails de l’analyse de ce composant.

Si des serveurs d’accès à distance sont déployés dans un déploiement de cluster ou multisite, tous les serveurs du cluster ou du déploiement multisite sont évalués de façon asynchrone et sont répertoriés avec leur état global. Les administrateurs peuvent parcourir la liste des serveurs et développer ou réduire la vue pour afficher les composants serveur DirectAccess et VPN.

Les composants d’accès à distance avec les moniteurs d’état affichés dans le volet État des opérations du serveur sont répertoriés ci-dessous.

  • 6to4

  • DNS

  • DNS64

  • Contrôleur de domaine

  • IP-HTTPS

  • IPsec

  • ISATAP

  • Kerberos

  • Serveurs d’administration

  • NAT64

  • Cartes réseau

  • Serveur d’emplacement réseau

  • Sécurité réseau (IPsec DoSP)

  • Services

  • Teredo

  • Équilibrage de la charge

  • Adressage VPN

  • Connectivité VPN

La résolution des problèmes d’échec de connexion d’accès à distance pour RRAS et DirectAccess peut s’avérer extrêmement complexe en raison des capacités de journalisation limitées actuellement fournies. Les administrateurs requièrent généralement des captures du moniteur réseau et le suivi RRAS pour la résolution des problèmes, étant donné que les journaux de l’Observateur d’événements ne sont pas très utiles ni normatifs.

Windows Server 2012 fournit les améliorations suivantes des fonctionnalités de diagnostic pour la résolution des problèmes d’accès à distance.

  • Enregistrement des événements détaillés pour DirectAccess

    Les administrateurs peuvent utiliser l’enregistrement amélioré des événements pour identifier les problèmes et effectuer l’analyse des capacités et des performances. Les journaux des événements sont standardisés pour garantir une expérience cohérente avec les autres composants réseau.

  • Suivi et capture des paquets

    Le suivi intégré permet aux administrateurs de rassembler facilement des journaux de suivi et des captures de paquets réseau d’un simple clic. Le suivi avec capture de paquets et la corrélation des journaux s’effectuent dans le cadre d’un processus individuel lorsque l’administrateur clique sur la tâche Démarrer le suivi dans le volet des tâches.

  • Corrélation de journaux

    Cette fonctionnalité fournit une collection et une corrélation automatisées de journaux pour différents composants DirectAccess d’un simple clic, tirant parti de la fonctionnalité de suivi de trace unifié de Windows. Les événements rassemblés à partir de différents composants sont consolidés en un fichier unique par le biais de la corrélation des ID d’activités. Les ID d’activités sont des GUID qui identifient une tâche ou une action particulière. Lorsqu’un composant enregistre un événement, il associe un ID d’activité à l’événement. Le composant transmet alors cet ID ou un événement de transfert mappé sur cet ID au composant qui effectue la tâche suivante dans le scénario, qui associe son ID d’activité aux événements à enregistrer. Lors de l’analyse du fichier de suivi obtenu, la relation entre les divers composants correspondant à un scénario peut être reconstruite.

  • Activation / affichage des journaux

    Le suivi peut être activé à partir du volet des tâches du tableau de bord de suivi ou à partir de la ligne de commande, qui contrôle également les niveaux d’enregistrement, les mots clés et les filtres. Les fichiers ETL de suivi de trace unifié obtenus peuvent être lus et affichés à l’aide du moniteur réseau.

Un serveur d’accès à distance Windows Server 2012 peut tirer parti d’un déploiement de serveur RADIUS existant ou du service Base de données interne de Windows (WID) dans le but de gérer les comptes. Des informations et des données d’historique sur l’état du serveur et la charge sont disponibles par le biais des compteurs de l’Analyseur de performances système et sont stockées dans le magasin de gestion des comptes WID. Dès qu’une connexion est reçue ou déconnectée sur le serveur d’accès à distance, toutes les statistiques de l’utilisateur distant (y compris les points de terminaison atteints) sont enregistrées dans le magasin de gestion des comptes en tant qu’une session. Cela permet d’accéder ultérieurement aux détails de la session dans le but de créer un rapport ou d’effectuer un audit.

Les fonctionnalités de gestion de comptes et de création de rapports fournies dans le rôle de serveur d’accès à distance incluent la capacité à mesurer des métriques spécifiques. Les métriques disponibles incluent le nombre d’utilisateurs connectés à un serveur DirectAccess particulier et le nombre total d’octets transférés. Les administrateurs peuvent créer des rapports personnalisés pour identifier les tendances de trafic et d’utilisation, y compris un historique de ces tendances.

Les capacités de création de rapports de DirectAccess et de RRAS permettent aux administrateurs de créer des rapports d’utilisation détaillés sur la base de statistiques variées, telles que les statistiques relatives aux utilisateurs distants, la disponibilité du serveur et la charge. Le magasin de gestion des comptes de boîte de réception est utilisé pour générer le rapport d’utilisation. La gestion des comptes de boîte de réception dans une base de données WID locale doit être activée pour que des rapports d’utilisation puissent être générés. La gestion des comptes NPS/RADIUS ne peut pas être utilisée pour la création de rapports.

Le rapport d’utilisation permet de visualiser l’historique d’utilisation, y compris quels utilisateurs ont établi des connexions distantes, à quelles ressources ils ont accédé, le nombre total d’utilisateurs uniques et la charge de serveur maximale générée. L’administrateur peut sélectionner une période spécifique pour laquelle il veut générer les données.

La connectivité intersite est une fonctionnalité Windows Server 2012 qui fournit la connectivité réseau pour permettre à des fournisseurs d’hébergement de service de migrer leurs applications et leur infrastructure vers le nuage. Cette fonctionnalité inclut une solution de connectivité VPN en mode tunnel IKEv2 (Internet Key Exchange version 2) de site à site et une interface de gestion. Windows Server 2008 R2 a introduit la prise en charge d’IKEv2 dans RRAS pour les connexions VPN. Un réseau VPN IKEv2 confère de la résilience au client VPN lorsque le client passe d’un réseau à un autre ou lorsqu’il bascule d’une connexion sans fil à une connexion câblée. L’utilisation d’IKEv2 et d’IPsec permet de prendre en charge les méthodes d’authentification et de chiffrement renforcés. RRAS dans Windows Server 2012 fournit des améliorations de fonctionnalités supplémentaires pour activer IKEv2 pour les connexions VPN de site à site.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

Afficher:
© 2014 Microsoft