Neue Netzwerkfeatures in Windows Server 2008 und Windows Vista

Veröffentlicht: 15. Feb 2006 | Aktualisiert: 25. Apr 2007
  Hinweis:

Änderungen der in diesem Artikel beschriebenen Features sind vorbehalten. Einige werden im fertigen Produkt aus vertrieblichen-, technischen oder anderen Gründen möglicherweise nicht enthalten sein.

Auf dieser Seite
ZusammenfassungZusammenfassung
EinführungEinführung
Protokolle und Kernkomponenten von NetzwerkenProtokolle und Kernkomponenten von Netzwerken
Drahtlose und 802.1X-basierte verdrahtete VerbindungenDrahtlose und 802.1X-basierte verdrahtete Verbindungen
NetzwerkinfrastrukturNetzwerkinfrastruktur
Entfernte TechnologienEntfernte Technologien
ZusammenfassungZusammenfassung
Verwandte LinksVerwandte Links

Zusammenfassung

Microsoft® Windows Server™ 2008 (derzeit in der Betatestversion) und Windows Vista™ beinhalten viele Änderungen und Erweiterungen der Netzwerktechnologien. In diesem Artikel werden die Änderungen an Protokollen und zentralen Netzwerkkomponenten, drahtlosen und 802.1X-authentifizierten verdrahteten Technologien sowie der Netzwerkinfrastruktur beschrieben. Grundlage bilden dabei die Beta 3 von Windows Server 2008 und die RTM-Version von Windows Vista.

Zum SeitenanfangZum Seitenanfang

Einführung

Netzwerke und Kommunikation sind wesentliche Aspekte für die Wettbewerbsfähigkeit eines Unternehmens auf dem globalen Markt. Mitarbeiter müssen von jedem Ort aus und mit den verschiedensten Geräten eine Verbindung mit dem Netzwerk herstellen können. Partner, Anbieter und andere Parteien außerhalb des Netzwerks müssen mit Schlüsselressourcen effizient interagieren können, und die Sicherheit ist wichtiger denn je.

Dieser Artikel stellt eine technische Übersicht zu Netzwerk- und Kommunikationserweiterungen in Windows Server 2008 und Windows Vista dar und befasst sich mit Verbindungsmöglichkeiten, Benutzerfreundlichkeit, Verwaltung, Verlässlichkeit und Sicherheit. Mit Windows Server 2008 und Windows Vista verfügen IT-Administratoren über umfassendere und flexiblere Optionen für die Verwaltung der Netzwerkinfrastruktur, den Schutz der Netzwerke (indem die Computer ihren Systemzustand nachweisen müssen), das Bereitstellen authentifizierter drahtloser und verdrahteter Verbindungen über Gruppenrichtlinien oder Skripts sowie das Bereitstellen geschützter Szenarios für den Netzwerkverkehr.

Zum SeitenanfangZum Seitenanfang

Protokolle und Kernkomponenten von Netzwerken

Windows Server 2008 und Windows Vista beinhalten viele Änderungen und Erweiterungen folgender Protokolle und Kernkomponenten von Netzwerken:

TCP/IP-Stack der nächsten Generation

QoS (Quality of Service)

Http.sys-Erweiterungen

WinINet-Erweiterungen

Windows Sockets-Erweiterungen

NDIS 6.0

Windows Peer-zu-Peer-Netzwerkumgebungserweiterungen

Windows Firewall-Erweiterungen

IPsec-Verbesserungen

TCP/IP-Stack der nächsten Generation

Windows Server 2008 und Windows Vista beinhalten eine neue Implementierung des TCP/IP-Protokollstapels, den TCP/IP-Stack der nächsten Generation. Der TCP/IP-Stack der nächsten Generation ist sowohl für IPv4 (Internetprotokoll, Version 4) als auch für IPv6 (Internetprotokoll, Version 6) eine vollständige Neuentwicklung der TCP/IP-Funktionalität, die die Verbindungs- und Leistungsanforderungen moderner, variabler Netzwerkumgebungen und -technologien erfüllt.

Automatische Optimierung des Empfangsfensters

Bei der Größe des TCP-Empfangsfensters handelt es sich um die Bytegröße des Speicherpuffers auf einem empfangenden Host, in dem eingehende Daten einer TCP-Verbindung gespeichert werden. Um den Wert der maximalen Empfangsfenstergröße für eine auf den derzeitigen Netzwerkbedingungen basierende Verbindung genau zu ermitteln, unterstützt der TCP/IP-Stack der nächsten Generation die automatische Optimierung des Empfangsfensters. Bei der automatischen Optimierung des Empfangsfensters wird die optimale Empfangsfenstergröße fortlaufend für jede Verbindung ermittelt, indem das Produkt aus Bandbreite und Verzögerung (die Bandbreite multipliziert mit der Latenz der Verbindung) sowie die Abrufrate der Anwendung gemessen und die maximale Empfangsfenstergröße ständig automatisch angepasst wird.

Durch einen besseren Durchsatz zwischen TCP-Peers wird die Nutzung der Netzwerkbandbreite während der Datenübertragung verbessert. Wenn sämtliche Anwendungen für das Empfangen von TCP-Daten optimiert sind, kann die Gesamtnutzung des Netzwerks erheblich gesteigert werden, wobei die Verwendung von QoS insbesondere bei Netzwerken wichtig ist, die bei oder nahe der maximalen Kapazität arbeiten. Weitere Informationen finden Sie in diesem Whitepaper unter "QoS (Quality of Service)".

Weitere Informationen zur automatischen Optimierung von Ergebnisfenstern finden Sie unter Verbesserungen im Next Generation TCP/IP-Stack im Bereich Leistung.

Compound TCP

Für TCP-Verbindungen mit einer großen Empfangsfenstergröße und einem großen Produkt aus Bandbreite und Verzögerung (die Bandbreite einer Verbindung multipliziert mit deren Verzögerung) erhöht Compound TCP (CTCP) im TCP/IP-Stack der nächsten Generation aggressiv die pro Übertragung gesendete Datenmenge, indem das Produkt aus Bandbreite und Verzögerung sowie Verzögerungsabweichungen und Paketverluste überwacht werden. CTCP stellt außerdem sicher, dass andere TCP-Verbindungen durch diese Anpassungen nicht negativ beeinflusst werden. Bei internen Tests von Microsoft konnten lange Dateisicherungszeiten bei Verbindungen mit 1 Gbit/s und einem Roundtrip von 50 Millisekunden fast um die Hälfte reduziert werden. Bei Verbindungen mit einem größeren Produkt aus Bandbreite und Verzögerung kann sogar eine noch bessere Leistung erzielt werden.

Die automatische Optimierung des Ergebnisfensters optimiert den empfängerseitigen Durchsatz, und CTCP verbessert den senderseitigen Durchsatz. Durch den gemeinsamen Einsatz kann die Ausnutzung einer Netzwerkverbindung verbessert und für Verbindungen mit einem großen Produkt aus Bandbreite und Verzögerung ein erheblicher Leistungsgewinn erzielt werden.

Der TCP/IP-Stack der nächsten Generation unterstützt folgende RFCs, um den Durchsatz in Umgebungen mit hohen Verlustraten zu optimieren:

RFC 2582: Die NewReno-Änderung des TCP-Algorithmus für die schnelle Wiederherstellung

Der NewReno-Algorithmus bietet einen schnelleren Durchsatz, indem die Art und Weise geändert wird, in der ein Sender seine Senderate verbessern kann, wenn in einem Datenfenster mehrere Segmente verloren gehen und der Sender nur eine partielle Bestätigung erhält (eine Bestätigung lediglich für den Teil der Daten, der erfolgreich empfangen wurde).

RFC 2883: Eine Erweiterung der TCP-Option für selektive Bestätigung (Selective Acknowledgement, SACK)

SACK (definiert in RFC 2018) ermöglicht es dem Empfänger, bis zu vier nicht zusammenhängende, empfangene Datenblöcke anzuzeigen. RFC 2883 definiert eine zusätzliche Verwendung der Felder der SACK TCP-Option, um doppelte Pakete zu bestätigen. Dadurch kann der Empfänger des TCP-Segments mit der SACK-Option ermitteln, ob er ein Segment unnötigerweise erneut übertragen hat, und daraufhin die Verarbeitung anpassen, um zukünftig erneute Übertragungen zu vermeiden. Je weniger erneute Übertragungen gesendet werden, desto besser ist der Gesamtdurchsatz.

RFC 3517: Ein auf einer konservativen selektiven Bestätigung (SACK) basierender Verlustwiederherstellungsalgorithmus für TCP

Bei der Implementierung von TCP/IP in Windows Server 2003 und Windows® XP werden SACK-Informationen lediglich verwendet, um zu ermitteln, welche TCP-Segmente ihr Ziel nicht erreicht haben. RFC 3517 definiert eine Methode zur Verwendung der SACK-Informationen für das Durchführen einer Verlustwiederherstellung, wenn doppelte Bestätigungen empfangen wurden. Dabei wird der Algorithmus für eine schnelle Wiederherstellung ersetzt, wenn SACK für eine Verbindung aktiviert ist. Der TCP/IP-Stack der nächsten Generation verfolgt die SACK-Informationen für jede Verbindung und überwacht eingehende Bestätigungen und doppelte Bestätigungen, um Verluste rascher zu korrigieren, wenn mehrere Segmente am Ziel nicht empfangen wurden.

RFC 4138: Forward-RTO-Wiederherstellung (F-RTO): Ein Algorithmus zum Ermitteln von Zeitüberschreitungen bei vermeidbaren erneuten Übertragungen mit TCP und dem Stream Control Transmission Protocol (SCTP)

Vermeidbare erneute Übertragungen von TCP-Segmenten können auftreten, wenn ein plötzlicher, zeitweiliger Anstieg der RTT registriert wird. Der F-RTO-Algorithmus verhindert vermeidbare erneute Übertragungen von TCP-Segmenten. In Umgebungen, in denen ein plötzliches, zeitweiliges Ansteigen der RTT z. B. durch den Wechsel eines drahtlosen Clients zu einem anderen Wireless-Zugriffspunkt verursacht wird, verhindert der F-RTO-Algorithmus erneute Segmentübertragungen und trägt damit zu einer raschen Wiederherstellung der normalen Senderate bei.

Weitere Informationen zu diesen Erweiterungen finden Sie unter Verbesserungen im Next Generation TCP/IP-Stack im Bereich Leistung.

Unerreichbarkeitserkennung für IPv4-Umgebungen (Neighbor Unreachability Detection)

Bei der Unerreichbarkeitserkennung handelt es sich um ein Feature von IPv6, bei dem ein Knoten verfolgt, ob ein benachbarter Knoten erreichbar ist. Dies ermöglicht eine bessere Fehlererkennung und Korrektur, wenn Knoten plötzlich nicht mehr verfügbar sind. Der TCP/IP-Stack der nächsten Generation unterstützt auch die Unerreichbarkeitserkennung für IPv4-Netzwerkverkehr, indem der Erreichbarkeitsstatus von IPv4-Umgebungsknoten im IPv4-Routecache verfolgt wird. Bei der IPv4-Unerreichbarkeitserkennung wird die Erreichbarkeit durch einen Austausch von Unicast-ARP-(Address Resolution Protocol-)Anfragen und ARP-Antworten oder durch die Verwendung von Protokollen auf höherer Ebene, wie z. B. TCP, ermittelt. Die IPv4-basierte Kommunikation profitiert von der IPv4-Unerreichbarkeitserkennung, indem nicht erreichbare benachbarte Knoten (einschließlich Routern) erkannt und gemeldet werden können.

Weitere Informationen zur Unerreichbarkeitserkennung finden Sie unter Verbesserungen im Next Generation TCP/IP-Stack im Bereich Leistung.

Änderungen bei der Identifizierung von deaktivierten Gateways

Die Identifizierung von deaktivierten Gateways in TCP/IP für Windows Server 2003 und Windows XP bietet eine Failover-Funktion, jedoch keine Failback-Funktion, bei der ein deaktiviertes Gateway erneut angewählt wird, um zu ermitteln, ob es mittlerweile verfügbar ist. Der TCP/IP-Stack der nächsten Generation bietet ein Failback für deaktivierte Gateways, indem regelmäßig versucht wird, TCP-Verkehr durch das zuvor als deaktiviert erkanntes Gateway zu senden. Wenn der durch das deaktivierte Gateway gesendete TCP-Verkehr erfolgreich ist, wechselt der TCP/IP-Stack der nächsten Generation das Standardgateway zum bislang als deaktiviert ermittelten Gateway. Die Unterstützung eines Failback für primäre Standardgateways kann einen schnelleren Durchsatz ermöglichen, indem Verkehr über das primäre Standardgateway des Subnetzes gesendet wird.

Änderungen bei der PMTU-Erkennung von Black Hole-Routern

Die in RFC 1191 definierte PMTU-(Path Maximum Transmission Unit-)Erkennung beruht auf dem Empfang der ICMP-(Internet Control Message Protocol-)Nachrichten "Destination Unreachable-Fragmentation Needed" und "Don’t Fragment Set" (DF) von Routern, in denen die MTU für die nächste Verbindung übermittelt wird. Mitunter werden jedoch nicht fragmentierbare Pakete ohne Warnung von Zwischenroutern verworfen. Diese Router werden als Black Hole-PMTU-Router bezeichnet. Außerdem werden ICMP-Nachrichten möglicherweise von Routern aufgrund der konfigurierten Firewallrichtlinien übergangen. Dadurch kann bei TCP-Verbindungen eine Zeitüberschreitung auftreten und die Verbindung beendet werden, da die Zwischenrouter ohne Warnung große TCP-Segmente, die erneuten Übertragungen dieser Segmente sowie die ICMP-Fehlermeldungen für die PMTU-Erkennung verwerfen.

Bei der PTMU-Black Hole-Router-Erkennung wird erkannt, wenn große TCP-Segmente erneut übertragen werden. Die PMTU für die Verbindung wird automatisch angepasst, anstatt sich auf den Erhalt der ICMP-Nachrichten "Destination Unreachable-Fragmentation Needed" und "DF Set" zu verlassen. In TCP/IP unter Windows Server 2003 und Windows XP ist die PTMU-Black Hole-Router-Erkennung in der Standardeinstellung deaktiviert, da durch eine Aktivierung die maximale Anzahl an erneuten Übertragungen für ein bestimmtes Segment erhöht wird.

Aufgrund der vermehrten Verwendung von Firewallregeln für das Blockieren von ICMP-Verkehr auf Routern aktiviert der TCP/IP-Stack der nächsten Generation in der Standardeinstellung die PTMU-Black Hole-Router-Erkennung, damit TCP-Verbindungen nicht beendet werden. Die PTMU-Black Hole-Router-Erkennung wird für eine TCP-Verbindung ausgelöst, wenn vollständige Segmente mit DF-Flag erneut übertragen werden. TCP setzt die PTMU für die Verbindung auf 536 Byte zurück und überträgt die Segmente erneut mit deaktivierter DF-Flag. Dadurch wird die TCP-Verbindung beibehalten, wenn auch möglicherweise bei einer geringeren PMTU-Größe als für diese Verbindung eigentlich vorhanden ist.

Routing-Compartments

Um ein unerwünschtes Weiterleiten von Verkehr zwischen Schnittstellen für virtuelle private Netzwerke (VPN), Terminal Server und Konfigurationen mit Anmeldungen für mehrere Benutzer zu vermeiden, unterstützt der TCP/IP-Stack der nächsten Generation Routing-Compartments. Bei einem Routing-Compartment handelt es sich um eine Kombination mehrerer Schnittstellen mit einer Anmeldesitzung, die über eigene IP-Routingtabellen verfügt. Ein Computer kann über mehrere, voneinander getrennte Routing-Compartments verfügen. Jede Schnittstelle kann nur zu einem einzigen Compartment gehören.

Wenn beispielsweise ein Benutzer über das Internet eine VPN-Verbindung mit der TCP/IP-Implementierung in Windows XP initialisiert, verfügt der Computer des Benutzers über eine teilweise Verbindung sowohl zum Internet und zu einem privaten Intranet, indem die Einträge in der IPv4-Routingtabelle geändert werden. Mitunter ist es möglich, Verkehr aus dem Internet über die VPN-Verbindung in das private Intranet weiterzuleiten. Bei VPN-Clients, die Routing-Compartments unterstützen, isoliert der TCP/IP-Stack der nächsten Generation die Internetverbindung mithilfe separater IP-Routingtabellen von der privaten Intranetverbindung.

Unterstützung für das Netzwerkdiagnose-Framework

