Le petit câbleurEAPHost dans Windows

Joseph Davies

Dans cette rubrique, les informations de la version bêta concernant Windows Server « Longhorn » sont susceptibles d’être modifiées.

Lorsqu’un client d’accès se connecte à un réseau protégé, il doit utiliser une méthode d’authentification négociée pour se vérifier auprès d’un serveur d’authentification. Par exemple, le client d’accès et le serveur d’authentification peuvent consentir à utiliser un protocole d’authentification par mot de passe spécifique, tel que Microsoft Challenge Handshake Authentication

Protocole version 2 (MS-CHAP v2). Cependant, lorsqu’un client d’accès et un serveur d’authentification utilisent des méthodes d’authentification intégrées et codées en dur, il est difficile d’ajouter de nouveaux protocoles.

L’EAP (Extensible Authentication Protocol) est une infrastructure architecturale qui fournit de l’extensibilité aux méthodes d’authentification pour les technologies d’accès réseau protégées fréquemment utilisées, telles que les réseaux sans fil basés sur IEEE 802.1X et les connexions PPP (Point-to-Point Protocol), comme la numérotation et le VPN. EAP n’est pas une méthode d’authentification comme MS-CHAP v2, mais plutôt une infrastructure sur le client d’accès et le serveur d’authentification qui permet aux fournisseurs de mise en réseau de développer et de facilement installer les nouvelles méthodes d’authentification connues sous le nom d’EAP. Pour plus d’informations de base sur EAP, voir la page Web Microsoft EAP sur microsoft.com/eap.

Bien qu’EAP soit pris en charge par Microsoft® Windows® depuis Windows 2000, l’architecture EAP dans Windows XP et Windows Server® 2003 est limitée pour les méthodes EAP et les demandeurs, lesquels sont des composants logiciels pouvant utiliser EAP sur un type spécifique de couche liaison. L’architecture EAPHost dans Windows Vista™ et dans la prochaine version de Windows Server, dont le nom de code est « Longhorn », traite de ces limites, ce qui, pour les fournisseurs de réseau tiers, facilite l’extension de Windows pour les nouveaux demandeurs et les nouvelles méthodes EAP.

Prise en charge d’EAP dans Windows Server 2003 et Windows XP

Windows Server 2003 et Windows XP utilisent EAP pour les connexions sans fil ou câblées qui procèdent à des authentifications avec 802.1X et pour les connexions basées sur PPP, telles que les connexions à distance ou site à site basées sur une numérotation ou un VPN. Ces systèmes d’exploitation contiennent plus particulièrement une mise en œuvre d’EAP qui adhère à la norme RFC 2284 et inclut les demandeurs IEEE 802.1X et PPP. La figure 1 montre l’architecture EAP et des demandeurs pour Windows XP et Windows Server 2003. Il faut remarquer, cependant, que la mise en œuvre d’EAP dans Windows XP Service Pack 2 (SP2) et Windows Server 2003 SP1 ne prend pas en charge la norme RFC 3748 (norme Internet actuelle pour EAP) et les autres RFC EAP.

Figure 1** Architecture EAP et des demandeurs pour Windows XP et Windows Server 2003 **

Dans Windows XP et Windows Server 2003, c’est une API EAP qui permet d’étendre l’authentification. Bien que les fournisseurs tiers puissent développer et installer les nouvelles méthodes EAP, les demandeurs PPP et 802.1X intégrés sont incapables d’utiliser toutes les méthodes EAP installées. Par exemple, un fournisseur pourrait créer une nouvelle méthode d’authentification EAP d’analyse des empreintes digitales, mais celle-ci pourrait ne pas être disponible pour les connexions sans fil.

