The Cable GuyEAPHost in Windows

Joseph Davies

Die Informationen in dieser Rubrik über Vorabversionen von Windows Server „Longhorn“ können jederzeit aktualisiert bzw. geändert werden.

Wenn ein Zugriffsclient eine Verbindung zu einem geschützten Netzwerk herstellt, muss sich dieser Client anhand einer ausgehandelten Authentifizierungsmethode von einem Authentifizierungsserver überprüfen lassen. So könnten sich z. B. der Zugriffsclient und der Authentifizierungsserver auf die Verwendung eines bestimmtes Kennwortauthentifizierungsprotokolls, z. B. das Microsoft Challenge Handshake

Authentication-Protokoll, Version 2 (MS-CHAP v2) einigen. Wenn ein Zugriffsclient und ein Authentifizierungsserver jedoch integrierte und hartcodierte Authentifizierungsmethoden nutzen, ist das Hinzufügen neuer Protokolle schwierig.

Das Extensible Authentication-Protokoll (EAP) ist ein Architekturframework, das Erweiterbarkeit für Authentifizierungsmethoden für gebräuchliche Technologien bereitstellt, die Zugriff auf geschützte Netzwerke ermöglichen, z. B. für IEEE 802.1X-basierte Drahtlosnetzwerke und für PPP-Verbindungen (Point-to-Point Protocol) wie DFÜ und VPN. EAP ist keine Authentifizierungsmethode wie MS-CHAP v2, sondern eher ein Framework auf dem Zugriffsclient und dem Authentifizierungsserver, mit dem Netzwerkanbieter neue Authentifizierungsmethoden, als EAP-Methoden bezeichnet, entwickeln und auf einfache Weise installieren können. Weitere Hintergrundinformation zu EAP finden Sie auf der EAP-Webseite von Microsoft unter microsoft.com/eap.

EAP wird in Microsoft® Windows® zwar bereits seit Windows 2000 unterstützt, aber die Architektur von EAP in Windows XP und Windows Server® 2003 verfügt über Einschränkungen bezüglich der Erweiterbarkeit von EAP-Methoden und Supplicants, wobei Supplicants Softwarekomponenten sind, die EAP über einen bestimmten Verbindungsschichttyp nutzen können. Die Architektur von EAPHost in Windows Vista™ und in der nächsten Version von Windows Server mit dem Codenamen „Longhorn“ behebt diese Einschränkungen. Dadurch können Netzwerkanbieter Windows auf einfachere Weise um neue Supplicants und EAP-Methoden erweitern.

Unterstützung von EAP in Windows Server 2003 und Windows XP

Windows Server 2003 und Windows XP nutzen EAP für drahtlose und verkabelte Verbindungen, die sich mit 802.1X authentifizieren, und für PPP-basierte Verbindungen wie DFÜ- oder VPN-basierte RAS- oder Standort-zu-Standort-Verbindungen. Insbesondere enthalten diese Betriebssysteme eine Implementierung von EAP, die mit RFC 2284 kompatibel ist und IEEE 802.1X- und PPP-Supplicants beinhaltet. Abbildung 1 zeigt die EAP- und Supplicantarchitektur für Windows XP und Windows Server 2003. Es sollte jedoch angemerkt werden, dass die Implementierung von EAP in Windows XP Service Pack 2 (SP2) und Windows Server 2003 SP1 den Standard RFC 3748 (der aktuelle Internetstandard für EAP) und auch andere EAP-RFCs nicht unterstützt.

Abbildung 1** EAP- und Supplicantarchitektur für Windows XP und Windows Server 2003 **

Eine EAP-API stellt die Mittel für die Erweiterung der Authentifizierung in Windows XP und Windows Server 2003 bereit. Drittanbieter können zwar neue EAP-Methoden entwickeln und installieren, die integrierten PPP- und 802.1X-Supplicants können jedoch nicht alle installierten EAP-Methoden verwenden. So könnte z. B. ein Anbieter eine neue EAP-Authentifizierungsmethode mittels Fingerabdruckscan erstellen, diese Methode würde jedoch nicht für drahtlose Verbindungen zur Verfügung stehen.

Aufgrund der Einschränkungen der integrierten Supplicants haben einige Drittanbieter von Software und Hardware ihre eigenen Supplicants entwickelt, die normalerweise die integrierten Supplicants und die gesamte EAP-Architektur deaktivieren und ersetzen. Diese Alternative führt jedoch zu Problemen. Erstens führt das Ersetzen der Architektur der integrierten Supplicants und EAP zu Entwicklungskosten und zu zeitlichen Verzögerungen. Wenn ein Geschäftskunde seine Supplicants nicht selbst entwickelt hat, kann es außerdem pro Arbeitsplatz zu Lizenz- und Installationskosten für ein Drittanbieterprodukt kommen.