Beim Netzwerkdiagnose-Framework handelt es sich um eine erweiterbare Architektur, die den Benutzern dabei hilft, Netzwerkverbindungsprobleme zu erkennen und zu beheben. Bei TCP/IP-basierter Kommunikation fordert das Netzwerkdiagnose-Framework den Benutzer über verschiedene Optionen auf, mögliche Ursachen zu entfernen, bis die zugrundeliegende Ursache des Problems identifiziert oder sämtliche möglichen Ursachen ausgeräumt sind. Folgende Probleme im Zusammenhang mit TCP/IP können vom Netzwerkdiagnose-Framework diagnostiziert werden:

Falsche IP-Adressen

Standardgateway (Router) ist nicht verfügbar

Falscher Standardgateway

Namensauflösungsfehler bei NetBIOS (Network Basic Input/Output System) über TCP/IP (NetBT)

Falsche DNS-Einstellungen

Lokaler Port wird bereits verwendet

DHCP-Clientdienst wird nicht ausgeführt

Kein Remotelistener

Medium ist nicht verbunden

Der lokale Port ist gesperrt

Unzureichender Speicher

ESTATS-Unterstützung

Der TCP/IP-Stack der nächsten Generation unterstützt den Internetentwurf "TCP Extended Statistics MIB" (draft-ietf-tsvwg-tcp-mib-extension-08.txt), der erweiterte Leistungsstatistiken für TCP definiert. Durch die Analyse von ESTATS für eine Verbindung kann ermittelt werden, ob Leistungsengpässe bei Verbindungen durch die sendende Anwendung, die empfangende Anwendung oder durch das Netzwerk verursacht werden. ESTATS ist in der Standardeinstellung deaktiviert und kann verbindungsweise aktiviert werden. Mithilfe von ESTATS können unabhängige Softwarehersteller leistungsstarke Diagnose- und Netzwerkdurchsatz-Analyseanwendungen erstellen.

Neues Paketfilterungsmodell mit der Windows-Filterungsplattform

Bei der Windows-Filterungsplattform (WFP) handelt es sich um eine neue Architektur im TCP/IP-Stack der nächsten Generation, die APIs bereitstellt, sodass unabhängige Softwarehersteller die Filterentscheidungen mitbestimmen können, die in den verschiedenen Schichten des TCP/IP-Protokollstapels und überall im Betriebssystem durchgeführt werden. Die Plattform integriert und unterstützt außerdem Firewallfeatures der nächsten Generation, z. B. authentifizierte Kommunikation und eine dynamische Firewallkonfiguration, die auf der Verwendung der Windows Sockets-API (anwendungsbasierte Richtlinie) durch die Anwendung basiert. Unabhängige Softwarehersteller können Firewalls, Antivirensoftware, Diagnosesoftware und weitere Arten von Anwendungen und Diensten erstellen. Windows Firewall und IPsec verwenden unter Windows Server 2008 und Windows Vista die WFP-API.

Weitere Informationen finden Sie unter Windows Filtering Platform (in englischer Sprache).

IPv6-Erweiterungen

Der TCP/IP-Stack der nächsten Generation unterstützt folgende Erweiterungen von IPv6:

Doppelter IP-Stack

Der TCP/IP-Stack der nächsten Generation unterstützt eine Architektur mit einer doppelten IP-Schicht, in der die IPv4- und IPv6-Implementierungen gemeinsame Transport- (einschließlich TCP und UDP) und Framingebenen verwenden. Im TCP/IP-Stack ist in der Standardeinstellung sowohl IPv4 als auch IPv6 aktiviert. Für eine IPv6-Unterstützung muss keine separate Komponente installiert werden.

In der Standardeinstellung aktiviert

In Windows Server 2008 und Windows Vista ist IPv6 in der Standardeinstellung installiert und aktiviert. IPv6 kann für Verbindungen deaktiviert werden, indem Sie im Ordner Connections and Adapters (Verbindungen und Netzwerkadapter) in den Eigenschaften einer Verbindung das Kontrollkästchen neben der Komponente Internet Protocol Version 6 (TCP/IPv6) deaktivieren. Alternativ kann die Deaktivierung in den Gruppenrichtlinien vorgenommen werden. IPv6-Einstellungen können über die Eigenschaften der Komponente Internet Protocol Version 6 (TCP/IPv6) und über Befehle im Kontext netsh interface ipv6 konfiguriert werden.

Konfiguration über die grafische Benutzeroberfläche

Windows Server 2008 und Windows Vista ermöglichen eine manuelle Konfiguration der IPv6-Einstellungen über verschiedene Dialogfelder im Ordner Connections and Adapters ähnlich der manuellen Konfiguration der IPv4-Einstellungen.

Teredo-Erweiterungen

Teredo ist für Computer, auf denen Windows Vista ausgeführt wird, sowie für Domänenmitgliedercomputer in der Standardeinstellung aktiviert. Teredo kann nun ausgeführt werden, wenn sich ein Teredo-Client hinter mindestens einem symmetrischen NAT (Network Address Translator) befindet. Ein symmetrischer NAT ordnet abhängig von der externen Zieladresse (für ausgehenden Verkehr) eine interne (private) Adresse und Portnummer verschiedenen externen (öffentlichen) Adressen und Ports zu. Dieses neue Verhalten ermöglicht es Teredo, zwischen einer größeren Reihe von mit dem Internet verbundenen Hosts ausgeführt zu werden.

Integrierte IPsec-Unterstützung

Unter Windows Server 2008 und Windows Vista entspricht die IPsec-Unterstützung für IPv6-Verkehr der für IPv4. Es werden Internet Key Exchange (IKE) und Datenverschlüsselung unterstützt. Die Windows Firewall mit erweiterten Sicherheits- und IP-Sicherheitsrichtlinien-Snap-Ins unterstützt nun die Konfiguration von IPsec-Richtlinien für IPv6-Verkehr ebenso wie für IPv4-Verkehr. Wenn beispielsweise im IP-Sicherheitsrichtlinien-Snap-In ein IP-Filter als Teil einer IP-Filterliste konfiguriert wird, können Sie nun beim Festlegen einer bestimmten Quell- oder Ziel-IP-Adresse unter IP Address or Subnet (IP-Adresse oder Subnetz) IPv6-Adressen und Adresspräfixe angeben.

MLDv2

Die in RFC 3810 definierte Multicast-Listener-Erkennung, Version 2 (Multicast Listener Discovery Version 2, MLDv2), bietet eine Unterstützung für quellspezifischen Multicastverkehr. MLDv2 entspricht dem Internet Group Management Protocol Version 3 (IGMPv3) für IPv4.

LLMNR

Die Link-Local-Multicast-Namensauflösung (Link-Local Multicast Name Resolution, LLMNR) ermöglicht IPv6-Hosts in einem einzelnen Subnetz ohne DNS-Server die gegenseitige Namensauflösung. Diese Möglichkeit ist in Heimnetzwerken mit einem Subnetz und in drahtlosen Ad-hoc-Netzwerken sinnvoll.

IPv6 über PPP

Der integrierte Remotezugriffsclient unterstützt nun IPv6 über das in RFC 2472 definierte Point-to-Point-Protokoll (PPP) (PPPv6). Systemeigener IPv6-Verkehr kann nun über PPP-basierte Verbindungen gesendet werden. So ermöglicht die PPPv6-Unterstützung beispielsweise das Herstellen einer Verbindung mit einem IPv6-basierten Internetdienstanbieter über DFÜ oder PPP über Ethernet-(PPPoE-)basierte Verbindungen, die für den Breitbandinternetzugriff verwendet werden können.

Zufällige Schnittstellen-IDs für IPv6-Adressen

Um Adressscans nach auf den bekannten Unternehmens-IDs von Netzwerkadapterherstellern basierenden IPv6-Adressen zu verhindern, werden unter Windows Server 2008 und Windows Vista in der Standardeinstellung zufällige Schnittstellen-IDs für nichttemporäre, automatisch konfigurierte IPv6-Adressen generiert. Dies gilt für öffentliche und Link-Local-Adressen.

DHCPv6-Unterstützung

Windows Server 2008 und Windows Vista beinhalten einen DHCPv6-fähigen DHCP-Client, der mit einem DHCPv6-Server eine statusbehaftete automatische Adresskonfiguration durchführt. Windows Server 2008 beinhaltet einen DHCPv6-fähigen DHCP-Serverdienst.

Weitere Informationen zu den IPv6-Änderungen in Windows Server 2008 und Windows Vista finden Sie unter Änderungen bezüglich IPv6 unter Windows Vista und Windows Server 2008.

QoS (Quality of Service)

In Windows Server 2003 und Windows XP wird die QoS-Funktionalität den Anwendungen über die generischen QoS-(GQoS-)APIs bereitgestellt. Anwendungen, die die GQoS-APIs verwendeten, konnten auf priorisierte Übermittlungsfunktionen zugreifen. Windows Server 2008 und Windows Vista verfügen über neue Möglichkeiten für die Verwaltung des Netzwerkverkehrs sowohl für Unternehmen als auch für Heimanwender.

Richtlinienbasierte QoS für Unternehmensnetzwerke

Die QoS-Richtlinien in Windows Server 2008 und Windows Vista ermöglichen es den IT-Mitarbeitern, die Senderate für ausgehenden Netzwerkverkehr zu priorisieren oder zu verwalten. Außerdem kann dieser bestimmten Anwendungen, Quell- und Ziel-IP-Adressen sowie Quell- und Ziel-TCP- oder UDP-Ports zugewiesen werden. Die QoS-Richtlinieneinstellungen sind Teil der Gruppenrichtlinine "User Configuration" (Benutzerkonfiguration) oder "Computer Configuration" (Computerkonfiguration) und werden mithilfe des Gruppenrichtlinienobjekt-Editors konfiguriert und über die Gruppenrichtlinien-Verwaltungskonsole mit Active Directory®-Verzeichnisdienstcontainern (Domänen, Standorten und Organisationseinheiten) verknüpft. QoS-Richtlinien können auf Benutzer und Computer angewendet werden, die Mitglieder einer Domäne, eines Standorts oder einer Organisationseinheit sind.

Um die Verwendung der Bandbreite zu verwalten, kann eine QoS-Richtlinie mit einer Begrenzungsrate für ausgehenden Verkehr konfiguriert werden. Die QoS-Richtlinie begrenzt auf diese Weise den ausgehenden Gesamtnetzwerkverkehr auf eine bestimmte Rate. Um eine priorisierte Übertragung festzulegen, wird der Verkehr mit einem konfigurierten Differentiated Services Code Point-(DSCP-)Wert gekennzeichnet. Die Router in der Netzwerkinfrastruktur können DSCP-gekennzeichnete Pakete in verschiedenen Warteschlangen für eine unterschiedliche Übertragung platzieren. Sowohl die DSCP-Kennzeichnung als auch die Begrenzung können gemeinsam verwendet werden, um den Netzwerkverkehr effektiv zu verwalten. Da die Begrenzung und Prioritätskennzeichnung auf Netzwerkebene erfolgt, müssen Anwendungen nicht geändert werden.

Weitere Informationen über richtlinienbasierte QoS finden Sie unter Quality of Service in Windows Server 2008 and Windows Vista (in englischer Sprache). Weitere Informationen zur Architektur der richtlinienbasierten QoS finden Sie unter Die richtlinienbasierte QoS-Architektur von Windows Server 2008 und Windows Vista.

qWave für Heimnetzwerke

Da Heimnetzwerke zunehmend sowohl für Daten- als auch für Audio/Video-(A/V-)Anwendungen verwendet werden, muss mithilfe einer QoS-Lösung dem zeitabhängigen A/V-Verkehr eine bevorzugte Behandlung vor dem Datenverkehr eingeräumt werden. Außerdem werden Heimnetzwerke zunehmend drahtlos eingerichtet, wodurch zusätzliche Komplikationen bei wartezeit- und bandbreitenanfälligen Anwendungen entstehen. Windows Vista unterstützt "Quality Windows Audio/Video Experience" (qWave), eine Sammlung von QoS-verwandten Softwaremodulen, die den Netzwerkanforderungen für A/V-Anwendungen und drahtlose Netzwerke Rechnung tragen. qWave ist in den Netzwerkstack als Teil des QoS-Subsystems integriert und verwendet mehrere Prioritätstechnologien für Netzwerk- und Datenverbindungsschichtpakete, um gleichzeitig mehrere A/V-Streams (Echtzeitübertragungen, die QoS erfordern) und Datenstreams (wie z. B. E-Mail- oder Dateiübertragungen) in einem Heimwerk sicher und zuverlässig zu übertragen.

Die Sammlung von qWave-Technologien ermittelt und überwacht die LAN-Bandbreite, erkennt die QoS-Fähigkeit des Heimnetzwerks und bietet eine verteilte Zugangskontrolle für eine ausgeglichene und konsistente Verwendung der Netzwerkbandbreite. Diese Technologien ermöglichen erweiterte AV-Streamingtechniken, sodass sich Anwendungen dynamisch an die variablen Netzwerkbedingungen anpassen können.

Weitere Informationen zu qWave finden Sie unter Quality Windows Audio-Video Experience - qWave (in englischer Sprache).

Http.sys-Erweiterungen

Http.sys, der Kernel-Modus-Treiber für Hypertext Transfer Protocol-(HTTP-)Verkehr, wurde in Windows Server 2008 und Windows Vista für folgende Elemente erweitert:

HTTP-Server-API 2.0

Serverseitige Authentifizierung

Protokollierung

Ereignisablaufverfolgung für Windows (ETW) für HTTP-Ereignisse

Netsh-Befehle

Leistungsindikatoren

HTTP-Server-API 2.0

Bei der HTTP-Server-API handelt es sich um einen HTTP-Protokolltreiber im Kernel-Modus, für den über Httpapi.dll APIs im Benutzermodus verfügbar sind. Die HTTP-Server-APIs ermöglichen einer Serveranwendung die Registrierung von HTTP-URLs sowie das Empfangen von Anfragen und von Dienstantworten. HTTP-Server-APIs beinhalten:

Benutzerfreundliche HTTP-Listener-Funktionalität für Windows sowohl für systemeigene als auch für verwaltete Windows .NET-Anwendungen.

Anwendungen können die HTTP-Server-API verwenden, um TCP-Ports gemeinsam mit Internet Information Services (IIS) 6.0 zu verwenden. Dadurch können viel genutzte TCP-Ports (z. B. 80 und 443) gleichzeitig sowohl von HTTP-Server-API-basierten als auch von IIS 6.0-Anwendungen verwendet werden, sofern diese verschiedene Teile des URL-Namespace bedienen.

Ein systemeigener HTTP-Stack für Computer, auf denen ein HTTP/1.1-kompatibles Windows-Betriebssystem ausgeführt wird.

Neue APIs für das Konfigurieren des HTTP-Servers: Authentifizierung, Bandbreitenbeschränkung, Protokollierung, Verbindungsbeschränkungen, Serverstatus, 503-Antworten, Anfragenwarteschlangen, Antwortzwischenspeicherung und SSL-Zertifikatbindung. Weitere Informationen finden Sie unter Using the HTTP Server Version 2.0 API (in englischer Sprache).

Serverseitige Authentifizierung

Http.sys führt nun eine serverseitige Authentifizierung durch. Bislang führten die Serveranwendungen eigene Authentifizierungen durch. Folgende Vorteile ergeben sich mit Http.sys bei serverseitiger Authentifizierung:

Serveranwendungen können unter geringer privilegierten Konten ausgeführt werden.

Serveranwendungen können unter verschiedenen Konten ausgeführt werden, da Http.sys nun die Service Principle Name-(SPN-)Authentifizierung für Anwendungen übernimmt.

Nahtlose NTLM-Authentifizierungs-Handshakes verursachen keinen Neustart des Handshakeprozesses.

Protokollierung

Http.sys bietet nun eine zentralisierte World Wide Web Consortium-(W3C-)Protokollierung, wobei alle Einträge für sämtliche Sites einer Serveranwendung (z. B. IIS) in einer einzigen Protokolldatei gespeichert werden. Innerhalb der zentralisierten Protokolldatei identifizieren ID-Felder die Site, zu der die Protokolleinträge gehören.

Ereignisablaufverfolgung für Windows (ETW) für HTTP-Ereignisse

Bei der Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW) handelt es sich um eine Möglichkeit, in Windows Informationen zu Komponenten und Ereignissen abzurufen, die in der Regel in Protokolldateien geschrieben werden. Mithilfe von ETW-Protokolldateien wird die Problembehebung deutlich erleichtert. Eine Ablaufverfolgung kann außerdem als Diagnose von End-to-End-Problemen dienen, bei der eine Aktivitäts-ID den Fluss durch die Vorgänge anzeigt. Http.sys unterstützt die Ablaufverfolgung für folgende Kategorien:

HTTP-Anforderungen und -Antworten

SSL- und Authentifizierungstransaktionen

Ereignisprotokollierung

Verbindungen und Verbindungszeitgeber

Zwischenspeicher

Dienst- oder Anwendungsinstallation; Einrichten oder Löschen von Eigenschaften

Aktivitäts-ID-basiert, einschließlich übergreifend über andere ETW-aktivierte Komponenten

Für jede Ablaufverfolgungskategorie unterstützt Http.sys vier Informationsebenen: Error, Warning, Informational und Verbose. Die Http.sys-Ablaufverfolgung kann als erweitertes Fehlerbehebungstool verwendet werden, um Informationen über die Prozesse und das Verhalten von Http.sys abzurufen.

Führen Sie folgende Schritte durch, um eine ETW-Ablaufverfolgungssitzung für Http.sys zu starten:

1.

Erstellen Sie einen Ordner, in dem die Ablaufverfolgungsdateien gespeichert werden sollen. Erstellen Sie in diesem Ordner die Datei Httptrace.txt mit folgendem Inhalt:

"Microsoft-Windows-HttpService" 0xFFFF

2.

Verwenden Sie folgenden Befehl, um die Ablaufverfolgung zu starten:

logman start "http trace" -pf httptrace.txt -o httptrace.etl -ets

3.

Führen Sie die Schritte oder Tests durch, für die die Ablaufverfolgung erfolgen soll.

Verwenden Sie folgenden Befehl, um die ETW-Ablaufverfolgungssitzung für Http.sys zu beenden:

logman stop "http trace" -ets

Im Ordner sollte nun die Ablaufverfolgungsdatei Httptrace.etl angezeigt werden. Diese Datei kann mithilfe des Tools Tracerpt.exe in das XML-Format, nach HTML oder in eine CSV-Datei konvertiert werden. Verwenden Sie beispielsweise folgenden Befehl, um die Inhalte der Datei Httptrace.etl in eine CSV-Datei zu konvertieren:

tracerpt httptrace.etl -y -o httptrace.csv

Die CSV-Dateien können anschließend in einem Texteditor oder einem Tabellenkalkulationsprogramm angezeigt werden.

Netsh-Befehle für Http.sys

Sie können nun die Konfigurationseinstellungen verwalten und die Diagnose für Http.sys über verschiedene Befehle im netsh http-Kontext steuern. Netsh ist ein Befehlszeilentool, das von vielen anderen Windows-Netzwerkdiensten verwendet wird (z. B. IPsec und Routing und RAS). Mithilfe dieser neuen Unterstützung können Sie an einer Windows-Eingabeaufforderung Folgendes durchführen:

Konfigurieren von SSL-Zertifikatbindungen, URL-Reservierungen, IP-Überwachungslisten oder globalen Zeitüberschreitungen

Löschen oder Leeren des HTTP-Zwischenspeichers oder Protokollieren von Puffern

Anzeigen des Status des Http.sys-Dienstes oder des Zwischenspeichers

Leistungsindikatoren für Http.sys

Http.sys verfügt nun über folgende Leistungsdatenindikatoren, die bei der Überwachung, Diagnose und Kapazitätsplanung von Webservern helfen sollen:

Leistungsindikatoren für HTTP-Dienste

Anzahl an URIs im Zwischenspeicher, hinzugefügt seit dem Start, gelöscht seit dem Start und Anzahl an Zwischenspeicherleerungen

Cachetreffer/Sekunde und Cachefehlversuche/Sekunde

HTTP-Dienst-URL-Gruppen

Datensenderate, Datenempfangsrate, übertragene Bytes (gesendet und empfangen)

Maximale Anzahl an Verbindungen, Verbindungsversuchsrate, Rate für GET- und HEAD-Anfragen und Gesamtanzahl an Anfragen

Anfragenwarteschlangen des HTTP-Dienstes

Anzahl der Anfragen in der Warteschlange, Alter der ältesten Anfrage in der Warteschlange

Rate der Anfrageeingänge in der Warteschlange, Ablehnungsrate, Gesamtzahl der abgelehnten Anfragen und Rate der Cachetreffer

Mithilfe dieser neuen Leistungsindikatoren können die entsprechenden Daten über das Diagnose-Konsolen-Snap-In angezeigt oder über die Leistungsindikatoren-API (Performance Counters API, Artikel in englischer Sprache) abgerufen werden.

WinINet-Erweiterungen

Zu den Erweiterungen der WinINet-API in Windows Server 2008 und Windows Vista gehören folgende Elemente:

Unterstützung für IPv6-Literale und Bereichs-IDs

Unterstützung für HTTP-Dekomprimierung

Unterstützung für internationalisierte Domänennamen

Unterstützung für die ETW-Ablaufverfolgung

IPv6-Unterstützung in Web Proxy Auto-Discovery-Skripts

Unterstützung für IPv6-Literale und Bereichs-IDs

WinINet unterstützt nun RFC 2732 und die Verwendung von IPv6-Literaladressen in URLs. So kann beispielsweise ein Benutzer mit einem WinINet-basierten Webbrowser (z. B. Internet Explorer) die Adresse http://[3ffe:ffff:100:2a5f::1] eingeben, um eine Verbindung mit dem Webserver unter der IPv6-Adresse 3ffe:ffff:100:2a5f::1 herzustellen. Obwohl gewöhnliche Benutzer möglicherweise keine IPv6-Literaladressen verwenden, ist die Möglichkeit, die IPv6-Adresse in einem URL anzugeben, für Anwendungsentwickler, Softwaretester und Netzwerkkonfliktlöser hilfreich. WinINet unterstützt außerdem die Codierung der IPv6-Bereichs-ID (auch als Zonen-ID bekannt) als Teil der Adresse, damit Benutzer den Bereich des IPv6-Ziels angeben können. Weitere Informationen finden Sie unter IP Version 6 Support (in englischer Sprache).

Unterstützung für HTTP-Dekomprimierung

WinINet beinhaltet nun eine integrierte Unterstützung für Codierungsschemas zur gzip- und deflate-Komprimierung. Bei der Verarbeitung der Dekomprimierung in WinINet werden Datenkomprimierungs-/dekomprimierungsprobleme zwischen Webbrowsern und Webservern reduziert, wobei gleichzeitig eine Leistungssteigerung durch reduzierte Downloadzeiten für Webseiten erreicht wird. Dies kann sich für Benutzer mit Verbindungen mit geringen Bandbreiten (z. B. DFÜ-Internetbenutzer) als äußerst vorteilhaft erweisen. Weitere Informationen finden Sie unter Content Encoding (in englischer Sprache).

Unterstützung für internationalisierte Domänennamen

WinINet folgt nun dem IDN-(Internationalized Domain Names-)Standard (RFC 3490) für Hostnamen unter Verwendung der Unicodeversionen der WinINet-API. Diese neue Unterstützung stellt sicher, dass Anwendungen ordnungsgemäß mit Domänennamen verwendet werden können, die nicht-ASCII-Zeichen enthalten. Dabei ist keine IDN-Unterstützung innerhalb der Webanwendung, keine Installation eines Plug-Ins von Drittanbietern und kein Zwischenknoten in einem Netzwerk-Kommunikationspfad erforderlich. Weitere Informationen finden Sie unter IDN Support in WinINet (in englischer Sprache).

Unterstützung für die ETW-Ablaufverfolgung

WinINet unterstützt nun die ETW-Ablaufverfolgung, die es dem IT-Helpdesk und Supportfachleuten ermöglicht, detaillierte Informationen zu WinINet-Prozessen und -Ereignissen abzurufen, die bei der Ermittlung der Quelle von Protokoll- oder Anwendungsproblemen helfen. Indem IDs für sämtliche WinINet-Ereignisse eingeschlossen werden, kann eine ETW-Ablaufverfolgungskette aufgebaut werden, die den gesamten Netzwerkstack umfasst, und die die IDs verwendet, um Ablaufverfolgungen von angrenzenden Netzwerkebenen zuzuordnen. Weitere Informationen zur ETW-Ablaufverfolgung finden Sie unter Event Tracing (in englischer Sprache).

IPv6-Unterstützung in Web Proxy Auto-Discovery-Skripts

Die von WinINet bereitgestellten Hilfsfunktionen für WPAD-(Web Proxy Auto-Discovery-)Skripts wurden aktualisiert, um Unterstützung für IPv6-Adressen und Subnetzpräfixe zu bieten. WPAD-Skripts, die die Proxy-Hilfs-APIs dnsResolve(), myIpAddress(), isInNet() und isResolvable() verwenden, können nun IPv6-Informationen von WinINet abrufen. Weitere Informationen zu WPAD finden Sie unter WinHTTP AutoProxy Support (in englischer Sprache).

WinHTTP-Erweiterungen

Zu den Aktualisierungen an der WinHTTP 5.1-API in Windows Server 2008 und Windows Vista gehören folgende Elemente:

Unterstützung für Datenuploads mit einer Größe von mehr als 4 Gigabyte

Unterstützung für eine aufgeteilte Übertragungscodierung

Unterstützung für ein Abrufen von Ausstellerlisten für die SSL-(Secure Sockets Layer-)basierte Clientauthentifizierung

Unterstützung für optionale Clientzertifikatsanfragen

Unterstützung für 4-Tupel-Verbindungsinformationsanzeige

Neue Fehlercodes für die SSL-Clientauthentifizierung

IPv6-Unterstützung in WPAD-Skripts

Unterstützung für Datenuploads mit einer Größe von mehr als 4 Gigabyte

WinHTTP ermöglicht es Anwendungen, einen Header "Content-Length" hinzuzufügen, um eine Datenlänge von bis zu 264 Byte festzulegen.

Unterstützung für eine aufgeteilte Übertragungscodierung

WinHTTP ermöglicht es Anwendungen, für deren Daten eine aufgeteilte Übertragungscodierung vorzunehmen und diese mithilfe der WinHttpWriteData()-API zu senden. WinHTTP erkennt das Vorhandensein eines Headers "Transfer-Encoding" und nimmt interne Anpassungen vor, um sicherzustellen, dass die Übertragung mit der HTTP 1.1-Spezifikation kompatibel ist.

Unterstützung für ein Abrufen von Ausstellerlisten für die SSL-(Secure Sockets Layer-)basierte Clientauthentifizierung

WinHTTP ermöglicht es Anwendungen, die einer Clientauthentifizierungsaufgabe zugeordnete Ausstellerliste abzurufen. Eine Ausstellerliste legt eine Liste von Zertifizierungsstellen fest, die vom Server für das Ausstellen von Clientzertifikaten autorisiert sind. Mithilfe dieser neuen Unterstützung kann eine WinHTTP-Anwendung das richtige Clientzertifikat für die Clientauthentifizierung ermitteln.

Unterstützung für optionale Clientzertifikatsanfragen

Einige HTTP-Sites fordern lediglich optional ein Clientzertifikat an. Wenn der Client nicht über ein Clientzertifikat für die Antwort auf die Anforderung verfügt, kann der Server andere Arten der HTTP-Authentifizierung verwenden oder stattdessen einen anonymen Zugriff gestatten. Um eine Zusammenarbeit mit solchen Serverkonfigurationen zu unterstützen, ermöglicht es WinHTTP Anwendungen, ein NULL-Clientzertifikat bereitzustellen, um dem Server anzuzeigen, dass kein Clientzertifikat für die SSL-Authentifizierung vorhanden ist.

Unterstützung für 4-Tupel-Verbindungsinformationsanzeige

Beim Abschluss einer WinHttpReceiveResponse()-API ermöglicht es WinHTTP einer Anwendung, den aus der Antwort resultierenden, der HTTP-Anfrage zugeordneten Quell- und Ziel-IP/Port abzufragen.

Neue Fehlercodes für die SSL-Clientauthentifizierung

WinHTTP beinhaltet nun Fehlercodes für folgende häufige Fehler bei der SSL-Clientauthentifizierung:

Das Clientzertifikat verfügt über keinen zugeordneten privaten Schlüssel. Dies liegt zumeist daran, dass ein Clientzertifikat ohne den privaten Schlüssel importiert wird.

Der Anwendungsthread, der WinHttpSendRequest() oder WinHttpReceiveResponse() aufruft, verfügt nicht über die Berechtigung, auf den dem bereitgestellten Clientzertifikat zugeordneten privaten Schlüssel zuzugreifen. Stellen Sie sicher, dass die Zugriffsteuerungsliste (Access Control List, ACL) dem privaten Schlüssel der Anwendung den Zugriff gestattet.

IPv6-Unterstützung in WPAD-Skripts

Die von WinHTTP bereitgestellten Hilfsfunktionen für WPAD-Skripts wurden aktualisiert, um Unterstützung für IPv6-Adressen und Subnetzpräfixe zu bieten. WPAD-Skripts, die die Proxy-Hilfs-APIs dnsResolve(), myIpAddress(), isInNet() und isResolvable() verwenden, können nun IPv6-Informationen von WinHTTP abrufen. Weitere Informationen zu WPAD finden Sie unter WinHTTP AutoProxy Support (in englischer Sprache).

Weitere Informationen zu Erweiterungen von WinHTTP in Windows Server 2008 und Windows Vista finden Sie unter What's New in Windows Longhorn und SSL in WinHTTP (jeweils in englischer Sprache).

Windows Sockets-Erweiterungen

Die Windows Sockets-(Winsock-)Unterstützung wurde um folgende Elemente erweitert:

Neue Winsock-APIs

Ereignisablaufverfolgung für Windows für Winsock-Ereignisse

Mehrschicht-Dienstanbieter-Erweiterungen

Winsock-Netzwerkdiagnose-Framework-Modul

Neue Sockets-API im Kernel-Modus

Neue Winsock-APIs

Windows Server 2008 und Windows Vista beinhalten folgende neue Winsock-APIs:

WSAConnectByName() Stellt eine Verbindung mit dem angegebenen Ziel her, sofern der Hostname des Ziels angegeben wurde. WSAConnectByName() versucht mithilfe sämtlicher bei der Namensauflösung zurückgegebenen Zieladressen und aller lokaler Adressen Verbindungen herzustellen, indem die Adresspaare mit der größten Erfolgsaussicht verwendet werden. Ein optimaler Zuordnungsalgorithmus des Transports ermittelt die Reihenfolge der Adresspaare. WSAConnectByName() stellt sicher, dass eine Verbindung (sofern möglich) in möglichst kurzer Zeit aufgebaut wird.

WSAConnectByList() Stellt eine Verbindung mit dem angegebenen Ziel her, sofern eine Liste der Ziel-IP-Adressen vorhanden ist. WSAConnectByList verwendet eine Liste der M-Adressen und der N-Adressen des lokalen Computers, und versucht mithilfe von bis zu M x N Adresskombinationen eine Verbindung herzustellen, bevor die Verbindung fehlschlägt.

Ereignisablaufverfolgung für Windows für Winsock-Ereignisse

Im Folgenden finden Sie einige Beispiele für Winsock-Ereignisse, die mithilfe der ETW-Ablaufverfolgung verfolgt werden können:

Socket creation (Socketerstellung)

Bind (Binden)

Connect (Verbinden)

Accept (Akzeptieren)

Send (Senden)

Recv (Empfangen)

Abort (Abbruchsanzeigen)

Die ETW-Ablaufverfolgung für Winsock-Ereignisse kann mithilfe folgender Elemente aktiviert werden:

Event Viewer-Snap-In (Ereignisanzeige)

Tools Logman.exe und Tracerpt.exe

Führen Sie folgende Schritte durch, um die ETW-Ablaufverfolgung für Winsock-Ereignisse mithilfe des Ereignisanzeige-Snap-Ins zu aktivieren:

1.

Führen Sie im Ordner Administrative Tools (Verwaltung) das Tool Event Viewer (Ereignisanzeige) aus.

2.

Öffnen Sie in der Struktur des Event Viewer-Snap-Ins Application Logs (Anwendungsprotokolle) und anschließend Microsoft-Windows-Winsock-AFD.

3.

Klicken Sie auf das Element Winsock/AFD.

4.

Klicken Sie im Menü Action (Aktion) auf Log Properties (Protokolleigenschaften).

5.

Klicken Sie im Dialogfeld Log Properties auf Enable Logging (Protokollierung aktivieren) und anschließend auf OK.

Klicken Sie im Bereich Action auf Refresh (Aktualisieren), um die Ereignisse anzuzeigen. Um die Protokollierung zu deaktivieren, deaktivieren Sie im Dialogfeld Log Properties das Kontrollkästchen Enable Logging für das Element Winsock/AFD.

