Nouvelles fonctionnalités réseau de Windows Server 2008 et Windows Vista

Remarque :

Les fonctionnalités présentées dans cet article sont susceptibles d'être modifiées. Il est possible que certaines d'entre elles ne soient pas intégrées au produit final pour des raisons techniques, marketing ou autres.

Sur cette page

Résumé

Introduction

Protocoles et composants réseau essentiels

Connexions sans fil et filaire basée sur IEEE 802.1X

Infrastructure réseau

Suppression de technologies

Résumé

Liens connexes

Résumé

Microsoft® Windows Server® 2008 et Windows Vista™ (tous les deux actuellement en phase de test de la version bêta) incluent de nombreux changements et améliorations des technologies réseau. Cet article décrit les changements apportés aux protocoles et aux composants réseau essentiels, aux technologies sans fil et filaires authentifiées par 802.1X, à l'infrastructure réseau et aux composants et services d'infrastructure réseau de la version bêta 2 de Windows Server 2008 et de la version d'évaluation finale 1 de Windows Vista.

Haut de page

Introduction

La gestion de réseau et les communications sont considérées comme essentielles pour les organisations qui doivent faire face à la concurrence sur le marché mondial. Quels que soient l'endroit où ils se trouvent et le périphérique utilisé, les employés doivent se connecter au réseau. Les partenaires, fournisseurs, etc. extérieurs au réseau doivent interagir de façon efficace avec les ressources essentielles, la sécurité étant primordiale.

Cet article est une présentation technique des améliorations en termes de gestion de réseau et de communication contenues dans Windows Server 2008 et Windows Vista, abordant la connectivité, la facilité d'utilisation, la gestion, la fiabilité et la sécurité. Windows Server 2008 et Windows Vista offrent aux administrateurs informatiques des possibilités étendues et plus souples pour gérer l'infrastructure réseau, protéger leurs réseaux en demandant aux ordinateurs de prouver le bon fonctionnement du système, déployer des connexions sans fil et filaires authentifiées via une stratégie de groupe ou des scripts, et pour déployer des scénarios de trafic protégé.

Haut de page

Protocoles et composants réseau essentiels

Windows Server 2008 et Windows Vista incluent de nombreux changements et améliorations aux protocoles et composants réseau essentiels suivants :

• Pile TCP/IP nouvelle génération

• Qualité de service basée sur les stratégies

• Protocole Server Message Block 2.0

• Améliorations de Http.sys

• Améliorations de WinINet

• Améliorations de Windows Sockets

• NDIS 6.0

• Détection réseau

• Améliorations des réseaux P2P Windows

• Améliorations du pare-feu Windows

• Améliorations d'IPsec

Pile TCP/IP nouvelle génération

Windows Server 2008 et Windows Vista incluent une nouvelle implémentation de la pile de protocole TCP/IP connue sous le nom de pile TCP/IP nouvelle génération. La pile TCP/IP nouvelle génération est une conception totalement nouvelle de la fonctionnalité TCP/IP pour IPv4 (Internet Protocol version 4) et IPv6 (Internet Protocol version 6), qui répond aux exigences de connectivité et de performances requises par les différents environnements réseau et technologies actuels.

Réglage automatique de la fenêtre de réception

La taille de la fenêtre de réception TCP correspond à la quantité de données qu'un émetteur TCP peut envoyer après autorisation du destinataire TCP, avant d'attendre un accusé de réception. Pour déterminer correctement la valeur de la taille de fenêtre de réception maximale pour une connexion basée sur les conditions actuelles du réseau, la pile TCP/IP nouvelle génération prend en charge le réglage automatique de la fenêtre de réception. Le réglage automatique de la fenêtre de réception détermine en permanence la taille optimale de fenêtre de réception en fonction de la connexion, en mesurant le produit bande passante/délai (la bande passante multipliée par le délai de latence de connexion) et le taux de récupération de l'application, et ajuste automatiquement et en continu la taille maximale de fenêtre de réception.

L'utilisation de la bande passante réseau augmente lors du transfert de données, grâce à un meilleur débit entre les homologues TCP. Si toutes les applications sont optimisées pour la réception de données TCP, l'utilisation globale du réseau peut considérablement augmenter, accentuant l'importance de la qualité de service (QoS) pour les réseaux utilisant toutes leurs capacités ou presque. Pour plus d'informations, reportez-vous à la section « Qualité de service » de cet article.

Pour plus d'informations sur le réglage automatique de la fenêtre de réception, reportez-vous à la page Performance Enhancements in the Next Generation TCP/IP Stack (Améliorations des performances dans la nouvelle génération de pile TCP/IP, en anglais).

Compound TCP