Features von EAPHost

EAPHost verfügt über die folgenden neuen Features:

Unterstützung für zusätzliche EAP-Methoden. EAPHost unterstützt die Installation und Nutzung aller unter EAP Registry unter www.iana.org/assignments/eap-numbers aufgeführten EAP-Methoden und weiterer populärer Authentifizierungsmethoden wie Lightweight EAP (LEAP), das von Cisco Systems, Inc. entwickelt und vertrieben wird.

Netzwerkerkennung. EAPHost unterstützt die Netzwerkerkennung wie in RFC 4284 definiert.

Konformität mit RFC 3748. EAPHost stimmt mit der Spezifikation des EAP-Statuscomputers überein und schließt einige der in RFC 3748 aufgeführten Sicherheitslücken. Bisher mussten Supplicants ihre eigenen Statuscomputer implementieren. Außerdem unterstützt EAPHost Funktionen wie erweiterte EAP-Typen (einschließlich anbieterspezifische EAP-Methoden).

EAP-Methodenkoexistenz. EAPHost ermöglicht die Koexistenz mehrerer Implementierungen derselben EAP-Methode. So können Sie z. B. Protected EAP (PEAP) sowohl in der Microsoft-Version als auch in der Version von Cisco Systems, Inc. installieren und auswählen.

Modulare Supplicantarchitektur. EAPHost unterstützt eine modulare Supplicantarchitektur, in der neue Supplicants einfach hinzugefügt werden können, ohne die gesamte EAP-Implementierung ersetzen zu müssen, wie dies in der vorherigen Version der Fall war.

Was Anbieter von EAP-Methoden betrifft, so bietet EAPHost Unterstützung für EAP-Methoden, die bereits für Windows Server 2003 und Windows XP entwickelt wurden. Außerdem steht eine vereinfachte Methode für das Entwickeln neuer EAP-Methoden für Windows Server „Longhorn“ und Windows Vista zur Verfügung. EAPHost ermöglicht außerdem eine bessere Klassifizierung von EAP-Typen, sodass diese von den integrierten 802.1X-Supplicants verwendet werden können.

Für die Anbieter von Supplicants bietet EAPHost Unterstützung für zusätzliche Supplicants für neue Verbindungsschichten. Da EAPHost in den Netzwerkzugriffsschutz (Network Access Protection, NAP) integriert ist, müssen neue Supplicants nicht NAP-fähig sein. Um an NAP teilnehmen zu können, müssen neue Supplicants lediglich eine Verbindungs-ID und eine Rückruffunktion registrieren, über die der Supplicant über eine erneute Authentifizierung informiert wird. Weitere Informationen zu NAP finden Sie in der Rubrik „Sicherheit auf dem Prüfstand“ von John Morello in dieser Ausgabe des TechNet Magazins sowie auf der NAP-Webseite unter microsoft.com/nap. Informationen zum Entwickeln von EAP-Methoden oder Supplicants für EAPHost finden Sie unter „Extensible Authentication-Protokoll-Host“ unter msdn2.microsoft.com/aa364249.aspx.

Architektur von EAPHost und EAP-Infrastruktur

Die Architektur von EAPHost besteht aus der EAP-Infrastrukturarchitektur für EAPHost, der EAPHost-Architektur auf dem EAP-Peer (der sich authentifizierende Client) und der EAPHost-Architektur auf dem Authentifizierungsserver. Abbildung 2 zeigt die Komponenten der Architektur der EAP-Infrastruktur für EAPHost auf Computern, die Windows Vista oder Windows Server „Longhorn“ ausführen. Bei diesen Betriebssystemen verfügt der EAP-Peer über eine Schicht von Supplicants (z. B. der integrierte Supplicant für 802.1X), die neue EAPHost-Architektur für EAP-Peers (die Kommunikation und Verwaltung von Supplicants und EAP-Methoden ermöglicht) und eine Schicht von EAP-Methoden zur Durchführung der Authentifizierung.

Abbildung 2** Architektur der EAP-Infrastruktur für EAPHost **(Klicken Sie zum Vergrößern auf das Bild)