Je nach Anzahl der anzuzeigenden Ereignisse muss möglicherweise die Protokollgröße geändert werden.

Verwenden Sie folgende Befehle, um die ETW-Ablaufverfolgung für Winsock-Ereignisse mithilfe des Tools Logman.exe zu aktivieren:

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

Es wird eine binäre Protokolldatei in LogFileLocation geschrieben. Um die vom Tool Logman.exe geschriebene binäre Datei in einen lesbaren Text zu konvertieren, verwenden Sie das Tool Tracerpt.exe. Verwenden Sie zum Beispiel folgenden Befehl:

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

Verwenden Sie folgenden Befehl, um die Protokollierung zu beenden:

logman stop afdlog

Mehrschicht-Dienstanbieter-Erweiterungen

Die Unterstützung für Winsock LSP (Layered Service Provider – Mehrschicht-Dienstanbieter) wurde in Windows Server 2008 und Windows Vista um folgende Elemente erweitert:

Die Installation und Entfernung von LSPs wird im Systemereignisprotokoll protokolliert, damit besser ermittelt werden kann, welche Anwendungen LSPs installieren. Außerdem wird die Fehlerbehebung fehlgeschlagener LSP-Installationen erleichtert. Verwenden Sie den Befehl netsh winsock audit trail, um die protokollierten Ereignisse in einem Konsolenfenster anzuzeigen.

Es ist eine neue Installations-API (WSCInstallProviderAndChains) verfügbar, die Softwarehersteller verwenden können, um im Winsock-Katalog einen LSP zu installieren. Eine manuelle Installation von LSPs kann mithilfe einer Reihe von Winsock-Funktionen erfolgen. Wenn dies jedoch nicht ordnungsgemäß durchgeführt wird, kann der Winsock-LSP-Katalog in einen inkonsistenten Status versetzt werden. Durch die Verwendung dieser neuen API kann ein Softwarehersteller, der einen LSP entwickelt, Hunderte von Codezeilen sparen.

Es sind neue Möglichkeiten für die Kategorisierung von LSPs und das Entfernen der meisten LSPs aus dem Verarbeitungspfad für systemwichtige Dienste verfügbar. Diese neuen Funktionen sorgen in Windows für eine höhere Stabilität, indem systemwichtige Dienste vor ungeeignet entwickelten LSPs geschützt werden.

Für das Netzwerkdiagnose-Framework ist ein Winsock-spezifisches Diagnosemodul vorhanden, mit dem Benutzer den Winsock-Katalog selektiv reparieren können, indem lediglich diejenigen LSPs entfernt werden, die Probleme verursachen.

Neue Sockets-API im Kernel-Modus

Die Netzwerkarchitektur von Windows Server 2008 und Windows Vista beinhaltet die neue Schnittstelle Winsock Kernel (WSK), die die TDI (Transport Driver Interface) ersetzen soll. WSK erleichtert Softwareherstellern die Entwicklung von Transporten (Protokolltreibern) in Windows. WSK beinhaltet eine neue Sockets-API im Kernel-Modus. Weitere Informationen finden Sie unter Windows Sockets in Kernel (in englischer Sprache).

NDIS 6.0

Windows Server 2008 und Windows Vista unterstützen Network Driver Interface Specification (NDIS) 6.0. NDIS legt eine Standardschnittstelle zwischen Netzwerktreibern im Kernel-Modus und dem Betriebssystem fest. NDIS legt außerdem eine Standardschnittstelle zwischen Mehrschicht-Netzwerktreibern fest, um zwischen untergeordneten Treibern für die Hardwareverwaltung und übergeordneten Treibern, wie z. B. Netzwerktransporten, zu abstrahieren. Weitere Informationen zu NDIS 6.0 finden Sie unter NDIS - Network Driver Interface Specification (in englischer Sprache).

NDIS 6.0 beinhaltet folgende Features:

Neue Verschiebeunterstützung

Unterstützung für einfache Filtertreiber

Empfangsseitige Skalierung

Neue Verschiebeunterstützung

NDIS 6.0 beinhaltet folgende eine neue Unterstützung für das Verschieben von Netzwerkverarbeitungsfunktionen auf Netzwerkadapter:

Verschieben von IPv6-Verkehr NDIS 5.1 in Windows Server 2003 und Windows XP unterstützt bereits das Verschieben der IPv4-Verkehrsverarbeitung. NDIS 6.0 unterstützt nun das Verschieben der IPv6-Verkehrsverarbeitung.

Prüfsummenverschiebung unterstützt IPv6 Das Verschieben von Prüfsummenberechnungen für IPv6-Verkehr wird nun unterstützt.

Giant Send Offload (Verschieben sehr großer Übertragungen) NDIS 5.1 unterstützt bereits das Verschieben großer Segmente (Large Segment Offload, LSO), bei der die Segmentierung von TCP-Daten für Datenblöcke von bis zu 64 Kilobyte (KB) verschoben wird. Beim Giant Send Offload (GSO) in NDIS 6.0 kann die Segmentierung von TCP-Daten für Datenblöcke verschoben werden, die größer als 64 Kilobyte (KB) sind.

Unterstützung für einfache Filtertreiber

In NDIS 6.0 wurden Zwischenfiltertreiber durch Treiber für einfache Filter (Lightweight Filter, LWF) ersetzt, bei denen es sich um eine Kombination eines NDIS-Zwischenfilters und eines Miniporttreibers handelt. LWF-Treiber verfügen jedoch über folgende Vorteile:

Es müssen nicht mehr länger ein separates Protokoll und ein Miniport geschrieben werden. Sämtliche Funktionen sind in einem einzelnen Treiber enthalten.

LWF-Treiber können dem Stack hinzugefügt oder aus diesem entfernt werden, ohne bestehende Verbindungen zu unterbrechen.

Verbesserte Leistung.

Ein Umgehungsmodus ermöglicht es dem LWF-Treiber, lediglich ausgewählte Steuerungs- und Datenpfade zu untersuchen.

Ein Beispiel für einen Zwischenfiltertreiber, der in einen LWF-Treiber konvertiert wurde, ist Pacer.sys (bislang Psched.sys). Er verfügt über dieselbe Funktionalität, nutzt jedoch die Vorteile der Leistungsverbesserungen von NDIS 6.0. Weitere Informationen und Beispiele finden Sie unter Windows Driver Kit (in englischer Sprache).

Empfangsseitige Skalierung

In der Architektur von Multiprozessorcomputern, auf denen Windows Server 2003 oder Windows XP ausgeführt wird, wird ein Netzwerkadapter einem einzelnen Prozessor zugeordnet. Dieser einzelne Prozessor muss den gesamten vom Netzwerkadapter empfangenen Verkehr verarbeiten. Dies gilt auch dann, wenn andere Prozessoren verfügbar sind. Eine solche Architektur führt bei hochvolumigen Servern wie Webservern mit Internetverbindung oder Unternehmensdateiservern dazu, dass die Menge an eingehendem Verkehr und die Anzahl an Verbindungen, die von dem dem Netzwerkadapter zugeordneten Prozessor verarbeitet werden können, beschränkt ist. Wenn der dem Netzwerkadapter zugeordnete Prozessor den eingehenden Verkehr nicht schnell genug verarbeiten kann, löscht der Netzwerkadapter den Verkehr, was zu erneuten Übertragungen und einer geringeren Leistung führt.

In Windows Server 2008 und Windows Vista wird ein Netzwerkadapter nicht einem einzelnen Prozessor zugeordnet. Stattdessen wird die Verarbeitung des eingehenden Verkehrs auf alle Prozessoren des Computers verteilt. Dank dieses neuen Features, der empfangsseitigen Skalierung (Receive-Side Scaling, RSS) kann auf einem hochvolumigen Server von einem Netzwerkadapter weit mehr Verkehr empfangen werden. Ein Multiprozessorcomputer kann nun mehr eingehenden Verkehr verarbeiten, ohne dass Server hinzugefügt werden müssen. Dies führt zu geringeren Kosten. Um die Vorteile des neuen Features nutzen zu können, müssen Sie RSS-fähige Netzwerkadapter installieren, die die neue Architektur in Windows Server 2008 und Windows Vista anwenden können. RSS-fähige Netzwerkadapter werden von vielen Netzwerkadapterherstellern angeboten.

Weitere Informationen finden Sie unter Scalable Networking with RSS (in englischer Sprache).

Windows Peer-zu-Peer-Netzwerkumgebungserweiterungen

Windows Peer-zu-Peer-Netzwerke, eingeführt mit dem erweiterten Netzwerkpaket für Windows XP, sind eine Betriebssystemplattform und eine API in Windows Vista, die die Entwicklung von Peer-zu-Peer-(P2P-)Anwendungen ermöglichen. Windows Vista beinhaltet folgende Erweiterungen zu Windows Peer-zu-Peer-Netzwerken:

Neue, benutzerfreundliche API Die APIs für den Zugriff auf Windows Peer-zu-Peer-Netzwerkfunktionen wie etwa die Namensauflösung, Gruppenerstellung und Sicherheit wurden in Windows Vista erheblich vereinfacht, um das Erstellen von P2P-Anwendungen für Windows zu erleichtern.

Neue Version von PNRP Windows Vista beinhaltet eine neue Version von PNRP, die skalierbarer ist und weniger Netzwerkbandbreite verwendet. Mit PNRP v2 in Windows Vista können Windows Peer-zu-Peer-Netzwerkanwendungen auf PNRP-Funktionen zur Namensveröffentlichung und Auflösung über eine vereinfachte PNRP-API zugreifen. Um die PNRP-Namensauflösung in Windows Vista erheblich zu vereinfachen, sind die PNRP-Namen nun in die Windows Sockets-Funktion getaddrinfo() integriert. Um PNRP für das Auflösen eines Namens für eine IPv6-Adresse zu verwenden, können Anwendungen die getaddrinfo()-Funktion verwenden, um den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) name.prnp.net aufzulösen, wobei name der aufzulösende Peername ist. Die Domäne pnrp.net ist eine in Windows Vista für die PNRP-Namensauflösung reservierte Domäne. Das PNRP v2-Protokoll ist nicht kompatibel mit dem PNRP-Protokoll, das von Computern mit Windows XP verwendet wird. Microsoft arbeitet an der Entwicklung und Veröffentlichung eines Updates der Windows Peer-zu-Peer-Netzwerkkomponenten in Windows XP, um PNRP v2 unterstützen zu können.

People Near Me (Benachbarte Benutzer) Eine neue Funktion der Windows Peer-zu-Peer-Netzwerke für Windows Vista, mit der Benutzer dynamisch andere Benutzer im lokalen Subnetz und für diese Benutzer registrierte Anwendungen mit Unterstützung für "People Near Me" erkennen und Benutzer zu einer Zusammenarbeitsaktivität einladen können. Durch die Einladung und das Akzeptieren der Einladung wird auf dem Computer des eingeladenen Benutzers eine Anwendung gestartet. Die beiden Anwendungen nehmen nun an einer Zusammenarbeitsaktivität teil (z. B. einem Chat, der Freigabe von Fotos oder einem Spiel).

P2P-basierte Meetinganwendung Windows Vista beinhaltet eine neue P2P-basierte Anwendung für Ad-hoc-Meetings, die die Windows Peer-zu-Peer-Netzwerkfunktionalität verwendet.

Windows Firewall

Die neue Windows Firewall in Windows Server 2008 und Windows Vista wurde gegenüber der aktuellen Windows Firewall in Windows XP mit Service Pack 2 und Windows Server 2003 mit Service Pack 1 folgendermaßen erweitert:

Unterstützung sowohl für eingehenden als auch für ausgehenden Verkehr

Ein Netzwerkadministrator kann die neue Windows Firewall mit einer Reihe von Ausnahmen so konfigurieren, dass jeglicher, an bestimmte Ports gesendete Verkehr blockiert wird. Hierbei kann es sich um als virenanfällig bekannte Ports oder um bestimmte Adressen handeln, die geschützte oder unerwünschte Inhalte bereitstellen.

Neue Windows Firewall mit erweitertem MMC-(Microsoft Management Console-)Sicherheits-Snap-In für die Konfiguration über eine grafische Benutzeroberfläche

Die neue Windows Firewall mit dem erweiterten Sicherheits-Snap-In bietet Assistenten für das Konfigurieren von Ausnahmen und Sicherheitsregeln. Für die Befehlszeilenkonfiguration der erweiterten Einstellungen der neuen Windows Firewall können Sie die Befehle im netsh advfirewall-Kontext verwenden.

Integrierte Firewall-Filterung und IPsec-Schutzeinstellungen

Mithilfe der Windows Firewall mit erweitertem Sicherheits-Snap-In können Sie sowohl die Firewall-Filterung als auch die Regeln für geschützten Datenverkehr konfigurieren.

Erweiterte Konfigurationen für Ausnahmen

Die Firewall-Filterungsausnahmen können für Quell- und Ziel-IP-Adressen, IP-Protokollnummern, Quell- und Ziel-TCP-und UDP-(User Datagram Protocol-)Ports, alle oder mehrere TCP- oder UDP-Ports, bestimmte Arten von Schnittstellen, ICMP und ICMP für IPv6-(ICMPv6-)Verkehr nach Typ und Code sowie für Dienste konfiguriert werden.

Weitere Informationen zu diesen Verbesserungen finden Sie unter Die neue Windows-Firewall in Windows Vista und Windows Server 2008.

IPsec-Verbesserungen

Windows Server 2008 und Windows Vista beinhalten folgende Verbesserungen der Internetprotokollsicherheit (Internet Protocol Security, IPsec):

Integrierte Firewall- und IPsec-Konfiguration

Vereinfachte IPsec-Richtlinienkonfiguration

IPsec-Schutz von Client zu Domänencontroller

Verbesserter Lastausgleich und Unterstützung für Clusteringserver

Verbesserte IPsec-Authentifizierung

Neue Kryptografieunterstützung

Integration mit NAP (Network Access Protection)

Zusätzliche Konfigurationsoptionen für geschützte Kommunikation

Integrierte IPv4- und IPv6-Unterstützung

Erweiterte Ereignis- und Leistungsüberwachungsindikatoren

Unterstützung für das Netzwerkdiagnose-Framework

Integrierte Firewall- und IPsec-Konfiguration

In Windows Server 2003 und Windows XP handelte es sich bei Windows Firewall und IPsec um Komponenten und Dienste, die separat konfiguriert werden mussten. Zwar war es der Zweck der Windows Firewall, eingehenden Verkehr zu sperren oder zuzulassen, IPsec konnte jedoch auch für das Sperren oder das Zulassen eingehenden Verkehrs konfiguriert werden. Da das Verhalten hinsichtlich des Sperrens oder Zulassens von eingehendem Verkehr über zwei unterschiedliche und separate Dienste konfiguriert werden konnte, bestand die Möglichkeit doppelter oder sich widersprechender Einstellungen. Außerdem unterstützten Windows Firewall und IPsec verschiedene Konfigurationsoptionen für das Festlegen zulässigen eingehenden Verkehrs. So gestattete beispielsweise die Windows Firewall Ausnahmen (zulässigen eingehenden Verkehr), indem der Anwendungsname angegeben wurde. Bei IPsec war dies nicht der Fall. IPsec ermöglichte im Gegensatz zur Windows Firewall auf einer IP-Protokollnummer basierende Ausnahmen.

In Windows Server 2008 und Windows Vista wurden die Windows Firewall und IPsec in einem konfigurierbaren Tool zusammengefasst, der neuen Windows Firewall mit erweitertem Sicherheits-Snap-In, die sowohl die herkömmlichen Firewall-Aufgaben (Sperren und Zulassen von ein- und ausgehendem Verkehr) als auch den Schutz des Verkehrs mit IPsec steuert. Zusätzlich können die Befehle im netsh advfirewall-Kontext für die Befehlszeilenkonfiguration sowohl des Firewall- als auch des IPsec-Verhaltens verwendet werden. Die Integration von Windows Firewall mit IPsec bietet Computern, auf denen Windows Server 2008 oder Windows Vista ausgeführt wird, eine authentifizierende Firewall.

Vereinfachte IPsec-Richtlinienkonfiguration