En raison des limites des demandeurs intégrés, certains fournisseurs tiers de logiciels et de matériel développent leurs propres demandeurs, lesquels remplacent et désactivent généralement les demandeurs intégrés, ainsi que l’intégralité de l’architecture EAP. Cependant, cette alternative présente quelques problèmes. D’abord, le remplacement des demandeurs intégrés et de l’architecture EAP entraîne des coûts au niveau du développement et provoque des retards. De plus, si un client d’entreprise ne développe pas ses propres demandeurs, l’octroi de licences et l’installation d’un produit tiers peuvent engendrer des coûts par siège.

Fonctionnalités d’EAPHost

EAPHost possède les nouvelles fonctionnalités suivantes :

Prise en charge de méthodes EAP supplémentaires. EAPHost prendra en charge l’installation et l’utilisation de toutes les méthodes EAP listées dans le Registre EAP sur www.iana.org/assignments/eap-numbers, ainsi que d’autres méthodes d’authentification fréquentes, telles que Lightweight EAP (LEAP), développée et fournie par Cisco Systems, Inc.

Découverte réseau EAPHost prend en charge la découverte réseau telle que définie dans la norme RFC 4284.

Conformité à la norme RFC 3748 EAPHost est conforme à l’ordinateur d’état EAP et traite plusieurs failles de sécurité qui ont été spécifiées dans la norme RFC 3748. Auparavant, les demandeurs devaient effectuer eux-mêmes cette mise en place. De plus, EAPHost prend en charge des capacités telles que les types Expanded EAP (y compris les méthodes EAP spécifiques aux fournisseurs).

Coexistence des méthodes EAP EAPHost permet la coexistence simultanée de plusieurs mises en place de la même méthode EAP. Par exemple, vous pouvez installer et sélectionner la version PEAP (Protected EAP) de Microsoft et celle de Cisco Systems, Inc.

Architecture modulaire des demandeurs EAPHost prend en charge une architecture modulaire de demandeurs dans laquelle il est facile d’ajouter de nouveaux demandeurs sans devoir remplacer la mise en place complète d’EAP, comme vous le faisiez dans la version précédente.

Pour les fournisseurs de méthodes EAP, EAPHost prend en charge les méthodes EAP déjà développées pour Windows XP et Windows Server 2003, ainsi qu’une méthode plus facile visant au développement de nouvelles méthodes EAP pour Windows Vista et Windows Server « Longhorn ». EAPHost permet également une meilleure classification des types EAP pour que le demandeur IEEE 802.1X intégré puisse les utiliser.

Pour les fournisseurs de demandeurs, EAPHost fournit la prise en charge de demandeurs supplémentaires pour les nouvelles couches liaison. Étant donné qu’EAPHost est intégré à NAP (Network Access Protection), les nouveaux demandeurs n’ont pas besoin d’y être sensibles. Pour participer à NAP, les nouveaux demandeurs ont juste besoin d’enregistrer un identificateur de connexion et une fonction de rappel qui informe le demandeur qu’il doit s’authentifier à nouveau. Pour plus d’informations sur NAP, voir la rubrique Vigilance sécurité de John Morello dans ce numéro de Technet Magazine, de même que la page Web NAP sur microsoft.com/nap. Pour des renseignements concernant le développement des méthodes EAP ou des demandeurs pour EAPHost, voir EAPHost à l’adresse msdn2.microsoft.com/aa364249.aspx.

Architecture d’infrastructure EAPHost et EAP

L’architecture EAPHost se compose de l’architecture d’infrastructure EAP pour EAPHost, l’architecture EAPHost sur l’homologue EAP (le client qui authentifie) et l’architecture EAPHost sur le serveur d’authentification. La figure 2 montre les composants de l’architecture d’infrastructure EAP pour EAPHost sur les ordinateurs fonctionnant sous Windows Vista ou Windows Server « Longhorn ». Sur ces systèmes d’exploitation, l’homologue EAP a une couche de demandeurs (tels que le demandeur intégré pour 802.1X), la nouvelle architecture EAPHost pour les homologues EAP (facilitant la communication et la gestion des demandeurs et des méthodes EAP) et une couche de méthodes EAP visant à l’exécution de l’authentification.