Dans le cas de connexions TCP possédant une fenêtre de réception volumineuse et un produit bande passante/délai élevé (la bande passante d'une connexion multipliée par son délai), Compound TCP (CTCP) dans la nouvelle génération de pile TCP/IP augmente considérablement la quantité de données envoyées en une fois, via la surveillance du produit bande passante/délai, des variations de délai et des pertes de paquets. CTCP s'assure également que son comportement n'a pas d'impact négatif sur d'autres connexions TCP. Les tests effectués en interne chez Microsoft ont révélé une forte réduction des temps de sauvegarde de fichiers (environ moitié moins) pour une connexion de 1 Gigabit par seconde avec un temps d'aller-retour de 50 millisecondes. Les connexions possédant un produit bande passante/délai supérieur peuvent bénéficier de meilleures performances.

Le réglage automatique de la fenêtre de réception optimise le débit côté réception et CTCP optimise le débit côté émetteur. En travaillant conjointement, ils peuvent augmenter l'utilisation de la liaison et générer des gains de performances substantiels pour les connexions de produits bande passante/délai élevés.

Prise en charge ECN

Lors de la perte d'un segment TCP, TCP suppose que la perte de ce segment est due à la congestion sur un routeur et effectue un contrôle de congestion, ce qui réduit fortement le taux de transmission de l'émetteur TCP. Grâce à la prise en charge ECN (Explicit Congestion Notification) sur les deux homologues TCP et dans l'infrastructure de routage, les routeurs subissant la congestion marquent les paquets lors de leur transfert. Les homologues TCP recevant des paquets marqués réduisent leur taux de transmission afin de faciliter la congestion et d'éviter les pertes de segments. La détection de la congestion avant les pertes de paquets augmente le débit global entre les homologues TCP. La version d'évaluation finale 1 de Windows Vista prend en charge ECN, mais cette fonctionnalité est désactivée par défaut. Vous pouvez activer la prise en charge ECN avec la commande netsh interface tcp set global ecncapability=enabled.

La description d'ECN figure dans la RFC 3168.

Améliorations pour les environnements à forte perte

La pile TCP/IP nouvelle génération prend en charge les RFC suivantes pour optimiser le débit dans les environnements à forte perte :

• RFC 2582 : Modification NewReno de l'algorithme de récupération rapide de TCP

  L'algorithme NewReno présente un débit plus rapide en modifiant le moyen permettant à un émetteur d'augmenter sa fréquence d'envoi lors de la perte de plusieurs segments dans une fenêtre de données, l'émetteur recevant un accusé de réception partiel (un accusé de réception pour une partie des données effectivement reçues, uniquement).

• RFC 2883 : Extension de l'option d'accusé de réception sélectif (SACK, Selective Acknowledgement) pour TCP (RFC 2883)

  L'option SACK, définie dans la RFC 2018, permet à un destinataire d'indiquer jusqu'à quatre blocs non contigus de données reçues. La RFC 2883 définit une utilisation supplémentaire des champs dans l'option SACK TCP pour accuser réception des paquets dupliqués. Cela permet au destinataire des segments TCP contenant l'option SACK de déterminer le moment où un segment a été inutilement retransmis et d'ajuster son comportement afin d'éviter de nouvelles retransmissions. La diminution du nombre de retransmissions améliore le débit global.

• RFC 3517 : Algorithme conservatif de récupération de perte basé sur SACK pour TCP

  L'implémentation de TCP/IP dans Windows Server 2003 et Windows® XP utilise les informations SACK uniquement dans le but de déterminer les segments TCP qui ne sont pas arrivés à destination. La RFC 3517 définit une méthode d'utilisation des informations SACK pour effectuer la récupération de perte lors de la réception d'accusés de réception dupliqués, remplaçant l'algorithme de récupération rapide lorsque l'option SACK est activée sur une connexion. La pile TCP/IP nouvelle génération conserve une trace des informations SACK en fonction de la connexion et contrôle les accusés de réception entrants et dupliqués pour effectuer une récupération plus rapide lorsque plusieurs segments ne sont pas reçus à destination.

• RFC 4138 : Récupération F-RTO (Forward RTO-Recovery) : Algorithme pour la détection des fausses expirations de retransmission avec TCP et le protocole SCTP (Stream Control Transmission Protocol)

  Les fausses retransmissions de segments TCP peuvent se produire lors d'une augmentation soudaine et temporaire du temps RTT. L'algorithme F-RTO empêche la fausse retransmission de segments TCP. Lorsque des environnements présentent des augmentations soudaines et temporaires du temps RTT (lorsqu'un client sans fil passe d'un point d'accès sans fil à un autre, par exemple), l'algorithme F-RTO empêche toute retransmission inutile de segments et revient plus rapidement à sa fréquence d'envoi normale.

Pour plus d'informations sur ces améliorations, reportez-vous à la page Performance Enhancements in the Next Generation TCP/IP Stack (Améliorations des performances dans la nouvelle génération de pile TCP/IP, en anglais)..

Détection de voisinage inaccessible pour IPv4

La détection de voisinage inaccessible est une fonctionnalité IPv6 dans laquelle un nœud détermine si un nœud voisin est accessible, ce qui permet une meilleure détection d'erreur et une meilleure récupération lorsque des nœuds deviennent subitement inaccessibles. La pile TCP/IP nouvelle génération prend également en charge la détection de voisinage inaccessible pour le trafic IPv4 en déterminant l'état d'accessibilité du voisinage IPv4 dans le cache d'itinéraire IPv4. La détection de voisinage inaccessible pour IPv4 détermine l'accessibilité via un échange de requête ARP (Address Resolution Protocol) monodiffusion et de messages de réponse ARP, ou grâce aux protocoles de couche supérieure, tels que TCP. Elle permet aux communications de type IPv4 d'en tirer profit en déterminant le moment où les nœuds voisins, y compris les routeurs, ne sont plus accessibles, et en signalant la condition.

Pour plus d'informations sur la détection de voisinage inaccessible pour IPv4, reportez-vous à la page Performance Enhancements in the Next Generation TCP/IP Stack (Améliorations des performances dans la nouvelle génération de pile TCP/IP, en anglais).

Changements dans la détection des passerelles inactives

La détection des passerelles inactives dans TC/IP pour Windows Server 2003 et Windows XP fournit une fonction de basculement, mais pas de fonction de restauration qui effectue une nouvelle tentative sur une passerelle inactive pour déterminer si elle est devenue accessible La pile TCP/IP nouvelle génération permet la restauration pour les passerelles inactives par la tentative d'envoi périodique de trafic TCP via la passerelle inactive détectée précédemment. Si le trafic TCP envoyé via la passerelle inactive aboutit, la pile TCP/IP nouvelle génération bascule de la passerelle par défaut à la passerelle inactive détectée précédemment. La prise en charge de la restauration aux passerelles principales par défaut peut fournir un débit plus rapide grâce à l'envoi de trafic via la passerelle principale par défaut sur le sous-réseau.

Changements dans la détection de routeur de trou noir PMTU.

La découverte PTMU (Path maximum transmission unit), définie dans la RFC 1191, est basée sur la réception de messages ICMP (Internet Control Message Protocol) Destination inaccessible-Fragmentation requise et Ne pas fragmenter (DF) paramétré des routeurs contenant la MTU de la liaison suivante. Toutefois, dans certains cas, des routeurs intermédiaires suppriment silencieusement les paquets qui ne peuvent pas être fragmentés. Ces types de routeurs sont appelés routeurs de trou noir PMTU. En outre, les routeurs intermédiaires peuvent ignorer les messages ICMP en raison des règles de pare-feu configurées. Les connexions TCP peuvent alors expirer et prendre fin, car les routeurs intermédiaires suppriment silencieusement les segments TCP importants, leurs retransmissions et les messages d'erreur ICMP pour la découverte PMTU.

La détection de routeur de trou noir PMTU détecte le moment où les segments TCP importants sont retransmis et ajuste automatiquement le PMTU pour la connexion, plutôt que d'utiliser la réception de messages ICMP Destination inaccessible-Fragmentation requise et DF paramétré. Avec TCP/IP dans Windows Server 2003 et Windows XP, la détection de routeur de trou noir PMTU est désactivée par défaut, car son activation augmente le nombre maximal de retransmissions pour un segment donné.

Toutefois, avec l'utilisation de plus en plus fréquente des règles de pare-feu sur les routeurs pour faire baisser le trafic ICMP, la pile TCP/IP nouvelle génération active par défaut la détection de routeur de trou noir PMTU afin d'empêcher les connexions TCP de prendre fin. La détection de routeur de trou noir PMTU est déclenchée sur une connexion TCP lorsqu'elle commence à retransmettre des segments en taille réelle avec l'indicateur DF paramétré. TCP réinitialise la PTMU de la connexion à 536 octets et retransmet ses segments avec l'indicateur DF effacé. La connexion TCP est ainsi maintenue, même si la taille PMTU peut être inférieure à celle existant pour la connexion.

Compartiments de routage.

Pour empêcher le réacheminement non souhaité du trafic entre les interfaces, dans le cas de configurations de réseau privé virtuel (VPN), la pile TCP/IP nouvelle génération prend en charge les compartiments de routage. Un compartiment de routage est la combinaison d'un jeu d'interfaces avec une session possédant ses propres tables de routage IP. Un ordinateur peut disposer de plusieurs compartiments de routage isolés les uns des autres. Chaque interface ne peut appartenir qu'à un seul compartiment.

Par exemple, lorsqu'un utilisateur lance une connexion VPN sur Internet avec l'implémentation TCP/IP dans Windows XP, son ordinateur possède une connectivité partielle avec Internet et un intranet privé en manipulant des entrées dans la table de routage IPv4. Dans certains cas, il est possible de transférer le trafic d'Internet vers l'intranet privé, via la connexion VPN. Pour les clients VPN qui prennent en charge les compartiments de routage, la pile TCP/IP nouvelle génération isole la connectivité Internet de la connectivité par intranet privé à l'aide de tables de routage IP distinctes.

Prise en charge de Network Diagnostics Framework

Network Diagnostics Framework est une architecture extensible qui permet aux utilisateurs de résoudre les problèmes liés aux connexions réseau. Dans le cas d'une communication TCP/IP, Network Diagnostics Framework invite l'utilisateur, via une série d'options, à éliminer les causes possibles jusqu'à l'identification de l'origine du problème ou jusqu'à l'élimination de toutes les possibilités. Network Diagnostics Framework peut diagnostiquer les problèmes TCP/IP spécifiques suivants :

• Adresse IP incorrecte

• Passerelle par défaut (routeur) non disponible

• Passerelle par défaut incorrecte

• Échec de résolution de nom NetBIOS (Network Basic Input/Output System) sur TCP/IP (NetBT)

• Paramètres DNS incorrects

• Port local déjà utilisé

• Service client DHCP pas en cours d'exécution

• Aucun écouteur distant

• Média déconnecté

• Port local bloqué

• Faible capacité de mémoire

Pour plus d'informations, reportez-vous à la page Network Diagnostics Framework in Windows Vista (Network Diagnostics Framework dans Windows Vista, en anglais).

Prise en charge ESTATS

La pile TCP/IP nouvelle génération prend en charge le brouillon Internet « TCP Extended Statistics MIB » (draft-ietf-tsvwg-tcp-mib-extension-08.txt), qui définit les statistiques de performances étendues de TCP. L'analyse ESTATS sur une connexion permet de déterminer si le goulet d'étranglement des performances d'une connexion est l'application d'envoi, l'application de réception ou le réseau. ESTATS est désactivé par défaut et peut être activé en fonction de la connexion. Avec ESTATS, les éditeurs de logiciels (ISV) tiers peuvent créer de puissantes applications de diagnostic et d'analyse de débit réseau.

Nouveau modèle de filtrage de paquets avec Windows Filtering Platform

La plate-forme WFP (Windows Filtering Platform) est une nouvelle architecture de la pile TCP/IP nouvelle génération, qui fournit des API permettant aux éditeurs de logiciels tiers de participer aux décisions de filtrage qui ont lieu dans plusieurs couches de la pile de protocole TCP/IP et dans le système d'exploitation. La plate-forme intègre et fournit également la prise en charge des fonctionnalités de pare-feu nouvelle génération, telles que la communication authentifiée et la configuration de pare-feu dynamique basée sur l'utilisation par les applications de l'API Windows Sockets (stratégie basée sur les applications). Les ISV peuvent créer des pare-feu, des logiciels antivirus, des logiciels de diagnostic et d'autres types d'applications et de services. Le pare-feu Windows et IPsec dans Windows Server « Longhorn » et Windows Vista utilisent l'API WFP.

Pour plus d'informations, reportez-vous à la page Windows Filtering Platform (en anglais).

Améliorations de IPv6

La pile TCP/IP nouvelle génération prend en charge les améliorations suivantes de IPv6 :

• Double pile IP

  La pile TCP/IP nouvelle génération prend en charge une architecture de couche IP double dans laquelle les implémentations IPv4 et IPv6 partagent des couches de transport (incluant TCP et UDP) et de cadrage communes. IPv4 et IPv6 sont activés par défaut sur cette pile. La prise en charge IPv6 ne nécessite pas l'installation d'un composant séparé.

• Activé par défaut

  Dans Windows Server 2008 et Windows Vista, IPv6 est installé et activé par défaut. Les paramètres IPv6 sont configurables dans les propriétés du composant Internet Protocol version 6 (TCP/IPv6) et via des commandes du contexte netsh interface ipv6.

  Dans Windows Server 2008 et Windows Vista, IPv6 peut être désactivé, mais pas désinstallé. Pour plus d'informations, reportez-vous à la page Configuring IPv6 with Windows Vista (Configuration de IPv6 avec Windows Vista, en anglais).

• Configuration GUI-based

  Windows Server 2008 et Windows Vista vous permettent désormais de configurer manuellement les paramètres IPv6 via un ensemble de boîtes de dialogue dans le dossier Connexions réseau, de la même manière que les paramètres IPv4.

  Pour plus d'informations, reportez-vous à la page Configuring IPv6 with Windows Vista (Configuration de IPv6 avec Windows Vista, en anglais).

• Améliorations de Teredo

  Le client Teredo dans Windows Vista est activé, mais il est inactif par défaut. Pour qu'il devienne actif, un utilisateur doit installer une application qui doit utiliser Teredo, ou décider de modifier les paramètres de pare-feu pour autoriser une application à utiliser Teredo.

  Teredo est activé pour les ordinateurs membres du domaine et ne peut fonctionner si un client Teredo est placé derrière un ou plusieurs traducteurs d'adresses réseau (NAT) symétriques. Un NAT symétrique mappe les mêmes numéros d'adresse (privée) et de port interne vers des adresses (publiques) et des ports différents, en fonction de l'adresse de destination externe (pour le trafic sortant). Ce nouveau comportement permet à Teredo de fonctionner entre un ensemble élargi d'hôtes connectés à Internet.

  Pour plus d'informations sur IPv6 et Teredo, reportez-vous à la page Using IPv6 and Teredo (Utilisation de IPv6 et Teredo, en anglais).

• Prise en charge IPsec intégrée

  Dans Windows Server 2008 et Windows Vista, la prise en charge IPsec du trafic IPv6 est similaire à celle de IPv4, y compris la prise en charge IKE (Internet Key Exchange) et le cryptage de données. Le pare-feu Windows avec les composants de sécurité avancée et de stratégies de sécurité IP prennent désormais en charge la configuration des stratégies IPsec pour le trafic IPv6 de la même manière que pour le trafic IPv4. Par exemple, lorsque vous configurez un filtre IP intégré à une liste de filtres IP dans le composant logiciel enfichable Stratégies de sécurité IP, vous pouvez désormais spécifier des adresses IPv6 et adresser des préfixes lors de la spécification d'une adresse IP source ou de destination spécifique.

  Pour plus d'informations, reportez-vous à la page Le nouveau pare-feu Windows dans Windows Vista et Windows Server 2008.

• MLDv2

  Multicast Listener Discovery version 2 (MLDv2), spécifié dans la RFC 3810, prend en charge le trafic de multidiffusion spécifique à la source. MLDv2 correspond à Internet Group Management Protocol version 3 (IGMPv3) pour IPv4.

• LLMNR

  Link-Local Multicast Name Resolution (LLMNR) permet aux hôtes IPv6 d'un sous-réseau unique sans serveur DNS de résoudre réciproquement les noms de chacun. Cette fonctionnalité est utile pour les réseaux domestiques à sous-réseau unique et les réseaux sans fil ad hoc.

• IPv6 sur PPP

  Le client d'accès distant intégré prend désormais en charge IPv6 sur le protocole Point-to-Point Protocol (PPPv6), tel que défini dans la RFC 2472. Le trafic natif IPv6 peut désormais être envoyé via des connexions PPP. Par exemple, la prise en charge PPPv6 vous permet de vous connecter avec un fournisseur de services Internet (ISP) IPv6 via une connexion d'accès distant ou une connexion PPP over Ethernet (PPPoE) qui pourrait être utilisée pour l'accès large bande via Internet.

• ID d'interface aléatoires pour adresses IPv6

  Pour empêcher les analyses d'adresses IPv6 à partir des ID de société connus des fabricants de cartes réseau, Windows Server 2008 et Windows Vista génèrent par défaut des ID d'interface aléatoires pour des adresses IPv6 configurées automatiquement, non temporaires, avec les adresses publiques et les adresses propres à la liaison. Windows XP et Windows Server 2003 utilisent les ID d'interface EUI (Extended Unique Identifier)-64 pour les adresses IPv6 configurées automatiquement.

• Prise en charge DHCPv6

  Windows Server 2008 et Windows Vista incluent un client DHCP compatible DHCPv6 qui effectuera la configuration automatique des adresses avec état avec un serveur DHCPv6.

Pour plus d'informations sur les changements de IPv6 dans Windows Server et 2008 Windows Vista, reportez-vous à la page Changes to IPv6 in Windows Vista and Windows Server 2008 (Changements du protocole IPv6 dans Windows Vista et Windows Server 2008, en anglais).

Qualité de service basée sur les stratégies

Dans Windows Server 2003 et Windows XP, la fonctionnalité de qualité de service (QoS, Quality of Service) était mise à la disposition des applications via les API GQoS (Generic QoS). Les applications qui utilisaient les API GQoS pouvaient accéder aux fonctions de distribution avec priorités. Dans Windows Server 2008 et Windows Vista, de nouvelles options permettent de gérer le trafic réseau pour l'entreprise et la maison.

QoS basé sur les stratégies pour les réseaux d'entreprise

Les stratégies QoS dans Windows Server 2008 et Windows Vista permettent au personnel informatique de définir des priorités ou de gérer la fréquence d'envoi du trafic réseau sortant. Elles peuvent se limiter à des applications spécifiques, à des adresses IP source et destination spécifiques, ainsi qu'à des ports TCP ou UDP source et destination spécifiques. Les paramètres des stratégies QoS sont intégrés à la stratégie de groupe de la configuration utilisateur ou de la configuration de l'ordinateur, et sont configurés avec l'Éditeur d’objets de stratégie de groupe et liés aux conteneurs de services d'annuaire Active Directory® (domaines, sites et unités d'organisation) avec la Console de gestion des stratégies de groupe. Les stratégies QoS peuvent s'appliquer aux utilisateurs ou ordinateurs membres d'un domaine, d'un site ou d'une unité d'organisation.

Pour gérer l'utilisation de la bande passante, vous pouvez configurer une stratégie QoS avec une fréquence de limitation pour le trafic sortant. La limitation permettra à une stratégie QoS de limiter le trafic réseau sortant cumulé à une fréquence spécifiée. Pour spécifier qu'une distribution est prioritaire, le trafic est marqué avec une valeur DSCP (Differentiated Services Code Point) configurée. Les routeurs de l'infrastructure réseau peuvent placer des paquets marqués DSCP dans différentes files d'attente pour une distribution différenciée. Le marquage et la limitation DSCP peuvent être utilisés conjointement pour gérer efficacement le trafic. Étant donné que le marquage de limitation et de hiérarchisation s'effectue au niveau de la couche réseau, il n'est pas nécessaire de modifier les applications.

Les paramètres avancés de QoS basé sur les stratégies vous permettent de contrôler indirectement les données TCP entrantes en spécifiant la taille maximale de la fenêtre de réception TCP (la taille par défaut est de 16 Mo), et de spécifier si les applications peuvent définir des valeurs DSCP (autorisé, par défaut).

Pour plus d'informations sur le QoS basé sur les stratégies, reportez-vous à la page Quality of Service in Windows Server 2008 and Windows Vista (Qualité de service dans Windows Server 2008 et Windows Vista, en anglais). Pour plus d'informations sur l'architecture de QoS basé sur les stratégies, reportez-vous à la page Policy-based QoS Architecture in Windows Server 2008 and Windows Vista (Architecture de QoS basé sur les stratégies dans Windows Server 2008 et Windows Vista, en anglais).

qWave pour les réseaux domestiques

Étant donné que les réseaux domestiques font l'objet d'un partage de plus en plus important par les applications de données et les applications audio/vidéo (A/V), il convient d'implémenter une solution de QoS pour pouvoir fournir un traitement préférentiel sur le trafic de données au trafic A/V dépendant du temps. En outre, les réseaux domestiques adoptent de plus en plus le sans-fil, ce qui ajoute des complications pour les applications sensibles à la latence et à la bande passante. Windows Vista prend en charge qWave (Quality Windows Audio/Video Experience), une collection de modules logiciels liés à QoS qui répondent aux défis des réseaux introduits par les applications A/V et les réseaux sans fil. qWave est intégré à la pile réseau dans le sous-système QoS et fonctionne avec plusieurs technologies de hiérarchisation de paquets réseau et de couche de liaison de données pour prendre en charge plusieurs flux A/V (flux en temps réel nécessitant QoS) et flux de données (flux optimaux, tels que les transferts de courriers électroniques ou de fichiers) simultanément sur un réseau domestique, tout en offrant une expérience utilisateur de qualité.

La collection de technologies qWave détecte et contrôle la bande passante sur le réseau local, découvre la fonctionnalité QoS du réseau domestique et fournit un contrôle d'admission distribué pour une utilisation à la fois juste et cohérente de la bande passante réseau. Ces technologies autorisent les techniques avancées de transmission AV en continu afin que les applications puissent s'adapter de façon dynamique aux conditions de réseaux variables.

Pour plus d'informations sur qWave, reportez-vous à la page Quality Windows Audio-Video Experience - qWave (Une expérience audio/vidéo Windows de qualité - qWave, en anglais).

Protocole Server Message Block 2.0

SMB (Server Message Block), également appelé CIFS (Common Internet File System), est le protocole de partage de fichiers utilisé par défaut sur les ordinateurs équipés de Windows. Windows inclut un client SMB (le composant Client pour Microsoft Windows installé via les propriétés d'une connexion réseau) et un serveur SMB (le composant Partage de fichiers et d'imprimantes pour Microsoft Windows installé via les propriétés d'une connexion réseau). SMB dans les versions de Windows antérieures à Windows Server 2008 et Windows Vista, appelé SMB 1.0, a été conçu il y a 15 ans pour les premiers systèmes d'exploitation réseau Windows tels que Microsoft LAN Manager et Windows for Workgroups, et affiche les limitations de sa conception initiale.

SMB dans Windows Server 2008 et Windows Vista prend également en charge SMB 2.0, une nouvelle version de SMB reconçue pour les environnements réseau actuels et pour répondre aux besoins de la nouvelle génération de serveurs de fichiers. SMB 2.0 contient les améliorations suivantes :

• Prise en charge de plusieurs commandes SMB dans le même paquet. Cela réduit le nombre de paquets envoyés entre un client SMB et le serveur, une critique courante dans SMB 1.0.

• Prise en charge de tailles de mémoire tampon supérieures par rapport à SMB 1.0.

• Augmentation des constantes restrictives dans la conception de protocole pour permettre l'évolutivité. Augmentation, par exemple, du nombre de handles de fichiers ouverts simultanément et du nombre de partages de fichiers qu'un serveur peut avoir.

• Prise en charge des handles durables qui peuvent résister à de courtes interruptions dans la disponibilité du réseau.

• Prise en charge des liens symboliques.

Les ordinateurs fonctionnant sous Windows Server 2008 ou Windows Vista prennent en charge à la fois SMB 1.0 et SMB 2.0. La version de SMB utilisée pour les opérations de partage de fichiers est déterminée au cours de la négociation de la session SMB. Le tableau suivant indique la version de SMB utilisée pour différentes combinaisons d'ordinateurs client et serveur.

Améliorations de Http.sys

Http.sys, le pilote en mode noyau qui traite le trafic HTTP (Hypertext Transfer Protocol), a été amélioré dans Windows Server 2008 et Windows Vista avec les fonctionnalités suivantes :

• API 2.0 de serveur HTTP

• Authentification côté serveur

• Journalisation

• Suivi ETW des événements HTTP

• Commandes Netsh

• Compteurs de performances

API 2.0 de serveur HTTP

L'API de serveur HTTP est un pilote de protocole HTTP en mode noyau doté d'API en mode utilisateur disponibles via Httpapi.dll. Les API de serveur HTTP permettent à une application serveur d'enregistrer des URL HTTP, de recevoir des requêtes et des réponses du service. Les API de serveur HTTP comprennent :

• Une fonctionnalité d'écoute HTTP simple à utiliser sous Windows avec des applications Windows .NET natives et gérées.

• Les applications peuvent utiliser l'API de serveur HTTP pour faire co-exister et partager les ports TCP avec les IIS (Internet Information Services) 6.0. Cela permet aux ports TCP de trafic Web les plus sollicités comme le 80 et le 443 d'être utilisés simultanément par des applications basées sur l'API de serveur HTTP Server et des applications IIS 6.0, à condition qu'elles servent différentes parties de l'espace de noms URL.

• Une pile HTTP native pour les ordinateurs fonctionnant sous un système d'exploitation Windows, compatible HTTP/1.1.

• De nouvelles API pour configurer le serveur HTTP : Authentification, limitation de la bande passante, journalisation, limites de connexion, état du serveur, réponses 503, files d'attente de demandes, mise en cache des réponses et liaison de certificats SSL. Pour plus d'informations, reportez-vous à la page Using the HTTP Server Version 2.0 API (Utilisation de l'API Version 2.0 de serveur HTTP, en anglais).

Authentification côté serveur

Http.sys procède désormais à l'authentification côté serveur. Auparavant, les applications serveur procédaient à leur propre authentification. Les avantages de l'authentification côté serveur par Http.sys sont les suivants :

• Les applications serveur peuvent s'exécuter sous des comptes aux privilèges inférieurs.

• Les applications serveur peuvent s'exécuter sous différents comptes, puisque Http.sys procède désormais à l'authentification SPN (Service Principle Name) pour elles.

• Des négociations d'authentification NTLM homogènes ne provoquent pas le redémarrage du processus de négociation.

Journalisation

Http.sys offre désormais la journalisation W3C (World Wide Web Consortium) centralisée, dans laquelle un fichier journal unique stocke les entrées de tous les sites d'une application serveur, par exemple IIS. Dans le fichier journal centralisé, les champs d'ID de site identifient le site auquel les entrées du journal appartiennent.

Suivi ETW des événements HTTP

Le suivi des événements (ETW, Event Tracing for Windows) est une fonctionnalité de Windows permettant d'obtenir des informations sur les composants et les événements, généralement écrites dans des fichiers journaux. Les fichiers journaux ETW simplifient la résolution des problèmes. Le suivi permet également de diagnostiquer les problèmes de bout-en-bout, suivi dans lequel l'ID d'activité indique le flux des différentes opérations. Http.sys prend en charge le suivi pour les catégories suivantes :

• Demandes et réponses HTTP

• Transactions SSL et d'Authentification

• Événements de journalisation

• Connexions et timers de connexion

• Cache

• Installation de service ou d'application ; définition ou suppression de propriétés

• Catégorie basée sur les ID d'activité, y compris pour les autres composants prenant en charge ETW

Pour chaque catégorie de suivi, Http.sys prend en charge quatre niveaux d'informations : Message d'erreur, d'avertissement, d'informations et de commentaires. Le suivi Http.sys peut être utilisé comme un outil de résolution avancé pour obtenir des informations sur les processus et le comportement Http.sys.

Pour démarrer une session de suivi ETW pour Http.sys, procédez comme suit :

1. Créez un dossier pour stocker les fichiers de suivi. Depuis ce dossier, créez un fichier nommé Httptrace.txt contenant le texte suivant :
   "Microsoft-Windows-HttpService" 0xFFFF

2. Utilisez la commande suivante pour démarrer le suivi :
   logman start "http trace" -pf httptrace.txt -o httptrace.etl -ets

3. Suivez les étapes ou faites les tests dont vous devez effectuer le suivi.

Pour arrêter la session de suivi ETW pour Http.sys, utilisez la commande suivante :

logman stop "http trace" -ets

Un fichier de suivi Httptrace.etl doit à présent apparaître dans le dossier. Ce fichier peut être converti en un fichier de format XML, HTML ou CSV à l'aide de l'outil Tracerpt.exe. Par exemple, pour convertir le contenu du fichier Httptrace.etl en fichier CSV, utilisez la commande suivante :

tracerpt httptrace.etl -y -o httptrace.csv

Les fichiers CSV peuvent alors être visualisés dans un éditeur de texte ou une application de feuilles de calcul.

Commandes Netsh pour Http.sys

Vous pouvez à présent gérer les paramètres de configuration et contrôler les diagnostics pour Http.sys via un ensemble de commandes dans le contexte netsh http. Netsh est un outil de ligne de commande utilisé par de nombreux autres services de mise en réseau Windows, tels que IPsec, le routage et l'accès distant. Grâce à cette nouvelle prise en charge, vous pouvez effectuer les tâches suivantes dans une invite de commande Windows :

• Configurer des liaisons de certificats SSL, des réservations URL, des listes d'écoute IP ou des délais d'expiration globaux

• Supprimer ou vider le cache HTTP ou les mémoires tampon de journalisation

• Afficher le service Http.sys ou l'état de cache

Compteurs de performance pour Http.sys

Http.sys possède désormais les compteurs métriques de performances pour vous aider à surveiller, diagnostiquer et planifier les fonctions pour les serveurs Web :

• Compteurs de service HTTP

  • Nombre d'URI dans le cache, ajoutés depuis le démarrage, supprimés depuis le démarrage et nombre de vidages du cache

  • Opérations réussies dans le cache/seconde et Opérations non réussies dans le cache/seconde

• Groupes d'URL de service HTTP

  • Taux d'envoi des données, taux de réception des données, nombre d'octets transférés (envoyés et reçus)

  • Nombre maximal de connexions, taux de tentatives de connexion, taux de demandes GET et HEAD et nombre total de demandes

• Files d'attente de demandes de service HTTP

  • Nombre de demandes dans la file d'attente, âge des demandes les plus anciennes de la file d'attente

  • Taux des arrivées de demandes dans le file d'attente, taux de rejet, nombre total de demandes rejetées, taux d'opérations réussies dans le cache

Grâce à ces nouveaux compteurs de performance, les mesures peuvent être visualisées via le composant logiciel enfichable Diagnostic Console ou obtenues via les Performance Counters API (API des compteurs de performance, en anglais).

Améliorations de WinINet

Les améliorations apportées à l'API WinINet dans Windows Server 2008 et Windows Vista sont les suivantes :

• Prise en charge des littéraux IPv6 et des ID de portée

• Prise en charge de la décompression HTTP

• Prise en charge des noms de domaine internationalisé

• Prise en charge du suivi ETW

• Prise en charge IPv6 dans les scripts Web Proxy Auto-Discovery

Prise en charge des littéraux IPv6 et des ID de portée

WinINet prend désormais en charge RFC 2732, ainsi que l'utilisation des adresses littérales IPv6 dans les URL. Par exemple, pour se connecter à un serveur Web à l'adresse IPv6 2001:db8:100:2a5f::1, un utilisateur possédant un navigateur Web basé sur WinINet (comme Internet Explorer) peut saisir http://[2001:db8:100:2a5f::1] comme adresse. Bien que les utilisateurs classiques puissent ne pas utiliser les adresses littérales IPv6, la possibilité de spécifier l'adresse IPv6 dans l'URL est utile pour les développeurs d'applications, les testeurs de logiciels et les dépanneurs de réseau. WinINet prend également en charge le codage de l'ID de portée IPv6 (aussi appelé ID de zone) en tant que partie de l'adresse pour permettre aux utilisateurs de spécifier la portée de la destination IPv6. Pour plus d'informations, consultez IP Version 6 Support (Prise en charge de IPv6, en anglais).

Prise en charge de la décompression HTTP

Désormais, WinINet inclut une prise en charge intégrée pour les schémas de codage de contenu gzip et compressé. Le traitement de la décompression dans WinINet permettra de réduire les problèmes de compression/décompression entre les navigateurs Web et les serveurs Web tout en garantissant des gains de performance grâce à la réduction des durées de téléchargement des pages Web. Cela peut s'avérer extrêmement avantageux pour les utilisateurs dotés de connexion à faible bande passante, comme les utilisateurs d'Internet par accès à ligne commutée. Pour plus d'informations, consultez Content Encoding (Codage du contenu, en anglais).

Prise en charge des noms de domaine internationalisé

Désormais, WinINet est conforme à la norme IDN (Internationalized Domain Names) RFC 3490 relatives aux noms d'hôte lorsque vous utilisez les versions Unicode de l'API WinINet. Cette nouvelle prise en charge garantit que les applications fonctionnent correctement avec des noms de domaine comprenant des caractères non-ASCII sans nécessiter de prise en charge IDN par l'application Web, d'installation d'un plug-in tiers ou de nœuds intermédiaires dans un chemin de communication réseau. Pour plus d'informations, consultez IDN Support in WinINet (Prise en charge IDN dans WinINet, en anglais).

Prise en charge du suivi ETW

Désormais, WinINet prend en charge le suivi ETW qui permet au support technique et aux spécialistes de l'assistance d'obtenir des informations détaillées sur les processus et événements WinINet pour parvenir à déterminer la source des problèmes de protocole ou d'application. En incluant des identificateurs pour tous les événements WinINet, vous pouvez construire une chaîne des suivis ETW qui recouvre la pile entière de mise en réseau, les identificateurs étant utilisés pour associer les suivis des couches de mise en réseau adjacentes. Pour plus d'informations sur le suivi ETW, reportez-vous à la page Event Tracing (Suivi des événements, en anglais).

Prise en charge IPv6 dans les scripts Web Proxy Auto-Discovery

Les fonctions d'aide à la création de scripts WPAD (Web Proxy Auto-Discovery) exposées par WinINet ont été mises à jour afin d'inclure la prise en charge des adresses et des préfixes de sous-réseau IPv6. Les scripts WPAD qui utilisent les API d'aide Proxy dnsResolve(), myIpAddress(), isInNet() et isResolvable() peuvent désormais obtenir des informations IPv6 de WinINet. Pour plus d'informations sur WPAD, reportez-vous à la page WinHTTP AutoProxy Support (Prise en charge AutoProxy WinHTTP, en anglais).

Améliorations de WinHTTP

Les améliorations apportées à l'API WinHTTP 5.1 dans Windows Server 2008 et Windows Vista sont les suivantes :

• Prise en charge des téléchargements de données supérieurs à 4 Go

• Prise en charge du codage de transfert mémorisé en bloc

• Prise en charge de la récupération des listes d'émetteurs pour l'authentification client SSL (Secure Sockets Layer)

• Prise en charge des demandes de certificat client facultatives

• Prise en charge des indications sur les informations de connexion à 4 multiplets

• Nouveaux codes d'erreur pour l'authentification client SSL

• Prise en charge IPv6 dans les scripts WPAD

Prise en charge des téléchargements de données supérieurs à 4 Go

Désormais, WinHTTP permet aux applications d'ajouter un en-tête de longueur du contenu pour spécifier une longueur de données allant jusqu'à 2⁶⁴ octets.

Prise en charge du codage de transfert mémorisé en bloc

Désormais, WinHTTP permet aux applications de procéder au codage de transfert « mémorisé en bloc » pour leur données et de les envoyer via l'API WinHttpWriteData(). WinHTTP détectera la présence d'un en-tête de codage de transfert et effectuera des ajustements internes pour garantir que le transfert est compatible à la spécification HTTP 1.1.

Prise en charge de la récupération des listes d'émetteurs pour l'authentification client SSL (Secure Sockets Layer)

Désormais, WinHTTP permet à l'application de récupérer la liste d'émetteurs qui est associée à une stimulation d'authentification client. Une liste d'émetteurs spécifie une liste d'autorités de certification (CA) autorisée par le serveur à émettre des certificats client. Grâce à cette nouvelle prise en charge, une application WinHTTP peut déterminer le certificat client correct à utiliser pour l'authentification client.

Prise en charge des demandes de certificat client facultatives

Certains sites HTTP sécurisés demandent un certificat client mais celui-ci n'est pas obligatoire. Si le client ne possède pas de certificat pour répondre à la demande, le serveur peut utiliser d'autres types d'authentification HTTP ou permettre un accès anonyme. Pour que l'interfonctionnement soit pris en charge par les configurations du serveur, WinHTTP permet désormais aux application de fournir un certificat client NULL pour indiquer au serveur qu'il ne possède pas de certificat client pour l'authentification Secure Sockets Layer (SSL).

Prise en charge des indications sur les informations de connexion à 4 multiplets

À la fin d’une API WinHttpReceiveResponse(), WinHTTP permet désormais aux applications de demander l'IP/port source et l'IP/port de destination associés à la demande HTTP qui donne une réponse.

Nouveaux codes d'erreur pour l'authentification client SSL

WinHTTP inclut désormais des codes d'erreur pour les erreurs communes d'authentification client SSL :

• Le certificat client ne possède pas de clé privée associée, en général à cause de l'importation d'un certificat client sans clé privée.

• Le thread d'application qui appelle WinHttpSendRequest() ou WinHttpReceiveResponse() n'a pas le privilège d'accès à la clé privée associée au certificat client fourni. Vérifiez que la liste de contrôle d'accès (ACL) de la clé privée autorise l'accès par l'application.

Prise en charge IPv6 par les scripts WPAD

Les fonctions d'aide à la création de scripts WPAD exposées par WinHTTP ont été mises à jour afin d'inclure la prise en charge des adresses et des préfixes de sous-réseau IPv6. Les scripts WPAD qui utilisent les API d'aide Proxy dnsResolve(), myIpAddress(), isInNet() et isResolvable() peuvent désormais obtenir des informations IPv6 de WinHTTP. Pour plus d'informations sur WPAD, reportez-vous à la page WinHTTP AutoProxy Support (Prise en charge AutoProxy WinHTTP, en anglais).

Pour plus d'informations sur WinHTTP dans Windows Server 2008 et Windows Vista, reportez-vous aux pages What's New in Windows Longhorn (Nouveautés de Windows 2008, en anglais) et SSL in WinHTTP (SSL avec WinHTTP, en anglais).

Améliorations de Windows Sockets

La prise en charge de Windows Sockets (WinSock) a été mise à jour :

• Nouvelles API Winsock

• Suivi ETW des événements HTTP

• Améliorations du fournisseur de services en couche

• Prise en charge du module Network Diagnostics Framework

• Nouvelle API de sockets en mode noyau

Nouvelles API Winsock

Windows Server 2008 et Windows Vista incluent les nouvelles API Winsock suivantes :

• WSAConnectByName() Crée une connexion vers une destination spécifiée, à partir des noms d'hôte de destination. WSAConnectByName() récupère toutes les adresses de destination renvoyées par la résolution des noms et toutes les adresses locales, puis tente de les connecter en utilisant des paires d'adresses avec les chances de réussite les plus élevées. Un algorithme de paire optimal fourni par le transport détermine l'ordre des paires d'adresses. WSAConnectByName() assure l'établissement (si possible) d'une connexion, en une durée minimale.

• WSAConnectByList() Crée une connexion à la destination spécifiée, à partir de la liste des adresses IP de destination. WSAConnectByList récupère une liste de M adresses et de N adresses de l'ordinateur local, puis tente de les connecter en utilisant jusqu'à M x N combinaisons d'adresses avant un échec de connexion.

Suivi ETW des événements Winsock

• Les événements Winsock suivants sont des exemples d'événements dont le suivi peut être effectué par le suivi ETW :

• Socket creation

• Bind

• Connect

• Accept

• Send

• Recv

• Abort indications

Vous pouvez activer le suivi ETW des événements Winsock en utilisant :

• Le pare-feu de l'observateur d'événements

• Les outils Logman.exe et Tracerpt.exe

Pour activer le suivi ETW des événements Winsock à l'aide du composant logiciel enfichable Observateur d'événements, suivez la procédure suivante :

1. Exécutez l'outil Observateur d'événements dans le dossier Outils d'administration.

2. Dans l'arborescence du composant logiciel enfichable Observateur d'événements, ouvrez Journaux d'applications, puis Microsoft-Windows-Winsock-AFD.

3. Cliquez sur l'élément Winsock/AFD.

4. Dans le volet Action, cliquez sur Propriétés du journal.

5. Dans la boîte de dialogue Propriétés du journal, cliquez sur Activer la journalisation, puis sur OK.

Pour observer les événements, dans le volet Action, cliquez sur Rafraîchir. Pour désactiver la journalisation, décochez la case Activer la journalisation dans la boîte de dialogue Propriétés du journal pour l'élément Winsock/AFD.

Vous pouvez augmenter la taille du journal si vous souhaitez voir plus d'événements.

Pour activer le suivi ETW des événements Winsock à l'aide de l'outil Logman.exe, utilisez les commandes suivantes :

logman create trace afdlog –o LogFileLocation
logman update afdlog –p “Microsoft-Windows-Winsock-AFD”
logman start afdlog

Un fichier journal binaire sera créé dans LogFileLocation. Pour convertir le fichier binaire créé par l'outil Logman.exe en texte lisible, utilisez l'outil Tracerpt.exe. Par exemple, utilisez les commandes suivantes :

tracerpt.exe c:\afdlog.etl –o afdlog.txt

Pour arrêter la journalisation, utilisez les commandes suivantes :

logman stop afdlog

Améliorations du fournisseur de services en couche

La prise en charge du fournisseur de services en couche (LSP) Winsock dans Windows Server 2008 et Windows Vista contient les améliorations suivantes :

• L'installation et la suppression des LSP sont consignées dans le journal des événements système pour permettre de déterminer les applications qui installent des LSP et de dépanner les installations des LSP ayant échoué. Utilisez la commande netsh winsock audit trail pour afficher les événements consignés dans une fenêtre de la console.

• Une nouvelle API d'installation (WSCInstallProviderAndChains) permet aux éditeurs de logiciels d'installer un LSP dans le catalogue Winsock. L'installation manuelle d'un LSP peut être effectuée à l'aide d'une série de fonctions Winsock. Toutefois, si elle n'est pas correctement effectuée, le catalogue LSP Winsock peut être incohérent. Cette nouvelle API permet à un fournisseur de logiciels développant un LSP d'économiser des centaines de lignes de code.

• De nouveaux outils permettent de regrouper des LSP en catégories et de supprimer la plupart des LSP du chemin de traitement pour les services essentiels du système. Ces nouveaux outils offrent une meilleure stabilité à Windows en protégeant les services essentiels du système des LSP mal conçus.

• Un module de diagnostic spécifique à Winsock pour Network Diagnostics Framework permettra aux utilisateurs de réparer de manière sélective le catalogue Winsock en supprimant uniquement les LSP qui posent des problèmes.

  Pour plus d'informations sur Network Diagnostics Framework, reportez-vous à la page Network Diagnostics Framework in Windows Vista (Network Diagnostics Framework dans Windows Vista, en anglais).

Nouvelle API de sockets en mode noyau

L'architecture réseau de Windows Server 2008 et Windows Vista comprend une nouvelle interface appelée Winsock Kernel (WSK) . WSK est une nouvelle interface NPI (Network Programming Interface) en mode noyau indépendante du transport pour les clients TDI. En utilisant WSK, les modules logiciels en mode noyau peuvent effectuer une communication réseau à l'aide d'une sémantique de programme de type socket similaire à celle prise en charge dans l'API Windows Sockets 2 en mode utilisateur. Tandis que TDI est pris en charge dans Windows Vista pour compatibilité descendante, les clients TDI doivent être mis à jour pour pouvoir utiliser WSK afin d'obtenir les meilleures performances.

Pour plus d' informations, reportez-vous aux pages Intro to WSK (Présentation de WSK, en anglais) et Kernel mode vs. user mode (Mode noyau et mode utilisateur, en anglais). Pour des informations sur l'API WSK, reportez-vous à la page Windows Sockets in Kernel (Windows Sockets en mode noyau, en anglais).

NDIS 6.0

Windows Server 2008 et Windows Vista incluent NDIS (Network Driver Interface Specification) 6.0. NDIS spécifie une interface standard entre les pilotes réseau en mode noyau et le système d'exploitation. NDIS spécifie également une interface standard entre les pilotes réseau en couche, en faisant abstraction des pilotes de niveau inférieur qui gèrent le matériel à partir des pilotes de niveau supérieur, tels que les transports réseau. Pour plus d'informations sur NDIS 6.0, reportez-vous à la page NDIS - Network Driver Interface Specification (en anglais).

NDIS 6.0 inclut les fonctions suivantes :

• Nouvelle prise en charge du déchargement

• Prise en charge des pilotes de filtre léger

• Évolutivité côté réception

Nouvelle prise en charge du déchargement

NDIS 6.0 inclut les nouvelles prises en charge suivantes pour les fonctions de déchargement du traitement du trafic réseau vers les cartes réseau :

• Déchargement du trafic IPv6 NDIS 5.1 dans Windows Server 2003 et Windows XP prend déjà en charge le transport du traitement du trafic IPv4. Désormais, NDIS 6.0 prend en charge le déchargement du traitement du trafic IPv6.

• Prise en charge d'IPv6 par le déchargement des totaux de contrôle Le déchargement des calculs de totaux de contrôle pour le trafic IPv6 est désormais pris en charge.

• Large Send Offload version 2 NDIS 5.1 prend déjà en charge le LSO (Large Segment Offload), qui transporte la segmentation des données TCP pour les blocs de données dont la taille va jusqu'à 64 Kilooctets (Ko). Large Send Offload version 2 (LSOv2) dans NDIS 6.0 peut transporter la segmentation des données TCP pour les blocs de données dont la taille va jusqu'à 64 Kilooctets (Ko).

Prise en charge des pilotes de filtre léger

Dans NDIS 6.0, les pilotes de filtre intermédiaire ont été remplacés par des pilotes de filtre léger (LWF) qui sont une combinaison d'un pilote intermédiaire NDIS et d'un pilote miniport. Les pilotes LWF présentent les avantages suivants :

• Il n'est plus nécessaire d'écrire un protocole et un miniport séparés. Toutes ces fonctions sont contenues dans un seul pilote.

• Les pilotes LWF peuvent être ajoutés ou supprimés dans la pile sans casser les connexions existantes.

• Performances améliorées.

• Un mode de contournement permet au pilote LWF d'examiner uniquement les chemins de données et de contrôle sélectionnés.

Pacer.sys, précédemment appelé Psched.sys, est un exemple de pilote de filtre intermédiaire qui a été converti en pilote LWF. Il dispose des mêmes fonctionnalités, mais il profite des améliorations des performances disponibles avec NDIS 6.0. Pour plus d'informations (y compris des exemples), reportez-vous à la page Windows Driver Kit (Kit de pilotes Windows, en anglais).

Évolutivité côté réception

Dans l'architecture pour les ordinateurs multiprocesseurs fonctionnant sous Windows Server 2003 ou Windows XP, une carte réseau est associée à un seul processeur. Ce processeur doit gérer l'ensemble du trafic reçu par la carte réseau, même si d'autres processeurs sont disponibles. Avec cette architecture destinée des serveurs à fort volume, tels que des serveurs Web Internet ou des serveurs de fichiers d'entreprises, la quantité de trafic entrant et le nombre de connexions qui peuvent être traitées par le processeur associé à la carte réseau sont limités. Si le processeur associé à la carte réseau ne peut pas gérer assez rapidement le trafic entrant, la carte réseau ignore le trafic, ce qui entraîne des retransmissions et des diminutions de performances.

Dans Windows Server 2008 et Windows Vista, une carte réseau n'est pas associée à un seul processeur. Au lieu de cela, le traitement du trafic entrant est distribué aux processeurs de l'ordinateur. Cette nouvelle fonction, appelée Évolutivité côté réception, permet la réception d'un trafic beaucoup plus important par une carte réseau sur un serveur à fort volume. Un ordinateur multiprocesseur peut désormais gérer davantage de trafic entrant sans avoir à ajouter de serveurs, permettant ainsi de réduire les coûts. Pour profiter de cette nouvelle fonction, vous devez installer des cartes réseau compatibles avec l'évolutivité côté réception, pouvant bénéficier de la nouvelle architecture de Windows Server 2008 et Windows Vista. Les cartes réseau compatibles avec l'évolutivité côté réception sont disponibles chez de nombreux fournisseurs de cartes réseau.

Pour plus d'informations, reportez-vous à la page Scalable Networking with RSS (Réseau évolutif avec RSS, en anglais).

Détection réseau

La création d'applications pouvant automatiquement s'adapter aux modifications des conditions du réseau s'avère difficile pour les développeurs. Les API de détection réseau dans Windows Vista permettent aux applications d'effectuer les tâches suivantes :

• Inscription auprès de Windows Vista pour être informé des modifications apportées au réseau auquel est connecté l'ordinateur.

  Par exemple, un utilisateur met un ordinateur portable en mode veille au travail et l'active ensuite au niveau d'une zone d'accès sans fil. Lorsque les applications sont prévenues des modifications de réseau par Windows Vista, elles peuvent automatiquement se configurer ou se comporter différemment pour fournir une expérience utilisateur plus transparente.

• Requête auprès de Windows Vista des caractéristiques du réseau actuellement connecté pour déterminer les paramètres et le comportement des applications. Les caractéristiques comprennent :

  • Connectivité Un réseau peut être déconnecté, il peut fournir un accès au réseau local uniquement, ou bien fournir un accès au réseau local et à Internet.

  • Connexions L'ordinateur peut être connecté à un réseau par une ou plusieurs connexions (telles que des cartes réseau). Les API de détection réseau permettent aux applications de déterminer les connexions actuellement utilisées par Windows Vista pour se connecter au réseau.

  • Type d'emplacement (également appelé Catégorie) Une application peut se configurer automatiquement pour le type d'emplacement du réseau Windows Vista.

Les développeurs peuvent améliorer leurs applications Windows Vista pour les différents types de connectivités, de connexions et de types d'emplacements de réseau sans avoir à créer leur propres composants de détection réseau. Les API de détection réseau permettent aux développeurs de se concentrer sur les fonctions qui rendent la connectivité réseau transparente pour l'utilisateur au lieu de se concentrer sur les détails de la détermination réseau de niveau inférieur.

Pour plus d'informations sur les API de détection réseau, reportez-vous à la page Network Awareness (Détection réseau, en anglais).

Améliorations de la fonctionnalité de réseau Peer-to-Peer Windows

La fonctionnalité de réseau Peer-to-Peer Windows, apparue pour la première fois avec le Pack réseau avancé pour Windows XP, est une plate-forme de système d'exploitation et une API dans Windows Vista permettant le développement d'applications P2P. Windows Vista inclut les améliorations suivantes pour la fonctionnalité de réseau Peer-to-Peer Windows :

• Nouvelle API facile d'utilisation Les API permettant d'accéder aux fonctionnalités de réseau Peer-to-Peer Windows, telles que la résolution de noms, la création de groupes et la sécurité, ont été énormément simplifiées dans Windows Vista, facilitant ainsi la création d'applications P2P pour Windows.

• Nouvelle version de PNRP Windows Vista inclut la version 2 du protocole PNRP (Peer Name Resolution Protocol) dont l'évolutivité est supérieure et qui utilise une bande passante réseau moins importante. Avec PNRP v2 dans Windows Vista, les applications de réseau Peer-to-Peer Windows peuvent accéder aux fonctions de résolution et de publication de noms PNRP via une API PNRP simplifiée. Pour une résolution des noms PNRP beaucoup plus simple dans Windows Vista, les noms PNRP sont désormais intégrés dans la fonction de Windows Sockets getaddrinfo(). Pour utiliser PNRP afin de résoudre un nom en une adresse IPv6, les applications peuvent utiliser la fonction getaddrinfo() pour résoudre le nom de domaine pleinement qualifié (FQDN) nom.prnp.net, nom étant le nom d'homologue en cours de résolution. Le domaine pnrp.net est un domaine réservé dans Windows Vista pour la résolution de noms PNRP. Le protocole PNRP v2 est incompatible avec le protocole PNRP utilisé par les ordinateurs fonctionnant sous Windows XP. Microsoft est en train d'étudier le développement et la publication d'une mise à jour pour les composants de réseau Peer-to-Peer Windows dans Windows XP afin de prendre en charge le protocole PNRP v2.

• Voisinage immédiat Nouvelle fonctionnalité de réseau Peer-to-Peer Windows pour Windows Vista permettant aux utilisateurs de découvrir de façon dynamique d'autres utilisateurs sur le sous-réseau local, leurs applications compatibles avec le voisinage immédiat inscrites, et d'inviter facilement des utilisateurs à une activité de collaboration. L'invitation et son acceptation lancent une application sur l'ordinateur de l'utilisateur invité et les deux applications peuvent commencer à participer à une activité de collaboration, telle qu'une conversation, un partage de photos ou un jeu.

• Espace de collaboration Windows Windows Vista inclut l'espace de collaboration Windows, une nouvelle application P2P permettant aux utilisateurs de facilement mettre en place des réunions et de commencer la collaboration. L'espace de collaboration Windows utilise la fonctionnalité de réseau Peer-to-Peer Windows.

• Prise en charge de la configuration Netsh Vous pouvez désormais définir les paramètres de réseau Peer-to-Peer Windows à partir des commandes du contexte netsh p2p.

• Prise en charge de la configuration de stratégie de groupe Vous pouvez désormais définir les paramètres de réseau Peer-to-Peer Windows avec la stratégie de groupe à partir du nœud Configuration de l'ordinateur\Modèles administratifs\Réseau\Activer les services réseau homologue Microsoft.

Pare-feu Windows

Le nouveau pare-feu Windows de Windows Server 2008 et Windows Vista comporte les améliorations suivantes par rapport au pare-feu Windows actuel de Windows XP avec Service Pack 2 et Windows Server 2003 avec Service Pack 1 :

• Prise en charge du filtrage du trafic entrant et sortant

  Un administrateur réseau peut configurer le nouveau pare-feu Windows avec un ensemble d'exceptions afin de bloquer l'ensemble du trafic envoyé vers des ports spécifiques, tels que les ports bien connus utilisés par les logiciels antivirus, ou vers des adresses spécifiques avec du contenu sensible ou indésirable.

• Nouveau composant logiciel enfichable MMC (Microsoft Management Console) Pare-feu Windows avec sécurité avancée pour la configuration de l'interface graphique

  Le nouveau composant enfichable Pare-feu Windows avec sécurité avancée propose des assistants pour la configuration d'exceptions et de règles de sécurité. Pour la configuration de ligne de commande des paramètres avancés du nouveau pare-feu Windows, vous pouvez utiliser les commandes du contexte netsh advfirewall.

• Intégration du filtrage du pare-feu et des paramètres de protection IPSec

  Lors de l'utilisation du composant logiciel enfichable Pare-feu Windows avec sécurité avancée, vous pouvez à la fois configurer le filtrage du pare-feu et les règles pour le trafic avancé.

• Configuration avancée pour les exceptions

  Possibilité de configurer des exceptions de filtrage de pare-feu pour les adresses IP source et destination, le numéro de protocole IP, les ports TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) source et destination, tous les ports ou plusieurs ports TCP ou UDP, des types d'interfaces spécifiques, le trafic ICMP (Internet Control Message Protocol) et ICMPv6 (ICMP pour IPv6) par type et par code, et les services.

Pour plus d'informations sur ces améliorations, reportez-vous à la page Le nouveau pare-feu de Windows Vista et Windows Server 2008 Pour des informations supplémentaires, reportez-vous à la page Introduction to Windows Firewall with Advanced Security (Présentation du pare-feu Windows avec sécurité avancée, en anglais).

Améliorations IPsec

Windows Server 2008 et Windows Vista incluent les améliorations suivantes de IPsec (Internet Protocol security) :

• Configuration intégrée du pare-feu Windows et de IPsec

• Configuration simplifiée des stratégies IPsec

• Protection IPsec Client-to-DC

• Amélioration de l'équilibrage de charge et de la prise en charge des serveurs de clusters

• Amélioration de l'authentification IPsec

• Nouvelle prise en charge cryptographique

• Intégration à la protection d'accès au réseau

• Options de configuration supplémentaires pour une communication protégée

• Prise en charge IPv4 et IPv6 intégrée

• Événements étendus et compteurs de l'analyseur de performances

• Prise en charge de Network Diagnostics Framework

Configuration intégrée du pare-feu Windows et de IPsec

Dans Windows Server 2003 et Windows XP, le pare-feu Windows et IPsec étaient des composants et des services qui devaient être configurés séparément. Même si l'objectif du pare-feu Windows était de bloquer ou d'autoriser le trafic entrant, IPsec pouvait également être configuré pour bloquer ou autoriser le trafic entrant. Étant donné que le blocage et l'autorisation du trafic pouvaient être configurés par l'intermédiaire de deux services distincts, il était possible d'avoir des paramètres dupliqués ou contradictoires. De plus, le pare-feu Windows et IPsec prenaient en charge des options de configuration différentes pour spécifier le trafic entrant autorisé. Par exemple, le pare-feu Windows autorisait des exceptions (trafic entrant autorisé) en indiquant le nom de l'application, mais IPsec ne procédait pas de cette manière. IPsec autorisait des exceptions en fonction d'un numéro de protocole IP, mais pas le pare-feu Windows.

Dans Windows Server 2008 et Windows Vista, la configuration du pare-feu Windows et d'IPsec a été combinée dans un seul outil avec le nouveau composant logiciel enfichable Pare-feu Windows avec sécurité avancée, qui contrôle désormais à la fois les rôles traditionnels du pare-feu (blocage et autorisation du trafic entrant et sortant) et la protection du trafic avec IPsec. De plus, les commandes du contexte netsh advfirewall peuvent être utilisées pour la configuration de ligne de commande du comportement du pare-feu et d'IPsec. L'intégration du pare-feu Windows et de IPsec fournit un pare-feu d'authentification aux ordinateurs fonctionnant sous Windows Server 2008 ou Windows Vista.

Configuration simplifiée des stratégies IPsec

Dans Windows Server 2003 et Windows XP, la configuration de stratégies IPsec dans plusieurs scénarii, tels que l'Isolement de serveur et de domaine, consiste en un ensemble de règles pour protéger la plupart du trafic sur le réseau et en un autre ensemble de règles pour les exceptions de trafic protégé. Les exceptions sont nécessaires pour la communication non protégée avec les serveurs d'infrastructure réseau, tels que les serveurs DHCP et DNS, ainsi que les contrôleurs de domaine. Lorsqu'un ordinateur démarre, il doit pouvoir obtenir une adresse IP, utiliser le DNS pour trouver un contrôleur de domaine et se connecter ensuite à son domaine avant de pouvoir commencer à utiliser l'authentification Kerberos pour s'authentifier en tant qu'homologue IPsec. D'autres exceptions sont nécessaires pour la communication avec des nœuds de réseau qui ne sont pas compatibles avec IPsec. Dans certains cas, il existe des douzaines ou des centaines d'exceptions, ce qui rend difficile le déploiement de la protection IPsec sur un réseau d'entreprise ou sa maintenance sur le long terme.

IPsec dans Windows Server 2008 et Windows Vista fournit un comportement facultatif lors de la négociation de la protection IPsec. S'il est activé, lors de l'initialisation de la communication avec un autre nœud de réseau, un nœud IPsec fonctionnant sous Windows Server 2008 ou Windows Vista peut tenter de communiquer de façon transparente et de négocier la communication protégée en parallèle. Si l'homologue IPsec d'initialisation ne reçoit pas de réponse à la tentative de négociation initiale, la communication se poursuit de façon transparente. Si l'homologue IPsec d'initialisation reçoit une réponse à la tentative de négociation initiale, la communication de façon transparente est interrompue jusqu'à ce que la négociation puisse se terminer.

Avec ce comportement facultatif et la configuration recommandée de nécessiter la protection des communications initialisées entrantes et de demander la protection des communications initialisées sortantes, le nœud d'initialisation découvre si le nœud avec lequel il communique est compatible avec IPsec et se comporte en conséquence, simplifiant grandement la configuration des stratégies IPsec. Par exemple, le nœud d'initialisation n'a pas besoin d'un ensemble de filtres IPsec prédéfinis pour les exceptions pour l'ensemble des hôtes qui ne doivent pas ou qui ne peuvent pas protéger le trafic réseau avec IPsec. Le nœud d'initialisation tente en parallèle la communication protégée et non protégée ; si la communication protégée n'est pas possible, la communication non protégée est utilisée.

Le nouveau comportement de négociation améliore également les performances des connexions non protégées aux hôtes. Un nœud IPsec fonctionnant sous Windows Server 2003 ou Windows XP qui est configuré pour demander des communications protégées, mais qui permet également des communications non protégées (comportement appelé basculement en clair) enverrait les messages de négociation et attendrait ensuite une réponse. Le nœud d'initialisation attend jusqu'à 3 secondes avant de basculer en clair et de tenter des communications non protégées. Avec Windows Server 2008 et Windows Vista, il n'y a plus de délai de 3 secondes lors du basculement en clair, car les communications de façon transparente sont déjà en cours lorsque le nœud d'initialisation attend une réponse.

Protection IPsec Client-to-DC

Dans Windows Server 2003 et Windows XP, la recommandation actuelle provenant de Microsoft est de ne pas utiliser la protection IPsec pour protéger le trafic entre des contrôleurs de domaine et des ordinateurs membres (toutefois, Microsoft recommande de protéger le trafic entre des contrôleurs de domaine). Cela est dû au fait que la configuration des stratégies IPsec peut devenir très complexe en raison des différents types de trafics envoyés entre des membres et des contrôleurs de domaine. De plus, il existe un problème pour joindre un domaine. Si le contrôleur de domaine requiert un trafic protégé par IPsec provenant des ordinateurs qui doivent fournir des informations d'identification basées sur le domaine pour l'authentification, un ordinateur qui n'est pas membre du domaine ne peut pas contacter un contrôleur de domaine pour joindre le domaine.

Windows Server 2008 et Windows Vista prennent en charge la sécurisation du trafic entre des membres et des contrôleurs de domaine dans les modes de déploiement suivants :

• En raison du nouveau comportement de négociation, vous n'avez plus besoin de configurer des exclusions pour les contrôleurs de domaine, ce qui simplifie la stratégie IPsec et le déploiement de la protection IPsec dans un domaine.

• Vous pouvez configurer la stratégie IPsec dans le domaine pour demander un trafic protégé, sans toutefois l'exiger.

  Les contrôleurs de domaine protégeront la plupart du trafic avec les membres de domaine mais permettront du texte clair pour les jonctions de domaine et autres types de trafic.

• Vous pouvez configurer la stratégie IPsec pour qu'elle exige un trafic protégé pour les contrôleurs de domaine.

  Lorsqu'un ordinateur fonctionnant sous Windows Server 2008 ou Windows Vista tente de joindre le domaine, l'utilisateur est invité à saisir le nom d'utilisateur et le mot de passe du compte d'un utilisateur du domaine. IPsec avec le contrôleur de domaine est négocié avec les informations d'identification utilisateur NTLM v2 (Windows NT/LAN Manager version 2) pour une jonction de domaine protégé. Ce nouveau comportement est également disponible pour les ordinateurs membres du domaine fonctionnant sous Windows Vista ou Windows Server 2008 et pour les contrôleurs de domaine fonctionnant sous Windows Server 2008.

Amélioration de l'équilibrage de charge et de la prise en charge des serveurs de cluster

IPsec dans Windows Server 2003 prend en charge l'équilibrage de charge et les serveurs de cluster. Toutefois, les temps de basculement pour établir à nouveau la connectivité IPsec avec une adresse IP virtuelle de cluster sont les suivants :

• 3 à 6 secondes en général pour les déplacements administratifs des ressources mises en cluster.

• Jusqu'à deux minutes lorsqu'un nœud de cluster devient subitement indisponible ou qu'une autre perte soudaine de connexion se produit. La durée de deux minutes inclut une minute pour l'expiration de la durée d'inactivité d'IPsec et une minute pour renégocier les SA. La durée d'inactivité importante peut entraîner l'échec des connexions TCP actives au cluster.

Dans Windows Server 2008 et Windows Vista, la durée pour l'échec d'un nœud de cluster est sensiblement réduite. IPsec dans Windows Server 2008 et Windows Vista est intégré de façon plus étroite à la pile TCP/IP nouvelle génération. Plutôt que d'utiliser les expirations d'inactivité IPsec pour détecter la défaillance d'un nœud de cluster, IPsec dans Windows Server 2008 et Windows Vista surveille les connexions TCP afin de détecter les SA établies. Si la connexion TCP d'une SA établie commence à retransmettre des segments, IPsec renégocie les SA. Il en résulte le basculement rapide vers un nouveau nœud de cluster, généralement à temps pour éviter l'échec de l'application.

Amélioration de l'authentification IPsec

IPsec dans Windows Server 2003 et Windows XP prend en charge l'IKE (Internet Key Exchange) et trois méthodes d'authentification lors des négociations en mode principal : Kerberos (pour les membres des domaines Active Directory), certificats numériques et clé prépartagée. Pour toutes ces méthodes d'authentification, le processus d'authentification valide l'identité et la fiabilité d'un ordinateur, et non l'utilisateur de l'ordinateur. IKE tente uniquement une authentification unique à l'aide d'une méthode d'authentification unique.

Windows Server 2008 et Windows Vista prennent en charge les possibilités suivantes pour l'authentification IPsec :

• Capacité d'exiger que les homologues IPsec s'authentifient à l'aide d'un certificat de bon fonctionnement

  Un serveur de certificats de bon fonctionnement émet un certificat de bon fonctionnement lorsqu'un client de la protection d'accès au réseau prouve que son état de bon fonctionnement est conforme à la stratégie de bon fonctionnement actuelle. Pour plus d'informations sur la plate-forme de protection d'accès au réseau, reportez-vous à la section « Protection de l'accès réseau »de cet article.

• Capacité d'indiquer une authentification basée sur un utilisateur ou un bon fonctionnement au cours d'une deuxième authentification

  IPsec dans Windows Server 2008 et Windows Vista permet une deuxième authentification pour la communication protégée par IPsec. Avec une deuxième authentification, IPsec dans Windows Server 2008 et Windows Vista peut effectuer un niveau supplémentaire d'authentification. Les informations d'identification utilisées lors de la deuxième authentification peuvent être basées sur les éléments suivants :

  • Informations d'identification Kerberos du compte de l'utilisateur connecté

  • Informations d'identification NTLM v2 du compte de l'utilisateur connecté

  • Un certificat utilisateur

  • Un certificat de bon fonctionnement de l'ordinateur

  Une deuxième authentification peut être effectuée avec ou sans la première authentification. Par exemple, vous pouvez utiliser la première authentification et les informations d'identification Kerberos pour authentifier l'ordinateur, puis la deuxième authentification et un certificat de bon fonctionnement pour valider l'état de bon fonctionnement de l'ordinateur.

• Plusieurs méthodes d'authentification sont tentées

  Dans Windows Server 2003 et Windows XP, vous pouvez sélectionner plusieurs méthodes d'authentification dans un ordre de préférence pour l'authentification IPsec en mode principal. Toutefois, une seule méthode d'authentification est utilisée pour l'authentification. Si le processus d'authentification pour la méthode d'authentification négociée échoue, le mode principal échoue et la protection IPsec ne peut pas être effectuée. Lorsque vous sélectionnez plusieurs méthodes d'authentification pour des ordinateurs fonctionnant sous Windows Server 2008 ou Windows Vista, IPsec effectue plusieurs tentatives d'authentification afin de réaliser une authentification mutuelle. Par exemple, si vous indiquez que vous souhaitez effectuer une authentification à l'aide de Kerberos et des certificats de l'ordinateur avec une autorité de certification (CA) (dans cet ordre), l'homologue IPsec peut faire échouer l'authentification Kerberos et tenter ensuite une authentification par certificat.

Pour plus d'informations sur les améliorations de l'authentification IPsec, reportez-vous à la page AuthIP in Windows Vista (AuthIP dans Windows Vista, en anglais).

Nouvelle prise en charge cryptographique

En raison des exigences gouvernementales en matière de sécurité et des tendances dans le secteur de la sécurité à prendre en charge un cryptage plus puissant, Windows Server 2008 et Windows Vista prend en charge de nouveaux algorithmes de cryptage et de dérivation de clé.

Windows Server 2008 et Windows Vista prennent en charge les algorithmes supplémentaires suivants pour négocier les clés principales dérivées lors de la négociation en mode principal :

• Groupe Diffie-Hellman (DH) 19, qui est un algorithme à courbe elliptique utilisant un groupe de courbes aléatoires 256 bits (identificateur NIST P-256)

• Groupe DH 20, qui est un algorithme à courbe elliptique utilisant un groupe de courbes aléatoires 384 bits (identificateur NIST P-384)

Ces méthodes sont plus puissantes que les algorithmes DH-768, DH-1024 et DH-2048 pris en charge dans Windows Server 2003 et Windows XP avec Service Pack 2 et sont incluses dans Windows Server 2008 et Windows Vista. Pour plus d'informations sur ces algorithmes, reportez-vous au brouillon Internet intitulé « ECP Groups For IKE and IKEv2 » (Groupes ECP pour IKE et IKEv2, en anglais). Ces nouveaux algorithmes DH ne peuvent pas être utilisés pour la négociation en mode principal avec un ordinateur fonctionnant sous Windows Server 2003, Windows XP ou Windows 2000.

En plus des algorithmes DES (Data Encryption Standard) et 3DES (Triple-DES), Windows Server 2008 et Windows Vista prennent en charge les algorithmes supplémentaires suivants pour le cryptage des données :

• Le protocole AES (Advanced Encryption Standard) avec CBC (Cipher Block Chaining) et une clé 128 bits (AES 128)

• Le protocole AES avec CBC et une clé 192 bits (AES 192)

• Le protocole AES avec CBC et une clé 256 bits (AES 256)

Ces nouveaux algorithmes de cryptage ne peuvent pas être utilisés pour une association de sécurité avec un ordinateur fonctionnant sous Windows Server 2003, Windows XP ou Windows 2000.

Intégration à la protection d'accès au réseau

Avec la nouvelle plate-forme Protection de l’accès réseau, vous pouvez exiger que des nœuds IPsec effectuent une deuxième authentification avec un certificat de bon fonctionnement, vérifiant ainsi que le nœud IPsec satisfait les exigences de bon fonctionnement du système actuel. Un serveur de certificats de bon fonctionnement émet un certificat de bon fonctionnement après que l'état de bon fonctionnement d'un homologue IPsec a été évalué par un serveur NPS (Network Policy Server). Pour plus d'informations, reportez-vous à la section « Protection de l’accès réseau » de cet article.

Options de configuration supplémentaires pour une communication protégée

Lorsque vous configurez la stratégie IPsec avec le nouveau composant logiciel enfichable Pare-feu Windows avec sécurité avancée, vous pouvez configurer une communication protégée avec les nouveaux paramètres suivants :

• Par nom d'application Cela simplifie énormément la configuration du trafic protégé, car les ports utilisés par l'application n'ont pas besoin d'être configurés manuellement.

• Tous les ports ou plusieurs ports Vous pouvez désormais indiquer tous les ports TCP ou UDP ou plusieurs ports TCP ou UDP dans une liste de ports séparés par des virgules, ce qui simplifie la configuration.

• Pour toutes les adresses comprises dans une plage numérique Vous pouvez maintenant spécifier une plage d'adresses IP à l'aide d'une plage numérique, comme par exemple 10.1.17.23 à 10.1.17.219.

• Pour toutes les adresses du sous-réseau local Un jeu d'adresses prédéfinies qui sont mappées de manière dynamique vers le jeu d'adresses définies par votre adresse IPv4 et le masque de sous-réseau ou par votre préfixe de sous-réseau local IPv6.

• Pour tous les adaptateurs sans-fil Vous pouvez protéger le trafic en fonction du type d'interface, laquelle inclut désormais un accès sans fil en plus du réseau local et de l'accès distant.

• Par un compte d'ordinateur ou d'utilisateur Active Directory Vous pouvez spécifier la liste des comptes d'ordinateur ou d'utilisateur ou des groupes autorisés à initier une communication protégée. Par exemple, vous pourrez ainsi spécifier que le trafic vers les serveurs spécifiques comportant des données sensibles doit être protégé et peut uniquement provenir de comptes utilisateur qui appartiennent à des groupes de sécurité Active Directory spécifiques.

• Par la valeur Type ou Code d'ICMP ou ICMPv6 Vous pouvez spécifier des messages ICMP ou ICMPv6 en indiquant leurs valeurs de champ Type et Code.

• Pour les services Vous pouvez spécifier que l'exception s'applique à n'importe quel processus, uniquement aux services, à un service spécifique reconnaissable à son nom, ou saisir le nom court du service.

Prise en charge IPv4 et IPv6 intégrée

La prise en charge IPsec pour le trafic IPv6 sur Windows XP et Windows Server 2003 est limitée. L'IKE (Internet Key Exchange) et le cryptage des données ne sont pas pris en charge. Les stratégies de sécurité IPsec, les associations de sécurité et les clés doivent être configurées à l'aide de fichiers texte et activées via un outil de ligne de commande, IPsec6.exe.

Dans Windows Server 2008 et Windows Vista, la prise en charge d'IPsec pour le trafic IPv6 est la même que pour IPv4, notamment en ce qui concerne la prise en charge d'IKE et du cryptage des données. Les paramètres de stratégie pour les trafics IPv4 et IPv6 sont configurés de manière identique à l'aide des composants logiciels enfichables Pare-feu Windows avec sécurité avancée ou Stratégies de sécurité IP .

Événements étendus et compteurs de l'analyseur de performances

Windows Server 2008 et Windows Vista incluent 15 nouveaux événements spécifiques à l'audit IPsec et le texte de 25 événements existants a été mis à jour avec des informations plus utiles. Ces améliorations vous permettront de résoudre les négociations IPsec en échec sans devoir activer les fonctionnalités de connexion avancées Oakley .

Windows Server 2008 et Windows Vista incluent également des compteurs de performances IPsec pour permettre l'identification des performances et des problèmes de réseau sur le trafic protégé par IPsec.

Prise en charge de Network Diagnostics Framework

Network Diagnostics Framework est une architecture extensible qui permet aux utilisateurs de résoudre les problèmes liés aux connexions réseau. Lors de l'échec d'une négociation IPsec, Network Diagnostics Framework demande à l'utilisateur s'il souhaite identifier et résoudre le problème. La prise en charge d'IPsec pour Network Diagnostics Framework tente ensuite de découvrir la source de l'échec de la connexion pour résoudre le problème automatiquement ou, en fonction de la sécurité, demande à l'utilisateur d'apporter les modifications appropriées.

Pour plus d'informations sur Network Diagnostics Framework, reportez-vous à la page Network Diagnostics Framework in Windows Vista (Network Diagnostics Framework dans Windows Vista, en anglais).

Haut de page

Connexions sans fil et filaire basée sur IEEE 802.1X

Windows Server 2008 et Windows Vista incluent de nombreuses améliorations qui permettent de prendre en charge les réseaux sans fil IEEE 802.11 et les réseaux qui utilisent des commutateurs d'authentification.

Changements et améliorations du mode sans fil IEEE 802.11

Windows Server 2008 et Windows Vista incluent les modifications suivantes et les améliorations à des fins de prise en charge du réseau sans fil IEEE 802.11 :

• Architecture Wi-Fi native

• Améliorations de l'interface utilisateur pour les connexions sans fil

• Améliorations des stratégies de groupe sans fil

• Modifications de la configuration automatique sans fil

• Prise en charge WPA2

• Intégration de la protection de l'accès réseau lors de l'authentification 802.1X

• Infrastructure EAPHost

• Diagnostics sans fil 802.11

• Prise en charge de la ligne de commande pour la configuration des paramètres sans fil

• NLA (Network Location Awareness) et profils de réseau

• Amélioration de la pile TCP/IP nouvelle génération pour les environnements sans fil

• Authentification unique

Architecture Wi-Fi native

Sur Windows Server 2003 et Windows XP, l'infrastructure logicielle qui prend en charge les connexions sans fil a été conçue pour émuler une connexion Ethernet et ne peut être étendue que par la prise en charge de types EAP supplémentaires pour l'authentification IEEE 802.1X. Sur Windows Server 2008 et Windows Vista, l'infrastructure logicielle des connexions 802.11 sans fil, appelée architecture Wi-Fi native, a été reconçue dans le but suivant :

• IEEE 802.11 est maintenant représenté dans Windows sous la forme d'un type de support distinct de IEEE 802.3. Les fournisseurs en matériel indépendants (IHV) disposent ainsi de davantage de flexibilité dans la prise en charge de fonctions avancées des réseaux IEEE 802.11, comme par exemple, une taille de frame supérieure à Ethernet.

• De nouveaux composants de l'architecture Wi-Fi native assurent l'authentification, l'autorisation et la gestion de connexions 802.11, réduisant ainsi la charge sur les IHV pour leur permettre d'incorporer ces fonctions dans leurs pilotes de carte réseau sans fil. Cela facilite le développement de pilotes de carte réseau sans fil. Sur Windows Server 2008 et Windows Vista, les IHV doivent développer un pilote miniport NDIS 6.0 plus petit qui expose une interface 802.11 native sur le bord supérieur.

• L'architecture Wi-Fi native prend en charge les API pour conférer aux ISV et aux IHV la possibilité d'étendre le client sans fil intégré afin qu'il accepte des services sans fil et des fonctionnalités personnalisées supplémentaires. Des composants extensibles écrits par les ISV et les IHV peuvent également fournir des boîtes de dialogue et des assistants de configuration personnalisés.

Améliorations de l'interface utilisateur pour les connexions sans fil

Voici les améliorations apportées à l'interface utilisateur en termes de connexion sans fil :

• Configuration sans fil intégrée dans le nouveau réseau et centre de partage La connectivité aux réseaux sans fil a été intégrée au nouveau réseau et centre de partage dans Windows Vista, plutôt qu'à partir des propriétés d'une carte réseau sans fil. À partir du réseau et du centre de partage, vous pouvez vous connecter à des réseaux sans fil, définir un réseau sans fil qui utilise un point d'accès sans fil ou un réseau sans fil ad hoc, puis gérer vos réseaux sans fil.

• Les réseaux sans fil peuvent être configurés globalement ou individuellement Dans le dossier Manage Wireless Networks (Gestion des réseaux sans fil) (disponible depuis le réseau et le centre de partage), vous pouvez désormais spécifier le type de profil du réseau sans fil. Vous pouvez ainsi indiquer que les nouveaux réseaux sans fil (connus sous le nom de profils) s'appliquent à tous les utilisateurs de l'ordinateur ou peuvent être configurés pour s'appliquer à des utilisateurs spécifiques. Les profils individuels sont connectés uniquement lorsque l'utilisateur auquel le profil s'applique se connecte sur l'ordinateur. Les profils individuels sont déconnectés lorsque l'utilisateur se déconnecte ou change de session.

• IU sans fil extensible Comme décrit dans la section « Architecture Wi-Fi native » de cet article, des assistants ou boîtes de dialogue de configuration sans fil personnalisés peuvent être écrits et ajoutés au client sans fil Windows intégré, permettant ainsi la configuration de fonctionnalités sans fil personnalisées des ISV ou IHV .

• Les réseaux sans fil de non diffusion peuvent être configurés Un réseau sans fil de non diffusion (également connu sous le nom de réseau sans fil masqué) n'indique pas son nom de réseau, également appelé identificateur SSID (Service Set Identifier). Un point d'accès sans fil d'un réseau sans fil de non diffusion peut être configuré pour envoyer des trames de signalisation d'incidents avec un identificateur SSID de valeur NULL. Voilà en quoi consiste l'utilisation des identificateurs SSID de non diffusion. Dans Windows Server 2003 et Windows XP, vous ne pouvez pas configurer de réseau sans fil de non diffusion préféré, ce qui peut parfois conduire à des confusions lors d'une connexion automatique à des réseaux sans fil préférés, dont certains sont des réseaux de non diffusion. Dans Windows Server 2008 et Windows Vista, vous pouvez configurer un réseau sans fil préféré comme réseau de non diffusion.

• Les réseaux sans fil de non diffusion apparaissent comme « Réseau sans nom » Dans la liste des réseaux sans fil disponibles dans l'assistant de connexion au réseau, des réseaux de non diffusion apparaissent avec le nom « Réseau sans nom »). Lorsque vous vous connectez au réseau sans fil de non diffusion, vous recevrez une invite vous demandant de saisir le nom du réseau sans fil de non diffusion.

• Envoi des invites à l'utilisateur lors de la connexion à un réseau sans fil non sécurisé En raison des risques associés à la communication sur des réseaux sans fil non sécurisés, Windows Server 2008 et Windows Vista enverront une invite à l'utilisateur au moment de sa connexion à un réseau sans fil non sécurisé permettant de confirmer la tentative de connexion.

• L'assistant de connexion au réseau répertorie les méthodes de sécurité prises en charge par la carte réseau sans fil L'assistant de connexion au réseau de Windows Server 2008 et Windows Vista récupère les fonctionnalités de sécurité de la carte réseau sans fil et permet à l'utilisateur de sélectionner la méthode de sécurité la plus élevée. Par exemple, si une carte réseau sans fil prend en charge les clés WEP (Wired Equivalent Privacy) et WPA (Wi-Fi Protected Access), l'assistant de connexion au réseau permet à l'utilisateur de sélectionner la méthode de sécurité WPA ou WEP.

Pour plus d'informations sur la nouvelle configuration de l'IU sans fil, reportez-vous à Connecting to Wireless Networks with Windows Vista (Connexion aux réseaux sans fil avec Windows Vista, en anglais).

Améliorations des stratégies de groupe sans fil

Dans Windows Server 2008 et Windows Vista, les paramètres de stratégie de groupe sans fil, situés dans le nœud Configuration de l'ordinateur\Paramètres Windows\Paramètres de sécurité du composant de stratégie de groupe, incluent les améliorations suivantes :

• Options d'authentification WPA2 Windows XP avec la mise à jour WPA2/WPS IE pour Windows XP Service Pack 2 est disponible prend en charge la configuration des options d'authentification WPA2 ; WPA2 (pour WPA2 Entreprise) et WPA2-PSK (pour WPA2 Personnel). Toutefois, les stratégies de réseau sans fil (IEEE 802.11) dans Windows Server 2003 avec Service Pack 1 ne prennent pas en charge la configuration centralisée des options d'authentification WPA2. Les paramètres de stratégie de réseau sans fil dans Windows Server “Longhorn” permettent de configurer les options d'authentification WPA2. Microsoft est en train d'étudier la prise en charge d'options d'authentification WPA2 dans les paramètres de stratégie de groupe pour une prochaine mise à jour de Windows XP.

• Listes des noms de réseau sans fil autorisés et refusés Le client sans fil dans Windows Server 2003 et Windows XP demande à l'utilisateur de se connecter pour savoir si des réseaux sans fil préférés ont été détectés et si certaines des connexions aux réseaux sans fil préférés détectés ont abouti. Des ordinateurs de client sans fil exécutant Windows Server 2003 ou Windows XP ne peuvent être configurés pour demander à l'utilisateur de se connecter uniquement aux réseaux sans fil spécifiques ou de ne jamais demander à l'utilisateur de se connecter aux réseaux sans fil spécifiques. Les paramètres de stratégie de groupe dans Windows Server 2008 et Windows Vista permettent de configurer des listes de noms de réseaux sans fil autorisés et refusés. La liste des noms autorisés vous permet de spécifier l'ensemble des réseaux sans fil par nom (SSID), auquel le client sans fil Windows Server 2008 ou Windows Vista a le droit d'accéder. Elle est utile pour les administrateurs réseau qui souhaitent qu'un ordinateur portable de l'organisation se connecte à un ensemble de réseaux sans fil, lequel peut inclure le réseau sans fil de l'organisation et les fournisseurs d'accès Internet sans fil. La liste des noms refusés permet de spécifier l'ensemble des réseaux sans fil par nom, auquel le client sans fil n'a pas le droit de se connecter. Elle est utile pour empêcher des ordinateurs portables gérés de se connecter à d'autres réseaux sans fil parmi ceux de l'organisation (par exemple, lorsqu'une organisation occupe l'étage d'un bâtiment et que d'autres réseaux sans fil d'une autre organisation existent à des étages attenants), ou pour empêcher des ordinateurs portables gérés de se connecter à des réseaux sans fil non sécurisés connus.

• Paramètres supplémentaires de réseau sans fil préféré Les paramètres de stratégie de groupe sans fil dans Windows Server 2008 permettent de configurer les réseaux sans fil préférés suivants :

  • Paramètres itinérants rapides Les paramètres itinérants rapides représentent une fonction avancée des réseaux sans fil WPA2 permettant aux clients sans fil de passer plus rapidement d'un AP sans fil à un autre à l'aide d'une pré-authentification et d'une clé PMK (pairwise master key) en cache. Dans la mise à jour WPA2/WPS IE pour Windows XP Service Pack 2, vous pouvez contrôler la pré-authentification et le comportement de la clé PMK en cache via des paramètres de registre. Windows Server 2008 vous permet de configurer ce comportement via des paramètres de stratégie de groupe sans fil.

  • Réseaux sans fil de non diffusion Comme décrit dans la section « Améliorations de l'interface utilisateur pour les connexions sans fil » de cet article, vous pouvez configurer en local les réseaux sans fil préférés comme réseaux sans fil de non diffusion. Windows Server 2008 vous permet maintenant de configurer des réseaux sans fil préférés dans des paramètres de stratégie de groupe sans fil comme des réseaux de non diffusion.

  • Connexion automatique ou manuelle Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, Windows Server 2008 et Windows Vista vous permettent de configurer un réseau sans fil préféré pour une connexion automatique (par défaut) ou manuelle dans l'onglet Connexion des propriétés du réseau sans fil préféré. À l'aide des paramètres de stratégie de groupe sans fil dans Windows Server 2008, vous pouvez maintenant configurer des réseaux sans fil préférés dans le cadre d'une connexion automatique ou manuelle.

Pour plus d'informations sur l'extension du schéma d'un environnement Windows Server 2003 Active Directory pour prendre en charge les améliorations de stratégie de groupe sans fil et filaire Windows Vista, reportez-vous à Extensions de Schema Active Directory pour Windows Vista et Améliorations des stratégies de groupe sans fil.

Modifications de la configuration automatique sans fil

La configuration automatique sans fil est un service qui sélectionne de manière dynamique le réseau sans fil auquel l'ordinateur se connectera automatiquement, en fonction de vos préférences ou des paramètres par défaut. Elle inclut automatiquement la sélection et la connexion d'un réseau sans fil à la préférence plus élevée lorsqu'elle est disponible. Windows Server 2008 et Windows Vista incluent les modifications suivantes à la configuration automatique sans fil :

• Modification du comportement lorsque aucun réseau sans fil préféré n'est disponible

  Dans Windows XP et Windows Server 2003, si un réseau sans fil préféré n'a pas pu être connecté et que le client sans fil est configuré de sorte à empêcher toute connexion automatique au réseaux sans fil qui ne sont pas contenus dans la liste des réseaux préférés (par défaut), la configuration automatique sans fil crée de manière aléatoire un nom pour le réseau sans fil et place la carte réseau sans fil en mode infrastructure. Toutefois, le réseau sans fil aléatoire ne dispose pas d'une configuration de sécurité, donnant la possibilité à un utilisateur malveillant de se connecter au client sans fil avec le nom de réseau sans fil aléatoire.

  Dans Windows Server 2008 et Windows Vista, la configuration automatique sans fil configure la carte réseau sans fil avec un nom aléatoire et une configuration de sécurité composée d'une clé de cryptage aléatoire 128 bits et de la méthode de cryptage le plus élevé prise en charge par la carte réseau sans fil. Ce nouveau comportement permet d'empêcher tout utilisateur malveillant de se connecter au client sans fil avec un nom de réseau sans fil aléatoire.

• Nouvelle prise en charge de réseaux sans fil de non diffusion

  Dans Windows XP et Windows Server 2003, la configuration automatique sans fil tente d'associer les réseaux sans fil préférés configurés avec des réseaux sans fil qui diffusent leur nom de réseau. Si aucun des réseaux disponibles ne correspond à un réseau sans fil préféré, la configuration automatique sans fil envoie alors des demandes d'analyse pour déterminer si les réseaux préférés répertoriés dans la liste sont des réseaux de non diffusion. Les réseaux diffusés seront alors connectés avant les réseaux de non diffusion, même si un réseau de non diffusion se situe plus haut dans la liste des réseaux préférés qu'un réseau diffusé. De plus, un client sans fil Windows XP ou Windows Server 2003 indique dans sa liste de réseaux sans fil préférés le moment où il envoie des demandes d'analyse.

  Dans Windows Server 2008 et Windows Vista, vous pouvez configurer des réseaux sans fil en tant que diffusés (le nom de réseau sans fil est inclus dans les trames de signalisation d'incidents envoyées par l'AP sans fil) ou de non diffusion (la trame de signalisation d'incidents présente un nom de réseau de valeur NULL). La configuration automatique sans fil tente maintenant de connecter les réseaux sans fil dans l'ordre de la liste, sans tenir compte de savoir s'ils sont diffusés ou non. Étant donné que les réseaux sans fil sont maintenant explicitement marqués comme diffusés ou non diffusés, les clients sans fil Windows Server 2008 ou Windows Vista envoient uniquement des demandes d'analyse pour les réseaux sans fil de non diffusion.

Prise en charge de WPA2

Windows Server 2008 et Windows Vista incluent une prise en charge intégrée pour configurer des options d'authentification WPA2 avec le profil standard (réseaux sans fil préférés configurés en local) et le profil de domaine avec des paramètres de stratégie de groupe. WPA2 est une certification de produit disponible via l'alliance Wi-Fi qui certifie si un équipement sans fil est compatible avec la norme IEEE 802.11i. WPA2 dans Windows Server 2008 et Windows Vista prend en charge les modes de fonctionnement Entreprise (authentification IEEE 802.1X) et Personnel (authentification par clé partagée).

Windows Server 2008 et Windows Vista incluent également la prise en charge de WPA2 pour un réseau sans fil en mode ad hoc (un réseau sans fil entre les clients sans fil qui n'utilise pas de point d'accès sans fil).

Intégration de la protection de l'accès réseau lors de l'authentification 802.1X

Les connexions WPA2-Entreprise, WPA-Entreprise et WEP dynamiques qui utilisent l'authentification 802.1X peuvent exploiter la plate-forme de protection d'accès au réseau pour empêcher des clients sans fil ne respectant les exigences de sécurité du système d'avoir un accès illimité à l'intranet. Pour plus d'informations sur la plate-forme de protection d'accès au réseau, reportez-vous à la section « Protection de l'accès réseau » de cet article.

Infrastructure EAPHost

Pour faciliter le développement des méthodes d'authentification EAP (Extensible authentification Protocol) pour des connexions sans fil authentifiées IEEE 802.1X, Windows Server 2008 et Windows Vista prennent en charge la nouvelle infrastructure EAPHost. Pour plus d'informations, reportez-vous à la section « Architecture EAPHost » de cet article.

Nouvelle méthode d'authentification EAP par défaut

Dans Windows Server 2003 et Windows XP, la méthode d'authentification EAP par défaut pour des connexions authentifiées 802.1X est la norme EAP-TLS (Transport Layer Security). Bien que le moyen d'authentification le plus sûr utilise une authentification mutuelle avec des certificats numériques, EAP-TLS nécessite une infrastructure de clé publique (PKI) pour distribuer, révoquer et renouveler des certificats utilisateur et ordinateur.

Dans certains cas, les organisations souhaitent exploiter l'infrastructure d'authentification basée sur le nom et le mot de passe du compte déjà existante dans Active Directory. Par conséquent, dans Windows Server 2008 et Windows Vista, la méthode d'authentification EAP par défaut pour les connexions sans fil authentifiées 802.1X a été changée en protocole d'authentification Protected EAP-Microsoft Challenge Handshake version 2 (PEAP-MS-CHAP v2). PEAP-MS-CHAP v2 est une méthode d'authentification 802.1X basée sur un mot de passe pour les connexions sans fil et nécessite l'installation de certificats d'ordinateur uniquement sur les serveurs RADIUS (Remote authentification Dial-In User Service). Pour plus d'informations sur PEAP-MS-CHAP v2, reportez-vous à la page PEAP with MS-CHAP Version 2 for Secure Password-based Wireless Access (EAP avec MS-CHAP Version 2 pour un accès sécurisé sans fil basé sur un mot de passe, en anglais).

Prise en charge de diagnostics pour les connexions sans fil

Le dépannage de connexions sans fil échouées, bien qu'amélioré dans Windows XP Service Pack 2 et Windows Server 2003 Service Pack 1, peut encore s'avérer difficile. Sur Windows Server 2008 et Windows Vista, le dépannage de connexions sans fil est plus facile à exécuter grâce aux fonctionnalités suivantes :

• Les connexions sans fil prennent en charge le nouveau Network Diagnostics Framework Network Diagnostics Framework est une architecture extensible qui permet aux utilisateurs de récupérer et de résoudre des problèmes liés aux connexions réseau. Lors de l'échec d'une connexion sans fil, Network Diagnostics Framework demande à l'utilisateur s'il souhaite identifier et résoudre le problème. La prise en charge sans fil pour Network Diagnostics Framework tente ensuite de découvrir la source de l'échec de la connexion pour résoudre le problème automatiquement ou, selon les considération sur la sécurité, pour demander à l'utilisateur d'apporter les modifications appropriées.

  Pour plus d'informations sur Network Diagnostics Framework, reportez-vous à la page Network Diagnostics Framework in Windows Vista (Network Diagnostics Framework dans Windows Vista, en anglais).

• De nouvelles informations enregistrées dans le journal d'événements Windows Lors d'une tentative de connexion sans fil, les composants sans fil de Windows Server 2008 et Windows Vista enregistrent les informations détaillées relatives à cette tentative dans le journal d'événements Windows. Ces enregistrements peuvent être utilisés par des professionnels du support au sein d'une organisation afin de continuer le dépassage lorsque les diagnostics sans fil ne peuvent pas résoudre le problème, ou lorsqu'ils peuvent résoudre le problème mais que la solution ne peut pas provenir d'une modification des paramètres du client sans fil. Les informations contenues dans le journal d'événements Windows peuvent raccourcir le temps nécessaire à la résolution des problèmes de connexion sans fil. En outre, ces entrées de journal d'événements peuvent être collectées automatiquement par l'administrateur réseau à l'aide du Microsoft Operations Manager ou d'autres types d'outils de gestion centralisés, puis analysées pour voir les tendances et les modifications de la conception de l'infrastructure sans fil.

• Les informations peuvent être envoyées à Microsoft à des fins d'analyse et d'améliorations Les utilisateurs qui rencontrent des problèmes de connexion sans fil recevront une invite leur demandant d'envoyer les informations de connexion à Microsoft à des fins d'analyse via l'infrastructure de rapport d'erreur Windows. De plus, des diagnostics réussis peuvent être envoyés à Microsoft via l'infrastructure de mesure de la qualité logicielle, également connue sous le nom de Programme d'amélioration du produit dans Windows XP. Dans les deux cas, seules les informations de diagnostic de réseau sans fil sont envoyées (aucune information personnelle relative à l'ordinateur ou à l'utilisateur). Microsoft utilise ces informations pour identifier les causes liées aux échecs de connexion sans fil, identifier les nouveaux problèmes de connexion sans fil et leurs causes, puis entreprendre les actions appropriées pour améliorer le logiciel client sans fil dans Windows ou travailler avec des fournisseurs sans fil pour améliorer des produits matériels sans fil.

Interface de ligne de commande pour la configuration des paramètres sans fil

Windows Server 2003 ou Windows XP ne disposent pas d'interface de ligne de commande qui permet la configuration des paramètres sans fil disponibles à partir des boîtes de dialogue sans fil dans le dossier Network Connections (Connexions réseau) ou via les paramètres de stratégie de groupe de réseau sans fil (IEEE 802.11). La configuration de ligne de commande des paramètres sans fil peut contribuer au développement de réseaux sans fil dans les situations suivantes :

• Un support de script automatisé pour des paramètres sans fil sans stratégie de groupe Les paramètres de stratégie de groupe de réseau sans fil (IEEE 802.11) s'appliquent uniquement dans un domaine Active Directory. Dans un environnement sans Active Directory ou infrastructure de stratégie de groupe, un script qui automatise la configuration de connexions sans fil peut être exécuté manuellement ou automatiquement (par exemple, une partie du script de connexion).

• Amorce d'un client sans fil sur le réseau sans fil protégé de l'organisation Un ordinateur client sans fil qui n'appartient pas au domaine ne peut pas se connecter au réseau sans fil protégé de l'organisation. De plus, un ordinateur ne peut pas joindre le domaine tant qu'il n'est pas connecté au réseau sans fil sécurisé de l'organisation. Un script de ligne de commande propose une méthode de connexion au réseau sans fil sécurisé de l'organisation pour joindre le domaine.

  Pour plus informations sur l'appartenance d'un client sans fil Windows Vista à un domaine, reportez-vous à la section Joindre un client Windows Vista sans fil à un domaine.

Dans Windows Server 2008 et Windows Vista, vous pouvez utiliser les commandes Netsh dans le contexte netsh wlan pour effectuer les opérations suivantes :

• Configurer tous les paramètres de client sans fil dans un profil nommé, y compris les paramètres généraux (les types de réseaux sans fil auxquels accéder), les paramètres 802.11 (identificateur SSID, type d'authentification, type de données de cryptage) et les paramètres d'authentification 802.1X (types EAP et leur configuration).

• Spécifier la liste de noms de réseau sans fil autorisés et refusés.

• Spécifier l'ordre des réseaux sans fil préférés.

• Afficher une configuration de client sans fil.

• Supprimer la configuration sans fil d'un client sans fil.

• Migrer les paramètres de configuration sans fil entre les clients sans fil.

NLA (Network Location Awareness) et profils de réseau

Plusieurs applications n'ont pas la connaissance de réseau, ce qui entraîne la confusion du client et une charge pour le développeur. Par exemple, une application ne peut ajuster automatiquement son comportement en fonction du réseau et des conditions actuellement attachés. Les utilisateurs sont susceptibles de devoir reconfigurer des paramètres d'application en fonction du réseau auquel ils sont associés (le réseau privé de leur employeur, le réseau personnel de l'utilisateur, Internet). Pour supprimer la charge de configuration, les développeurs d'applications peuvent utiliser des API Windows de niveau bas, des structures de données et probablement même l'analyse du réseau pour déterminer le réseau actuel et ajuster le comportement de leur application en conséquence.

Pour fournir une infrastructure de système d'exploitation afin d'autoriser les développeurs d'application à reconfigurer plus facilement le comportement de l'application en fonction du réseau actuellement associé, les API de détection réseau de Windows Server « Longhorn » et Windows Vista permettent aux applications d'accéder aux informations de réseau et de s'adapter facilement et efficacement à ces environnements en évolution Les API de détection réseau permettent aux applications d'obtenir des informations de réseau à jour et une notification de changement d'emplacement.

Pour plus d'informations sur les API de détection réseau, reportez-vous à la page Network Awareness (Détection réseau, en anglais).

Amélioration de la pile TCP/IP nouvelle génération pour les environnements sans fil

Comme décrit dans la section « Améliorations pour les environnements à forte perte » de cet article, la pile TCP/IP nouvelle génération inclut la prise en charge de nouveaux algorithmes TCP qui optimisent le débit en récupérant des pertes de paquets uniques et multiples et en supprimant les fausses retransmissions, ce qui améliore les performances dans les environnements de réseau sans fil.

Authentification unique

Le déploiement de technologies sans fil sécurisées a encouragé l'utilisation de l'authentification de réseau de la couche 2, telle que IEEE 802.1X, pour s'assurer que seul un utilisateur authentifié ou un dispositif est autorisé sur le réseau et que leurs données sont sécurisées au niveau de la transmission radio. La fonctionnalité Authentification unique de Windows Server 2008 et Windows Vista exécute l'authentification 802.1X à l'heure appropriée, pour une configuration de sécurité du réseau donnée, tout en s'intégrant de manière simple et transparente à l'expérience d'ouverture de session Windows de l'utilisateur.

Les administrateurs réseau peuvent utiliser les paramètres de stratégie de groupe ou les nouvelles commandes netsh wlan pour configurer les profils d'authentification unique sur les ordinateurs client sans fil. Après la configuration d'un profil d'authentification unique, l'authentification 802.1X précèdera l'ouverture de session de l'ordinateur sur le domaine, et les utilisateurs sont invités à saisir des informations d'identification uniquement si nécessaire. Cette fonctionnalité garantit que la connexion sans fil est placée avant la connexion de l'ordinateur au domaine, ce qui permet aux scénarios qui nécessitent une connectivité réseau préalable à la connexion utilisateur de telles mises à jour de stratégies de groupe, l'exécution de scripts de connexion et les jonctions de domaine client sans fil.

Dans le cas de l'utilisation d'un profil d'authentification unique pour joindre un client sans fil Windows Vista à un domaine, reportez-vous à la section Joindre un client Windows Vista sans fil à un domaine.

Améliorations de connectivité filaire basée sur IEEE 802.1X

Dans Windows Server 2003 et Windows XP, il existe une prise en charge limitée du déploiement des paramètres d'authentification 802.1X pour les connexions filaires à un commutateur d'authentification. Pour simplifier le déploiement des connexions filaires authentifiées par 802.1X, Windows Server 2008 et Windows Vista incluent les éléments suivants :

• Prise en charge de stratégies de groupe pour les paramètres 802.1X filaires

• Interface de ligne de commande pour la configuration des paramètres 802.1X filaires

• Intégration de la protection de l'accès réseau lors de l'authentification 802.1X

• Infrastructure EAPHost

• Modification de l'état du service 802.1X

Prise en charge de stratégies de groupe pour les paramètres 802.1X filaires

Pour les environnements qui utilisent Active Directory et les stratégies de groupe, Windows Server 2008 et Windows Vista intègrent la prise en charge des stratégies de groupe pour les paramètres d'authentification 802.1X pour les connexions filaires sous Configuration de l'ordinateur/Paramètres Windows/Paramètres de sécurité/Stratégies de réseau filaire (IEEE 802.11).

Interface de ligne de commande pour la configuration des paramètres 802.1X filaires

Pour les environnements qui n'utilisent pas Active Directory ou les stratégies de groupe, ou dans le cas de jonctions de domaines, Windows Server 2008 et Windows Vista prennent également en charge une interface de ligne de commande pour la configuration des paramètres d'authentification 802.1X pour les connexions filaires. Grâce aux commandes du contexte netsh lan, vous pouvez effectuer les tâches suivantes :

• Configurer tous les paramètres client filaires dans un profil nommé incluant les paramètres d'authentification 802.1X (types EAP et leur configuration)

• Afficher la configuration d'un client filaire

• Supprimer la configuration filaire d'un client filaire

• Exporter et importer un profil filaire pour migrer les paramètres de configuration filaire entre les clients filaires

Pour plus d'informations sur l'utilisation de profils filaires pour joindre un client filaire Windows Vista à un domaine, reportez-vous la section Jonction d'un client Windows Vista filaire à un domaine.

Intégration de la protection de l'accès réseau lors de l'authentification 802.1X

Les connexions filaires authentifiées par IEEE 802.1X peuvent exploiter la plate-forme NAP (protection d'accès au réseau) pour empêcher les clients filaires qui ne répondent pas aux exigences d'état du système d'avoir un accès illimité à un réseau privé. Pour plus d'informations sur la plate-forme de protection d'accès au réseau, reportez-vous à la section « Protection de l'accès réseau » de cet article.

Infrastructure EAPHost

Pour faciliter le développement des méthodes d'authentification EAP pour des connexions filaires authentifiées par IEEE 802.1X, Windows Server 2008 et Windows Vista prennent en charge la nouvelle infrastructure EAPHost. Pour plus d'informations, reportez-vous à la section « Architecture EAPHost » de cet article.

Modification de l'état du service 802.1X

Dans Windows XP et Windows Server 2003, le service 802.1X a été activé par défaut mais a été placé en mode d'écoute passive. Dans Windows Vista, le service 802.1X pour les connexions filaires, appelé service Wired AutoConfig, est désactivé par défaut, mais fonctionne en mode d'écoute active lorsqu'il est activé. Pour accéder à l'onglet Authentification dans les propriétés d'une connexion LAN afin de configurer les paramètres 802.1X, vous devez tout d'abord démarrer le service Wired AutoConfig.

Haut de page

Infrastructure réseau

Windows Server 2008 et Windows Vista incluent des modifications apportées aux services et composants suivants de l'infrastructure réseau :

• Protection de l’accès réseau

• Network Policy Server

• Nouvelle Architecture EAPHost

• Améliorations de l'accès distant et des connexions VPN

• Améliorations de DHCP

Protection de l’accès réseau

La protection de l’accès réseau (NAP, Network Access Protection) dans Windows Server 2008 et Windows Vista offre des composants d'application des stratégies qui contribuent à ce que les ordinateurs se connectant à un réseau ou communiquant sur un réseau soient conformes aux exigences d'état du système définies par l'administrateur. Par exemple, ces exigences peuvent spécifier que tous les ordinateurs possèdent les dernières mises à jour du système d'exploitation et les derniers fichiers de signature antivirus.

Les administrateurs peuvent utiliser une combinaison de composants de validation des stratégies et de limitation d'accès au réseau pour contrôler l'accès au réseau ou les communications. Les administrateurs peuvent également choisir de restreindre de façon temporaire l'accès au réseau des ordinateurs qui ne répondent pas aux exigences. En fonction de la configuration choisie, il est possible que le réseau restreint contienne les ressources nécessaires à la mise à jour des ordinateurs non conformes, donc nécessaires pour répondre aux exigences d'état et obtenir un accès illimité au réseau et une communication normale. La protection de l’accès réseau (NAP) inclut un ensemble d'API permettant aux développeurs et aux fournisseurs de créer des solutions complètes de validation des stratégies d'état, de limitation d'accès au réseau, d'assainissement automatique et de conformité aux stratégies d'état en vigueur.

Technologies NAP Enforcement

Windows Server 2008 et Windows Vista incluent les technologies NAP Enforcement suivantes :

• IPsec IPsec Enforcement vous permet de confiner la communication sur votre réseau aux ordinateurs compatibles. Les ordinateurs client et serveur peuvent bloquer toutes les communications provenant des ordinateurs non compatibles. IPsec Enforcement confine la communication aux ordinateurs compatibles après qu'ils ont réussi à se connecter et à obtenir une configuration d'adresse IP valide. IPsec Enforcement est la forme la plus forte d'accès réseau limité dans Network Access Protection.

• IEEE 802.1X Avec 802.1X Enforcement, un serveur NPS (Network Policy Server) ordonne à un point d'accès 802.1X (commutateur Ethernet ou point d'accès sans fil) de placer un profil d'accès restreint sur le client 802.1X jusqu'à ce qu'il exécute un ensemble de fonctions de correction du bon fonctionnement. Un profil d'accès restreint peut être constitué d'un ensemble de filtres de paquet IP ou d'un identificateur de réseau local virtuel pour confiner le trafic d'un client 802.1X. 802.1X Enforcement offre un accès réseau limité renforcé pour tous les ordinateurs qui accèdent au réseau via une connexion 802.1X. Pour plus d'informations sur NPS, reportez-vous à la section « Network Policy Server » de cet article.

• VPN Avec VPN Enforcement, les serveurs VPN peuvent imposer les exigences des stratégies de bon fonctionnement chaque fois qu'un ordinateur tente d'effectuer une connexion VPN au réseau. VPN Enforcement offre un accès réseau limité renforcé pour tous les ordinateurs qui accèdent au réseau via une connexion VPN. VPN Enforcement avec NAP est différent de Network Access Quarantine Control, fonctionnalité offerte par Windows Server 2003. VPN Enforcement dans NAP et Network Access Quarantine Control effectuent une fonction similaire, mais NAP est plus simple à déployer.

• DHCP Avec DHCP Enforcement, les serveurs DHCP peuvent imposer les exigences des stratégies de bon fonctionnement chaque fois qu'un ordinateur tente de louer ou de renouveler une configuration d'adresse IP sur le réseau. DHCP Enforcement repose sur les entrées de la table de routage IP et est la forme la plus faible de NAP Enforcement.

Avec les API NAP, les éditeurs de logiciels tiers peuvent créer leurs propres technologies NAP Enforcement.

Pour plus d'informations sur la plate-forme NAP, reportez-vous à la page Web Network Access Protection (Protection de l'accès réseau, en anglais).

Network Policy Server

NPS (Network Policy Server) est l'implémentation par Microsoft d'un serveur et proxy RADIUS (Remote Authentication Dial-In User Service) dans Windows Server 2008. NPS remplace le Service d'authentification Internet (IAS) de Windows Server 2003. NPS effectue toutes les fonctions présentes dans IAS de Windows Server 2003 pour les connexions VPN et les connexions sans fil et filaire basées sur IEEE 802.1X, et effectue une évaluation du bon fonctionnement et l'octroi d'accès limité ou illimité pour les clients NAP. Pour plus d'informations, reportez-vous à la section « Protection de l’accès réseau » de cet article.

NPS prend également en charge l'envoi du trafic RADIUS via IPv6, comme indiqué dans la RFC 3162.

Nouvelle Architecture EAPHost

Windows Server 2008 et Windows Vista incluent EAPHost, nouvelle architecture pour les méthodes d'authentification EAP (Extensible authentification Protocol) et les suppliants basés sur EAP. EAPHost fournit les fonctions suivantes, qui ne sont pas prises en charge par l'implémentation EAP dans Windows Server 2003 et Windows XP:

• Prise en charge des méthodes EAP supplémentaires EAPHost prendra en charge les autres méthodes EAP répandues.

• Découverte réseau EAPHost prendra en charge la découverte réseau, telle que définie dans le brouillon Internet « Identity Hints for EAP » (draft-adrangi-eap-network-discovery-13.txt).

• Compatible RFC 3748 EAPHost sera conforme à la machine d'état EAP et adressera un certain nombre de vulnérabilités de sécurité indiquées dans la RFC 3748. De plus, EAPHost prendra en charge des fonctions supplémentaires, telles que les types EAP étendus (y compris les méthodes EAP spécifiques des fournisseurs).

• Coexistence des méthodes EAP EAPHost permet la co-existence simultanée de plusieurs implémentations de la même méthode EAP. Par exemple, la version Microsoft de PEAP et la version Cisco Systems, Inc. de PEAP peuvent être installées et sélectionnées.

• Architecture de suppliant modulaire Outre la prise en charge des méthodes EAP modulaires, EAPHost prend également en charge l'architecture d'un suppliant modulaire dans laquelle de nouveaux suppliants peuvent être facilement ajoutés sans qu'il soit nécessaire de remplacer l'implémentation EAP dans son ensemble.

Pour les fournisseurs de méthodes EAP, EAPHost fournit la prise en charge des méthodes EAP déjà développées pour Windows Server 2003 et Windows XP, et une méthode plus simple pour le développement de nouvelles méthodes EAP pour Windows Server 2008 et Windows Vista. Les méthodes EAP certifiées peuvent être distribuées via Windows Update. EAPHost permet également une meilleure classification des types EAP, de sorte que les suppliants Windows 802.1X et PPP intégrés puissent les utiliser.

Pour les fournisseurs de méthodes de suppliant, EAPHost fournit la prise en charge des suppliants modulaires et enfichables pour les nouvelles couches de liaison. Étant donné que EAPHost est intégré à NAP, les nouveaux suppliants n'ont pas besoin d'être sensibles à NAP. Pour participer à NAP, les nouveaux suppliants ont juste besoin d'enregistrer un identificateur de connexion et une fonction de rappel qui informe le suppliant qu'il doit s'authentifier à nouveau.

Pour les administrateurs réseau, EAPHost fournit la disponibilité de nouvelles méthodes EAP, ainsi qu'une infrastructure plus solide et plus flexible pour les connexions d'authentification 802.1X.

Pour plus d'informations sur EAPHost, consultez EAPHost Extensibility in Windows Server 2008 and Windows Vista (Extensibilité EAPHost dans Windows Server 2008 et Windows Vista, en anglais).

Améliorations de l'accès distant et des connexions VPN

L'accès distant et les connexions VPN dans Windows Server 2008 incluent les améliorations suivantes :

• Prise en charge des compartiments de routage En exploitant la prise en charge des compartiments de routage dans la pile TCP/IP nouvelle génération, le client VPN dans Windows Server 2008 et Windows Vista peut créer des connexions VPN dont le trafic peut être séparé du trafic Internet, garantissant ainsi que le trafic d'Internet ne puisse pas être transféré à un réseau privé via la connexion VPN. Pour plus d'informations, consultez « Compartiments de routage » dans cet article.

• VPN Enforcement des connexions VPN d'accès distant Le client VPN intégré et la fonction Routage et accès distant ajoutent des composants pour prendre en charge VPN Enforcement dans la plate-forme NAP. Pour plus d'informations, reportez-vous à la section « Protection de l’accès réseau » de cet article.

• Prise en charge IPv6 Le client d'accès distant intégré et la fonction Routage et accès distant prennent désormais en charge IPv6 sur PPP (Point-to-Point Protocol, PPPv6), défini dans la RFC 2472. Le trafic natif IPv6 peut désormais être envoyé sur les connexions PPP. Par exemple, la prise en charge PPPv6 vous permet de vous connecter avec un fournisseur de services Internet (ISP) IPv6 via une connexion d'accès distant ou une connexion PPP over Ethernet (PPPoE) (utilisée pour l'accès large bande via Internet). Le client d'accès distant intégré et la fonction Routage et accès distant prennent également en charge les connexions VPN L2TP/IPsec (Layer Two Tunneling Protocol avec IPsec) basées sur IPv6. Un autre élément IPv6 pris en charge inclut un agent de relais DHCPv6, des filtres de paquets statiques basés sur IPv6 et l'envoi et la réception du trafic RADIUS sur IPv6.

• Un assistant de création de connexions révisé Ce nouvel assistant fournit une méthode simplifiée de configuration des connexions à ligne commutée, par Internet large bande, VPN et entrantes.

• Prise en charge Winlogin mise à jour Permet à un fournisseur d'accès tiers de se brancher à ses connexions afin de créer automatiquement une connexion d'accès distant lors de l'ouverture de session utilisateur.

• Prise en charge de plusieurs types de paramètres régionaux du kit d'administration du gestionnaire de connexions Permet la création de profils de gestionnaire de connexions sur un serveur de n'importe quelle région en vue de l'installation sur un client de n'importe quelle autre région, s'exécutant sous Windows Vista ou Windows XP, ce qui simplifie la gestion client basée sur le kit d'administration du gestionnaire de connexions (CMAK).

• Les clients du gestionnaire des connexions prennent en charge la mise à jour dynamique DNS Les clients du gestionnaire des connexions prennent désormais en charge l'enregistrement des noms DNS et des adresses IP qui utilisent la mise à jour dynamique DNS.

• Nouvelle prise en charge cryptographique Les connexions VPN basées sur L2TP/IPsec prennent désormais en charge le protocole AES (Advanced Encryption Standard) avec des clés 128 et 256 bits. La prise en charge des algorithmes cryptographiques plus faibles (40 et 56 bits RC4 pour PPTP et DES avec MD5 pour L2TP/IPSec) a été supprimée.

• Prise en charge pour Network Diagnostics Framework Les connexions basées sur le client prennent en charge les fonctions de diagnostic basiques avec Network Diagnostics Framework.

  Pour plus d'informations sur Network Diagnostics Framework, reportez-vous à la page Network Diagnostics Framework in Windows Vista (Network Diagnostics Framework dans Windows Vista, en anglais).

Améliorations de DHCP

Les services serveur DHCP et client DHCP incluent les améliorations suivantes :

• Prise en charge de DHCPv6 (Dynamic Host Configuration Protocol for IPv6) Le protocole DHCPv6 défini dans RFC 3315 fournit une configuration d'adresse avec état pour les hôtes IPv6 sur un réseau natif IPv6.

• Prise en charge de l'application de la protection d’accès réseau DHCP Enforcement dans la plate-forme NAP (Network Access Protection) nécessite qu'un client DHCP prouve la bonne santé de son système avant de recevoir une configuration d'adresse pour un accès illimité. Pour plus d'informations, reportez-vous à la section « Protection de l’accès réseau » de cet article.

Haut de page

Suppression de technologies

La prise en charge des technologies suivantes a été supprimée de Windows Server 2008 et Windows Vista :

• BAP (Bandwidth Allocation Protocol)

• X.25

• SLIP (Serial Line Interface Protocol)

  Les connexions basées sur SLIP seront automatiquement mises à jour vers les connexions basées sur PPP.

• Services for Macintosh (SFM)

• Composant du protocole de routage OSPF (Open Shortest Path First) dans la fonction Routage et accès distant

• Pare-feu basique dans la fonction Routage et accès distant (remplacé par le pare-feu Windows)

• API de filtre d'IP statiques pour la fonction Routage et accès distant (remplacée par les API Windows Filtering Platform)

Haut de page

Résumé

Windows Server 2008 et Windows Vista incluent de nombreuses améliorations en termes de connectivité, de performances et de simplicité de configuration des protocoles et des composants réseau essentiels ; amélioration de la sécurité, de la facilité d'utilisation et du déploiement des connexions sans fil et filaires authentifiées par 802.1X ; ainsi qu'amélioration de la protection des réseaux privés en exigeant que les ordinateurs se connectant soit compatibles avec les stratégies d'état du système.

Haut de page

Liens connexes

Pour plus d'informations, consultez les ressources suivantes :

• Site Web de Windows Server 2008 à l'adresse http://www.microsoft.com/france/windowsserversystem/longhorn/decouvrez/default.mspx

• Site Web de Windows Vista à l'adresse http://www.microsoft.com/france/windowsvista/default.aspx

• Réseaux Windows Vista à l'adresse suivante http://www.microsoft.com/france/windowsvista/fonctionnalites/toutlemonde/networking.mspx

• Windows Vista - Ressources pour les professionnels de l'informatique à l'adresse http://www.microsoft.com/france/technet/produits/windowsvista/default.mspx

Haut de page