In Windows Server 2003 und Windows XP besteht die IPsec-Richtlinienkonfiguration in vielen Szenarios (z. B. einer Server- oder Domänenisolation) aus einer Reihe von Regeln, um den größten Teil des Verkehrs im Netzwerk zu schützen sowie aus weiteren Regeln, um Ausnahmen für geschützten Verkehr aufzustellen. Ausnahmen sind für eine ungeschützte Kommunikation mit Netzwerkinfrastrukturservern wie z. B. DHCP- und DNS-Servern sowie Domänencontrollern erforderlich. Beim Starten eines Computers muss dieser in der Lage sein, eine IP-Adresse abzurufen, DNS zu verwenden, um einen Domänencontroller zu finden, und sich anschließend an der Domäne anzumelden. Erst anschließend kann die Kerberos-Authentifizierung verwendet werden, damit sich der Computer als IPsec-Peer authentifizieren kann. Andere Ausnahmen sind für die Kommunikation mit nicht IPsec-fähigen Netzwerkknoten erforderlich. In einigen Fällen gibt es Dutzende oder Hunderte von Ausnahmen. Dadurch wird das Bereitstellen und langfristige Beibehalten des IPsec-Schutzes in einem privaten Netzwerk erschwert.

IPsec bietet in Windows Server 2008 und Windows Vista ein optionales Verhalten beim Aushandeln des IPsec-Schutzes. Wenn diese Option aktiviert ist versucht ein IPsec-Knoten, auf dem Windows Server 2008 oder Windows Vista ausgeführt wird, beim Aufbau der Kommunikation mit einem anderen Netzwerknoten, normal zu kommunizieren und gleichzeitig eine geschützte Kommunikation auszuhandeln. Wenn der initiierende IPsec-Peer keine Antwort auf den ersten Aushandlungsversuch erhält, wird die normale Kommunikation fortgeführt. Wenn der initiierende IPsec-Peer eine Antwort erhält, wird die normale Kommunikation angehalten, bis die Aushandlung abgeschlossen ist.

Mithilfe dieses optionalen Verhaltens und der empfohlenen Konfiguration für die Schutzanforderung für eingehende initiierte Kommunikation und den Anfrageschutz für ausgehende initiierte Kommunikation erkennt der initiierende Knoten, ob der Knoten, mit dem eine Kommunikation aufgebaut wird, IPsec-fähig ist und sich entsprechend verhält, wodurch die IPsec-Richtlinienkonfiguration erheblich vereinfacht wird. So benötigt der initiierende Knoten beispielsweise keine vordefinierten IPsec-Filter für Ausnahmen für Hosts, die Netzwerkverkehr mit IPsec nicht schützen sollen oder können. Der initiierende Knoten versucht parallel, eine geschützte und ungeschützte Kommunikation herzustellen. Wenn keine geschützte Kommunikation möglich ist, wird eine ungeschützte Kommunikation verwendet.

Dieses neue Aushandelverhalten verbessert außerdem die Leistung von ungeschützten Verbindungen mit Hosts. Ein IPsec-Knoten mit Windows Server 2003 oder Windows XP, der für das Anfordern geschützter Kommunikation und das Zulassen ungeschützter Kommunikation konfiguriert ist (ein so genanntes "Fallback to Clear"-Verhalten), sendet die Aushandlungsmeldungen und wartet anschließend auf eine Antwort. Der initiierende Knoten wartete bis zu drei Sekunden vor dem "Fallback to Clear" und dem Versuch einer ungeschützten Verbindung. Unter Windows Server 2008 und Windows Vista besteht beim "Fallback to Clear" keine Verzögerung mehr, da die normale Kommunikation bereits in Bearbeitung ist, während der initiierende Knoten noch auf eine Antwort wartet.

IPsec-Schutz von Client zu Domänencontroller

In Windows Server 2003 und Windows XP gilt aktuell die Empfehlung von Microsoft, den IPsec-Schutz nicht zu verwenden, um den Verkehr zwischen Domänencontrollern und Mitgliedercomputern zu schützen (der Schutz des Verkehrs zwischen Domänencontrollern wird jedoch empfohlen). Dies liegt daran, dass die IPsec-Richtlinienkonfiguration aufgrund der verschiedenen Verkehrstypen, die zwischen Domänenmitgliedern und Domänencontrollern gesendet werden, äußerst komplex werden kann. Außerdem besteht ein Bootstrap-Problem bei Beitritt zu einer Domäne. Wenn der Domänencontroller IPsec-geschützten Verkehr von Computern erfordert, die domänenbasierte Anmeldeinformationen für die Authentifizierung angeben müssen, können Computer, die nicht Mitglieder der Domäne sind, keinen Domänencontroller kontaktieren, um der Domäne beizutreten.

Windows Server 2008 und Windows Vista unterstützen den Schutz von Verkehr zwischen Domänenmitgliedern und Domänencontrollern in folgenden Bereitstellungsmodi:

Aufgrund des neuen Aushandlungsverhaltens müssen für Domänencontroller keine Ausnahmen mehr konfiguriert werden, wodurch die IPsec-Richtlinie und die Bereitstellung des IPsec-Schutzes in einer Domäne vereinfacht werden.

Die IPsec-Richtlinie der Domäne kann so konfiguriert werden, dass geschützter Verkehr zwar angefordert wird, jedoch nicht erforderlich ist.

Domänencontroller schützen den größten Teil des Verkehrs mit Domänenmitgliedern, gestatten jedoch unverschlüsselte Kommunikation für Domänenbeitritte und andere Verkehrstypen.

Die IPsec-Richtlinie kann so konfiguriert werden, dass für Domänencontroller geschützter Verkehr erforderlich ist.

Wenn ein Computer mit Windows Longhorn "Server" oder Windows Vista versucht, der Domäne beizutreten, wird der Benutzer aufgefordert, den Benutzernamen und das Kennwort eines Domänenbenutzerkontos anzugeben. IPsec mit dem Domänencontroller wird mithilfe von Windows NT/LAN Manager Version 2-(NTLM v2-)Benutzeranmeldinformationen für einen geschützten Domänenbeitritt ausgehandelt. Diese neue Verhalten ist lediglich für Domänenmitgliedercomputer, auf denen entweder Windows Vista oder Windows Server 2008, und für Domänencontroller verfügbar, auf denen Windows Server 2008 ausgeführt wird.

Verbesserter Lastausgleich und Unterstützung für Clusteringserver

IPsec unterstützt unter Windows Server 2003 Lastausgleich und Clusterserver. Es treten jedoch beim erneuten Aufbauen einer IPsec-Verbindung mit einer virtuellen Cluster-IP-Adresse folgende Failoverzeiten auf:

In der Regel 3 - 6 Sekunden für administrative Verschiebungen von gruppierten Ressourcen.

Bis zu zwei Minuten, wenn ein Clusterknoten plötzlich nicht mehr verfügbar ist, oder wenn ein anderer plötzlicher Verbindungsverlust auftritt. Die Zeitüberschreitung von zwei Minuten beinhaltet eine Minute bis zum Ablauf der IPsec-Leerlaufzeit sowie eine Minute, in der die SAs neu ausgehandelt werden. Durch die lange Leerlaufzeit können aktive TCP-Verbindungen mit dem Cluster fehlschlagen.

In Windows Server 2008 und Windows Vista wurde die Zeitüberschreitung für einen Clusterknotenfehler erheblich reduziert. IPsec ist in Windows Server 2008 und Windows Vista enger in den TCP/IP-Stack der nächsten Generation integriert. Anstatt IPsec-Leerlaufzeitlimits für die Erkennung eines Clusterknotenfehlers zu verwenden, überwacht IPsec in Windows Server 2008 und Windows Vista TCP-Verbindungen für vorhandene SAs. Wenn TCP-Verbindungen für vorhandene SAs Segmente neu zu übertragen beginnen, handelt IPsec die SAs erneut aus. Dadurch wird der Failover zu einem Clusterknoten beschleunigt. Dies geschieht in der Regel so rechtzeitig, dass die Anwendung nicht fehlschlägt.

Verbesserte IPsec-Authentifizierung

IPsec unterstützt in Windows Server 2003 und Windows XP bei den Hauptmodusaushandlungen Internet Key Exchange (IKE) und drei Authentifizierungsmethoden: Kerberos (für Active Directory-Domänenmitglieder), digitale Zertifikate und einen vorinstallierten Schlüssel. Für sämtliche dieser Authentifizierungsmethoden wird beim Authentifizierungsprozess anstelle des Computerbenutzers die Identität und die Vertrauenswürdigkeit eines Computers geprüft. IKE versucht lediglich eine Authentifizierung mithilfe einer einzigen Authentifizierungsmethode.

Windows Server 2008 und Windows Vista unterstützen folgende Funktionen für die IPsec-Authentifizierung:

Optionale Anforderung eines Health Certificate (Integritätszertifikats) von IPsec-Peers

Ein Integritätszertifikatserver gibt ein Integritätszertifikat heraus, wenn ein NAP-Client nachweisen kann, dass sein Integritätsstatus mit der aktuellen Integritätsrichtlinie übereinstimmt. Weitere Informationen zur NAP-Plattform finden Sie in diesem Artikel unter "Network Access Protection (NAP)".

Optionale Angabe einer benutzer- oder integritätsbasierten Authentifizierung im erweiterten Modus

IPsec definiert in Windows Server 2008 und Windows Vista den erweiterten Modus als einen neuen Aushandlungsmodus. Im erweiterten Modus kann IPsec unter Windows Server 2008 und Windows Vista eine zusätzliche Authentifizierungsebene durchführen. Die bei der Authentifizierung im erweiterten Modus verwendeten Anmeldeinformationen können auf folgenden Informationen basieren:

Kerberos-Anmeldeinformationen des angemeldeten Benutzerkontos

NTLM v2-Anmeldeinformationen des angemeldeten Benutzerkontos

Ein Benutzerzertifikat

Ein Computerintegritätszertifikat (Health Certificate)

Die Authentifizierung im erweiterten Modus kann mit oder ohne eine Hauptmodusauthentifizierung erfolgen. So können beispielsweise eine Hauptmodusauthentifizierung und die Kerberos-Anmeldeinformationen verwendet werden, um den Computer zu authentifizieren, und anschließend mithilfe der Authentifizierung im erweiterten Modus und eines Integritätszertifikats der Integritätsstatus des Computers überprüft werden.

Mehrere Authentifizierungsmethoden werden geprüft

In Windows Server 2003 und Windows XP können für die Hauptmodus-IPsec-Authentifizierung mehrere Authentifizierungsmethoden nach Priorität ausgewählt werden. Für die Authentifizierung wird jedoch lediglich eine Authentifizierungsmethode verwendet. Wenn der Authentifizierungsprozess für die ausgehandelte Authentifizierungsmethode fehlschlägt, schlägt auch der Hauptmodus fehl, und der IPsec-Schutz kann nicht durchgeführt werden. Bei der Auswahl mehrerer Authentifizierungsmethoden für Computer, auf denen Windows Server 2008 oder Windows Vista ausgeführt wird, unternimmt IPsec mehrere Authentifizierungsversuche, um eine gegenseitige Authentifizierung durchzuführen. Wenn Sie beispielsweise festlegen, dass die Authentifizierung mithilfe von Kerberos und Computerzertifikaten mit einer bestimmten Zertifizierungsstelle (in dieser Reihenfolge) erfolgen soll, kann der IPsec-Peer beim Fehlschlagen der Kerberos-Authentifizierung den Versuch einer Zertifikatauthentifizierung unternehmen.

Neue Kryptografieunterstützung

Als Reaktion auf die Sicherheitsanforderungen von Regierungsbehörden und auf Trends in der Sicherheitsbranche, eine leistungsstärkere Kryptografie zu unterstützen, unterstützen Windows Server 2008 und Windows Vista zusätzliche Schlüsselableitungs- und Verschlüsselungsalgorithmen.

Windows Server 2008 und Windows Vista unterstützen folgende zusätzliche Algorithmen für das Aushandeln des Hauptschlüsselmaterials, das bei der Aushandlung im Hauptmodus abgeleitet wurde:

Diffie-Hellman-(DH-)Gruppe 19, ein elliptischer Kurvenalgorithmus, der eine zufällige 256-Bit-Kurvengruppe verwendet (NIST-ID P-256)

DH-Gruppe 20, ein elliptischer Kurvenalgorithmus, der eine zufällige 384-Bit-Kurvengruppe verwendet (NIST-ID P-384)

Diese Methoden sind leistungsstärker als die in Windows Server 2003 und Windows XP mit Service Pack 2 unterstützten und in Windows Server 2008 und Windows Vista ebenfalls enthaltenen Diffie-Hellman-(DH-)768, DH-1024- und DH-2048-Algorithmen. Weitere Informationen zu diesen Algorithmen finden Sie im Internetentwurf "ECP Groups For IKE and IKEv2". Diese neuen DH-Algorithmen können auf Computern nicht für die Aushandlungen im Hauptmodus verwendet werden, auf denen Windows Server 2003, Windows XP oder Windows 2000 ausgeführt wird.

Zusätzlich zu Data Encryption Standard (DES) und Triple-DES (3DES) unterstützen Windows Server 2008 und Windows Vista für das Verschlüsseln von Daten folgende weitere Algorithmen:

Advanced Encryption Standard (AES) mit Verschlüsselungsblockverkettung (Cipher Block Chaining, CBC) und einer Schlüsselgröße von 128 Bit (AES 128)

AES mit CBC und einer Schlüsselgröße von 192 Bit (AES 192)

AES mit CBC und einer Schlüsselgröße von 256 Bit (AES 256)

Diese neuen Verschlüsselungsalgorithmen können nicht für die Sicherheitszuordnung auf Computern verwendet werden, auf denen Windows Server 2003, Windows XP oder Windows 2000 ausgeführt wird.

Integration mit NAP (Network Access Protection)

Mithilfe der neuen NAP-Plattform können Sie festlegen, dass IPsec-Knoten sich bei der Aushandlung im erweiterten Modus mit einem Integritätszertifikat (Health Certificate) authentifizieren, sodass geprüft werden kann, ob der IPsec-Knoten den aktuellen Systemintegritätsanforderungen entspricht. Ein Integritätszertifikatserver gibt ein Integritätszertifikat heraus, nachdem der Integritätsstatus eines IPsec-Peers von einem Netzwerkrichtlinienserver (Network Policy Server, NPS) überprüft wurde. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "Network Access Protection (NAP)".

Zusätzliche Konfigurationsoptionen für geschützte Kommunikation

Bei der Konfiguration der IPsec-Richtlinie mit der neuen Windows Firewall mit erweitertem Sicherheits-Snap-In kann eine geschützte Kommunikation mithilfe der folgenden neuen Einstellungen konfiguriert werden:

Nach Anwendungsname Hierdurch wird die Konfiguration geschützten Verkehrs erheblich vereinfacht, da die von der Anwendung verwendeten Ports nicht manuell konfiguriert werden müssen.

Alle oder mehrere Ports Sie können nun alle TCP- oder UDP-Ports oder mehrere TCP- oder UDP-Ports in einer durch Kommas getrennten Liste angeben, wodurch die Konfiguration vereinfacht wird.

Für alle Adressen in einem numerischen Bereich Sie können nun einen IP-Adressbereich als numerischen Wert angeben, wie z. B. 10.1.17.23 bis 10.1.17.219.

Für alle Adressen im lokalen Subnetz Eine Reihe vordefinierter Adressen, die dynamisch den durch ihre IPv4-Adresse, die Subnetzmaske oder ihre lokale IPv6-Subnetzpräfix definierten Adressen zugeordnet werden.

Für alle drahtlosen Adapter Sie können den Verkehr basierend auf dem Schnittstellentyp schützen. Hierzu gehört nun zusätzlich zu LAN und Remotezugriff auch drahtloser Zugriff.

Nach Active Directory-Benutzer- oder Computerkonto Sie können eine Liste von Computer- oder Benutzerkonten bzw. -gruppen angeben, die autorisiert sind, eine geschützte Kommunikation zu initiieren. So können Sie beispielsweise festlegen, dass der Verkehr zu bestimmten Servern mit wichtigen Daten geschützt werden muss und nur von bestimmten Benutzerkonten in bestimmten Active Directory-Sicherheitsgruppen stammen darf.

Nach ICMP- oder ICMPv6-Typ oder Codewert Sie können ICMP- oder ICMPv6-Nachrichten festlegen, indem Sie die ICMP- oder ICMPv6-Nachrichtentypen und Codefeldwerte angeben.

Für Dienste Sie können festlegen, ob die Ausnahme für sämtliche Prozesse, nur für Dienste oder nach Dienstname oder durch Eingabe des Kurznamens eines Dienstes für einen bestimmten Dienst gelten soll.

Integrierte IPv4- und IPv6-Unterstützung

Die IPsec-Unterstützung für IPv6-Verkehr ist in Windows XP und Windows Server 2003 eingeschränkt. Es ist keine Unterstützung für Internet Key Exchange (IKE) oder eine Datenverschlüsselung vorhanden. IPsec-Sicherheitsrichtlinien, Sicherheitszuordnungen und Schlüssel müssen über Textdateien konfiguriert und über ein Befehlszeilentool (IPsec6.exe) aktiviert werden.