Figure 2** L’architecture d’infrastructure EAP pour EAPHost **(Cliquer sur l'image pour l'agrandir)

Le serveur d’authentification pour Windows Server « Longhorn » dispose du NPS (Network Policy Server), la nouvelle architecture EAPHost pour les serveurs d’authentification, ainsi que d’une couche de méthodes EAP. Anciennement connu sous le nom d’IAS (Internet Authentication Service) dans Windows Server 2003, NPS est un serveur et un proxy RADIUS (Remote Authentication Dial-In User Service), ainsi qu’un serveur de stratégie pour NAP.

Le demandeur de l’homologue EAP utilise une technologie de couche liaison, telle que PPP ou 802.1X, pour envoyer et recevoir des messages EAP sur la liaison entre l’homologue EAP et l’authentificateur direct (un serveur d’accès réseau comme point d’accès sans fil ou un serveur d’accès à distance). L’authentificateur direct et le NPS du serveur d’authentification utilisent RADIUS pour envoyer et recevoir des messages EAP sur le réseau basé sur IP, lequel se situe entre ces deux entités.

Une fois que l’homologue EAP et le serveur d’authentification ont négocié l’utilisation d’une méthode EAP spécifique, la communication logique se compose de messages EAP envoyés entre la méthode EAP négociée sur l’homologue EAP et le serveur d’authentification.

La figure 3 montre l’architecture EAPHost sur l’homologue EAP fonctionnant sous Windows Vista ou Windows Server « Longhorn ». Cette architecture est constituée de demandeurs, composants EAPHost, composants de gestion des méthodes EAP et composants NAP.

Figure 3** Architecture EAPHost sur l’homologue EAP **(Cliquer sur l'image pour l'agrandir)

Windows Server et Windows Server « Longhorn » incluent un demandeur 802.1X pour les connexions sans fil et câblées basées sur 802.1X. Un demandeur PPP pour les connexions à distance ou site à site basées sur la numérotation ou un VPN visant à prochainement mettre à jour ces deux systèmes d’exploitation est en cours d’étude. Il est également possible d’ajouter d’autres demandeurs développés par des tiers. L’API EAPHost permet aux demandeurs d’utiliser EAP pour les connexions. Pour plus d’informations, voir l’article correspondant sur msdn2.microsoft.com/aa364249.aspx.

Les composants EAPHost incluent le Validateur de machine/protocole d'état de client EAP, qui maintient l’ordinateur d’état de l’homologue EAP (voir RFC 3748) et valide les messages EAP. Également compris est le Gestionnaire de méthodes EAP, qui gère les diverses méthodes EAP, qu’elles soient compatibles ou non à EAPHost, et aide à mettre à disposition les méthodes EAP aux applications et services. Pour finir, il y a le Gestionnaire de bibliothèques EAP, qui facilite le chargement et le déchargement des bibliothèques de méthodes EAP.

Les composants des méthodes EAP comprennent :

Les méthodes EAP intégrées. Elles comprennent PEAP, EAP-TLS (Transport Layer Security) et EAP-MS-CHAP-V2.

Deux API hôtes Ces API hébergent des méthodes EAP non compatibles avec EAPHost (API EAP héritée) et des méthodes EAP compatibles avec EAPHost (API de méthode EAPHost).

Méthode de traduction héritée. Elle traduit les méthodes EAP non compatibles avec EAPHost écrites pour l’API EAP héritée et l’API de méthode EAPHost.

Gestionnaire de proxy de la méthode EAP . Il héberge des méthodes EAP tierce, qu’ils soient compatibles ou non avec EAPHost.

L’API de méthode EAP est la nouvelle API pour les méthodes EAP compatibles avec EAPHost. Les méthodes EAP exportent les API définies dans l’API de méthode EAP. EAPHost charge les méthodes et appels EAP dans les fonctions d’API exportées.

Les composants NAP incluent les éléments suivants :