Der Authentifizierungsserver für Windows Server „Longhorn“ verfügt über den Netzwerkrichtlinienserver (Network Policy Server, NPS), die neue EAP­Hostarchitektur für Authentifizierungsserver und eine Schicht von EAP-Methoden. Der NPS war bisher als Internetauthentifizierungsdienst (Internet Authentication Service, IAS) in Windows Server 2003 bekannt. Es handelt sich dabei um einen RADIUS-Server (Remote Authentication Dial-In User Service) und Proxy- und Richtlinienserver für NAP.

Der Supplicant auf dem EAP-Peer verwendet eine Verbindungsschichttechnologie, z. B. PPP oder 802.1X, um EAP-Meldungen über die Verbindung zwischen dem EAP-Peer und dem Pass-Through-Authentifikator (ein Netzwerkzugriffserver, z. B. ein Drahtloszugriffspunkt oder ein RAS-Server) zu senden und zu empfangen. Der Pass-Through-Authentifikator und NPS auf dem Authentifizierungsserver senden und empfangen mithilfe von RADIUS EAP-Meldungen auf dem IP-basierten Netzwerk zwischen dem Pass-Through-Authentifikator und dem NPS.

Nachdem der EAP-Peer und der Authentifizierungsserver die Verwendung einer bestimmten EAP-Methode ausgehandelt haben, besteht die logische Kommunikation aus EAP-Meldungen, die zwischen der ausgehandelten EAP-Methode auf dem EAP-Peer und dem Authentifizierungsserver gesendet werden.

Abbildung 3 zeigt die EAPHost-Architektur auf dem EAP-Peer, auf dem Windows Vista oder Windows Server „Longhorn“ ausgeführt wird. Diese Architektur besteht aus Supplicants, EAPHost-Komponenten, Komponenten für die Verwaltung von EAP-Methoden und NAP-Komponenten.

Abbildung 3** EAPHost-Architektur auf dem EAP-Peer **(Klicken Sie zum Vergrößern auf das Bild)

Windows Vista und Windows Server „Longhorn“ verfügen über einen 802.1X-Supplicant für 802.1X-basierte Drahtlos- und Kabelverbindungen. Derzeit werden Untersuchungen mit einem PPP-Supplicant für DFÜ- oder VPN-basierte RAS- oder Standort-zu-Standort-Verbindungen durchgeführt, um später ein Update für diese beiden Betriebssysteme bereitzustellen. Außerdem können zusätzliche Supplicants von Drittanbietern hinzugefügt werden. Die EAPHost-API ermöglicht den Supplicants, EAP für Verbindungen zu verwenden. Weitere Informationen finden Sie im Artikel unter msdn2.microsoft.com/aa364249.aspx.

Zu den EAPHost-Komponenten gehören die EAP-Clientstatuscomputer/Protokollprüfung, die den Statuscomputer des EAP-Peers realisiert (siehe RFC 3748) und EAP-Meldungen überprüft. Ebenfalls enthalten ist der EAP-Methodenmanager, der die verschiedenen EAP-Methoden verwaltet, unabhängig davon, ob diese EAPHost-kompatibel sind oder nicht, und die Bereitstellung von EAP-Methoden für Anwendungen und Dienste unterstützt. Schließlich gibt es den EAP-Bibliotheksmanager, der das Laden und Entladen von EAP-Methodenbibliotheken ermöglicht.

Die EAP-Methodenkomponenten umfassen:

Integrierte EAP-Methoden. Diese Methoden sind PEAP, EAP-Transport Layer Security (TLS) und EAP-MS-CHAP-V2.

Zwei Host-APIs. Diese hosten nicht mit EAPHost kompatible EAP-Methoden (Legacy-EAP-API) und mit EAPHost kompatible EAP-Methoden (EAPHost-Methoden-API) von Drittanbietern.

Legacykonvertierungsmethode. Diese Methode übersetzt zwischen den nicht mit EAPHost kompatiblen EAP-Methoden, die über die Legacy-EAP-API und die EAPHost-Methoden-API geschrieben werden.

EAP-Methodenproxymanager . Dieser hostet EAP-Methoden von Drittanbietern, gleichgültig, ob diese mit dem EAPHost kompatibel sind oder nicht.

Die EAP-Methoden-API ist die neue API für mit EAPHost kompatible EAP-Methoden. EAP-Methoden exportieren die in der EAP-Methoden-API definierten APIs. EAPHost lädt die EAP-Methoden und ruft die exportierten API-Funktionen auf.

Zu den NAP-Komponenten gehören folgende Elemente:

EAP-NAP-EC-Messenger . Diese Komponente ermöglicht die Kommunikation von NAP-bezogenen Daten, z. B. SoHs (Statement of Health) und Ereignisse, zwischen dem EAPHost-NAP-Erzwingungsclient (EC) und anderen Komponenten von EAPHost.

EAPHost-NAP-EC . Dieser Client interagiert mit anderen NAP-Komponenten, um Integritätsprüfungen und die Erzwingung des begrenzten Zugriffs bereitzustellen, wenn eine 802.1X-authentifizierte Verbindung nicht mit den von NAP gestellten Anforderungen an die Systemintegrität übereinstimmt.

NAP-Agent Dieser Agent hält den aktuellen Zustand des Clients aufrecht und ermöglicht die Kommunikation zwischen den installierten NAP-ECs und der Schicht der Systemintegritäts-Agents (System Health Agent, SHA). Jeder SHA ist für eine oder mehrere Anforderungen an die Systemintegrität definiert.

Wie Abbildung 3 zeigt, können Drittanbieter neue Supplicants und neue EAPHost-kompatible EAP-Methoden entwickeln. Es können auch bereits vorhandene, für Windows Server 2003 oder Windows XP entwickelte EAP-Methoden genutzt werden.

Abbildung 4 zeigt die EAPHost-Architektur auf dem Authentifizierungsserver, auf dem Windows Server „Longhorn“ und NPS ausgeführt werden. Diese Architektur ist mit der Architektur für den EAP-Peer für die Unterstützung von EAP-Methoden identisch. Statt über Supplicants verfügt der Authentifizierungsserver über einen NPS, der mithilfe der EAPHost-API EAP-Methoden verwendet und konfiguriert. Von den EAP-Komponenten erledigt die EAP-Serverstatuscomputer/Protokollprüfung die Aufgabe, den EAP-Serverstatuscomputer zu verwalten und eingehende EAP-Meldungen zu überprüfen.

Abbildung 4** EAPHost-Architektur auf dem Authentifizierungsserver **(Klicken Sie zum Vergrößern auf das Bild)

Der EAPHost auf dem Authentifizierungsserver ermöglicht Softwareanbietern, neue mit EAPHost kompatible EAP-Methoden zu entwickeln und zu installieren sowie EAP-Methoden zu unterstützen, die bereits für Windows XP und Windows Server 2003 entwickelt wurden.

Sowohl für den EAP-Peer als auch für den Authentifizierungsserver stellt EAPHost außerdem eine EAPHost-Benutzeroberflächen-Proxy-API bereit (in Abbildung 3 und Abbildung 4 nicht dargestellt), über die mit EAPHost kompatible Methoden Dialogfelder für erforderliche Benutzerinteraktionen anzeigen können. Mithilfe der EAPHost-Benutzeroberflächen-Proxy-API können Drittanbieter ihre eigenen Dialogfelder einfügen und so für nahtlose Benutzerfunktionalität sorgen.

Schlussbemerkung

Durch EAPHost in Windows Server „Longhorn“ und Windows Vista wird die EAP-Implementierung in Windows auf die neuesten Internetstandards aktualisiert. EAPHost stellt eine neue modulare Architektur zur Erweiterung von Windows mit EAP-Authentifizierungsmethoden und Supplicants bereit. Netzwerkanbieter können die derzeitige Benutzerfreundlichkeit in Windows verbessern, ohne die gesamte EAP-Implementierung von Windows zu ersetzen. Dies erfolgt durch eine Neuentwicklung von Supplicants für die EAPHost-API und von Authentifizierungsmethoden für die EAPHost-Methoden-API. EAPHost unterstützt außerdem bereits vorhandene EAP-Methoden, die für Windows Server 2003 und Windows XP entwickelt wurden.

EAPHost für Windows XP

Microsoft plant die Veröffentlichung eines Updates für Windows XP SP2, in dem die EAPHost-Architektur, Unterstützung für RFC 3748 und ein EAPHost-basierter Supplicant für verkabelte 802.1X-Konnektivität enthalten sind. Mit dem Update funktionieren für Windows Vista entwickelte EAPHost-Supplicants auch unter Windows XP SP2. Aktuelle Informationen zu diesem Update finden Sie im Blog des NAP-Produktteams unter blogs.technet.com/nap.

Joseph Daviesist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Windows-Netzwerkthemen. Er hat fünf Bücher für Microsoft Press verfasst und ist der Autor der monatlich erscheinenden TechNet-Rubrik „The Cable Guy“.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.