Unter Windows Server 2008 und Windows Vista entspricht die IPsec-Unterstützung für IPv6-Verkehr der für IPv4. Es werden IKE und Datenverschlüsselung unterstützt. Die Richtlinieneinstellungen sowohl für IPv4 als auch für IPv6-Verkehr werden auf dieselbe Weise konfiguriert, indem entweder die Windows Firewall mit erweiterter Sicherheit oder die IP-Sicherheitsrichtlinien-Snap-Ins verwendet werden.

Erweiterte Ereignis- und Leistungsüberwachungsindikatoren

Windows Server 2008 und Windows Vista beinhalten 15 neue überwachungsspezifische IPsec-Ereignisse. Der Text für 25 vorhandene Ereignisse wurde um weitere hilfreiche Informationen aktualisiert. Diese Verbesserungen helfen bei der Problembehandlung fehlgeschlagener IPsec-Aushandlungen ohne die erweiterte Oakley-Protokollierungsfunktion aktivieren zu müssen.

Windows Server 2008 und Windows Vista beinhalten außerdem IPsec-Leistungsindikatoren, die bei der Identifizierung von Leistungs- und Netzwerkproblemen mit IPsec-geschütztem Verkehr helfen.

Unterstützung für das Netzwerkdiagnose-Framework

Beim Netzwerkdiagnose-Framework handelt es sich um eine erweiterbare Architektur, die den Benutzern dabei hilft, Netzwerkverbindungsprobleme zu erkennen und zu beheben. Bei einer fehlgeschlagenen IPsec-Aushandlung bietet das Netzwerkdiagnose-Framework dem Benutzer die Möglichkeit an, das Problem zu identifizieren und zu beheben. Die IPsec-Unterstützung für das Netzwerkdiagnose-Framework versucht anschließend, die Quelle der fehlgeschlagenen Verbindung zu ermitteln und das Problem entweder manuell zu beheben oder, abhängig von Sicherheitsüberlegungen, den Benutzer aufzufordern, die geeignete Konfigurationsänderung durchzuführen.

Zum SeitenanfangZum Seitenanfang

Drahtlose und 802.1X-basierte verdrahtete Verbindungen

Windows Server 2008 und Windows Vista beinhalten viele Erweiterungen für die Unterstützung von drahtlosen IEEE 802.11-Netzwerken und Netzwerken, die authentifizierende Switches verwenden.

Änderungen und Erweiterungen für drahtlose IEEE 802.11-Netzwerke

Windows Server 2008 und Windows Vista beinhalten die folgenden Änderungen und Erweiterungen für die Unterstützung von drahtlosen IEEE 802.11-Netzwerken:

Systemeigene Wi-Fi-Architektur

Verbesserungen der Benutzeroberfläche für drahtlose Verbindungen

Erweiterungen der Richtlinine für Drahtlosnetzwerke

Änderungen an der Wireless Auto Configuration

WPA2-Unterstützung

Einmalige Anmeldung (Single Sign-on)

Integration mit NAP bei der Verwendung der 802.1X-Authentifizierung

EAPHost-Infrastruktur

Drahtlose 802.11-Diagnose

Befehlszeilenunterstützung für die Konfiguration drahtloser Einstellungen

Network Location Awareness und Netzwerkprofile

Erweiterungen des TCP/IP-Stacks der nächsten Generation für drahtlose Umgebungen

Systemeigene Wi-Fi-Architektur

In Windows Server 2003 und Windows XP wurde die Softwareinfrastruktur für die Unterstützung drahtloser Verbindungen entwickelt, um eine Ethernetverbindung zu emulieren. Sie kann nur erweitert werden, indem zusätzliche EAP-Typen für die IEEE 802.1X-Authentifizierung unterstützt werden. In Windows Server 2008 und Windows Vista wurde die Softwareinfrastruktur für drahtlose 802.11-Verbindungen, die so genannte systemeigene Wi-Fi-Architektur, folgendermaßen neu entwickelt:

IEEE 802.11 stellt in Windows nun einen von IEEE 802.3 separaten Medientyp dar. Daher verfügen unabhängige Softwareanbieter über eine größere Flexibilität bei der Unterstützung der erweiterten Features von IEEE 802.11-Netzwerken, z. B. der größeren Framegröße als im Ethernet.

Neue Komponenten der systemeigenen Wi-Fi-Architektur führen die Authentifizierung, Autorisierung und Verwaltung von 802.11-Verbindungen durch, sodass unabhängige Softwareanbieter diese Funktionen nicht in ihre Adaptertreiber für Drahtlosnetzwerke integrieren müssen. Dies erleichtert die Entwicklung von Adaptertreibern für Drahtlosnetzwerke erheblich. In Windows Server 2008 und Windows Vista müssen unabhängige Softwareanbieter einen kleineren NDIS 6.0-Miniporttreiber entwickeln, der zuoberst eine systemeigene 802.11-Schnittstelle bereitstellt.

Die systemeigene Wi-Fi-Architektur unterstützt APIs, damit unabhängige Softwareanbieter und unabhängige Softwarehersteller die Möglichkeit haben, den integrierten drahtlosen Client für zusätzliche drahtlose Dienste und benutzerdefinierte Funktionen zu erweitern. Die von unabhängigen Softwareanbietern und unabhängigen Softwareherstellern geschriebenen erweiterbaren Komponenten können außerdem benutzerdefinierte Konfigurationsdialogfelder und Assistenten enthalten.

Verbesserungen an der Benutzeroberfläche für drahtlose Verbindungen

Die drahtlose Konfigurationsbenutzeroberfläche wurde folgendermaßen verbessert:

Erweiterbare drahtlose Benutzeroberfläche Wie im Abschnitt "Systemeigene Wi-Fi-Architektur" dieses Artikels beschrieben, können benutzerdefinierte drahtlose Konfigurationsdialogfelder oder Assistenten geschrieben und dem integrierten drahtlosen Windows-Client hinzugefügt werden, wodurch unabhängige Softwareanbieter und unabhängige Softwarehersteller benutzerdefinierte Konfigurationen der drahtlosen Features und Funktionen durchführen können.

Versteckte drahtlose Netzwerke können gekennzeichnet werden Ein verstecktes drahtloses Netzwerk gibt seinen Netzwerknamen (Service Set Identifier, SSID) nicht bekannt. Der drahtloser Zugriffspunkt eines versteckten drahtlosen Netzwerks kann so konfiguriert werden, dass Signalframes gar nicht oder mit einem auf NULL gesetzten SSID gesendet werden. Dieses Vorgehen wird als das Verwenden von Nicht-Broadcast-SSIDs bezeichnet. In Windows Server 2003 und Windows XP konnte ein bevorzugtes Drahtlosnetzwerk als versteckt gekennzeichnet werden, was beim automatischen Verbinden mit Drahtlosnetzwerken mitunter zu unklarem Verhalten führte, wenn einige dieser Netzwerke versteckt und andere nicht versteckt waren. In Windows Server 2008 und Windows Vista kann ein bevorzugtes Drahtlosnetzwerk als versteckt angegeben werden, indem es als Nicht-Broadcast-Netzwerk konfiguriert wird.

Benutzeraufforderung bei Verbindungen mit ungesicherten Drahtlosnetzwerken Aufgrund der Risiken bei der Kommunikation in ungesicherten Drahtlosnetzwerken erhalten die Benutzer in Windows Server 2008 und Windows Vista nun beim Herstellen einer Verbindung mit einem ungesicherten drahtlosen Netzwerk eine Aufforderung, die es ihnen erlaubt, den Verbindungsversuch zu bestätigen.

Konfigurationsassistent übernimmt in der Standardeinstellung die höchste vom drahtlosen Netzwerkadapter unterstützte Sicherheit Der Wireless Network Setup-Assistent in Windows Server 2008 und Windows Vista ruft die Sicherheitsfunktionen des drahtlosen Netzwerkadapters ab und empfiehlt die Verwendung der strengsten vom drahtlosen Netzwerkadapter unterstützten Sicherheit. Wenn ein drahtloser Netzwerkadapter beispielsweise sowohl Wired Equivalent Privacy (WEP) und Wi-Fi Protected Access (WPA) unterstützt, so werden im Wireless Network Setup-Assistenten in der Standardeinstellung Einstellungen für WPA konfiguriert.

Erweiterungen der Richtlinine für Drahtlosnetzwerke

In Windows Server 2008 und Windows Vista beinhaltet die im Gruppenrichtlinien-Snap-In unter dem Knoten Computer Configuration/Windows Settings/Security Settings (Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen) gespeicherte Gruppenrichtlinine für Drahtlosnetzwerke folgende Erweiterungen:

WPA2-Authentifizierungsoptionen Windows XP mit Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update für Windows XP mit Service Pack 2 unterstützt die Konfiguration der WPA2-Authentifizierungsoptionen sowie WPA2 (für WPA2 Enterprise) und WPA2-PSK (für WPA2 Personal). Die Richtlinie für Drahtlosnetzwerke (IEEE 802.11) in Windows Server 2003 mit Service Pack 1 unterstützt jedoch keine zentralisierte Konfiguration der WPA2-Authentifizierungsoptionen. Die Einstellungen der Richtlinie für Drahtlosnetzwerke in Windows Server 2008 ermöglichen die Konfiguration von WPA2-Authentifizierungsoptionen. Microsoft arbeitet an der Unterstützung der WPA2-Authentifizierungsoptionen in den Einstellungen der Richtlinie für Drahtlosnetzwerke für ein zukünftiges Update von Windows Server 2003.

Listen der zulässigen und abgelehnten Drahtlosnetzwerknamen Der drahtlose Client in Windows Server 2003 und Windows XP fordert den Benutzer auf, eine Verbindung mit erkannten Drahtlosnetzwerken herzustellen, wenn keines der bevorzugten Drahtlosnetzwerke gefunden wurde oder keine der Verbindungen mit erkannten bevorzugten Drahtlosnetzwerken erfolgreich war. Drahtlose Clientcomputer, auf denen Windows Server 2003 oder Windows XP ausgeführt wurde, konnten nicht so konfiguriert werden, dass den Benutzern nur Aufforderungen für Verbindungen mit bestimmten Drahtlosnetzwerken angezeigt werden. Die Einstellungen der Richtlinie für Drahtlosnetzwerke in Windows Server 2008 und Windows Vista ermöglicht Ihnen das Konfigurieren von Listen mit zulässigen und abgelehnten Drahtlosnetzwerknamen. In einer Liste für zugelassene Namen können Sie Drahtlosnetzwerke anhand des Namens (SSID) angeben. Der drahtlose Client unter Windows Server 2008 oder Windows Vista stellt daraufhin nur Verbindungen mit diesen Netzwerken her. Dies ist sinnvoll für Netzwerkadministratoren, die erreichen möchten, dass Laptopcomputer in einem Unternehmen nur Verbindungen mit bestimmten Drahtlosnetzwerken herstellen, z. B. dem Drahtlosnetzwerk des Unternehmens und drahtlosen Netzwerken von Internetdienstanbietern. In einer Liste unzulässiger Namen können Sie Drahtlosnetzwerke anhand des Namens angeben, mit denen der Client keine Verbindungen herstellen darf. Dies ist sinnvoll, um verwalteten Laptopcomputern zu untersagen, eine Verbindung mit anderen Drahtlosnetzwerken im Bereich des Drahtlosnetzwerks der Organisation herzustellen (etwa wenn eine Organisation eine Etage eines Gebäudes nutzt und auf anderen Etagen weitere Drahtlosnetzwerke anderer Organisationen vorhanden sind). Auch kann so verhindert werden, dass verwaltete Laptopcomputer Verbindungen mit anderen bekannten ungesicherten Drahtlosnetzwerken herstellen.

Zusätzliche Einstellungen für bevorzugte Drahtlosnetzwerke Die Einstellungen für die Richtlinie für Drahtlosnetzwerke in Windows Server 2008 ermöglichen eine Konfiguration der folgenden Elemente für bevorzugte Drahtlosnetzwerke:

Einstellungen für schnelles Roaming Beim schnellen Roaming handelt es sich um eine erweiterte Funktion von WPA2-Drahtlosnetzwerken, die es drahtlosen Clients ermöglicht, mithilfe der Präauthentifizierung und einer paarweisen Hauptschlüsselzwischenspeicherung rascher von einem drahtlosen AP zu einem anderen zu wechseln. Im Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update für Windows XP mit Service Pack 2 können Sie das Verhalten von Präauthentifizierung und Hauptschlüsselzwischenspeicherung über die Registrierungseinstellungen steuern. Unter Windows Server 2008 kann dieses Verhalten über die Einstellungen für die Richtlinie für Drahtlosnetzwerke gesteuert werden.

Versteckte Drahtlosnetzwerke Wie im Abschnitt "Verbesserungen an der Benutzeroberfläche für drahtlose Verbindungen" dieses Artikels beschrieben, können Sie bevorzugte Drahtlosnetzwerke lokal als versteckte Drahtlosnetzwerke konfigurieren. Unter Windows Server 2008 können bevorzugte Drahtlosnetzwerke nun in den Einstellungen für die Richtlinie für Drahtlosnetzwerke als versteckte Drahtlosnetzwerke konfiguriert werden.

Automatische oder manuelle Verbindung Mit Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, Windows Server 2008 und Windows Vista kann ein bevorzugtes Drahtlosnetzwerk auf der Registerkarte Connection (Verbindung) der Eigenschaften des bevorzugten drahtlosen Netzwerks für eine automatische (in der Standardeinstellung) oder manuelle Verbindung konfiguriert werden. Mithilfe der Einstellungen für die Richtlinie für Drahtlosnetzwerke in Windows Server 2008 können Sie bevorzugte Drahtlosnetzwerke nun für eine automatische oder manuelle Verbindung konfigurieren.

Änderungen an der Wireless Auto Configuration

Bei der Wireless Auto Configuration handelt es sich um einen Dienst, der dynamisch das Drahtlosnetzwerk auswählt, mit dem der Computer automatisch eine Verbindung herstellt. Dies basiert entweder auf benutzerdefinierten oder auf Standardeinstellungen. Hierzu gehört das automatische Auswählen und Verbinden mit einem bevorzugteren Drahtlosnetzwerk, sobald dieses verfügbar wird. Windows Server 2008 und Windows Vista beinhalten folgende Änderungen an Wireless Auto Configuration:

Änderung des Verhaltens, wenn keine bevorzugten Drahtlosnetzwerke verfügbar sind Sofern keine Verbindung mit einem bevorzugten Drahtlosnetzwerk hergestellt werden kann und das Drahtlosnetzwerk dahingehend konfiguriert ist, dass automatische Verbindungen mit Drahtlosnetzwerken verhindert werden, die sich nicht in der Liste der bevorzugten Drahtlosnetzwerke (der Standardeinstellung) befinden, erstellt Wireless Auto Configuration in Windows XP und Windows Server 2003 einen zufälligen Drahtlosnetzwerknamen und konfiguriert den Adapter für das Drahtlosnetzwerk im Infrastrukturmodus. Anschließend wird der drahtlose Adapter nicht mit einem Drahtlosnetzwerk verbunden, sondern sucht alle 60 Sekunden nach bevorzugten Drahtlosnetzwerken. In Windows Server 2008 und Windows Vista parkt Wireless Auto Configuration den Adapter für das Drahtlosnetzwerk, während weiter regelmäßig nach bevorzugten Netzwerken gesucht wird, sodass eine drahtlose Verbindung mit einem Drahtlosnetzwerk verhindert wird, das mit dem zufälligen Drahtlosnetzwerknamen übereinstimmt.

Neue Unterstützung für versteckte Drahtlosnetzwerke In Windows XP und Windows Server 2003 versucht Wireless Auto Configuration, konfigurierte bevorzugte Drahtlosnetzwerke mit Drahtlosnetzwerken in Übereinstimmung zu bringen, die ihren Netzwerknamen senden. Wenn keines der verfügbaren Netzwerke mit einem bevorzugten Drahtlosnetzwerk übereinstimmt, sendet Wireless Auto Configuration Probeanfragen, um zu ermitteln, ob die bevorzugten Netzwerke in der sortierten Liste versteckt sind. Durch dieses Verhalten werden Broadcast-Netzwerke mit versteckten Netzwerken verbunden. Dies gilt selbst dann, wenn ein verstecktes Netzwerk in der Bevorzugungsliste höher als ein Broadcast-Netzwerk eingestuft wurde. Außerdem führt dies dazu, dass ein drahtloser Windows XP- oder Windows Server 2003-Client seine Liste bevorzugter Drahtlosnetzwerke beim Senden von Probeanfragen bekannt gibt.