Messager CC NAP EAP . Ce composant facilite la communication de données liées à NAP, telles que les déclarations d’intégrité et les événements, entre le EAPHost NAP EC (Enforcement Client) et les autres composants EAPHost.

CC NAP EAPHost . Il interagit avec les autres composants NAP pour fournir une validation et une application d’accès restreint de l’intégrité lorsqu’une connexion 802.1X authentifiée n’est pas conforme aux exigences d’intégrité d’un système NAP.

Agent NAP Il maintient l’état actuel d’intégrité du client et facilite la communication entre les NAP EC installés et la couche SHA (System Health Agent). Chaque SHA est défini pour une ou plusieurs exigences d’intégrité d’un système.

Comme le montre la figure 3, les fournisseurs tiers peuvent développer de nouveaux demandeurs et de nouvelles méthodes EAP compatibles avec EAPHost. Vous pouvez également utiliser les méthodes EAP existantes développées pour Windows Server 2003 ou Windows XP.

La figure 4 montre l’architecture EAPHost sur le serveur d’authentification fonctionnant sous Windows Server « Longhorn » et NPS. Cette architecture est identique à celle de l’homologue EAP et prend en charge les méthodes EAP. Au lieu des demandeurs, le serveur d’authentification dispose du NPS, qui utilise l’API EAPHost pour utiliser et configurer les méthodes EAP. Au sein des composants EAP, le Validateur de machine/protocole d'état de serveur EAP s’occupe de maintenir la machine d’état du serveur d’authentification EAP et de valider les messages EAP entrants.

Figure 4** Architecture EAPHost sur le serveur d’authentification **(Cliquer sur l'image pour l'agrandir)

EAPHost sur le serveur d’authentification permet aux fournisseurs tiers de logiciels de développer et d’installer de nouvelles méthodes EAP compatibles avec EAPHost et prend en charge les méthodes EAP qui ont déjà été développées pour Windows XP et Windows Server 2003.

Pour l’homologue EAP et le serveur d’authentification, EAPHost fournit également une API de proxy d’interface utilisateur EAPHost (qui n’apparaît pas aux figures 3 et 4) que les méthodes compatibles avec EAPHost peuvent utiliser pour afficher des boîtes de dialogue nécessitant l’interaction des utilisateurs. L’API de proxy d’interface utilisateur EAPHost permet aux fournisseurs tiers d’ajouter leurs propres boîtes de dialogue pour une expérience utilisateur plus transparente.

Conclusion

Dans Windows Server « Longhorn » et Windows Vista, EAPHost met à jour la mise en œuvre d’EAP dans Windows, pour se conformer aux dernières normes Internet, et fournit une nouvelle architecture modulaire permettant d’étendre Windows avec des méthodes d’authentification et des demandeurs EAP. Les fournisseurs de mise en réseau peuvent étendre l’expérience utilisateur existante dans Windows sans remplacer la mise en œuvre complète d’EAP par Windows et ce, en développant de nouveaux demandeurs écrits pour l’API d’EAPHost et de nouvelles méthodes d’authentification écrites pour l’API de méthode EAPHost. EAPHost prend également en charge les méthodes EAP existantes développées pour Windows Server 2003 et Windows XP.

EAPHost pour Windows XP

Microsoft prévoit de sortir une mise à jour pour Windows XP SP2, incluant l’architecture EAPHost, la prise en charge de la norme RFC 3748 et un demandeur basé sur EAPHost pour la connectivité 802.1X câblée. Avec cette mise à jour, les demandeurs EAPHost développés pour Windows Vista fonctionneront également sous Windows XP SP2. Pour les toutes dernières informations sur cette mise à jour, consultez le blog de l’équipe produit NAP à l’adresse blogs.technet.com/nap.

Joseph Daviesest rédacteur technique chez Microsoft et il enseigne et écrit sur le réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et on lui doit les articles mensuels du petit câbleur de Technet.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.