In Windows Server 2008 und Windows Vista können Sie Drahtlosnetzwerke als Broadcast (der Name des Drahtlosnetzwerks ist in den vom drahtlosen AP gesendeten Signalframes enthalten) oder als Nicht-Broadcast konfigurieren (der Name des Drahtlosnetzwerks ist versteckt, da der drahtlose AP entweder keinen Signalframe sendet oder die Signalframes einen auf NULL gesetzten Netzwerknamen enthalten). Wenn versteckte Netzwerke in der Liste der bevorzugten Drahtlosnetzwerke platziert werden, wird die Reihenfolge der Verbindungsversuche zu bevorzugten Drahtlosnetzwerken beibehalten, und ein drahtloser Client unter Windows Server 2008 und Windows Vista gibt seine Liste der bevorzugten Drahtlosnetzwerke nicht mehr bekannt.

WPA2-Unterstützung

Windows Server 2008 und Windows Vista beinhalten eine integrierte Unterstützung für das Konfigurieren von WPA2-Authentifizierungsoptionen sowohl mit dem Standardprofil (lokal konfigurierte bevorzugte Drahtlosnetzwerke) als auch mit dem Domänenprofil über Gruppenrichtlinieneinstellungen. Die Produktzertifizierung WPA2 ist bei der Wi-Fi-Allianz erhältlich und bescheinigt der Drahtloshardware, dass sie mit dem Standard IEEE 802.11i kompatibel ist. WPA2 unterstützt in Windows Server 2008 und Windows Vista sowohl den Enterprise-Betriebsmodus (IEEE 802.1X-Authentifizierung) als auch den Personal-Betriebsmodus (Authentifizierung über vorinstallierten Schlüssel).

Windows Server 2008 und Windows Vista beinhalten außerdem Unterstützung für WPA2 für ein Drahtlosnetzwerk im Ad-hoc-Modus (ein Drahtlosnetzwerk zwischen drahtlosen Clients, das keinen drahtlosen Zugriffspunkt verwendet).

Einmalige Anmeldung (Single Sign-on)

Durch die Bereitstellung von sicheren drahtlosen Technologien setzte sich die Verwendung der Layer 2-Netzwerkauthentifizierung, wie z. B. 802.1X, immer mehr durch, um sicherzustellen, dass lediglich geeignete Benutzer oder Geräte im geschützten Netzwerk zugelassen werden und die Daten auf Funkübertragungsebene sicher sind. Das Feature für eine einmalige Anmeldung (Single Sign-On) von Windows Server 2008 und Windows Vista führt basierend auf der Netzwerksicherheitskonfiguration zu einem geeigneten Zeitpunkt eine 802.1X-Authentifizierung durch, die einfach und nahtlos in den Windows-Anmeldeprozess des Benutzers integriert ist.

Netzwerkadministratoren können die Gruppenrichtlinieneinstellungen oder die neuen netsh wireless-Befehle verwenden, um für drahtlose Clientcomputer Profile für eine einmalige Anmeldung zu erstellen. Nach der Konfiguration eines Profils für eine einmalige Anmeldung wird die 802.1X-Authentifizierung vor der Computeranmeldung bei der Domäne durchgeführt, und Benutzer werden nur bei Bedarf zur Angabe ihrer Anmeldeinformationen aufgefordert. Dieses Feature stellt sicher, dass die drahtlose Verbindung vor der Computerdomänenanmeldung platziert wird, sodass Szenarios möglich sind, in denen vor der Benutzeranmeldung eine Netzwerkverbindung erforderlich ist, z. B. bei Aktualisierungen der Gruppenrichtlinie, dem Ausführen von Anmeldeskripts und bei Domänenbeitritten von drahtlosen Clients.

Integration mit NAP bei der Verwendung der 802.1X-Authentifizierung

WPA2-Enterprise, WPA-Enterprise und dynamische WEP-Verbindungen, die die 802.1X-Authentifizierung verwenden, können die NAP-Plattform nutzen, um zu verhindern, dass Drahtlosnetzwerke, die nicht mit den Systemintegritätsanforderungen übereinstimmen, unbegrenzten Zugriff auf ein privates Netzwerk erhalten. Weitere Informationen zur NAP-Plattform finden Sie in diesem Artikel unter "Network Access Protection (NAP)".

EAPHost-Infrastruktur

Für eine einfachere Entwicklung von Extensible Authentication Protocol-(EAP-)Authentifizierungsmethoden für IEEE 802.1X-authentifizierte drahtlose Verbindungen unterstützen Windows Server 2008 und Windows Vista die neue EAPHost-Infrastruktur. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "EAPHost-Architektur".

Neue Standard-EAP-Authentifizierungsmethode

In Windows Server 2003 und Windows XP ist die Standard-EAP-Authentifizierungsmethode für 802.1X-authentifizierte drahtlose Verbindungen EAP-Transport Layer Security (EAP-TLS). Obwohl es sich um die sicherste Form der Authentifizierung unter Verwendung einer gegenseitigen Authentifizierung mit digitalen Zertifikaten handelt, erfordert EAP-TLS eine PKI, um Benutzer- und Computerzertifikate verteilen, sperren und erneuern zu können.

In vielen Fällen möchten Organisationen die in Active Directory bereits vorhandene kontennamen- und kennwortbasierte Authentifizierungsinfrastruktur nutzen. Daher wurde die Standard-EAP-Authentifizierungsmethode für 802.1X-authentifizierte drahtlose Verbindungen in Windows Server 2008 und Windows Vista in Protected EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) geändert. PEAP-MS-CHAP v2 ist eine kennwortbasierte 802.1X-Authentifizierungsmethode für drahtlose Verbindungen, bei der lediglich Computerzertifikate auf den Remote Authentication Dial-In User Service-(RADIUS-)Servern installiert werden müssen. Weitere Informationen zu PEAP-MS-CHAP v2 finden Sie unter PEAP with MS-CHAP Version 2 for Secure Password-based Wireless Access (in englischer Sprache).

Diagnoseunterstützung für drahtlose Verbindungen

Die Fehlerbehebung fehlgeschlagener drahtloser Verbindungen kann trotz der Verbesserungen in Windows XP Service Pack 2 und Windows Server 2003 Service Pack 1 immer noch recht schwierig sein. In Windows Server 2008 und Windows Vista wurde die Problembehebung bei drahtlosen Verbindungen dank folgender Features deutlich vereinfacht:

Drahtlose Verbindungen unterstützen das neue Netzwerkdiagnose-Framework Beim Netzwerkdiagnose-Framework handelt es sich um eine erweiterbare Architektur, die den Benutzern dabei hilft, Netzwerkverbindungsprobleme zu erkennen und zu beheben. Bei einer fehlgeschlagenen drahtlosen Verbindung bietet das Netzwerkdiagnose-Framework dem Benutzer die Möglichkeit an, das Problem zu identifizieren und zu beheben. Die Drahtlosnetzwerk-Unterstützung für das Netzwerkdiagnose-Framework versucht anschließend, die Quelle der fehlgeschlagenen Verbindung zu ermitteln und das Problem entweder manuell zu beheben oder, abhängig von Sicherheitsüberlegungen, den Benutzer aufzufordern, die geeignete Konfigurationsänderung durchzuführen.

Neue, im Windows-Ereignisprotokoll gespeicherte Informationen Bei einem fehlgeschlagenen drahtlosen Verbindungsversuch zeichnen die drahtlosen Komponenten von Windows Server 2008 und Windows Vista im Windows-Ereignisprotokoll detaillierte Informationen über den Verbindungsversuch auf. Diese Ereignisdatensätze können von Supportfachleuten einer Organisation verwendet werden, um eine weitere Problembehebung vorzunehmen, wenn die drahtlose Diagnose das Problem entweder nicht auflösen konnte, oder wenn das Problem zwar aufgelöst, dieses jedoch nicht durch eine Änderung der Einstellungen des drahtlosen Clients behoben werden konnte. Die Informationen im Windows-Ereignisprotokoll können die für das Auflösen von Problemen mit der Unterstützung von drahtlosen Verbindungen benötigte Zeit verringern. Außerdem können diese Ereignisprotokolleinträge vom Netzwerkadministrator mithilfe von Microsoft Operations Manager oder anderen zentralen Verwaltungstools automatisch gesammelt und nach Trends und Änderungen am Infrastrukturentwurf analysiert werden.

Die Informationen können zur Analyse und für Verbesserungen an Microsoft gesendet werden Benutzer, bei denen Probleme mit drahtlosen Verbindungen auftreten, werden außerdem aufgefordert, die Verbindungsinformationen über die Windows-Infrastruktur für die Fehlerberichterstattung (Windows Error Reporting, WER) zur weiteren Analyse an Microsoft zu senden. Zusätzlich kann eine erfolgreiche Diagnose über die Infrastruktur für Softwarequalitätseigenschaften (Software Quality Metrics, SQM) (in Windows XP das Programm zur Verbesserung der Benutzerfreundlichkeit) an Microsoft gesendet werden. In beiden Fällen werden lediglich Diagnoseinformationen zu Drahtlosnetzwerken gesendet (keine persönlichen Informationen über den Computer oder den Benutzer). Microsoft verwendet diese Informationen, um die wichtigsten Hauptursachen für das Fehlschlagen von drahtlosen Verbindungen zu identifizieren. Auch werden neue Probleme mit drahtlosen Verbindungen und deren Ursachen ermittelt, sodass geeignete Maßnahmen ergriffen werden können, um entweder die drahtlose Clientsoftware in Windows zu verbessern, oder um gemeinsam mit Herstellern von drahtlosen Elementen die drahtlosen Hardwareprodukte zu verbessern.

Befehlszeilenschnittstelle für das Konfigurieren drahtloser Einstellungen

Windows Server 2003 und Windows XP verfügen über keine Befehlszeilenschnittstelle, mit der die drahtlosen Einstellungen der Dialogfelder für Drahtlosnetzwerke im Ordner Netzwerkverbindungen oder die Richtlinie für Drahtlosnetzwerke (IEEE 802.11) in den Gruppenrichtlinieneinstellungen konfiguriert werden können. Eine Befehlszeilenkonfiguration der drahtlosen Einstellungen kann bei der Bereitstellung von Drahtlosnetzwerken in folgenden Situationen helfen:

Automatisierte Skriptunterstützung für drahtlose Einstellungen ohne Verwendung der Gruppenrichtlinie Gruppenrichtlinieneinstellungen für Drahtlosnetzwerke (IEEE 802.11) gelten nur in einer Active Directory-Domäne. In einer Umgebung ohne Active Directory oder Gruppenrichtlinieninfrastruktur kann ein Skript für die Automatisierung der Konfiguration von drahtlosen Verbindungen entweder manuell oder automatisch ausgeführt werden, z. B. als Teil des Anmeldeskripts.

Bootstrap eines drahtlosen Clients für das gesicherte Drahtlosnetzwerk eines Unternehmens Ein drahtloser Clientcomputer, der kein Mitglied der Domäne ist, kann keine Verbindung mit dem sicheren Drahtlosnetzwerk der Organisation aufbauen. Außerdem kann ein Computer der Domäne nicht beitreten, solange keine erfolgreiche Verbindung mit dem sicheren Drahtlosnetzwerk des Unternehmens aufgebaut wurde. Ein Befehlszeilenskript stellt eine Methode für das Herstellen einer Verbindung mit dem sicheren Drahtlosnetzwerk der Organisation dar, um der Domäne beizutreten.

In Windows Server 2008 und Windows Vista können Sie Netsh-Befehle im netsh wireless-Kontext verwenden, um folgende Schritte durchzuführen:

Konfigurieren sämtlicher drahtloser Clienteinstellungen in einem benannten Profil einschließlich der allgemeinen Einstellungen (die Drahtlosnetzwerktypen, auf die zugegriffen werden soll), der 802.11-Einstellungen (SSID, Authentifizierungstyp, Datenverschlüsselungstyp) und der 802.1X-Authentifizierungseinstellungen (EAP-Typen und deren Konfiguration).

Festlegen der Liste mit zulässigen und abgelehnten Namen für Drahtlosnetzwerke.

Festlegen der Reihenfolge bevorzugter Drahtlosnetzwerke.

Anzeigen der Konfiguration eines drahtlosen Clients.

Entfernen der drahtlosen Konfiguration eines drahtlosen Clients.

Migrieren der drahtlosen Konfigurationseinstellungen zwischen drahtlosen Clients.

Network Location Awareness und Netzwerkprofile

Viele Anwendungen sind nicht netzwerkfähig, wodurch bei den Kunden Verwirrung und bei den Entwicklern ein großer Aufwand entsteht. So kann eine Anwendung beispielsweise das Verhalten nicht automatisch anhand der aktuell verbundenen Netzwerke oder der Bedingungen anpassen. Benutzer müssen je nach verbundenem Netzwerk (privates Netzwerk des Arbeitgebers, Heimnetzwerk des Benutzers oder das Internet) die Anwendungseinstellungen neu konfigurieren. Um die Konfigurationsaufgaben zu verringern, können Anwendungsentwickler Low-Level-Windows-APIs und -Datenkonstrukte verwenden und ggf. selbst Prüfungen auf verbundene Netzwerke durchführen, um das aktuelle Netzwerk zu ermitteln und das Verhalten der Anwendung entsprechend anzupassen.

Um eine Betriebssysteminfrastruktur bereitzustellen, die es Anwendungsentwicklern basierend auf dem aktuell verbundenen Netzwerk gestattet, das Anwendungsverhalten einfacher neu zu konfigurieren, erfasst der Network Location Awareness-(NLA-)Dienst in Windows Server 2008 und Windows Vista die in Windows verfügbaren Netzwerkinformationen. Anwendungen können anhand dieser Informationen einfach und effektiv auf Umgebungsänderungen reagieren. NLA stellt Anwendungen hierfür eine einheitliche API zur Verfügung, über die aktuelle Netzwerkinformationen und Benachrichtigungen zu Umgebungsänderungen abgerufen werden können.

Weitere Informationen finden Sie unter How to Write a Network-Aware Application und Longhorn Network Location Awareness Service (in englischer Sprache).

Erweiterungen des TCP/IP-Stacks der nächsten Generation für drahtlose Umgebungen

Wie im Abschnitt "Erweiterungen für Umgebungen mit hohen Verlustraten" dieses Artikels beschrieben, beinhaltet der TCP/IP-Stack der nächsten Generation eine Unterstützung für neue TCP-Algorithmen, die den Durchsatz optimieren, indem beim Verlust von einem oder mehreren Paketen eine Korrektur erfolgt und vermeidbare erneute Übertragungen erkannt werden. Dies verbessert die Leistung in Umgebungen mit Drahtlosnetzwerken.

Erweiterungen für IEEE 802.1X-basierte verdrahtete Verbindungen

In Windows Server 2003 und Windows XP besteht nur eine eingeschränkte Unterstützung für die Bereitstellung von 802.1X-Authentifizierungseinstellungen bei verdrahteten Verbindungen mit einem authentifizierenden Switch. Windows Server 2008 und Windows Vista beinhalten folgende Elemente für eine einfachere Bereitstellung von 802.1X-authentifizierten verdrahteten Verbindungen:

Gruppenrichtlinienunterstützung für verdrahtete 802.1X-Einstellungen

Befehlszeilenschnittstelle für das Konfigurieren von verdrahteten 802.1X-Einstellungen

Integration mit NAP bei der Verwendung der 802.1X-Authentifizierung

EAPHost-Infrastruktur

Änderungen des 802.1X-Dienststatus

Einmalige Anmeldung (Single Sign-on)

Gruppenrichtlinienunterstützung für verdrahtete 802.1X-Einstellungen

Für Umgebungen, in denen Active Directory und Gruppenrichtlinien verwendet werden, beinhalten Windows Server 2008 und Windows Vista unter Computer Configuration/Windows Settings/Security Settings/Wired Network (Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Richtlinie für verdrahtete Netzwerke (IEEE 802.3)) eine Gruppenrichtlinienunterstützung für 802.1X-Authentifizierungseinstellungen für verdrahtete Verbindungen.

Befehlszeilenschnittstelle für das Konfigurieren von verdrahteten 802.1X-Einstellungen

Für Umgebungen, in denen weder Active Directory noch Gruppenrichtlinien verwendet werden, sowie für Bootstrapping-Szenarios unterstützen Windows Server 2008 und Windows Vista außerdem eine Befehlszeilenschnittstelle für die Konfiguration der 802.1X-Authentifizierungseinstellungen für verdrahtete Verbindungen. Mithilfe der Befehle im netsh wired-Kontext können Sie folgende Aufgaben durchführen:

Konfigurieren sämtlicher verdrahteter Clienteinstellungen in einem benannten Profil einschließlich der 802.1X-Authentifizierungseinstellungen (EAP-Typen und deren Konfiguration)

Anzeigen der Konfiguration eines verdrahteten Clients

Entfernen der verdrahteten Konfiguration eines verdrahteten Clients

Migrieren der verdrahteten Konfigurationseinstellungen zwischen verdrahteten Clients

Integration mit NAP bei der Verwendung der 802.1X-Authentifizierung

IEEE 802.1X-authentifizierte verdrahtete Verbindungen können die NAP-Plattform nutzen, um zu verhindern, dass verdrahtete Netzwerke, die nicht mit den Systemintegritätsanforderungen übereinstimmen, unbegrenzten Zugriff auf ein privates Netzwerk erhalten. Weitere Informationen zur NAP-Plattform finden Sie in diesem Artikel unter "Network Access Protection (NAP)".

EAPHost-Infrastruktur

Für eine einfachere Entwicklung von EAP-Authentifizierungsmethoden für IEEE 802.1X-authentifizierte verdrahtete Verbindungen unterstützen Windows Server 2008 und Windows Vista die neue EAPHost-Infrastruktur. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "EAPHost-Architektur".

Änderungen des 802.1X-Dienststatus

Unter Windows XP und Windows Server 2003 war der 802.1X-Dienst in der Standardeinstellung aktiviert, wurde jedoch in einen passiven Wartemodus gesetzt. In Windows Vista ist der 802.1X-Dienst in der Standardeinstellung deaktiviert, durch eine Aktivierung wird er jedoch in einem aktiven Modus ausgeführt.

Einmalige Anmeldung (Single Sign-on)

Durch die Bereitstellung von authentifizierenden Switches setzte sich die Verwendung der Layer 2-Netzwerkauthentifizierung (wie z. B. 802.1X) immer mehr durch, um sicherzustellen, dass lediglich geeignete Benutzer oder Geräte mit dem Switch Frames austauschen können. Das Feature für eine einmalige Anmeldung (Single Sign-On) von Windows Server 2008 und Windows Vista führt basierend auf der Netzwerksicherheitskonfiguration zu einem geeigneten Zeitpunkt eine 802.1X-Authentifizierung durch, die einfach und nahtlos in den Windows-Anmeldeprozess des Benutzers integriert ist.

Netzwerkadministratoren können die Gruppenrichtlinieneinstellungen oder die neuen netsh wired-Befehle verwenden, um für verdrahtete Clientcomputer Profile für eine einmalige Anmeldung zu erstellen. Nach der Konfiguration eines Profils für eine einmalige Anmeldung wird die 802.1X-Authentifizierung vor der Computeranmeldung bei der Domäne durchgeführt, und Benutzer werden nur bei Bedarf zur Angabe ihrer Anmeldeinformationen aufgefordert. Dieses Feature stellt sicher, dass die verdrahtete Verbindung vor der Computerdomänenanmeldung platziert wird, sodass Szenarios möglich sind, in denen vor der Benutzeranmeldung eine Netzwerkverbindung erforderlich ist, z. B. bei Aktualisierungen der Gruppenrichtlinie, dem Ausführen von Anmeldeskripts und bei Domänenbeitritten von verdrahteten Clients.

Zum SeitenanfangZum Seitenanfang

Netzwerkinfrastruktur

Windows Server 2008 und Windows Vista beinhalten Änderungen an folgenden Komponenten der Netzwerkinfrastruktur:

Network Access Protection (NAP)

Netzwerkrichtlinienserver (Network Policy Server, NPS)

Neue EAPHost-Architektur

Erweiterungen bei Remotezugriff und VPN-Verbindungen

DHCP-Erweiterungen

Network Access Protection (NAP)

Die Network Access Protection (NAP) in Windows Server 2008 und Windows Vista bietet Komponenten für das Erzwingen von Richtlinien, die dabei helfen sicherzustellen, dass Computer, die eine Verbindung mit einem Netzwerk herstellen oder in einem Netzwerk kommunizieren, die vom Administrator definierten Anforderungen an die Systemintegrität erfüllen. So kann zu den Anforderungen an die Systemintegrität beispielsweise gehören, dass auf sämtlichen Computern die aktuellen Betriebssystemupdates und Antiviren-Signaturdateien installiert wurden.

Administrator können eine Kombination aus Komponenten für die Richtlinienüberprüfung und die Netzwerkzugriffsbeschränkung verwenden, um den Netzwerkzugriff oder die Kommunikation zu steuern. Administratoren können außerdem temporär den Zugriff auf Computer einschränken, die nicht den Anforderungen eines eingeschränkten Netzwerks entsprechen. Abhängig von der Konfiguration kann das eingeschränkte Netzwerk Ressourcen bereitstellen, die erforderlich sind, um inkompatible Computer zu aktualisieren, damit diese die Integritätsanforderungen für einen unbeschränkten Netzwerkzugriff und eine normale Kommunikation erfüllen. NAP beinhaltet für Entwickler und Anbieter ein API-Set, mit dem vollständige Lösungen für die Integritätsrichtlinienüberprüfung (Health Policy Validation), die Netzwerkzugriffsbeschränkung, automatische Korrekturen und eine kontinuierliche Kompatibilität mit der Integritätsrichtlinie erstellt werden können.

Technologien für die NAP-Erzwingung

Windows Server 2008 und Windows Vista beinhalten folgende Technologien für die NAP-Erzwingung:

DHCP Mit der DHCP-Erzwingung können DHCP-Server Richtlinien für Integritätsanforderungen immer dann erzwingen, wenn ein Computer versucht, im Netzwerk eine IP-Adresskonfiguration zu leasen oder zu erneuern. Bei der DHCP-Erzwingung handelt es sich um die einfachste Erzwingung für die Bereitstellung, da sämtliche DHCP-Clientcomputer IP-Adressen leasen müssen.

VPN Mithilfe der VPN-Erzwingung können VPN-Server Richtlinien für Integritätsanforderungen immer dann erzwingen, wenn ein Computer versucht, eine VPN-Verbindung mit dem Netzwerk herzustellen. Die VPN-Erzwingung bietet einen sicheren eingeschränkten Netzwerkzugriff für alle Computer, die auf das Netzwerk über eine VPN-Verbindung zugreifen. Die VPN-Erzwingung mit NAP unterscheidet sich von der Quarantänesteuerung für Netzwerkzugriffe in Windows Server 2003.

IEEE 802.1X Mithilfe der 802.1X-Erzwingung weist ein NPS (Network Policy Server) einen 802.1X-basierten Zugriffspunkt (ein Ethernet-Switch oder ein drahtloser Zugriffspunkt) an, für den 802.1X-Client so lange ein eingeschränktes Zugriffsprofil zu verwenden, bis eine Reihe von Korrekturfunktionen ausgeführt wurde. Ein eingeschränktes Zugriffsprofil kann aus einer Reihe von IP-Paketfiltern oder einer virtuellen LAN-ID bestehen, mit der der Verkehr eines 802.1X-Clients eingeschränkt wird. Die 802.1X-Erzwingung bietet einen sicheren eingeschränkten Netzwerkzugriff für alle Computer, die auf das Netzwerk über eine 802.1X-Verbindung zugreifen. Weitere Informationen zu NPS finden Sie in diesem Artikel unter "Netzwerkrichtlinienserver (Network Policy Server, NPS)".

IPsec Mithilfe der IPsec-Erzwingung kann die Kommunikation in einem Netzwerk auf kompatible Computer beschränkt werden. Da IPsec verwendet wird, können Sie Anforderungen für eine geschützte Kommunikation mit kompatiblen Clients definieren. Dies kann für einzelne IP-Adressen oder pro TCP/UDP-Portnummer erfolgen. Anders als bei der DHCP-, VPN- und 802.1X-Erzwingung beschränkt die IPsec-Erzwingung die Kommunikation auf kompatible Computer, nachdem diese erfolgreich eine Verbindung hergestellt und eine gültige IP-Adresskonfiguration abgerufen haben. Bei der IPsec-Erzwingung handelt es sich um die sicherste Form eines eingeschränkten NAP-Netzwerkzugriffs.

Mithilfe von NAP-APIs können Softwarehersteller eigene NAP-Erzwingungstechnologien erstellen.

Weitere Informationen zur NAP-Plattform finden Sie auf der Webseite Network Access Protection (in englischer Sprache).

Netzwerkrichtlinienserver (Network Policy Server, NPS)

NPS ist die Microsoft-Implementierung eines Remote Authentication Dial-In User Service-(RADIUS-)Servers und -Proxys. NPS ersetzt den Internetauthentifizierungsdienst (Internet Authentication Service, IAS) von Windows Server 2003. NPS führt sämtliche Funktionen von IAS in Windows Server 2003 für die VPN- und 802.1X-basierte drahtlose und verdrahtete Verbindungsauthentifizierung durch. Zusätzlich wird eine Integritätsprüfung und das Gewähren von uneingeschränktem oder eingeschränktem Zugriff auf NPS-Clients durchgeführt. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "Network Access Protection (NAP)".

NPS unterstützt außerdem das Senden von RADIUS-Verkehr über IPv6 (gemäß RFC 3162).

Neue EAPHost-Architektur

Windows Server 2008 und Windows Vista beinhalten EAPHost, eine neue Architektur für EAP-Authentifizierungsmethoden und EAP-basierte Supplicants. EAPHost bietet folgende, in der EAP-Implementierung von Windows Server 2003 und Windows XP nicht unterstützte Features:

Unterstützung für zusätzliche EAP-Methoden EAPHost unterstützt weitere häufig verwendete EAP-Methoden.

Netzwerkerkennung EAPHost unterstützt die im Internetentwurf "Identity Hints for EAP" (draft-adrangi-eap-network-discovery-13.txt) definierte Netzwerkerkennung.

RFC 3748-Kompatibilität EAPHost stimmt mit der Spezifikation der EAP State Machine überein und schließt einige der in RFC 3748 bezeichneten Sicherheitslücken. Außerdem unterstützt EAPHost zusätzliche Funktionen, wie z. B. erweiterte EAP-Typen (einschließlich anbieterspezifische EAP-Methoden).

EAP-Methodenkoexistenz EAPHost ermöglicht eine gleichzeitige Koexistenz mehrerer Implementierungen derselben EAP-Methode. So kann beispielsweise PEAP sowohl in der Microsoft-Version als auch in der Version von Cisco Systems, Inc. installiert und ausgewählt werden.

Modulare Supplicantarchitektur Zusätzlich zur Unterstützung von modularen EAP-Methoden unterstützt EAPHost außerdem eine modulare Supplicantarchitektur, in der neue Supplicants einfach hinzugefügt werden können, ohne die gesamte EAP-Implementierung ersetzen zu müssen.

Für EAP-Methodenanbieter bietet EAPHost eine 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 2008 und Windows Vista zur Verfügung. Zertifizierte EAP-Methoden können über Windows Update verteilt werden. EAPHost ermöglicht außerdem eine bessere Klassifikation von EAP-Typen, sodass diese von den integrierten 802.1X- und PPP-basierten Windows-Supplicants verwendet werden können.

Für die Anbieter von Supplicantmethoden bietet EAPHost eine Unterstützung für modulare und dynamisch austauschbare Supplicants für neue Verbindungsschichten. Da EAPHost in 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.

Erweiterungen bei Remotezugriff und VPN-Verbindungen

Remotezugriffe und VPN-Verbindungen in Windows Server 2008 weisen folgende Erweiterungen auf:

Unterstützung für Routing-Compartments Indem die Unterstützung für Routing-Compartments des TCP/IP-Stacks der nächsten Generation genutzt wird, kann der VPN-Client in Windows Server 2008 und Windows Vista VPN-Verbindungen erstellen, deren Verkehr vom Internetverkehr getrennt werden kann. So wird sichergestellt, dass der Verkehr aus dem Internet nicht über eine VPN-Verbindung an ein privates Netzwerk weitergeleitet wird. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "Routing-Compartments".

VPN-Erzwingung für VPN-Verbindungen über Remotezugriffe Der integrierte VPN-Client und Routing und RAS fügen Komponenten hinzu, um in der NAP-Plattform eine VPN-Erzwingung zu ermöglichen. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "Network Access Protection (NAP)".

IPv6-Unterstützung Der integrierte Remotezugriffsclient und Routing und RAS unterstützen nun IPv6 über das in RFC 2472 definierte Point-to-Point-Protokoll (PPP) (PPPv6). Systemeigener IPv6-Verkehr kann nun über PPP-basierte Verbindungen gesendet werden. So ermöglicht die PPPv6-Unterstützung beispielsweise das Herstellen einer Verbindung mit einem IPv6-basierten Internetdienstanbieter über DFÜ oder PPP über Ethernet-(PPPoE-)basierte Verbindungen, die für den Breitband-Internetzugriff verwendet werden. Der integrierte Remotezugriffsclient und Routing und RAS unterstützen außerdem IPv6-basierte VPN-Verbindungen über das Layer-2-Tunneling-Protokoll mit IPsec (L2TP/IPsec).

Ein überarbeiteter Verbindungsassistent (Get Connected Wizard) Dieser neue Assistent bietet eine einfachere Konfiguration von DFÜ-, Breitband-Internet- und VPN-Verbindungen sowie von eingehenden Verbindungen.

Aktualisierte Winlogin-Unterstützung Ermöglicht Zugriffsprovidern von Drittanbietern das Einbinden von Verbindungen, um bei der Benutzeranmeldung automatisch eine Remotezugriffsverbindung zu erstellen.

Unterstützung mehrer Gebietsschemas für das Verbindungs-Manager-Verwaltungskit Ermöglicht unabhängig vom Gebietsschema des Servers das Erstellen von Verbindungs-Manager-Profilen mit einem beliebigen Gebietsschema für die Installation auf Clients, auf denen Windows Vista oder Windows XP ausgeführt wird. Dies vereinfacht die Verbindungs-Manager-Verwaltungskit-basierte Clientverwaltung.

Verbindungs-Manager-Clients unterstützen dynamische DNS-Updates Verbindungs-Manager-Clients unterstützen nun das Registrieren von DNS-Namen und IP-Adressen unter Verwendung dynamischer DNS-Updates.

Unterstützung für das Netzwerkdiagnose-Framework Clientbasierte Verbindungen unterstützen die grundlegenden Diagnosefunktionen des Netzwerkdiagnose-Frameworks.

DHCP-Erweiterungen

Die DHCP-Server- und DHCP-Clientdienste beinhalten folgende Erweiterungen:

Unterstützung von Dynamic Host Configuration Protocol für IPv6 (DHCPv6) Dynamic Host Configuration Protocol für IPv6 (DHCPv6) (gemäß RFC 3315) bietet eine statusbehaftete Adresskonfiguration für IPv6-Hosts in einem systemeigenen IPv6-Netzwerk.

Unterstützung für die Network Access Protection-(NAP-)Erzwingung Bei der DHCP-Erzwingung in der NAP-Plattform muss ein DHCP-Client seine Systemintegrität nachweisen, bevor er eine Adresskonfiguration für unbeschränkten Zugriff erhält. Weitere Informationen finden Sie in diesem Artikel im Abschnitt "Network Access Protection (NAP)".

Zum SeitenanfangZum Seitenanfang

Entfernte Technologien

Folgende Technologien werden in Windows Server 2008 und Windows Vista nicht mehr unterstützt:

Bandwidth Allocation Protocol (BAP)

X.25

Serial Line Interface Protocol (SLIP)

SLIP-basierte Verbindungen werden automatisch auf PPP-basierte Verbindungen aktualisiert.

Dienste für Macintosh (Services for Macintosh, SFM)

Zum SeitenanfangZum Seitenanfang

Zusammenfassung

Windows Server 2008 und Windows Vista beinhalten viele Erweiterungen, die die Verbindungsqualität und die Leistung verbessern und eine einfachere Konfiguration von Protokollen und Hauptnetzwerkkomponenten bieten. Ebenso werden Sicherheit, Benutzerfreundlichkeit und die Bereitstellung von drahtlosen und 802.1X-authentifizierten verdrahteten Verbindungen verbessert. Private Netzwerke werden effektiv geschützt, da Computer, die eine Verbindung herstellen, erforderliche Systemintegritätsrichtlinien erfüllen müssen.

Zum SeitenanfangZum Seitenanfang

Verwandte Links

Weitere Informationen finden Sie in folgenden Ressourcen:

Windows Server 2008-Website

Windows Vista-Website

Windows Vista – Ressourcen für IT-Profis

Windows Vista - Netzwerktechnologien


Zum SeitenanfangZum Seitenanfang