Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 7: Problembehandlung für IPSec

Dieses Kapitel bietet Informationen zur Verfahrensweise der Problembehandlung für IPSec (Internet Protocol Security), beispielsweise in Server- und Domänenisolierungsszenarien. Die hier aufgeführten Inhalte basieren auf den Erfahrungen und Abläufen der Microsoft IT-Experten (Microsoft Information Technology). Gegebenenfalls verweist dieses Kapitel auf bestehende Verfahren zur Problembehandlung und verwandte Informationen.

Der Microsoft IT-Support basiert auf einem Modell, das aus mehreren Ebenen besteht. Das Helpdesk wird dabei als Support der Ebene 1 bezeichnet. Über Eskalationsverfahren können Helpdeskmitarbeiter Supportanfragen eskalieren, die die Unterstützung von Experten erfordern.

Die Verfahren in diesem Kapitel beziehen sich auf drei Supportebenen: Ebene 1, Ebene 2 und Ebene 3. Um diesen Leitfaden so praxisbezogen und präzise wie möglich zu gestalten, bezieht sich ein Großteil dieses Kapitels auf die Erläuterung des Supports der Ebene 2. Anhand der zunächst bereitgestellten Anleitung für Ebene 1 erhält eine Organisation Unterstützung dafür, um schnellstmöglich zu ermitteln, ob ein Problem durch IPSec verursacht wird, und, falls dies der Fall sein sollte, die erforderlichen Informationen bereitzustellen, die die Supporttechniker der Ebene 2 bei der Problembehandlung benötigen.

Die detailgenauen und komplexen Informationen, die für die Problembehandlungsschritte für Ebene 3 erforderlich sind, sind nicht Gegenstand dieses Kapitels. Wenn mithilfe der Informationen dieses Kapitels das IPSec-Problem nicht behoben werden kann, empfiehlt Microsoft, sich an die Microsoft® Product Support Services zu wenden, um weitere Unterstützung zu erhalten.

Viele der von Microsoft verwendeten Supportverfahren, Tools und Skripts werden in diesem Kapitel als Referenz angegeben. Es ist ratsam, diese Empfehlungen und Tools zu übernehmen, um den besonderen Anforderungen Ihrer Organisation gerecht zu werden.

Wenn IPSec für die Sicherung von Datenverkehr für TCP (Transmission Control Protocol) und UDP (User Datagram Protocol) im Netzwerk verwendet wird, führen übliche Verfahren und Tools zur TCP/IP-Netzwerkproblembehandlung eventuell zu keiner Lösung des Problems. Daher ist die Planung und Entwicklung von IPSec-spezifischen Problembehandlungstechniken unabdingbar, die eingesetzt werden, wenn ein Problem bei der Kommunikation zwischen Computern auftritt, bei der IPSec verwendet wird (oder dies versucht wird).

Auf dieser Seite	In diesem Beitrag
Supportebenen und Eskalation Problembehandlung der Ebene 1 Vorbereitung der Problembehandlung von Ebene 2 Der Problembehandlungsprozess für IPSec Problembehandlung der Ebene 3 Zusammenfassung	Überblick - Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien Kapitel 1: Einführung in die Server- und Domänenisolierung Kapitel 2: Grundlagen der Server- und Domänenisolierung Kapitel 3: Ermitteln des aktuellen Status der IT-Infrastruktur Kapitel 4: Entwerfen und Planen von Isolierungsgruppen Kapitel 5: Erstellen von IPSec-Richtlinien für Isolierungsgruppen Kapitel 6: Verwalten einer Server- und Domänenisolierungsumgebung Kapitel 7: Problembehandlung für IPSec Anhang A: Überblick über IPSec-Richtlinienkonzepte Anhang B: Zusammenfassung zu IPSec-Richtlinien Anhang C: Leitfaden zum Aufbau einer Testumgebung Anahng D: IT-Bedrohungskategorien Danksagungen
	Vollständige Lösung downloaden Server-und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien (engl.)

Supportebenen und Eskalation

Von Microsoft wird standardmäßig ein Support für eine Server- und Domänenisolierungsumgebung bereitgestellt, der in den Standard-SLA-Vorgaben (Service Level Agreements, Vereinbarung über die Bereitstellung von Diensten) definiert wird. Isolierungssupport wird von den folgenden Ebenen bereitgestellt:

• Ebene 1: Helpdesk. Das Helpdesk ist der Einstiegspunkt für Clientstörungen mit und ohne Domänenzugehörigkeit. Das Helpdesk unterstützt darüber hinaus Server, die von der zentralen IT-Organisation verwaltet werden. (Andere Server können von LOB-Anwendungsteams [Line Of Business] oder Produktgruppen verwaltet werden). Helpdeskmitarbeiter sind daraufhin geschult, eine Klassifizierung und mehrere Flussdiagramme anzuwenden, um Probleme zu kategorisieren, die Server- und Domänenisolierung betreffen.

  Während der Pilotphase der Microsoft-Isolierungslösung wurden Clientstörungen an die Abteilung Corporate IT Security eskaliert. Nach Bereitstellen der Lösung wurden Clientstörungen jedoch von den Supportteams der Ebene 2 bearbeitet.

• Ebene 2: Betrieb im Rechenzentrum, globales Netzwerkbetriebszentrum, LOB-Anwendungssupport und Support für die Nachrichtenverwaltung und Zusammenarbeit. Diese Gruppen bilden Teams für den alltäglichen Betrieb, die IT-Dienste und zugehörige Ressourcen überwachen und verwalten. Während der Pilotphasen der Server- und Domänenisolierung bildeten diese Teams den ersten Eskalationspunkt für das Helpdesk und die Corporate IT Security für serverbezogene Störungen und die Behandlung von zugehörigen Problemen. Jeder Gruppe ist ein auf den jeweiligen Bereich spezialisierter Experte für Server- und Domänenisolierungsumgebungen zugewiesen, darüber hinaus verfügt jede Gruppe über detaillierte Verfahren zur Problembehandlung.

• Ebene 3: Dienste für Windows-Netzwerke und Windows-Infrastruktur. In der Pilotphase der Server- und Domänenisolierung ernannte diese Gruppe ein Expertenteam für die Problembehandlung für diese lösungsbezogenen Architekturkomponenten und -technologien, wie IPSec, TCP/IP-Paketverarbeitung, Computerkonten und Netzwerkanmeldeberechtigungen. Sofern eine weitere Eskalation erforderlich ist, arbeitet Ebene 3 innerhalb von Microsoft direkt mit den Windows Development-Teams zusammen, bis das Problem behoben werden kann. Außerhalb von Microsoft bezieht diese Ebene gegebenenfalls die Microsoft Product Support Services ein.

Der folgende Abschnitt bietet eine Übersicht über die Problembehandlungstechniken, die von den Helpdeskmitarbeitern der Ebene 1 einer Supportorganisation angewendet werden können.

Zum Seitenanfang

Problembehandlung der Ebene 1

Dieser Abschnitt stellt das allgemeine Verfahren der Problembehandlung für IPSec-bezogene Probleme dar, das von Mitarbeitern am Helpdesk angewendet wird, die Supportdienstleistungen der Ebene 1 bereitstellen. Bei Supportmitarbeitern der Ebene 1 handelt es sich meist um Helpdeskmitarbeiter, die telefonisch Störungen aufnehmen und versuchen, eine Remotediagnose der Probleme zu erstellen.

Wird das Problem durch IPSec verursacht?

Das Helpdesk erhält häufig Anrufe, wie "Ich konnte auf Server x zugreifen, bis IPSec aktiviert wurde" oder "Gestern funktionierte alles noch problemlos, heute kann überhaupt keine Verbindung mehr hergestellt werden". Die Erfahrung von Microsoft IT zeigt, dass der Rollout von IPSec zu einer erhöhten Zahl an Anrufen zu allen Arten von Netzwerkverbindungsstörungen und Ereignissen wie "Zugriff verweigert" führt, da die Benutzer verstärkt auf das Verhalten der Anwendungen und des Netzwerks achten. Wenn die Benutzer der Meinung sind, es handele sich um durch IPSec verursachte Störungen, wenden sie sich an das Helpdesk. Ein Plan zur Implementierung der Server- und Domänenisolierung muss ein Klassifizierungssystem für Anrufe umfassen, so dass Helpdeskmitarbeiter genaue Berichte zur Anzahl und Art der IPSec-bezogenen Probleme bereitstellen können.

Nachdem entsprechende verwaltungsbezogene Informationen vom Anrufer erfragt wurden, müssen die Helpdeskmitarbeiter einen definierten Ablauf zur Problembehandlung einhalten. Da die Definition der IPSec-Richtlinien unter Umständen bezüglich ihrer Auswirkungen auf die Kommunikation variieren und der Rolloutprozess mehrere Tage oder Wochen in Anspruch nehmen kann, muss ein Flussdiagramm erstellt werden, das für sämtliche vorgenommenen Änderungen an der Isolierungsimplementierung aktualisiert werden muss. Helpdeskverwaltungsmitarbeiter müssen in diesen Planungsprozess mit einbezogen werden.

Das Ziel des Helpdesks sollte die Kategorisierung des Problems sein, so dass bekannte Lösungsansätze angewendet werden können. Wenn dadurch das Problem nicht behoben werden kann, können die Helpdeskmitarbeiter sicherstellen, dass korrekte Informationen zusammengestellt wurden, und das Problem an den Support der Ebene 2 eskalieren. Das Helpdesk sollte beispielsweise in der Lage sein, verschiedene Problemtypen wie folgt zu identifizieren:

• Netzwerkkonnektivität. Verwenden Sie den Befehl ping und tracert für das Protokoll ICMP (Internet Control Message Protocol) zum Überprüfen der Netzwerkpfade.
• Namensauflösung. Verwenden Sie ping*<Name des Ziels>* und nslookup.
• Anwendungen. Für einige Anwendungen ist die Kommunikation mit dem Ziel möglich (beispielsweise net view), für andere jedoch unter Umständen nicht.
• Dienste. Ermitteln Sie beispielsweise, ob der Server den RRAS-Dienst (Routing and Remote Access Service) ausführt, der zu einem automatischen Konflikt der IPSec-Richtlinie mit L2TP-Verbindungen führt.
• Der Computer des Anrufers. Ermitteln Sie, ob der Computer auf einen beliebigen Host oder auf Computer bestimmter vertrauenswürdiger Hosts zugreifen kann, die für Test- und Diagnosezwecke des Helpdesks verwendet werden.
• Der Zielcomputer. Ermitteln Sie, ob der Computer des Anrufers auf sämtliche Helpdeskcomputer, die für Testzwecke verwendet werden, nicht jedoch auf den Zielcomputer zugreifen kann.

Je nach der betreffenden Organisationsstruktur kann das Helpdesk mithilfe einer Remoteunterstützung oder über Remotedesktop auf den Computer des Anrufers zugreifen. Die in diesem Kapitel angegebenen Richtlinien erfordern keinen Remotezugriff; diese Tools bieten jedoch eine hilfreiche Unterstützung für Helpdeskmitarbeiter als Alternative dazu, den Anrufer durch das Snap-In für die IPSec Monitor Microsoft Management Console (MMC) oder die Ereignisanzeige anzuleiten.

In Szenarien, in denen eine Serverisolierung ohne Domänenisolierung verwendet wird, müssen die Helpdeskmitarbeiter über Informationen dazu verfügen, welche Server zur Isolierungsgruppe gehören.

Zuweisen von Sicherheitsanfälligkeit und Schweregrad

Eine der ersten Fragen, die der Support der Ebene 1 stellen muss, ist: Wer ist von dem Problem betroffen? Supportmitarbeiter müssen wissen, ob das Problem auch bei anderen Benutzern auftritt und, sollte das der Fall sein, um wie viele Benutzer es sich dabei handelt und wo sich diese Benutzer befinden. Die Supportmitarbeiter müssen dann das Ausmaß des Problems betrachten. Ist beispielsweise ein einzelner Server betroffen oder bestehen schwerer wiegende Probleme, wie fehlgeschlagene Anmeldungen oder Authentifizierungen in weiten Teilen des Netzwerks?

Verbindungsprobleme können viele unterschiedliche Schichten und Technologien betreffen, die bei der Netzwerkkommunikation verwendet werden. Supporttechniker müssen allgemein mit der Funktionsweise der Kommunikation in Windows TCP/IP-Netzwerken sowie mit bestimmten Themen, die mit der Lösung verknüpft sind, vertraut sein. Dieser Abschnitt bietet eine Übersicht über bestimmte Problemtypen und häufige Anfragen, mit denen sich der Support der Ebene 1 befassen muss.

• Computerspezifische Probleme. Für die IPSec-geschützte Kommunikation ist ein gegenseitiger Schlüsselaustausch (Internet Key Exchange, IKE) für die Authentifizierung der Computer erforderlich. Computer, die eine Kommunikation starten, und Computer, die auf eine Kommunikation antworten, müssen über gültige Domänenkonten und einen Zugriff auf Domänencontroller für ihre Domäne verfügen. Darüber hinaus richtet sich die Zuweisung von IPSec-Richtlinien und Netzwerkzugriffssteuerungen nach den Computerkonten, die sich in den korrekten Domänengruppen befinden. Zu weiteren computerspezifischen Gegebenheiten, die das IPSec-Verhalten beeinträchtigen können, gehört Folgendes:

  • Das Betriebssystem verfügt nicht über das korrekte Service Pack, das korrekte Patch oder die korrekte Registrierungsschlüsselkonfiguration.
  • Auf dem Computer ist eine bestimmte Software installiert, oder es werden bestimmte Dienste ausgeführt.
  • Die Netzwerkverbindung verwendet eine spezielle IP-Adresse oder kommuniziert über einen bestimmten Netzwerkpfad.

  Aufgrund dieser Gegebenheiten können eventuell Verbindungsprobleme bei einigen Computern auftreten; diese müssen jedoch nicht bei allen Computern zu Störungen führen.

  Hinweis

  
  Für alle in diesem Kapitel aufgeführten Tools zur IPSec-Problembehandlung sind lokale Administratorgruppenberechtigungen erforderlich.

• Netzwerkstandort- und -pfadspezifische Probleme. Bei einer Server- und Domänenisolierungslösung oder einer anderen weit verbreiteten Bereitstellung von IPSec wird in den meisten Fällen eine Kapselung des gesamten TCP- und UDP-Datenverkehrs durchgeführt. Daher werden für die Netzwerkgeräte im Pfad nur IKE-, IPSec- und ICMP-Protokolle angezeigt. Wenn bei der Übertragung dieser drei Protokolle zwischen der Quelle und dem Ziel Netzwerkprobleme auftreten, kann die Kommunikation zwischen den beiden Computern blockiert werden.

• Benutzerspezifische Probleme. Die Bereitstellung von IPSec, wie in einem Server- und Domänenisolierungszenario, kann Anmeldeberechtigungen am Netzwerk für Domänenbenutzer beeinträchtigen. Das Problem kann beispielsweise nur Benutzer betreffen, die nicht Mitglied einer autorisierten Gruppe für den Netzwerkzugriff sind. Es kann auch vorkommen, dass bei einem autorisierten Benutzer Probleme beim Abrufen der Anmeldeinformationen der Kerberos-Authentifizierung auftreten, die die korrekten Gruppenmitgliedschaften enthalten. Es können eventuell Unterschiede im Verhalten zwischen Domänenbenutzern und lokalen Benutzern oder Dienstkonten bestehen.

Zwei weitere Funktionen der Server- und Domänenisolierungslösung, die ebenfalls häufig in Organisationen mit IPSec-Bereitstellung eingesetzt werden, sind die Verwendung von Subnetzfiltern zur Definition des im internen Netzwerk verwendeten Adressbereichs und die Anwendung von IPSec-Richtlinien, die auf der Domänen- und Gruppenmitgliedschaft basieren, unabhängig davon, wo sich der Computer im internen Netzwerk befindet. Wenn daher ein Problem aufgrund der erstellten Subnetzfilters oder des Netzwerkpfads auftritt, der vom Computer für die Kommunikation mit anderen Computern verwendet wird, bestehen Verbindungsprobleme unter Umständen nur in bestimmten Teilen des Netzwerks, wenn eine bestimmte IP-Adresse (beispielsweise eine drahtlose Adresse statt einer LAN-Adresse) verwendet wird, oder das Problem tritt eventuell nur bei bestimmten Computern auf.

Flussdiagramme bei der Problembehandlung

Die Flussdiagramme für die Verwaltung von Anrufen in diesem Abschnitt wurden von Microsoft IT entwickelt, um den IPSec-Support der Ebene 1 beim Klassifizieren der Probleme zu unterstützen. Neben den Standardtools beziehen sich zwei der Flussdiagramme auf ein Aktualisierungsskript der IPSec-Richtlinien, das in Abschnitt "Beispiele für Supportskripts" weiter unten in diesem Kapitel genauer erläutert wird.

Abbildung 7.1 wird für die erste Diagnose und für die Ermittlung der Art des Problems verwendet:

• Handelt es sich um ein Problem mit der Netzwerkverbindung? Falls ja, gehen Sie anhand des grundlegenden Ansatzes zur Netzwerkproblembehandlung vor. Führt dies nicht zur Lösung des Problems, eskalieren Sie zum Support der Ebene 2.

• Handelt es sich um ein Problem mit der Namensauflösung? Falls ja, gehen Sie anhand des grundlegenden Problembehandlungsansatzes für die Namensauflösung vor. Führt dies nicht zur Lösung des Problems, eskalieren Sie zum Support der Ebene 2.

• Handelt es sich um ein Problem mit einer Anwendung? Falls ja, eskalieren Sie zum Support der Ebene 2.

• Handelt es sich um ein IPSec-Problem mit dem Computer des Anrufers? Falls ja, wechseln Sie zu Abbildung 7.2.

• Handelt es sich um ein IPSec-Problem mit dem Zielcomputer, den der Anrufer erreichen möchte? Falls ja, wechseln Sie zu Abbildung 7.3.

  

  Abbildung 7.1: Problembehandlungsprozess bei Fehlschlagen der Kommunikation mit einem Zielcomputer

  Bild in voller Größe anzeigen

Abbildung 7.2 wird als Unterstützung beim Identifizieren von Problemen mit dem Computer des Anrufers verwendet. Beachten Sie, dass dieses Flussdiagramm sich neben der Diagnose auf die Verwendung eines Aktualisierungsskripts für IPSec-Richtlinien bezieht (siehe "Beispiele für Supportskripts" weiter unten in diesem Kapitel), mit der eventuell eine Behebung des Problems möglich ist, ohne dieses zu identifizieren. Die Schritte in Abbildung 7.2 bieten Unterstützung bei folgenden möglichen Problemen mit dem Computer des Anrufers:

• Handelt es sich um ein Problem mit dem RRAS-Dienst (Routing and Remote Access Service)? Falls ja, beenden Sie entweder den RRAS-Dienst (wenn RRAS nicht benötigt wird), oder eskalieren Sie das Problem zum Support der Ebene 2.

• Handelt es sich um ein Problem mit der Richtlinie? Falls ja, versuchen Sie, die Gruppenrichtlinie und die IPSec-Richtlinie zu aktualisieren.

• Handelt es sich um ein Problem mit dem Domänenkonto? Falls ja, erstellen Sie ein Domänenkonto für den Computer des Anrufers.

• Handelt es sich um keines der oben genannten Probleme? Wenn das Problem nicht durch die Aktualisierung der IPSec-Richtlinie und/oder Erstellung eines Domänenkontos behoben werden kann, eskalieren Sie die Störung zum Support der Ebene 2.

  

  Abbildung 7.2: Problembehandlung bei IPSec-bezogenen Problemen des Computers des Anrufers

  Bild in voller Größe anzeigen

Abbildung 7.3 wird als Unterstützung beim Identifizieren von Problemen mit einem bestimmten Zielcomputer verwendet. Beachten Sie, dass dieses Flussdiagramm sich auch auf die Verwendung eines Aktualisierungsskripts für IPSec-Richtlinien bezieht, mit der eventuell eine Behebung des Problems möglich ist, ohne dieses zu identifizieren. Abbildung 7.3 wird als Unterstützung beim Ermitteln der folgenden möglichen Probleme mit dem Zielcomputer (oder dem zugehörigen Pfad) verwendet:

• Handelt es sich um ein Problem mit dem RRAS-Dienst (Routing and Remote Access Service)? Falls ja, eskalieren Sie zum Support der Ebene 2.

• Handelt es sich um ein Problem mit der IPSec-Richtlinie? Falls ja, versuchen Sie, die Gruppenrichtlinie und die IPSec-Richtlinie zu aktualisieren. Überprüfen Sie anschließend die Netzwerkkonnektivität.

• Handelt es sich um ein Problem mit der Netzwerkkonnektivität? Falls ja, eskalieren Sie zum Support der Ebene 2.

• Handelt es sich um ein Problem mit der Anmeldeberechtigung? Falls ja, eskalieren Sie zum Support der Ebene 2.

  

  Abbildung 7.3: Problembehandlung bei IPSec-bezogenen Problemen des Zielcomputers

  Bild in voller Größe anzeigen

Nachdem die Supportmitarbeiter der Ebene 1 entsprechend den Flussdiagrammen vorgegangen sind, besteht einer der folgenden Problemstatus:

• Behoben und verstanden. Dieser Status bedeutet, dass das Problem gelöst und die Ursache des Problems ermittelt wurde.
• Behoben und unklar. Dieser Statusbedeutet, dass die Störung behoben, die Problemursache jedoch nicht vollständig geklärt wurde. Das Problem kann beispielsweise durch eine Aktualisierung einer IPSec-Richtlinie behoben werden, dadurch wird jedoch nicht notwendigerweise erklärt, warum vorher eine nicht korrekte Richtlinie oder gar keine Richtlinie angewendet wurde.
• Nicht behoben. Dieser Status bedeutet, dass das Problem noch besteht, es wurden jedoch wahrscheinlich Informationen zum Problem zusammengestellt, da die Störung zum Support der Ebene 2 eskaliert wurde.

Vorbeugung von Social-Engineering-Angriffen

In einer isolierten Lösung ermitteln Helpdeskmitarbeiter unter Umständen bestimmte Bereiche innerhalb der IT-Umgebung, die nicht durch IPSec geschützt sind, wie Computer, die zu einer Ausnahmeliste gehören. Sie werden unter Umständen nicht dafür eingesetzt, sensible Daten zu schützen, da solche kritischen Informationen in anderen Sicherheitslösungen üblicherweise nur für Supportteams höherer Ebenen zugänglich sind. Daher sollten die Helpdeskmitarbeiter darin geschult werden, Social-Engineering-Angriffe zu erkennen und diesen zu widerstehen.

Bei einem Social-Engineering-Angriff versucht eine nicht vertrauenswürdige Person an Informationen dazu zu gelangen, wie Sicherheitslösungen implementiert wurden und wo Sicherheitslücken bestehen. Häufig wird dabei einfach der Umstand ausgenutzt, dass im Allgemeinen anderen Personen ein gewisses Vertrauen entgegengebracht wird. Es wird empfohlen, die folgenden Informationen sorgfältig durch die Helpdeskmitarbeiter prüfen zu lassen:

• Mitglieder der Ausnahmeliste. Die Liste der IP-Adressen in den Filtern der Ausnahmeliste ist wahrscheinlich für die lokalen Administratoren auf allen vertrauenswürdigen Hosts über das MMC-Snap-In für den IPSec Monitor oder über den Cachespeicher der Domänen-IPSec-Richtlinie in der lokalen Registrierung zugänglich. Darüber hinaus gewähren die Sicherheitseinstellungen der Organisation eventuell Benutzern ohne Administratorrechte einen Lesezugriff auf den Cachespeicher. Nachdem die Domänenisolierung vollständig implementiert wurde, müssen Angreifer das Netzwerk durchsuchen, um Computer der Ausnahmeliste zu ermitteln, die auf TCP- und UDP-Verbindungsanforderungen antworten können. Beachten Sie, dass DNS-Server, DHCP-Server und WINS-Server einfach durch die DHCP-Konfiguration identifiziert werden können und dass die Position eines Domänencontrollers einfach über eine DNS-Anfrage oder eine UDP-LDAP-Anfrage (LDAP = Light Directory Access Protocol) ermittelt werden kann.
• Computer in der Organisation, die nicht an der Isolierungslösung beteiligt sind. Bestimmte Domänen- oder Servertypen sind beispielsweise eventuell nicht in die Lösung mit eingeschlossen.
• Computer, die eine Serverisolierung verwenden oder eine computerbasierte Zugriffssteuerung erfordern. Die Server, die die sensibelsten Daten enthalten, sind meist durch die effektivsten Sicherheitsmaßnahmen geschützt.
• Benutzer, die als Administrator tätig sind oder die bestimmte Rollen in einer IT-Organisation einnehmen. In einigen Fällen werden E-Mail-Adressen als Computernamen oder Teil eines Computernamens verwendet, wobei Anmeldenamen oder E-Mail-Adressen bekannt gegeben werden.
• Subnetze, die für bestimmte Zwecke oder von bestimmten Organisationen verwendet werden. Wenn diese Informationen bekannt sind, kann ein Angreifer sich auf die sensibelsten und wertvollsten Teile des Netzwerks konzentrieren.
• Weitere eingesetzte netzwerkbasierte Sicherheitsmaßnahmen. Kenntnisse beispielsweise darüber, ob Firewalls eingerichtet sind, ob Routerfilter bestimmten Datenverkehr zulassen oder ob Systeme zur Erkennung von Netzwerkeindringungsversuchen verwendet werden, sind für einen Angreifer äußerst nützlich.

Helpdeskmitarbeiter müssen darüber hinaus dafür geschult werden, wachsam zu sein, wenn ein Anrufer sie darum bittet, eine Verbindung mit der IP-Adresse ihrer Computer herzustellen, um das Problem zu ermitteln beispielsweise wenn ein Angreifer von einer Person am Helpdesk verlangt, eine Verbindung mit ihrem Computer über Freigabeoptionen, Remotedesktop, Telnet oder andere Netzwerkprotokolle herzustellen. Wenn ein Helpdeskmitarbeiter die Verbindung ohne IPSec herstellt, kann der Computer des Angreifers Informationen zum Kennwort erhalten oder (in einigen Fällen, wie mit Telnet), das Kennwort selbst übernehmen. Dies kann vorkommen, da einige Clientnetzwerkprotokolle keine Authentifizierung veranlassen und eine streng vertrauenswürdige Verbindung mit dem Zielcomputer herstellen bzw. keinen strengen Kennwortschutz anfordern, bevor die Identität des Benutzers oder kennwortbezogene Informationen freigegeben werden.

Beispiele für Supportskripts

In den meisten Problembehandlungsszenarien wird eine Lösung schnell ermittelt, nachdem die entsprechenden Informationen identifiziert wurden. Diese Informationen können verschiedenen Windows-Tools entnommen werden, wie in den Flussdiagrammen angegeben. Für die Lösung in der Woodgrove Bank wurden mehrere Skripts erstellt, um wichtige Informationen bereitzustellen, ohne dass die Supportmitarbeiter der Ebene 1 über detaillierte Kenntnisse zum Betrieb und zur Syntax der Tools verfügen müssen. Diese Skripts sind im Ordner "Tools and Templates" als Download für diesen Leitfaden verfügbar.

Verfügbare Skripts für den Support der Ebene 1

Wenn es sich beim Benutzer um einen lokalen Administrator des Computers handelt, können die Helpdeskmitarbeiter diesen dazu auffordern, eines der drei mit der Lösung bereitgestellten Skripts auszuführen. Diese Skripts sind Beispiele für benutzerdefinierte Skripts, die für die in diesem Leitfaden erläuterte Umgebung der Woodgrove Bank verwendet werden. Die Beschreibung dieser Skripts in diesem Kapitel dient dazu, die Verwendung von Skripts als Unterstützung beim Problembehandlungsprozess darzustellen.

IPsec_Debug.vbs

Neben der Bereitstellung von Fehlerbehebungsinformationen kann dieses Skript eventuell selbst zum Beheben von einigen Problemen verwendet werden. Es beendet den IPSec-Dienst und starten ihn erneut (dadurch werden alle IKE- und IPSec-Sicherheitszuordnungen gelöscht), erzwingt die Aktualisierung einer Gruppenrichtlinie zum Neuladen der aktuellen IPSec-Richtlinie, die der Domäne vom Verzeichnisdienst Active Directory® zugewiesen wurde, und aktualisiert den Richtliniencache. Um den Verlust der Verbindung für Remotedesktopsitzungen zu vermeiden, sollte dieses Skript auf den Computer des Anrufers geladen werden und lokal von einem Konto aus ausgeführt werden, das über Administratorrechte verfügt. Verwenden Sie die folgende Syntax, um das Skript über eine Eingabeaufforderung auszuführen:

    cscript IPsec_Debug.vbs

Das Skript führt Folgendes aus:

• Feststellen der Version des Betriebssystems
• Aufrufen von Detect_IPsec_Policy.vbs
• Verstärkte Protokollierung der Gruppenrichtlinien
• Verstärkte Protokollierung des Authentifizierungsprotokolls Kerberos Version 5
• Löschen von aktuellen Kerberos-Protokolltickets
• Aktualisieren von Gruppenrichtlinien
• Aktivieren der IPSec-Protokollierung
• Ausführen von PING- und SMB-Überprüfungen (Net View)
• Ermitteln der IPSec-Dateiversionen
• Ausführen der Richtlinien- und Netzwerkdiagnoseüberprüfungen
• Kopieren der IPSec 547-Ereignisse in eine Textdatei
• Deaktivieren der IPSec-Protokollierung
• Wiederherstellen der Protokollierung des Kerberos-Protokolls
• Wiederherstellen der Protokollierung der Gruppenrichtlinien

Dieses Skript aktiviert darüber hinaus alle IPSec-bezogenen Protokolle für die Problembehandlung des Supports der Ebene 2.

Detect_IPsec_Policy.vbs

Dieses Skript stellt fest, ob ein Computer die korrekte IPSec-Richtlinie ausführt, indem der aktuelle lokale Registrierungscache auf Richtlinienversionsinformationen der IPSec-Domänenrichtlinie überprüft wird. Verwenden Sie die folgende Syntax, um das Skript über eine Eingabeaufforderung auszuführen:

    cscript Detect_IPsec_Policy.vbs

Refresh_IPsec_Policy.vbs

Dieses Skript ist das Aktualisierungsskript der IPSec-Richtlinie, auf das in den Flussdiagrammen der Problembehandlung verwiesen wird. Es aktualisiert Kerberos-Authentifizierungsprotokolltickets des Computers und kann das Problem beheben, wenn dieses durch eine nicht korrekt zugewiesene IPSec-Richtlinie oder einen fehlgeschlagenen Download der Gruppenrichtlinien verursacht wird. Verwenden Sie die folgende Syntax, um das Skript über eine Eingabeaufforderung auszuführen:

    cscript Refresh_IPsec_Policy.vbs

Eskalation

Wenn Helpdeskmitarbeiter eine Anfrage eskalieren müssen, bei der es sich vermutlich um ein IPSec-Problem handelt, müssen folgende Informationen von Ebene 1 gesammelt und zusammen mit der Dienstanforderung weitergeleitet werden:

• Protokolldateien, die mit dem Skript IPsec_Debug.vbs erstellt wurden
• Computername des Anrufers, damit die nächste Supportebene die vom Skript erstellte Protokolldatei identifizieren kann
• Zielcomputer, für den der Zugriff verweigert wurde, so dass die Eskalation an die zuständige Supportgruppe weitergeleitet werden kann

In Serverisolierungsszenarien bestehen oft eigene Supportgruppen für die Überprüfung einer Mitgliedschaft einer Netzwerkzugriffsgruppe.

Zum Seitenanfang

Vorbereitung der Problembehandlung von Ebene 2

Der Support der Ebene 2 hat zwei hauptsächliche Rollen zu erfüllen. Zunächst bewertet die Ebene 2 als Empfänger aller Eskalationen von Ebene 1 die Störungen und überprüft die von Ebene 1 durchgeführten Schritte, um sicherzustellen, dass keine Problembehandlungsschritte ausgelassen wurden. In diesem Zusammenhang muss die Ebene 2 eine Bestätigung ausgeben, dass sämtliche eskalierten Störungen tatsächlich durch IPSec verursacht wurden und es sich nicht um eine Fehldiagnose handelt. Zudem müssen Supportmitarbeiter der Ebene 2 als qualifizierte Supporttechniker in der Lage sein, ihre Fertigkeiten und Erfahrungen (wie im folgenden Abschnitt aufgeführt) einzusetzen, um eine erfolgreiche Problemlösung durch eine Protokollanalyse durchzuführen, ohne dass ein Administratorzugriff auf den Computer erforderlich ist. Die Protokolle erfassen jedoch lediglich die Daten, für die Korrekturmaßnahmen muss ein Administratorzugriff erfolgen. Es wird nicht vorausgesetzt, dass es sich bei einem Supportmitarbeiter der Ebene 2 um einen Domänenadministrator handelt oder dass dieser Änderungen an einer domänenbasierten IPSec-Richtlinie oder an Mitgliedschaften einer Computergruppe vornehmen kann.

Fertigkeiten des Supports der Ebene 2

Supportmitarbeiter, die IPSec-Supportdienstleistungen der Ebene 2 bereitstellen, müssen über Fertigkeiten und Erfahrungen in folgenden Bereichen verfügen:

• Gruppenrichtlinien. Der Supportmitarbeiter muss über Kenntnisse darüber verfügen, welche Richtlinien zugewiesen werden und wie die Zuweisung erfolgt, und er muss in der Lage sein, die folgenden Aufgaben auszuführen:
  • Überprüfen der Zugriffssteuerungslisten (Access Control Lists, ACL) für Gruppenrichtlinienobjekte (Group Policy Objects, GPO)
  • Überprüfen der GPO-Einstellungen
  • Überprüfen der Gruppenmitgliedschaften für Computer und Benutzer
• Erfahrungen mit Software von Drittanbietern, die von der Organisation verwendet wird
• Identifizierung von Authentifizierungsfehlern
  • Kenntnisse darüber, wie ein Domänencomputerkonto auf seine ordnungsgemäße Funktionalität unter Verwendung der Dienstprogramme netdiag und nltest überprüft wird
• IPSec-Konfiguration. Der Supportmitarbeiter muss in der Lage sein, die folgenden Aufgaben auszuführen:
  • Überprüfen der IPSec-Filterkonfigurationen
  • Neuladen der IPSec-Domänenrichtlinie
  • Vollständiges Deaktivieren von IPSec oder nur der Domänenrichtlinie, die für die lokale Überprüfung verwendet wird
  • Problembehandlung des IPSec-IKE-Verhandlungsvorgangs und der Sicherheitsprotokolle
• Netzwerk. Der Supportmitarbeiter muss in der Lage sein, die folgenden Aufgaben auszuführen:
  • Problembehandlung des Netzwerkprotokollstapels auf einem Hostcomputer
  • Analysieren und Durchführen einer Problembehandlung für die Informationen, die bei einer Netzwerkverfolgung gesammelt wurden
  • Behandeln von Netzwerkpfadproblemen, einschließlich Remotezugriffslösungen für die Ermittlung der TCP-Pfad-MTU und für das virtuelle private Netzwerk (VPN)

Störungen in Verbindung mit der Verwendung von IPSec

Wie im vorherigen Abschnitt erwähnt, verfügen die Supportmitarbeiter der Ebene 2 für eine Server- und Domänenisolierungslösung über die Details zur Kommunikation, die durch IPSec geschützt ist; sie müssen jedoch darüber hinaus auch in der Lage sein, Probleme für andere technologische Komponenten zu isolieren.

Für eine erfolgreiche Kommunikation zwischen zwei Computern müssen in der Regel beide Computer über eine kompatible IPSec-Richtlinie verfügen. Eine IPSec-Richtlinie kann unter Umständen eine Kommunikation blockieren, wenn der Remotecomputer über keine entsprechende IPSec-Richtlinie verfügt. Auch wenn es sich dabei um ein erwünschtes oder akzeptables Verhalten während des Rollouts einer Richtlinienänderung handelt, wird unter Umständen nicht immer sofort erkannt, ob die geänderte Richtlinie die Netzwerkkonnektivität mit einem oder mehreren Computern blockiert und zu Warnmeldungen oder Fehlern führt. Im schlimmsten anzunehmenden Fall kann ein Administrator allen Mitgliedern der Domäne eine IPSec-Richtlinie zuweisen, die den gesamten Datenverkehr blockiert. Sofern der Fehler nicht umgehend erkannt wird und schnell eine Replikation der korrekten Zuweisung nach der ursprünglichen Zuweisung erfolgt, kann die Replikation der Richtlinie, die den Schaden verursacht, nicht einfach angehalten werden. Dieser Fehlertyp führt zu einer Situation, in der für eine Kommunikation zwischen einen Client und einem Domänencontroller die Verwendung von IPSec erforderlich ist. Da die für diese Lösung verwendete Authentifizierung auf dem Kerberos-Protokoll beruht, kann kein Client, der diese Richtlinie übernimmt, den Anmeldevorgang abschließen, denn die Clients können das erforderliche Kerberos-Ticket zum Sichern der Kommunikation nicht abrufen. Für sämtliche Änderungen an den Richtlinien ist eine sorgfältige Planung seitens der Administratoren erforderlich, die darüber hinaus sicherstellen müssen, dass prozedurale Sicherheitsmaßnahmen bestehen, die in einer solchen Situation eine Schadensbegrenzung bieten können.

Hintergrundinformationen zur Problembehandlung von TCP/IP finden Sie in den Leitfäden zur Problembehandlung im Abschnitt "Weitere Informationen" am Ende dieses Kapitels. Viele der Vorgänge, auf die in diesen Leitfäden verwiesen wird, funktionieren nur, wenn IPSec eine erfolgreiche Möglichkeit zum Aufbau von Verbindungen bereitstellt. Wenn IKE oder IPSec fehlschlägt, können die meisten dieser Vorgänge oder Tools nicht zum Beheben von Problemen eingesetzt werden. In einem Server- oder Domänenisolierungszenario funktionieren einige der in diesen informativen Leitfäden dokumentierten Verfahren unter Umständen gar nicht, auch wenn IPSec eine erfolgreiche Verbindungserstellung ermöglicht. Eine Supportorganisation muss daher die Problembehandlungstools und -verfahren aktualisieren und so anpassen, dass sie auch weiterhin innerhalb einer Server- und Domänenisolierungsumgebung effektiv eingesetzt werden können. Da für die Bereitstellung von IPSec-Richtlinien zur Steuerung und Unterstützung von sicherem Datenverkehr viele unterschiedliche Möglichkeiten bestehen, kann sich eine Organisation meist nicht auf nur auf bestehende Verfahren und ein generisches Toolkit verlassen.

Für Supportmitarbeiter ist es unabdingbar, über dokumentierte Beispiele des erwarteten Ergebnisses mit Problembehandlungstools für Netzwerke zu verfügen, das in einer Testumgebung gewonnen wurde, in der die Server- und Domänenisolierung oder eine andere IPSec-Bereitstellung fehlerlos funktioniert. Häufig erwarten die Netzwerkdiagnosetools keine 3-Sekunden-Verzögerungen für das Zurückgreifen auf ungesicherte Verbindungen oder kurze Verzögerungszeiten, die bei der erstmaligen IKE-Verhandlung der IPSec-Sicherheitszuordnungen (Security Associations, SA) auftreten. Daher zeigen die Tools unter Umständen bei der erstmaligen Ausführung ein anderes Ergebnis an als einige Sekunden später bei einer weiteren Ausführung. Darüber hinaus geben die Tools einen Fehlerbericht aus, wenn der Netzwerkzugriff gezielt von IPSec verweigert wurde. Der Fehlertyp hängt vom Tool und von der IPSec-Umgebung ab.

Grupperichtlinie und Gruppenmitgliedschaften

Domänenbasierte IPSec-Richtlinien hängen von der Gruppenrichtlinie und dem Download von GPOs ab. Wenn im Gruppenrichtliniensystem des Clients Fehler beim Ermitteln der GPO-Änderungen oder beim Download der GPOs auftreten, können davon auch die IPSec-Verbindungen beeinträchtigt werden. Wenn die Zuweisung der Gruppenrichtlinie von einem Mitglied einer Organisationseinheit (Organizational Unit, OU) gesteuert wird und die Computerkonten versehentlich an eine andere OU verschoben, gelöscht oder in der falschen OU erstellt wurden, wird eventuell eine nicht korrekte IPSec-Richtlinie zugewiesen.

Diese Lösung verwendet Domänensicherheitsgruppen zum Steuern der Gruppenzuweisung und des Netwerkzugriffs. Die Gruppenmitgliedschaft ist in Protokolltickets für die Kerberos-Authentifizierung der Version 5 (TGT und Diensttickets) mit einer relativ langen Lebensdauer enthalten. Deshalb müssen die Administratoren die Zeit bei ihrer Planung berücksichtigen, die die Computer für den Empfang der neuen Anmeldeinformationen für das Kerberos-TGT und Dienstticket benötigen, die Aktualisierungsdaten für die Gruppenmitgliedschaft enthalten. Mit dem Kerberos-Protokoll ist es äußerst schwierig zu bestimmen, ob die Kerberos-Tickets für einen Computer die korrekte Gruppenmitgliedschaft enthalten. Diese Schwierigkeiten sind durch die Beschaffenheit der Tickets bedingt, da alle Informationen zur Gruppenmitgliedschaft in verschlüsselter Form innerhalb des Tickets gespeichert sind. Die Gruppenmitgliedschaft muss unter Verwendung der Informationen innerhalb des Verzeichnisdienstes ermittelt werden, nicht anhand der Tickets selbst.

Kerberos-Authentifizierung

Für den Entwurf der Server- und Domänenisolierung wird das Kerberos-Protokoll, Version 5, für die IKE-Authentifizierung verwendet. Da für das Kerberos-Protokoll eine Netzwerkverbindung und Dienste von DNS- und Domänencontrollern erforderlich sind, führt ein Fehlen der Verbindung zum Fehlschlagen der Kerberos-Authentifizierung sowie zum Fehlschlagen von IKE. (IKE schlägt auch fehl, wenn Kerberos selbst fehlschlägt.) Somit können Konnektivitätsprobleme zwischen Computer A und Computer B durch eine blockierte Netzwerkverbindung zwischen Computer A und Computer C verursacht werden. Diese Probleme werden dadurch bedingt, dass für das Kerberos-Protokoll keine Authentifizierung mit einem Domänencontroller möglich ist. In einem solchen Fall bieten die 547-Ereignisse der Überwachungs- und Sicherheitsprotokolle von Windows im Allgemeinen wertvolle Hinweise auf die Ursache des Problems.

Durch IPSec geschützter eingehender Datenverkehr erforderlich

Diese Server- und Domänenisolierungslösung gibt an, dass für einen eingehenden Zugriff eine durch IPSec geschützte Kommunikation erforderlich ist. Diese Anforderung veranlasst Remote-Überwachungstools, die auf nicht vertrauenswürdigen Computern ausgeführt werden, oder bestimmte Netzwerküberwachungsgeräte zur Ausgabe einer Meldung, dass keine Verbindung zu einem Remotecomputer hergestellt werden kann. Wenn diese Computer oder Geräte der "vertrauenswürdigen" Umgebung nicht beitreten können, können sie ihre Überwachungsaufgaben nicht ausführen, sofern bei diesem Entwurf nicht bestimmte Ausnahmen berücksichtigt werden. Wenn für die Verbindung zu einem vertrauenswürdigen Host IPSec erforderlich ist, wird die Problembehandlung schwieriger, da ein Administrator eventuell keine Verbindung zu einem vertrauenswürdigen Host herstellen und danach den IPSec-Dienst beenden kann, ohne dass die Verbindung unterbrochen wird. Wenn die IPSec-Richtlinie des Administrators das Zurückgreifen auf eine ungesicherte Verbindung zulässt, besteht für die Remoteverbindung eine Verzögerung von drei oder vier Sekunden, nachdem der Dienst auf dem Remotecomputer angehalten wird. Durch das Anhalten des IPSec-Dienstes auf einem Remotecomputer werden jedoch die IPSec-Sicherheitszuordnungen (SA) gelöscht, die von allen anderen Computern verwendet werden, für die derzeit eine Verbindung besteht. Wenn diese anderen Computer nicht auf eine unsichere Verbindung zurückgreifen können, wird die Kommunikation angehalten, und die TCP-Verbindungen überschreiten schließlich das Zeitlimit und werden beendet. Da durch plötzliche Unterbrechungen der TCP-Kommunikation Daten in Anwendungen beschädigt werden können, sollte das Beenden des IPSec-Dienstes nur als letzte Möglichkeit im Problembehandlungsprozess verwendet werden. Bevor der IPSec-Dienst angehalten wird, muss der Computer auf das Herunterfahren vorbereitet werden, so dass alle Benutzer, zu denen eine Verbindung besteht, sowie alle Anwendungen die Kommunikation korrekt beenden können.

Störungen der Kommunikationsrichtung

Ein häufiges Problembehandlungsszenario betrifft eine erfolgreiche Kommunikation in eine Richtung, während die Kommunikation in die Gegenrichtung fehlschlägt. Für die IKE-Authentifizierung ist in der Regel die gegenseitige Authentifizierung zwischen den Computern erforderlich. Wenn ein Computer kein Kerberos-Ticket beim Initiieren des IKE-Hauptmodus für einen Remotecomputer abrufen kann, führt dies zu einem Fehlschlagen des IKE. Das kann vorkommen, wenn der Kerberos-Client des Computers, der die Verbindung initiiert, auf keinen Domänencontroller in der Domäne des Zielcomputers zugreifen konnte. Wenn die Computer Mitglieder von Domänen sind, die sich nicht gegenseitig als vertrauenswürdig betrachten (beiderseitige Vertrauensstellung), sind die Verhandlungen des IKE-Hauptmodus erfolgreich, wenn einer der Computer die Verbindung startet, und schlagen fehl, wenn der Verbindungsversuch von dem anderen Computer initiiert wird. Ebenso können die eingehenden Netzwerkanmeldeberechtigungen auf zwei Computern unterschiedlich sein. Die Verhandlung des IKE-Hauptmodus und -Schnellmodus in eine Richtung kann aus diesem Grund fehlschlagen; es kann jedoch auch eine Inkompatibilität der IPSec-Richtlinie auf beiden Seiten für das Fehlschlagen verantwortlich sein.

Hostbasierte Firewalls, die den Datenverkehr über der IPSec-Schicht abfangen, können erzwingen, dass der Datenfluss in nur eine Richtung möglich ist. Einige hostbasierte Firewalls fangen Datenverkehr unterhalb der IPSec-Schicht ab. Nachdem eine erfolgreiche IPSec-Kommunikation hergestellt wurde, wird der durch IPSec geschützte Datenverkehr wahrscheinlich für eine bestimmte Zeitdauer in beide Richtungen zugelassen.

Eine statusbehaftete Filterung eines Netzwerkrouters oder einer Firewall kann den erneuten IKE-Schlüsselaustausch oder den IPSec-Datenfluss ebenfalls blockieren, ohne andere Diagnoseprotokolle wie ICMP zu beeinträchtigen. Es ist unter Umständen kein Zugriff auf TCP- und UDP-Ports auf einem Computer möglich, da ein bestimmter Dienst nicht ausgeführt wird oder ein Gerät, das über der IPSec-Schicht ausgeführt wird (wie die Windows-Firewall oder ein Netzwerkrouter) den Zugriff blockiert.

Ablaufverfolgung für das Netzwerk und erweiterte Problembehandlung für Netzwerkpfade

Fehler bei IKE-Verhandlungen führen häufig dazu, dass der Computer, bei dem der Fehler auftritt, nicht mehr auf die IKE-Verhandlung reagiert oder in einigen Fällen die letzte positive Meldung erneut sendet, bis die Beschränkung für die erneuten Versuche überschritten wird. IKE muss in der Lage sein, fragmentierte UDP-Datagramme, die Kerberos-Tickets enthalten, zu senden, da solche Pakete häufig die maximale Übertragungseinheit für den Pfad (Path Maximum Transmission Unit, PMTU) an die Ziel-IP-Adresse überschreiten. Wenn die Fragmentierung nicht korrekt unterstützt wird, werden solche Fragmente unter Umständen von den Netzwerkgeräten in einem bestimmten Pfad entfernt. Darüber hinaus leitet das Netzwerk IPSec-Protokollpakete oder Fragmente von IPSec-Paketen eventuell nicht korrekt weiter. Bei einer IPSec-Integration mit TCP kann TCP die Paketgröße reduzieren, um der Restkapazität der IPSec-Header zu entsprechen. Bei der TCP-Verhandlung der maximalen Segmentgröße (Maximum Segment Size, MSS) während des TCP-Handshake wird die IPSec-Restkapazität jedoch nicht berücksichtigt. Somit besteht eine erhöhte Anforderung an die ICMP-PMTU-Ermittlung im Netzwerk, um eine erfolgreiche IPSec-geschützte TCP-Kommunikation sicherzustellen. Aus diesem Grund kann die Problembehandlung von Verbindungsfehlern eine Ablaufverfolgung von Netzwerken auf beiden Seiten der Kommunikation sowie Protokolle von beiden Seiten der Kommunikation erfordern.

Die Mitarbeiter des technischen Supports müssen deshalb mit dem Lesen der Ablaufverfolgung von Netzwerken und mit der IKE-Verhandlung vertraut sein. Auf den Servern sollte die Software Windows Netzwerkmonitor installiert sein. Windows 2000 Netzwerkmonitor ermöglicht das Analysieren von IPSec AH und IKE. Windows Server 2003 ermöglicht darüber hinaus eine Unterstützung von IPSec ESP Null, eine Analyse von ESP bei einer ausgelagerten Verschlüsselung und eine Analyse der UDP-ESP-Kapselung für die Verwendung der NAT-Durchquerung.

Das Toolkit für die Problembehandlung

Vor Beginn der Problembehandlung ist es wichtig, die Hilfsmittel zu identifizieren, mit denen Informationen zusammengefasst werden können, um Unterstützung beim Problembehandlungsprozess bereitzustellen. Ziel dieses Abschnitts ist es nicht, Informationen erneut aufzuführen, die in der Hilfe zu Windows 2000, Windows XP oder Windows Server 2003 aufgeführt werden oder die über die Seite Troubleshooting Tools der Website von Microsoft Windows Server 2003 Website unter dieser Adresse aufgerufen werden können: www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/sag\_IPSec\_tools.asp.

Genauere Informationen zu Tools werden nur dann in diesem Abschnitt wiedergegeben, wenn diese nicht den Seiten zu den Problembehandlungstools entnommen werden können oder wenn eine Übersicht über die Versionen der Betriebssysteme sinnvoll ist.

MMC-Snap-In für die IP-Sicherheitsrichtlinienverwaltung

Das MMC-Snap-In für die IP-Sicherheitsrichtlinienverwaltung wird verwendet, um lokale IPSec-Richtlinien oder IPSec-Richtlinien, die in Active Directory gespeichert sind, zu erstellen oder zu verwalten. Es kann darüber hinaus verwendet werden, um IPSec-Richtlinien auf Remotecomputern zu ändern. Das MMC-Snap-In für die IP-Sicherheitsrichtlinienverwaltung ist in den Betriebssystemen Windows Server 2003, Windows XP, Windows 2000 Server und Windows 2000 Professional enthalten und kann zum Anzeigen von IPSec-Richtliniendetails, Filtern, Filterlisten und Filteraktionen und zum Zuweisen von IPSec-Richtlinien bzw. deren Aufhebung verwendet werden.

MMC-Snap-In für den IP-Sicherheitsmonitor

Das MMC-Snap-In für den IP-Sicherheitsmonitor zeigt IPSec-Statistiken und aktive Sicherheitszuordnungen (Securiy Association, SA) an. Es wird darüber hinaus verwendet, um Informationen zu folgenden IPSec-Komponenten anzuzeigen:

• IKE-Hauptmodus und -Schnellmodus
• Lokale oder domänenbasierte IPSec-Richtlinien
• IPSec-Filter, die auf den Computer angewendet werden

Dieses Snap-In gehört zu den Betriebssystemen von Windows XP und Windows Server 2003; es bestehen jedoch Unterschiede in der Funktionsweise und in der Benutzeroberfläche zwischen den Versionen für Windows XP und Windows Server 2003. Die Version für Windows Server 2003 verfügt darüber hinaus über die folgenden Zusatzfunktionen:

• Bietet Details zur aktiven IPSec-Richtlinie, einschließlich Richtlinienname, Beschreibung, letztes Änderungsdatum, Speichername, Pfadname, Name der Organisationseinheit sowie Name des Gruppenrichtlinienobjekts. Um dieselben Informationen unter Windows XP abzurufen, müssen Sie das Befehlszeilenprogramm "IPseccmd" verwenden (wird später in diesem Abschnitt erläutert).

• Die Statistiken für den Hauptmodus und den Schnellmodus werden getrennt in eigenen Ordnern unter jedem Modus und nicht in einer einzigen Anzeige dargestellt.

  Hinweis

  
  Unter Windows 2000 ist IP-Sicherheitsmonitor ein Programm, das eigenständig ausgeführt werden kann ("IPsecmon.exe") und über eine eigene grafische Benutzeroberfläche verfügt. Dieses Tool und seine Verwendung wird im Microsoft Knowledge Base-Artikel 257225, IPsec zu Problembehandlung in Microsoft Windows 2000 Server, erläutert, der unter https://support.microsoft.com/kb/257225 abgerufen werden kann.
  

Ein Update dieses Snap-Ins ist für Windows XP als Teil des Updates verfügbar, das in der Microsoft Knowledge Base-Artikel 818043 "L2TP/IPSec-NAT-T-Update für Windows XP und Windows 2000", erläutert ist. Dieser Artikel kann unter https://support.microsoft.com/?kbid=818043 abgerufen werden. Mit diesem Update können Windows Server 2003-Computer unter Windows XP angezeigt werden. Das aktualisierte MMC-Snap in für den IP-Sicherheitsmonitor kann darüber hinaus erweiterte Funktionen lesen, die unter Windows Server 2003 erstellt wurden (beispielsweise Diffie-Hellman 2048-Gruppeninformationen, Zertifikatszuordnungen und dynamische Filter), diese können jedoch nicht bearbeitet werden. Weitere Informationen dazu finden Sie in dem angegebenen Artikel in der Knowledge Base.

Netsh

"Netsh" ist ein Befehlszeilenskriptprogramm, mit dem Sie die Netzwerkkonfiguration anzeigen oder ändern können. Die Verwendung von "Netsh" ist lokal oder über einen Remotezugriff möglich. "Netsh" ist verfügbar für Windows 2000, Windows XP und Windows Server 2003. Die Version für Windows Server 2003 wurde jedoch um die IPSec-Diagnose- und -Verwaltungsfunktion erweitert. Die Netsh-Befehle für IPSec sind nur für Windows Server 2003 verfügbar; unter Windows XP ersetzen sie "Ipseccmd" und unter Windows 2000 ersetzen sie "Netdiag".

Ipseccmd

"Ipseccmd" ist ein alternatives Befehlszeilenprogramm zum MMC-Snap-In für die IP-Sicherheitsrichtlinie. Es ist nur für Windows XP verfügbar, und Windows XP Service Pack 2 stellt eine erweiterte Funktionalität für dieses Tool bereit.

"Ipseccmd" muss über den auf der Windows XP-CD enthaltenen Ordner "Support Tools" installiert werden. Eine aktualisierte Version ist in Verbindung mit Windows XP SP2 verfügbar. Sie muss über den auf der CD Windows XP SP2 enthaltenen Ordner "Support Tools" installiert werden. Die Version vor dem für SP2 verfügbaren Tool funktioniert nicht auf aktualisierten Computern, und die aktualisierte Version funktioniert nicht auf Computern, auf denen eine Vorgängerversion von SP2 ausgeführt wird.

Das aktualisierte Dienstprogramm "Ipseccmd" verfügt über folgende Funktionen:

• Schaltet die IKE-Protokollierung dynamisch ein und aus.
• Zeigt Informationen zu einer aktuell zugewiesenen Richtlinie an.
• Ermöglicht Ihnen, eine permanente IPSec-Richtlinie zuzuweisen.
• Kann die derzeit zugewiesene und aktive IPSec-Richtlinie anzeigen.

Weitere Informationen zum aktualisierten Dienstprogramm "Ipseccmd" finden Sie in der Microsoft Knowledge Base-Artikel 818043 (Verweis darauf siehe weiter oben in diesem Abschnitt).

Verwenden Sie zum Anzeigen aller IPSec-Richtlinieneinstellungen und Statistiken für Diagnosen die folgende Syntax:

ipseccmd show all

Verwenden Sie zum Anzeigen der derzeit zugewiesenen und aktiven IPSec-Richtlinien (lokal oder Active Directory) die folgende Syntax:

ipseccmd show gpo

Verwenden Sie zum Aktivieren der Debug-Protokollierung unter Windows XP SP2 die folgende Syntax:

"ipseccmd set logike" (kein Neustart des IPSec-Dienstes erforderlich)

Verwenden Sie zum Deaktivieren der Debug-Protokollierung die folgende Syntax:

"ipseccmd set dontlogike" (ebenfalls kein Neustart des IPSec-Dienstes erforderlich)

Netdiag

"Netdiag" ist ein Befehlszeilendiagnose-Tool, das zum Überprüfen der Netzwerkkonnektivität und -konfiguration, einschließlich der IPSec-Informationen, verwendet wird. "Netdiag" ist verfügbar unter Windows 2000, Windows XP und Windows Server 2003, die entsprechende Funktionalität variiert jedoch bei den einzelnen Betriebssystemversionen. Unter Windows Server 2003 umfasst Netdiag keine IPSec-Funktionalität mehr; stattdessen können Sie den Kontext "netsh ipsec" verwenden. Darüber hinaus kann eine grundlegende Netzwerküberprüfung über "Netsh" abgerufen werden. Sie müssen bei allen Betriebssystemen sicherstellen, dass die neueste Version verwendet wird. Die entsprechenden Informationen dazu erhalten Sie über das Microsoft Download Center. Netdiag muss über den Ordner "Support Tools" installiert werden, der auf der CD des jeweiligen Windows-Betriebssystems enthalten ist.

Die Relevanz von "Netdiag" bei der Problembehandlung für IPSec hängt vom Betriebssystem ab. Die Funktionsunterschiede werden in der folgenden Tabelle dargestellt.

Tabelle 7.1: IPSec-Funktionen von "Netdiag" bei verschiedenen Betriebssystemen

Befehl	Beschreibung	Windows2000?	WindowsXP?	Windows2003?
netdiag /test:ipsec	Anzeigen der zugewiesenen IPSec-Richtlinie	Ja	Ja	Nein**
netdiag /test:ipsec /debug	Anzeigen der aktiven IPSec-Richtlinie, der Filter und der Schnellmodusstatistiken	Ja	Ja*	Nein**
netdiag /test:ipsec /v	Anzeigen der aktiven IPSec-Richtlinie, der Filter und der Hauptmodusstatistiken	Ja	Ja*	Nein**

* Bietet eine Netzwerkdiagnose, zeigt jedoch nur den Namen der IPSec-Richtlinie an. Zusätzliche IPSec-Informationen sind unter Verwendung von Ipseccmd verfügbar.

** Bietet eine Netzwerkdiagnose, zeigt jedoch keine IPSec-Informationen an. Verwenden Sie stattdessen die folgende Syntax: "netsh ipsec dynamic show all".

Weitere nützliche Tools für die Unterstützung von IPSec

Als Ergänzung zu den oben aufgeführten IPSec-spezifischen Tools listet die folgende Tabelle weitere nützliche Tools für die Problembehandlung auf, die Sie zu Ihrem Toolkit für die Problembehandlung für Ebene 2 hinzufügen sollten.

Tabelle 7.2: Verschiedene nützliche Tools für die Problembehandlung für IPSec

Programm	Unterstützte Betriebssysteme	Bezugsquellen	Rolle	Weitere Informationen
Ipsecpol.exe	Nur Windows 2000	Windows 2000 Resource Kit	Konfigurieren von IPSec-Richtlinien im Verzeichnis oder in einer Registrierung	Hilfe zu den Windows 2000 Resource Kit-Tools
Gpresult	Windows 2000, Windows Server 2003, Windows XP	Windows 2000 Resource Kit; für Windows XP und Windows Server 2003, Teil des Betriebssystems	Überprüfen, wann Gruppenrichtlinie zuletzt angewendet wurde	Hilfe zu den Windows 2000 Resource Kit-Tools, Windows XP und Hilfe zu Windows Server 2003
MMC-Snap-In für den Richtlinienergebnissatz (RSoP)	Windows Server#160; 2003, Windows XP	Teil des Betriebssystems	Anzeigen von IPSec-Richtlinien für einen Computer oder für Mitglieder eines Gruppenrichtliniencontainers	Hilfe zu Windows#160;Server#160; 2003
Srvinfo	Windows 2000, Windows Server 2003, Windows XP	Windows 2000 und Windows Server 2003 Resource Kits	Dienste, Diensttreiber und Protokollinformationen	Hilfe zu den Windows#160;Server#160; 2003 Resource Kit-Tools
PortQry	Windows 2000, Windows Server 2003, Windows XP	Windows Server#160; 2003 Resource Kit	Berichterstellung über Status der Netzwerkports	http://support. microsoft.com/kb/310099
NLTest	Windows 2000, Windows Server 2003, Windows XP	Supporttools	Testen von Vertrauensstellungen und sicheren Netlogon-Channels	Hilfe zu Windows#160;Server#160; 2003-Supporttools
Klist	Windows 2000, Windows Server 2003, Windows XP	Windows 2000 and Windows Server 2003 Resource Kits	Berichterstellung für Kerberos-Ticket	Hilfe zu Windows#160;Server#160; 2003 Resource Kit-Tools
Pathping	Windows 2000, Windows Server 2003, Windows XP	Teil des Betriebssystems	Überprüfen der Netzwerkkonnektivität und des Netzwerkpfads	Windows-Hilfe
LDP	Windows 2000, Windows Server 2003, Windows XP	Supporttools	Überprüfen des LDAP-Clients für Active Directory	Hilfe zu Windows#160;Server#160; 2003-Supporttools

Verwenden von ICMP-basierten Tools mit IPSec

Die Ping-, Pathping- und Tracert-Funktionen unter Windows XP und Windows Server 2003 berücksichtigen IPSec, werden jedoch eventuell nicht korrekt ausgeführt, solange keine schwachen Sicherheitszuordnungen (SAs) erstellt wurden (wenn das Zurückgreifen auf eine unsichere Verbindung zugelassen wird). Bei einer erfolgreichen Verhandlung von IPSec-SAs für eine Kapselung des ICMP-Datenverkehrs, der von diesen Dienstprogrammen verwendet wird, können diese zwischen dem Client und dem Ziel keine Netzwerkabschnitte (Router) ermitteln. Berechnungen von Paketverlusten für Ping können ergeben, dass während der Zeit, die IKE für eine erfolgreiche Verhandlung eines IPSec-SA-Paars mit dem Ziel benötigt, Paketverluste auftreten. Berechnungen von Paketverlusten für jeden Netzwerkabschnitt sind nicht verfügbar, wenn eine Kapselung des ICMP-Datenverkehrs durch IPSec erfolgt ist.

Diese ICMP-Dienstprogramme wurden erstellt, um zu ermitteln, ob der IPSec-Treiber mit einem IPSec-Filter im ausgehenden ICMP-Echoanforderungspaket übereinstimmt und daher bei IKE eine Sicherheitsverhandlung anfordert. Sollte dies der Fall sein, gibt das Dienstprogramm die Meldung "IP-Sicherheit wird ausgehandelt" aus. Ein bekannter Fehler unter Windows 2000 verursacht, dass das Ping-Dienstprogramm vor dem nächsten Versuch der Echoanforderung die erforderliche Zeitdauer nicht abwartet. Der Befehl wird dann eventuell sofort beendet, ohne dass drei Sekunden lang gewartet wird, bis die schwache SA erstellt ist. Das Ping-Dienstprogramm unter Windows XP und Windows Server 2003 wartet für die erwartungsgemäße Anzahl an Sekunden ab, bevor die nächste Echoanforderung gesendet wird.

Die Meldung "IP-Sicherheit wird ausgehandelt" wird nicht angezeigt, wenn folgende Voraussetzungen gegeben sind:

• Wenn das ausgehende ICMP-Paket im IPSec-Treiber wegen eines Blockierungsfilters entfernt wurde.

• Wenn der IPSec-Treiber einen ungesicherten Durchlass des ICMP-Pakets aufgrund eines Zulassungsfilters oder einer schwachen SA erlaubt.

• Wenn der IPSec-Treiber das ausgehende Paket nicht erkennt (wenn es beispielsweise in Schichten oberhalb des IPSec-Treibers entfernt wurde).

  Hinweis

  
  Einige von ICMP verwendeten Tools können eventuell nicht erkennen, dass IPSec eine Sicherheitsverhandlung vornimmt, und geben dann unter Umständen uneinheitliche oder fehlerhafte Ergebnisse aus.
  

Zum Seitenanfang

Der Problembehandlungsprozess für IPSec

Wenn der Support der Ebene 1 das Problem klar identifiziert hat, ist der Support der Ebene 2 in der Lage, die relevanten Problembehandlungsverfahren, die in den folgenden Abschnitten erläutert werden, schnell zu ermitteln. In diesem Modell befasst sich der Support der Ebene 1 vorwiegend mit clientbezogenen Zugriffsproblemen. Es wird erwartet, dass die administrativen Servereigentümer in der Lage sind, eine grundlegende Diagnose der Netzwerkkonnektivität durchzuführen, und ggf. den Support der Ebene 1 überspringen. Jede Organisation muss dass Modell entsprechend ihrer eigenen Supportumgebung anpassen. Der Support der Ebene 2 muss sich auf die Identifizierung dessen konzentrieren, wo der Kommunikationsfehler auftritt, und anschließend zugehörige mögliche Fehler in der Architektur des Systems untersuchen.

Wenn Ihre Organisation die Skripts verwendet, die als Teil des Problembehandlungsprozesses bereitgestellt wurden, verfügen Sie über den Zugriff auf eine Reihe an Textprotokolldateien, die Sie beim Diagnostizieren des Problems unterstützen können. In der folgenden Tabelle finden Sie eine Beschreibung der erstellten Skripts.

Tabelle 7.3: Dateien, die über das Skript "IPsec_Debug.vbs" erstellt wurden

Dateiname	Beschreibung
<Komp.-name>_FileVer.txt	Listet die Dateiversionen verschiedener IPSec-bezogener DLLs auf.
<Komp.-name>_gpresult.txt	Ausgabe des Befehls "gpresult".
<Komp.-name>_ipsec_547_events.txt	Ausgabe aller IPSEC 547-Fehler im Sicherheitsereignisprotokoll.
<Komp.-name>_ipsec_policy_version.txt	Ausgabe des Skripts "Detect_IPsec_Policy.vbs". Zeigt im Feld die derzeitige Richtlinienversion an und gibt an, ob eine Übereinstimmung mit der Active Directory-Richtlinie besteht.
<Komp.-name>_ipseccmd_show_all.txt	Nur unter Windows XP. Diese Datei erfasst die Ausgabe des ipseccmd-Befehls.
<Komp.-name>_kerberos_events.txt	Ausgabe aller Kerberos-Ereignisse im Systemereignisprotokoll.
<Komp.-name>_klist_purge_mt.txt	Ausgabe aus "KList" während des Löschens der Computertickets.
<Komp.-name>_lsass.log	Kopieren der Datei "lsass.log", sofern vorhanden.
<Komp.-name>_netdiag.txt	Ausgabe des ausgeführten Tools "netdiag".
<Komp.-name>_netsh_show_all.txt	Nur auf Serverplattformen. Ausgabe des Befehls "show all" in "netsh".
<Komp.-name>_netsh_show_gpo.txt	Nur auf Serverplattformen. Ausgabe des Befehls "show gpo" in "netsh".
<Komp.-name>_oakley.log	Kopieren der Datei "Oakley.log", sofern vorhanden.
<Komp.-name>_OSInfo.txt	Ausgabe der aktuellen Informationen zum Betriebssystem.
<Komp.-name>_RegDefault.txt	Ausgabe der ursprünglichen Werte für den Registrierungsschlüssel vor deren Änderung. Kann verwendet werden, um die Registrierung wieder auf die vorherigen Werte zurückzusetzen, wenn das Skript aus irgendeinem Grund fehlschlägt.
<Komp.-name>_userenv.log	Kopieren der Datei "userenv.log", sofern vorhanden.
<Komp.-name>_<SrvName>_netview.txt	Ausgabe des Befehls "net view" für <SrvName>.
<Komp.-name>_<SrvName>_ping.txt	Ausgabe des Befehls "ping" für <SrvName>.
<Komp.-name>_winlogon.log	Kopieren der Datei "winlogon.log", sofern vorhanden.

Da viele potenzielle Fehlerursachen bestehen, befasst sich dieser Abschnitt der Reihe nach mit allen Komponenten der Architektur, beginnend mit der Netzwerkkonnektivität. Es wurden Verfahren definiert, die Sie bei folgenden Aufgaben unterstützen:

• Überprüfen der IP-Netzwerkkonfiguration, der Netzwerkkonnektivität und des Dienstes mit Domänencontrollern sowie der Verbindung des Client-Server-Pfads für IPSec-bezogene Protokolle
• Überprüfen der korrekten Anwendung der Gruppenrichtlinie und IPSec-Richtlinie sowohl auf dem Client als auch auf dem Server
• Untersuchen der Störungen bei der IKE-Verhandlung und IPSec-geschützten Kommunikation
• Identifizieren der Problemursache für die Eskalation an Ebene 3, falls erforderlich

Betrachten Sie folgendes Beispielszenario: Ein Client meldet, dass ein Ping an einen Server ausgeführt werden könne, ein Zugriff auf eine Dateifreigabe auf diesem Server jedoch nicht möglich sei. Dieser Server ist der einzige Server, auf den der Client nicht zugreifen kann. Eine kurze Überprüfung des Sicherheitsprotokolls für Ereignis 547 (Fehlschlagen der IKE-Verhandlung), das die IP-Adresse des Servers enthält, zeigt an, dass der Client über eine IPSec-Richtlinie verfügt und dass IKE initiiert wird. Wenn das Clientereignis 547 angibt, dass das Zeitlimit für die Client-IKE-Verhandlung überschritten wurde, schlägt die Verhandlung für den Server-IKE wahrscheinlich fehl. Der Support der Ebene 2 überprüft dann die MOM-Ereignisdatenbank auf 547-Ereignisse, die vom angegebenen Server gesammelt wurden und die aktuelle IP-Adresse des Clients enthalten.

Warnung Starten und Beenden des IPSec-Dienstes

Das Dokument "Windows Server 2003 TCP/IP Troubleshooting" und andere Referenzdokumente erläutern, wie ermittelt wird, ob IPSec ein Konnektivitätsproblem durch das Beenden des IPSec-Dienstes verursacht. Auch wenn dadurch die IPSec-Filterung auf dem Computer beendet wird, wird auch der durch IPSec bereitgestellte Schutz deaktiviert, der Computer nicht vertrauenswürdigen Netzwerkzugriffen ausgesetzt und der Paketschutz deaktiviert. In einer Domänenisolierungsumgebung wird darüber hinaus TCP- und UDP-Datenverkehr, der nicht durch IPSec geschützt ist, von anderen Mitgliedern der Isolierungsdomäne entfernt. Wenn IPSec auf einem Computer deaktiviert ist, wird die Verbindung mit den Remotecomputern unterbrochen, für die derzeit IPSec-Sicherheitszuordnungen erstellt wurden. Wenn der IPSec-Dienst angehalten wird, sendet IKE Benachrichtigungen zu allen IPSec-SAs und IKE-SAs an alle Computer, für die eine aktive Verbindung besteht. Für Remotecomputer mit einer IPSec-Richtlinie, die ein Zurückgreifen auf eine unsichere Verbindung zulässt, wird die Verbindung nach einer Verzögerung von drei Sekunden erneut hergestellt. Für Remotecomputer mit einer IPSec-Richtlinie, die kein Zurückgreifen auf eine unsichere Verbindung erlauben, ist keine Kommunikation möglich.

Daher ist es wichtig, die in den folgenden Abschnitten erläuterten Techniken bei der Problembehandlung von Isolierungsumgebungen zu verwenden, ohne den IPSec-Dienst zu beenden. Das Deaktivieren des IPSec-Dienstes sollte nur als letzte Möglichkeit gewählt werden, um IPSec-bezogene Probleme in folgenden Situationen auszuschließen:

• Broadcast- und Multicast-Umgebungen
• Verbindungen mit Remotecomputern, die IPSec nicht für eingehenden Zugriff erfordern (beispielsweise Computer, die zur Ausnahmeliste gehören)

Unter Windows 2000 wird durch das Beenden des IPSec-Dienstes die Bindung des IPSec-Treibers mit TCP/IP aufgehoben und der IPSec-Treiber aus dem Speicher entfernt.

Unter Windows XP und Windows Server 2003 werden durch das Beenden des IPSec-Dienstes alle Filter aus dem IPSec-Treiber gelöscht und der Treibermodus auf PERMIT (Zulassen) gesetzt. Der IPSec-Treiber wird dadurch nicht aus dem Speicher entfernt. Der IPSec-Dienst muss deaktiviert und der Computer neu gestartet werden, um das Laden des IPSec-Treibers zu verhindern.

Unter Windows 2000 und Windows XP SP1 ist für die IKE-Protokollierung in der Datei Oakley.log ein Neustart des IPSec-Dienstes erforderlich. Für die Aktivierung und Deaktivierung der IKE-Protokollierung in der Datei Oakley.log unter Windows XP SP2 und Windows Server 2003 ist das Beenden des Dienstes nicht erforderlich. Das neueste Update von "Ipseccmd" für Windows XP SP2 enthält die Syntax
"ipseccmd set logike" und "ipseccmd set dontlogike" für eine dynamische Aktivierung und Deaktivierung der IKE-Protokollierung in der Datei Oakley.log. Die IKE-Protokollierung unter Windows Server 2003 kann dynamisch aktiviert werden, indem die Netsh-Befehle verwendet werden, wie in der Onlinehilfe erläutert.

Überprüfen der Netzwerkkonnektivität

Wenn der Support der Ebene 1 mögliche Störungen der Netzwerkkonnektivität identifiziert, muss zunächst ermittelt werden, ob eine grundlegende Netzwerkkonnektivität besteht. Diese Ermittlung umfasst die Überprüfung dessen, ob eine korrekte IP-Konfiguration verwendet wird, ob ein gültiger Netzwerkpfad zwischen dem Initiator- und dem Respondercomputer besteht und ob die Namensauflösungsdienste funktionieren.

Probleme mit der Konfiguration der Netzwerk-IP-Adresse

Wenn die dynamische IP-Konfiguration nicht erfolgreich ist oder die Kommunikation nach einem Neustart (oder sogar während des normalen Betriebs) des Computers blockiert wird, wird das Problem unter Umständen durch IPSec verursacht. Unter Windows Server 2003 können solche Probleme in Verbindung mit dem Failsafe-Verhalten stehen (wenn der Computer beispielsweise im abgesicherten Modus oder im Wiederherstellungsmodus von Active Directory gestartet wird).

Windows Server 2003 setzt das Failsafe-Verhalten ein, wenn der IPSec-Dienst nicht erfolgreich gestartet werden kann oder dieser die zugewiesenen Richtlinie nicht anwenden kann. Failsafe wird nur dann verwendet, wenn dem Computer eine IPSec-Richtlinie zugewiesen ist und wenn der IPSec-Dienst nicht deaktiviert ist. Somit kann die Verbindung zu und von einem Computer während des normalen Betriebs fehlschlagen, da der IPSec-Treiber nicht die domänenbasierte IPSec-Richtlinie erzwingt. Nachdem Sie ermittelt haben, welcher Datenverkehr vom Bootmodus und bestehenden Konfigurationen zugelassen und blockiert wird, kann eine Erklärung für eine fehlgeschlagene Kommunikation meist schnell gefunden werden. Um andere oder zusätzliche Informationen zu erhalten, können Sie den aktuellen Status über die Befehlszeile unter Verwendung der folgenden Syntax abfragen:

    netsh ipsec dynamic show config

Unter Windows Server 2003 wird der IPSec-Treiber beim Start des Computers mit dem TCP/IP-Treiber geladen. Daher muss zum Verhindern des IPSec-Failsafe-Verhaltens der IPSec-Dienst deaktiviert und der Computer neu gestartet werden. Das Kapitel zur IPSec-Bereitstellung, auf das oben verwiesen wurde, umfasst die empfohlene Konfiguration der Bootausnahmen, die für eingehende Protokollverbindungen des Remotedesktop ausgenommen werden müssen, so dass sichergestellt wird, dass der Remotezugriff auf den Server verfügbar ist, wenn andere Datenverkehrstypen blockiert werden.

In einer Server- und Domänenisolierungslösung wird Broadcastdatenverkehr und Datenverkehr an DHCP-Server ausgenommen, um eine korrekte Funktionsweise der dynamischen IP-Konfiguration sicherzustellen. Die Ausnahmeliste muss manuell verwaltet werden; sie kann eventuell veraltet sein. Wenn ein Computer keine korrekte DHCP-Konfiguration abrufen kann (wenn er beispielsweise eine automatisch konfigurierte IP-Adresse 169.254.x.x verwendet) oder Probleme mit der Erneuerung der Version auftreten, muss die IPSec-Richtlinie auf korrekte Ausnahmen überprüft werden. Verwenden Sie bei aktiviertem IPSec-Dienst "Ipconfig", um sicherzustellen, dass keine Probleme beim Abrufen der IP-Adresse bestehen:

• Öffnen Sie für DHCP-Clients ein Befehlsfenster, und führen Sie "ipconfig /release" gefolgt von "ipconfig /renew" aus.

Wenn die Probleme mit der Adressenkonfiguration nur während des Computerstarts unter Windows XP SP2 und Windows Server 2003 auftreten, muss die Konfiguration der Ausnahmen (Standardausnahmen und Bootausnahmen) überprüft werden.

Probleme mit der Namensauflösung

Die Funktionsweise der IPSec-Richtlinie, die in den Server- und Domänenisolierungszenarien verwendet wird, darf die üblichen Abläufe nicht stören, die zur Ermittlung dazu verwendet werden, ob die Namensauflösung korrekt abläuft. Im Szenario der Woodgrove Bank beispielsweise erklärt die IPSec-Richtlinie sämtlichen Datenverkehr an DNS- und WINS-Server zu Ausnahmen. DNS- und WINS-Server können jedoch so konfiguriert werden, dass sie nicht auf Ping-Anforderungen antworten. Beantworten Sie die folgenden Fragen, um sicherzustellen, dass die Namensauflösung korrekt abläuft, während der IPSec-Dienst ausgeführt wird:

• Kann der Client eine Ping-Anforderung an die IP-Adresse des DNS-Servers ausführen, die in seiner IP-Konfiguration aufgelistet ist?
• Wird mithilfe von "nslookup" ein DNS-Server gefunden?
• Kann der Client eine Ping-Anforderung an den voll qualifizierten DNS-Namen des Ziels ausführen?
• Kann der Client eine Ping-Anforderung an den gekürzten DNS- oder NetBIOS-Namen des Ziels ausführen?

Zu den potenziellen Ursachen für Namensauflösungsprobleme gehören eine aktive und nicht korrekt konfigurierte HOSTS-Datei, ein nicht korrekt konfigurierter DNS-Servereintrag in den IP-Eigenschaften, nicht korrekte DNS-Registrierungserfassungen, Updateprobleme bei Zonendateien, Replikationsfehler bei Active Directory, ein Zurückgreifen auf unsichere Verbindungen bei DNS-Servern und Probleme bei automatischen DHCP-Updates.

Zu den möglichen Ursachen für Fehler bei der NetBIOS-Namensauflösung gehören eine aktive und nicht korrekt konfigurierte LMHOSTS-Datei, ein nicht korrekt konfigurierter WINS-Servereintrag in den IP-Eigenschaften, die fehlende Verfügbarkeit des WINS-Servers, nicht korrekte WINS-Erfassungen, WINS-Replikationsprobleme, WINS-Proxyfehler und Netzwerkzeitüberschreitungen beim Versuch, auf den WINS-Server zuzugreifen.

Verfahren, die Sie bei der Problembehandlung von Active Directory-integriertem DNS unterstützen, finden Sie auf der Microsoft-Website auf der Seite Troubleshooting Active Directory - Related DNS Problems unter www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd10.mspx (in englischer Sprache).

In einigen Umgebungen, die hohe Sicherheitsanforderungen stellen, müssen DNS- und WINS-Server eventuell durch IPSec geschützt werden, was zu Problemen bei der Namensauflösung führen kann. Wenn DNS innerhalb von Active Directory integriert ist und in der IPSec-Richtlinie doppelte Filter für dieselbe IP-Adresse vorhanden sind, kann der eine Filter die Sicherheit für den DNS-Server verhandeln und der andere die Domänencontroller zu Ausnahmen erklären. Weitere Informationen dazu finden Sie im Abschnitt zur Fehlerbehandlung von IPSec-Richtlinien weiter unten in diesem Kapitel.

Wenn weiterhin Probleme mit der Namensauflösung bestehen, können Sie vom Initiator eine Filterliste erhalten und diese auf doppelte Filter überprüfen. Sie können die folgenden Befehlszeilenoptionen verwenden, um die Filterlisten für diese Aufgaben anzuzeigen:

Ipseccmd show filters
Netsh ipsec static show all 

Wenn weiterhin Probleme mit der Namensauflösung bestehen, sollte der IPSec-Dienst kurz beendet werden (falls möglich), während die Auflösungsüberprüfung erneut durchgeführt wird. Wenn die Überprüfungen der Namensauflösung nur dann fehlschlagen, wenn der IPSec-Dienst ausgeführt wird, sollten weitere Überprüfungen durchgeführt werden, um festzustellen, welche IPSec-Richtlinie verwendet wird. Dieser Punkt wird später in diesem Abschnitt erläutert.

Überprüfen der Konnektivität und Authentifizierung mit Domänencontrollern

Da die Bereitstellung von IPSec-Richtlinien, die IKE-Authentifizierung und die meisten Protokolle der oberen Schicht vom Zugriff auf Domänencontroller abhängen, müssen die Überprüfungen der Netzwerkkonnektivität und der erfolgreichen Ausführung der Authentifizierungsdienste vor den IPSec-spezifischen Problembehandlungsschritten (im nächsten Abschnitt erläutert) durchgeführt werden. In einem Szenario wie dem der Woodgrove Bank erklärt die IPSec-Richtlinie sämtlichen Datenverkehr zu allen Domänencontrollern zu Ausnahmen, so dass die Überprüfungen der Netzwerkkonnektivität für die Domänencontroller nicht von IPSec beeinträchtigt werden sollten. Die Liste der IP-Adressen für die Domänencontroller in der Ausnahmeliste muss jedoch manuell verwaltet werden. Wenn eine IKE-Verhandlung der IP-Adresse eines Domänencontrollers verzeichnet wird, erfolgt eventuell keine korrekte Zuweisung oder Aktualisierung der IPSec-Richtlinie.

So führen Sie die Problembehandlung für den Zugriff auf Netzwerkdienste in Active Directory durch

• Überprüfen Sie, ob der Client eine Ping-Anforderung für die IP-Adresse jedes Domänencontrollers ausführen kann. Ist dies nicht der Fall, folgen Sie den oben aufgeführten Schritten zur Überprüfung der Netzwerkkonnektivität.
• Identifizieren Sie, welche IP-Adressen für die Domänencontroller der Domänenmitglieder verwendet werden. Verwenden Sie "nslookup <Domänenname>", um eine vollständige Liste der IP-Adressen zu erhalten. In einem Server- und Domänenisolierungszenario sollte ein schneller modusspezifischer Filter mit einer Verhandlungsrichtlinie (Filteraktion) zum Zulassen aller dieser Adressen vorhanden sein.
• Verwenden Sie Version 2.0 oder höher des Tools portqry.exe oder das Tool "PortQueryUI", um den Zugriff auf die UDP-, LDAP- und RPC-Ports des Domänencontrollers zu überprüfen. Die UDP-Protokollmeldungen, die von "portqry" verwendet werden, erfordern keine Authentifizierung für Protokolle der darüber liegenden Schicht, so dass sie die Verfügbarkeit der Diensts überprüfen können, auch wenn keine Authentifizierung verfügbar ist. Diese Schritte werden im Dokument HOW TO: verwenden Sie Portqry, um Active Directory-Verbindungsprobleme zu beheben unter https://support.microsoft.com/?kbid=816103 erläutert.
• Wenn eine Verbindung zu einem internen Netzwerk besteht, verwenden Sie "netdiag /v >outputfile.txt", um eine Reihe von DNS-bezogenen und domänenbezogenen Konnektivitätstests durchzuführen. "Netdiag" verwendet mehrere Netzwerkverbindungen und -protokolle für Überprüfungen; wenn eine dieser Verbindungen oder eines dieser Protokolle IKE-Verhandlungen auslöst und die Authentifizierung fehlschlägt, weil IKE keinen Domänencontroller für die Kerberos-Authentifizierung finden kann, ist eventuell der Ereignisfehler 547 im Sicherheitsprotokoll aufgeführt.

Das Windows-Supporttool klist.exe kann verwendet werden, um eine erfolgreiche Kerberos-Anmeldung und -Authentifizierung zu überprüfen. "Klist" muss im lokalen Systemkontext ausgeführt werden, um die Kerberos-Tickets für den Computer anzuzeigen.

So zeigen Sie Kerberos-Diensttickets für die angemeldeten Domänenbenutzer an

• Starten Sie eine Eingabeaufforderung, und geben Sie Folgendes ein:

  klist tickets
  

So zeigen Sie Domänencomputertickets an

1. Stellen Sie sicher, dass der Taskplanerdienst ausgeführt wird und der angemeldete Benutzer Mitglied der lokalen Administratorengruppe ist.

2. Wählen Sie bei einer Eingabeaufforderung als Zeitpunkt eine Minute vor der aktuellen Systemzeit aus (beispielsweise 16:38), und geben Sie Folgendes ein:

   at 4:38pm /interactive cmd /k klist tickets
   

   Beachten Sie, dass die Titelleiste des Befehlsfensters Folgendes enthält: C:\Windows\System32\svchost.exe.

Auch wenn Kerberos-Tickets Gruppeninformationen für den Benutzer oder den Computer enthalten, werden diese Informationen verschlüsselt, so dass die Gruppen nicht angezeigt werden können. Daher muss die Bestätigung der Gruppenmitgliedschaft manuell erfolgen, indem die Gruppenmitgliedschaft in Active Directory überprüft wird. Um sicherzustellen, dass die Computer über die neuesten Informationen zur Gruppenmitgliedschaft in ihren Kerberos-Tickets verfügen, verwenden Sie "klist", um die derzeitigen Kerberos-Tickts zu löschen. Wenn ein erneuter Versuch der IKE-Verhandlung gestartet wird, werden die neuen Kerberos-Tickets automatisch abgerufen.

So löschen Sie die Kerberos-Tickets auf dem Computer

(Schritte 1 4 müssen im lokalen Systemkontext ausgeführt werden.)

1. Stellen Sie sicher, dass der Taskplanerdienst ausgeführt wird und der angemeldete Benutzer Mitglied der lokalen Administratorengruppe ist.

2. Wählen Sie bei einer Eingabeaufforderung als Zeitpunkt eine Minute vor der aktuellen Systemzeit aus (beispielsweise 16:38), und geben Sie Folgendes ein:

   at 4:38pm /interactive cmd
   

3. Geben Sie "klist purge" ein, und drücken Sie für jeden Tickettyp die Taste "Y", um alle Kerberos-Tickets zu löschen.

4. Geben Sie "klist tickets" ein, um sicherzustellen, dass keine Tickets mehr bestehen.

5. Wenn dieses Verfahren Teil der Problembehandlung für fehlgeschlagene IKE-Verhandlungen ist, warten Sie eine Minute, bis das Zeitlimit für die IKE-Authentifizierung überschritten wurde, und versuche Sie dann erneut, mit der Anwendung auf den Zielserver zuzugreifen. Neue IKE-Hauptmodusverhandlungen fordern neue Kerberos-TGT- und Diensttickets für den Zielcomputer an, die über die neuesten Gruppeninformationen verfügen. Achten Sie darauf, dass die Anwendung nicht über das Befehlsfenster im lokalen Systemkontext ausgeführt wird.

Weitere detaillierte Verfahren für die Problembehandlung für Kerberos finden Sie in den folgenden Whitepapers:

• Troubleshooting Kerberos Errors unter www.microsoft.com/downloads/details.aspx?
  FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en (in englischer Sprache)
• Troubleshooting Kerberos Delegation unter www.microsoft.com/downloads/details.aspx?
  FamilyID=99b0f94f-e28a-4726-bffe-2f64ae2f59a2&displaylang=en (in englischer Sprache)

Überprüfen der Berechtigungen und der Integrität der IPSec-Richtlinie in Active Directory

Es kann notwendig sein, Informationen zum IPSec-Richtliniencontainer in Active Directory zu überprüfen. Für die folgenden Verfahren wird das Supporttool ldp.exe verwendet.

So überprüfen Sie die Informationen zum IPSec-Richtliniencontainer

1. Klicken Sie auf Start, Ausführen, geben Sie ldp.exe ein, und drücken Sie die EINGABETASTE.

2. Wählen Sie Verbindung und anschließend Verbinden. Geben Sie den Namen der Zieldomäne an.

3. Wählen Sie Verbindung und anschließend Binden. Geben Sie die Anmeldeinformationen für die Zieldomäne an.

4. Wählen Sie Ansicht und anschließend Struktur. Geben Sie entweder "no base DN" ein, und wechseln Sie zum IPSec-Richtliniencontainer, oder geben Sie den LDAP DN für den IPSec-Richtliniencontainer als Basisspeicherort an.

5. Klicken Sie in der Strukturansicht neben dem Containerkonten auf + (Pluszeichen). Wenn Sie über einen Lesezugriff für den Container verfügen, werden alle IPSec-Richtlinienobjekte im Container angezeigt.

   Hinweis

   
   Aufgrund der Konfiguration der Berechtigungen verfügen eventuell nicht alle Domänenbenutzer über einen Lesezugriff für den Container. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 329194, Richtlinie-IPSec-Berechtigungen in Windows 2000 und Windows Server 2003unter http//support.microsoft.com/?kbid=329194.
   

Bei einer erweiterten Problembehandlung für das Abrufen von Richtlinien und für Probleme durch beschädigte Komponenten kann ldp.exe verwendet werden, um Inhalte des IP-Sicherheitscontainers und die Beziehungen zwischen IPSec-Richtlinienobjekten zu untersuchen. Windows 2000, Windows XP und Windows Server 2003 verwenden dasselbe grundlegende Verzeichnisschema für IPSec-Richtlinien, das im Strukturdiagramm für IPSec-Richtlinien in der Windows Server 2003 Technical Reference How IPsec Works unter www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr\_ipsec\_how.asp (in englischer Sprache) dargestellt ist.

Die folgende Tabelle zeigt die Beziehung zwischen den Active Directory-Objektnamen und den Namen der IPSec-Richtliniekomponente an, die im Snap-In für die IPSec-Richtlinienverwaltung konfiguriert sind:

Tabelle 7.4: Zuordnung der IPSec-Richtlinienkomponente zu Active Directory-Objektnamen

Name der IPSec-Richtlinienkomponente	Active Directory-Objektname
IPSec-Richtlinie	ipsecPolicy{GUID}
IKE-Schlüsselaustausch-Sicherheitsmethoden	ipsecISAKMPPolicy{GUID}
IPSec-Regel	ipsecNFA{GUID}
IPSec-Filterliste	ipsecFilter{GUID}
IPSec-Filteraktion	ipsecNegotiationPolicy{GUID}

Mit Ldp.exe kann ermittelt werden, wann IPSec-Richtlinienobjekte zuletzt geändert wurden. Diese Informationen bieten eine Unterstützung bei der Problembehandlung für die Objektversion und für Replikationsstörungen. Das Tool kann über ein Befehlsfenster im lokalen Systemkontext gestartet werden, um Probleme mit den Lesezugriffsberechtigungen für den IPSec-Dienst zu beheben.

Wenn ein IPSec-Objekt einen DN-Verweis auf ein Objekt enthält, das nicht mehr existiert, liegt die Ursache für das Problem meist in einer beschädigten IPSec-Richtlinie. Eine beschädigte Richtlinie kann auch dann auftreten, wenn Steuerzeichen Teil eines Objekts werden, einzelne Objekte aufgrund von Berechtigungsproblemen nicht gelesen werden können oder identische Namen zu einer nicht korrekten Erstellung der IPSec-Richtlinie führen (beispielsweise zwei Versionen derselben Filterliste). Weitere Informationen dazu, wie eine beschädigte Richtlinie korrigiert werden kann, finden Sie im folgenden Problembehandlungsabschnitt "IPSec-Dienst".

Netzwerkpfadkonnektivität

Microsoft empfiehlt, das ICMP-Protokoll in Server- und Domänenisolierungslösungen als Ausnahme zu definieren. Dieser Empfehlung liegen mehrere Ursachen zugrunde, einschließlich der Anforderung an eine Verwendung von ICMP für die Überprüfung von Netzwerkpfaden durch Dienstprogramme, wie "Ping", "Pathping" und "Tracert". Diese Dienstprogramme müssen daher korrekt ausgeführt werden und dürfen nicht die Meldung "IP-Sicherheit wird ausgehandelt" anzeigen. Wenn diese Meldung angezeigt wird, wurde eventuell eine nicht korrekte IPSec-Richtlinie zugewiesen.

So ermitteln Sie, ob das Problem durch die grundlegende Netzwerkkonfiguration oder die Pfadkonnektivität verursacht wird

• Kann der Client einen Ping-Befehl an seine eigene IP-Adresse oder an die lokale Loopback-Adresse 127.0.0.1 ausführen? Ist dies nicht der Fall, kann eventuell ein Problem mit der TCP/IP-Konfiguration vorliegen, eine Firewall eines Drittanbieters installiert sein, ein Ping-Dienstprogramm fehlen oder eine ungültige IP-Konfiguration bestehen. Verwenden Sie die anderen Problembehandlungsverfahren für die TCP/IP-Konfiguration, um das Problem zu untersuchen.
• Kann der Client einen Ping-Befehl an das Standardgateway ausführen, das in seiner IP-Konfiguration angezeigt wird? Ist dies nicht der Fall, kann eventuell die IP-Konfiguration auf dem Client das Problem verursachen, keine oder nur eine unzureichende Konnektivität für die lokale Schnittstelle bestehen, Datenverkehr durch lokale oder Netzwerkfilter blockiert werden oder der Netzwerkpfad oder das Standardgateway unterbrochen sein. Verwenden Sie die anderen Problembehandlungsverfahren für TCP/IP, um das Problem zu untersuchen.
• Kann der Client einen Ping-Befehl an die DNS-Server ausführen, die in seiner IP-Konfiguration angezeigt werden? Ist dies nicht der Fall, lassen DNS-Server für sich selbst den Empfang von ICMP-Echoanforderungsmeldungen eventuell nicht zu, definiert die IPSec-Richtlinie unter Umständen nicht die richtigen IP-Adressen des DNS-Servers als Ausnahmen, oder es besteht eine der vorher genannten Störungen. Verwenden Sie die anderen Problembehandlungsverfahren für TCP/IP, um das Problem zu untersuchen.
• Kann der Client einen Ping-Befehl an eine IP-Adresse in der Ausnahmeliste, wie an einen DC, ausführen? Ist dies nicht der Fall, wird das Problem nicht durch IPSec verursacht, oder IPSec verfügt über keinen Filter für diese ausgenommene IP-Adresse. Ob die zweite Möglichkeit zutrifft, kann durch eine Überprüfung der Filterkonfiguration ermittelt werden. Informationen dazu finden Sie im folgenden Abschnitt zu IPSec-Richtlinien in diesem Kapitel.
• Kann der Client einen Ping-Befehl an die IP-Adresse des Ziels ausführen? Ist dies der Fall, besteht eine grundlegende Netzwerkverbindung zwischen dem Client und dem Ziel ohne IPSec. Ist dies nicht der Fall, versuchen Sie einen Tracert-Befehl an das Ziel oder an eine andere Ziel-IP-Adresse auszuführen, um zu ermitteln, bis zu welchem Punkt der Netzwerkpfad gültig ist. Verwenden Sie andere Problembehandlungsverfahren für TCP/IP und Kernnetzwerkkomponenten, um das Problem zu untersuchen.

Überprüfungen der Pfadkonnektivität können für ICMP erfolgreich verlaufen, sind jedoch nicht unbedingt bei der Verwendung von IKE- oder IPSec-Protokollen erfolgreich. Der Grund liegt darin, dass die IPSec-Restkapazität für Authentifizierungspakete des IKE-Hauptmodus, die das Kerberos-Ticket enthalten, häufig größer ist als die PMTU für die Ziel-IP-Adresse, für die eine Fragmentierung erforderlich ist. Daher müssen hostbasierte Firewalls, Filterfunktionen in Router, Netzwerkfirewalls und Filter auf dem Zielhost die folgenden Protokolle und Ports öffnen und eine Fragmentierung unterstützen:

• IKE. UDP-Quellport 500, Zielport 500 und Fragmente
• IKE/IPsec NAT-T. UDP-Quellport 4500, Zielport 4500
• IPsec ESP. IP-Protokoll 50 und Fragmente
• IPsec AH. IP-Protokoll 51 und Fragmente

Es wird nicht empfohlen, eine statusbehaftete Filterung im Pfad vorzunehmen

Die statusbehaftete Filterung kann zu Konnektivitätsproblemen für IKE, AH und ESP führen, da der Status üblicherweise auf Zeitüberschreitungswerten für Aktivitäten basiert. Die Geräte können keinen IKE-Datenverkehr untersuchen, um zu ermitteln, wann IPSec-SAs gelöscht werden, da diese Meldungen durch IKE verschlüsselt sind. Dies bedeutet, dass IKE für den Schlüsselaustausch in beide Richtungen erforderlich ist, so dass Meldungen über gelöschte Objekte in beide Richtungen gesendet werden können. Wenn eine Seite keine Meldung über gelöschte Objekte erhält, wird eventuell davon ausgegangen, dass ein IPSec-SA-Paar noch existiert, wenn der Peer dieses nicht mehr erkennen kann, so dass die Pakete, die diese Paare verwenden, verworfen werden. Die Richtung, für die IKE einen erneuten Schlüsselaustausch vornimmt, ist abhängig von der Richtung des Datenflusses mit der kürzeren bytebasierten Lebensdauer, dem geringen Zeitversatz für einen erneuten Schlüsselaustausch, wenn die zeitbasierte Gültigkeitsdauer abläuft, und der Richtung des Paketflusses, nachdem ungenutzte IPSec-SAs gelöscht wurden. Eine hostbasierte und statusbehaftete Filterung von IKE-Datenverkehr auf Clients, die Verbindungen (und damit IKE-Verhandlungen) starten, führt unter Verwendung der Windows-Firewall in der Regel zu keinen Problemen. Die Windows-Firewall filtert keine IPSec-Pakete, da der IPSec-Treiber Pakete auf einer niedrigeren Ebene verarbeitet als der, in der der Firewallfilter ausgeführt wird. Es muss jedoch eine Konfiguration zum Öffnen der IKE-Ports in der Hostfirewall erfolgen, um eingehende IKE-Verhandlungen für Protokollverbindungen der darüber liegenden Ebene zu erhalten, für die ein Durchlass durch die Firewall zulässig ist (beispielsweise für einen gemeinsamen Zugriff auf das SMB-Protokoll über TCP-Port 445).

Von TCP erforderliche Unterstützung für ICMP-PMTU

Die Standardeinstellungen unter Windows 2000 und höheren Versionen erfordern für jedes TCP-Paket im IP-Header das Setzen des DF-Bits (Don't Fragment). Diese Einstellung wird beibehalten, wenn entweder der AH- oder der ESP-IPSec-Transportmodus zur Sicherung des Pakets verwendet wird. Daher wird ein zu großes Paket am Router entfernt, und der Router gibt die Meldung Ziel nicht erreichbar für ICMP aus, die die maximal zulässige Größe angibt. Dieses Verhalten wird als Ermittlung der TCP-Pfad-MTU bezeichnet. Sowohl der Client- als auch der Zielcomputer müssen in der Lage sein, ICMP-PMTU-Meldungen bei zu großen IPSec-Paketen zu empfangen. Bei durch IPSec geschützten Datenverkehr muss besonders darauf geachtet werden, dass eine Fragmentierung vermieden wird, da die Hardwarebeschleunigung in der Regel keine fragmentierten Pakete verarbeitet. Fragmentierte IPSec-Pakete müssen vom IPSec-Treiber in der Software verarbeitet werden.

Unter Windows 2000 und Windows XP wird eine Verarbeitung der ICMP-PMTU-Ermittlung für Pakete des IPSec-Transportmodus, die eine Kapselung der NAT-Durchquerung (UDP-Port 4500) verwenden, nicht unterstützt. Unter Windows Server 2003 wird diese Verarbeitung der Ermittlung unterstützt. Weitere Informationen zu Optionen und Tools, die ohne PMTU-Ermittlung ausgeführt werden, finden Sie auf der Seite "Troubleshooting Translational Bridging" im Abschnitt TCP/IP Troubleshooting der Onlinedokumentation zu Windows Server 2003 unter www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/cnet/cnbd\_trb\_gdhe.asp (in englischer Sprache).

Erforderliche Unterstützung für die Fragmentierung

Netzwerkpfade und -filter müssen den Durchlass von Fragmenten für IKE-, IPSec-, AH- und ESP-Protokolle unterstützen. IKE verwendet UDP-Pakete und erlaubt deren Fragmentierung, falls dies erforderlich ist. Durch die Implementierung der IPSec-NAT-Durchquerung wird nur dann eine Vermeidung der IKE-Fragmentierung unterstützt, wenn die Authentifizierung von IKE unter Verwendung von Zertifikaten durchgeführt wird (beispielsweise in L2TP/IPSec-VPN-Szenarios). Eine IKE-Authentifizierung, die Kerberos verwendet, unterstützt nicht die Vermeidung der Fragmentierung und muss in der Lage sein, fragmentierte UDP-Pakete, die das Kerberos-Ticket enthalten, zu senden und zu erhalten.

Der Netzwerkpfad muss den Durchlass von Fragmenten für AH und ESP unterstützen, da IPSec das gesamte ursprüngliche Paket vor der ausgehenden Fragmentierung in der IP-Schicht sichert. IPSec ist in TCP integriert. Wenn für TCP-Pakete also das Attribut "DF" (Don't Fragment, Nicht fragmentieren) gesetzt ist (Standardeinstellung), reduziert TCP die zugehörige Paketgröße aufgrund der zusätzlichen Bytes, die durch die IPSec-Kapselung hinzugefügt werden.

IPSec ist nicht in UDP integriert, und UDP-Anwendungen verfügen über keine Möglichkeit, zu ermitteln, ob der zugehörige Datenverkehr durch IPSec geschützt wird. Daher werden UDP-Pakete, die die vollständige MTU-Größe verwenden, durch den Host bei der Übertragung fragmentiert, wenn IPSec-AH oder ESP verwendet wird. Entsprechend werden bei der Verwendung von Ping-Dienstprogrammen eventuell ICMP-Pakete erstellt, die als fragmentierte IPSec-AH- oder ESP-Pakete bei der Übertragung dargestellt werden, wenn IPSec-Richtlinienfilter ICMP nicht als Ausnahme definieren.

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 233256, Aktivieren von IPSec-Verkehr über einen Firewall, unter https://support.microsoft.com/?kbid=233256.

Erforderliche Unterstützung für Broadcast- oder Multicast-Datenverkehr

Der Entwurf für die IP-Sec-Richtlinie für die Server- und Domänenisolierung verwendet Filter von "Beliebig <-> Subnetz". Daher erfasst der ausgehende Filter "Subnetz -> Beliebig" ausgehenden Broadcast- und Multicast-Datenverkehr von Hosts, die eine interne Subnetz-IP-Adresse verwenden. Da IPSec jedoch nicht zur Sicherung von Multicast- oder Broadcast-Datenverkehr verwendet werden kann, muss der Datenverkehr allerdings verworfen werden, wenn für diesen eine Übereinstimmung mit dem Filter besteht. Für eingehenden Multicast- und die meisten Typen von Broadcast-Datenverkehr besteht keine Übereinstimmung mit dem entsprechenden eingehenden Filter "Beliebig -> Subnetz". Wenn Multicast- oder Broadcast-Datenverkehr erforderlich ist, können Sie den Registrierungsschlüssel auf NoDefaultExempt=1 setzen, wodurch unter Windows XP und Windows Server 2003 der Durchlass von Multicast- und Broadcast-Datenverkehr durch den IPSec-Filter zugelassen wird. Diese Konfiguration verhindert bekannte Probleme mit RTC-Clients (Real Time Communications) und Windows Media-Server, die beide Multicast-Datenverkehr verwenden. Informationen zur Verwendung des Registrierungsschlüssels NoDefaultExempt sowie zu den Auswirkungen auf die Sicherheit bei dessen Nutzung finden Sie in den folgenden Knowledge Base-Artikeln:

• 810207 IPSec-Standardausnahmen werden in Windows Server 2003 entfernt unter https://support.microsoft.com/?kbid=810207

• 811832 IPSec Default Ausnahmen können zu dem Umgehen von IPsec-Schutz in einigen Szenarios verwandt werden unter https://support.microsoft.com/?kbid=811832

  Hinweis

  
  Unter Windows XP SP2 werden dieselben Ausnahmen wie unter Windows Server 2003 verwendet.
  

Der Registrierungsschlüssel kann zur Steuerung der Standardausnahmen gesetzt werden, die für alle Plattformen erforderlich sind. Die IPSec-Filterfunktion unterstützt nicht die Konfiguration von Zieladressen für bestimmte Broadcast- oder Multicast-Adressen

Einsatz der Diagnosefunktion in Netzwerkgeräten ist eventuell nicht sinnvoll

Eine IPSec-Kapselung wirkt sich unter anderem auf Anwendungen aus, die TCP/IP-Datenverkehr in Klartext erwarten, so dass diese keine Überprüfung des Datenverkehrs mehr im Netzwerk durchführen können. Netzwerkdiagnosetools, die Überprüfungen durchführen oder Berichte basierend auf TCP- und UDP-Ports bereitstellen, sind meistens nicht in der Lage, Pakete, die durch IPSec gekapselt sind, zu interpretieren, auch wenn keine AH- oder ESP-Verschlüsselung verwendet wird. Für die Überprüfung von IPSec-AH- oder ESP-Null-Paketen müssen eventuell Updates für solche Tools über die entsprechenden Anbieter bezogen werden.

Probleme mit Treibern für Netzwerkkarten

Ein IPSec-Paketverlust kann durch Netzwerkkarten (Network Interface Cards, NICs) verursacht werden, die bestimmte Funktionen ausführen. Es wird empfohlen, Karten, die Clusterfunktionen oder "Teaming" (Teamkonfiguration) ausführen, auf IPSec-Kompatibilität zu überprüfen. Bei Netzwerkkartentreibern, die Funktionen beschleunigen, die nicht auf IPSec-basieren, können Probleme mit Datenverkehr auftreten, der durch IPSec geschützt ist. Netzwerkkarten, die TCP-Funktionen beschleunigen, können Karten sein, die eine Berechnung von TCP-Prüfsummen und deren Überprüfung (Prüfsummenverschiebung) unterstützen, sowie große TCP-Datenpuffer (große Übertragungsverschiebung) effizient versenden können. Unter Windows 2000 und späteren Versionen wird diese Übertragungsverschiebungsfunktion für TCP in den TCP-IP-Stapeln automatisch deaktiviert, wenn der IPSec-Treiber über Filter verfügt, auch wenn IPSec nur Zulassungs- und Blockierungsfunktionen ausführt. Netzwerkkartentreiber, die nicht vom Windows Hardware Quality Lab (WHQL) genehmigt und signiert wurden, können Probleme verursachen, wenn IPSec zum Schutz des Datenverkehrs verwendet wird. WHQL führt umfassende Überprüfungen für die Genehmigung von Netzwerkkartentreibern durch, die für die Unterstützung der Übertragungsverschiebung durch IPSec entwickelt wurden. Um eine einfachere Problembehandlung zu ermöglichen, unterstützen TCP/IP-Stapel unter Windows 2000, Windows XP und Windows Server 2003 eine Registrierungsschlüsseloption, um alle Formen der Übertragungsverschiebung durch TCP/IP zu unterstützen. Einige Netzwerkkartentreiber unterstützen darüber hinaus eine Deaktivierung der Übertragungsverschiebung für die Netzwerkverbindung unter Verwendung der Eigenschaften "Erweitert". Damit die Konfigurationsänderungen wirksam werden, ist eventuell ein Neustart des Computers erforderlich.

Problembehandlung bei Paketverlust in IPSec-Protokollen

Pakete können verworfen werden oder verloren gehen, wodurch die Anwendungskonnektivität beeinträchtigt wird. Dieser Abschnitt untersucht häufige Fälle, in denen Pakete von IPSec verworfen werden. Wie oben erwähnt, lassen bestimmte Netzwerkgeräte keinen Durchlass für die IP-Protokolltypen 50 oder 51 oder für UDP-Port 500 oder 4500 zu. Ebenso können durch IPSec gekapselte Pakete die Fragmentierung von einigen Paketen veranlassen, für die kein Durchlass durch das Netzwerk zulässig ist. In solchen Fällen wird in der Regel eine Verfolgung durch eine Netzwerküberprüfung auf beiden Seiten der Kommunikation benötigt, um zu identifizieren, welche Pakete gesendet und welche empfangen werden, und einen korrekten Bezug zu diesen Paketen herzustellen. Achten Sie auf Neuübetragungen, die wiederholt durch dieselbe Paketgröße angezeigt werden. Es kann erforderlich sein, das normale Protokollverhalten ohne IPSec zu verfolgen und dieses dann mit dem Protokollverhalten bei IPSec-geschütztem Datenverkehr zu vergleichen.

Ereignisfehler 4285

Ereignistitel: Fehlgeschlagene Hashauthentifizierung

IKE und IPSec bieten Schutz vor Paketänderungen während der Übertragung im Netzwerk. Wenn ein Gerät einen Teil eines Pakets, das durch die Integrierung von Hash geschützt ist, verändert, verwirft der IKE- oder IPSec-Treiber dieses Paket und gibt einen Hash-Authentifizierungsfehler aus, der im Systemprotokoll als Ereignis 4285 erfasst wird. Es kann vorkommen, dass einige Geräte, Netzwerktreiber und Paketprozessoren von Drittanbietern Pakete einer bestimmten Größe, mit einer bestimmten Anzahl an Fragmenten, mit bestimmten Protokolltypen oder unter anderen bestimmten Bedingungen beschädigen (beispielsweise wenn das Gerät überlastet ist, Datenverkehr überwacht oder ein Neustart durchgeführt wird). Dieser Fehler kann auch dann auftreten, wenn ein Angriff auf das Paket von einer böswilligen Anwendung erfolgt, bzw. von einer Anwendung, die nicht erkennt, dass das Paket geschützt war. Der Fehler kann auch ein Hinweis auf einen Denial-of-Service-Angriff sein.

Um festzustellen, dass IPSec-Pakete aufgrund von beschädigten Paketen verworfen wurden, können folgende Techniken eingesetzt werden. Diese Verfahren müssen jedoch in Verbindung mit einer Verfolgung einer Netzwerküberwachung erfolgen, um die Ursache für die beschädigten Pakete festzustellen.

• Überprüfen Sie den Indikator IPsec Packets Not Authenticated. Unter Windows Server 2003 kann dieser Indikator überprüft werden, indem im "Systemmonitor" der IPSec-Indikator unter Verwendung des Befehls netsh ipsec dynamic show stats verwendet wird, oder indem im MMC-Snap-In für den IPSec-Sicherheitsmonitor die Statistiken angezeigt werden. Unter Windows XP kann dieser Indikator überprüft werden, indem der Befehl ipseccmd show stats verwendetwird oder indem im MMC-Snap-In für den IPSec-Sicherheitsmonitor die Statistiken angezeigt werden. Unter Windows 2000 wird dieser Indikator in der Grafikanzeige von ipsecmon.exe angezeigt; es kann auch der Befehl
  netdiag /test:ipsec /v verwendet werden.

• Aktivieren Sie die Protokollierungsfunktion für den IPSec-Treiber, und suchen Sie im Systemprotokoll des Quell-IPSec nach dem Ereignis 4285. Im Abschnitt "Toolkit" dieses Kapitels finden Sie genauere Informationen zum Aktivieren der Protokollierungsfunktion für den IPSec-Treiber. Als Ereignistext wird ein Text der folgenden Art angezeigt:

  "Die Hashauthentifizierung für 5 Paket(e), die von 192.168.0.10 empfangen wurden, ist fehlgeschlagen. Dies könnte ein temporärer Fehler sein. Sollte dieser Zustand andauern, halten Sie den Dienst für den IPSec-Richtlinien-Agenten an, und starten Sie ihn neu."

Auch wenn der Ereignistext darauf hinweist, dass das Problem durch einen Neustart des IPSec-Dienstes behoben werden kann, werden die meisten Paketverluste nicht durch das IPSec-System verursacht. Das Problem wird durch einen Neustart des Dienstes nicht behoben, stattdessen kann dieser noch zu weiteren Problemen führen. Ein Beenden des IPSec-Dienstes sollte immer nur als letzte Möglichkeit durchgeführt werden, um festzustellen, ob das Problem durch IPSec verursacht wird oder nicht.

Das Beheben dieses Fehlers erfordert die Überprüfung eines wiederkehrenden Musters in den Quell-IP-Adressen, der Tageszeit, der Adapter oder der Bedingungen, unter denen der Fehler auftritt. Wenn nur eine geringe Anzahl an Paketen vorhanden ist, stellt eine Überprüfung aufgrund dieses Fehlers einen unverhältnismäßig hohen Aufwand dar. Zunächst muss versucht werden, die Fehlerquellen im lokalen System auszuschließen. Deaktivieren Sie die IPSec-Übertragungsverschiebung, versuchen Sie, erweiterte oder Systemleistungsfunktionen des Treibers zu deaktivieren, der die Konfiguration verwendet, die über die Option "Erweiterte Eigenschaften" verfügbar ist, und verwenden Sie die neuesten Netzwerkkartentreiber, die vom Anbieter bereitgestellt werden, vorzugsweise solche, die vom Windows Hardware Quality Lab genehmigt und signiert wurden. Untersuchen Sie dann die Merkmale des Netzwerkpfads, über den die Übertragung der Pakete erfolgen soll. Suchen Sie nach Belegen für eine Paketbeschädigung in den Statistiken zu verworfenen TCP/IP-Paketen und auf anderen Computern, die dieselbe Konfiguration verwenden. Der IP-Indikator für Empfangene Datagramme verworfen erhöht sich jedes Mal, wenn IPSec ein Paket verwirft.

Ereignisfehler 4268

Ereignistitel: Es wurden Pakete mit einem falschen Sicherheitsparameterindex (PSI) empfangen

Bei der Implementierung von IKE unter Windows 2000 und Windows XP (einschließlich SP1) besteht ein bekanntes Problem, das unter bestimmten Bedingungen zu Paketverlusten führt. Dieses Problem wurde unter Windows Server 2003 und Windows XP SP2 behoben. Die Auswirkungen auf die Protokollkommunikation der oberen Schicht sind in der Regel unerheblich, da die Protokolle aufgrund unterschiedlicher Ursachen bereits von einem Paketverlust ausgehen. Dieses Problem kann durch folgende Störungen identifiziert werden:

• Langsamer, aber stetiger Anstieg der Indikatorenwerte für beschädigte SPIs.
• Systemprotokollmeldungen zu Ereignis 4268 (sofern aktiviert). Unter Windows 2000 werden diese Meldungen im Systemprotokoll als Ereignis 4268 protokolliert. Unter Windows XP wird dieses Ereignis nicht standardmäßig protokolliert; dazu muss die Treiberprotokollfunktion aktiviert werden. Als Ereignistext wird ein Text der folgenden Art angezeigt:
  • "Es wurde(n) <Anzahl> Paket(e) mit einem falschem Sicherheitsparameterindex von <IP-Adresse> empfangen. Dies könnte ein temporärer Fehler sein. Sollte dieser Zustand andauern, halten Sie den Dienst für den IPSec-Richtlinien-Agenten an, und starten Sie ihn neu."

Auch wenn der Ereignistext darauf hinweist, dass das Problem durch einen Neustart des IPSec-Dienstes behoben werden kann, liegt die Ursache für einen solchen Paketverlust in der Art und Weise, wie das IPSec-System erstellt wurde. Das Problem wird durch einen Neustart des Dienstes nicht behoben, stattdessen kann dieser noch zu weiteren Problemen führen. Wie oben erläutert, sollte das Beenden des IPSec-Dienstes immer nur als letzte Möglichkeit durchgeführt werden, um festzustellen, ob das Problem durch IPSec verursacht wird oder nicht.

Ein IPSec-Sicherheitsparameterindex (SPI) ist eine Bezeichnung im Paket, die dem Responder mitteilt, welche Sicherheitszuordnung bei der Verarbeitung des Pakets verwendet werden soll. Wenn kein SPI erkannt wird, wird dies als "beschädigter SPI" (bad SPI) bezeichnet. Dieser Fehler gibt an, dass der empfangende Computer IPSec-formatierte Pakete erhalten hat, ohne dass eine IPSec-Sicherheitszuordnung vorhanden ist, mit der die Pakete verarbeitet werden können. Daher müssen die Pakete verworfen werden.

Auch wenn die Pakete verworfen werden, sind diese Fehlermeldungen unkritisch. Die Anzahl der Ereignisse bezüglich beschädigter SPIs richtet sich nach der derzeitigen Auslastung des Computers und nach der Geschwindigkeit, mit der IPSec-geschützte Daten zum Zeitpunkt des erneuten Schlüsselaustauschs übertragen werden. Diese Ereignisse werden meist häufiger generiert, wenn folgende Bedingungen zutreffen:

• Große IPSec-Datenvolumen werden über Verbindungen mit mehr als 1 Gigabit übertragen werden.
• Ausgelastete (langsame) Server werden zusammen mit schnellen Clients eingesetzt.
• Langsame Clients werden für die Kommunikation mit einem schnellen Server eingesetzt.
• Viele aktive Clients kommunizieren mit einem Server, so dass IKE einen ständigen Schlüsselaustausch mit vielen Clients gleichzeitig durchführen muss.

Dies führt für einige Sekunden zu einer Verlangsamung der durch IPSec geschützten TCP-Verbindung, damit die verloren gegangenen Daten erneut übertragen werden können. Wenn mehrere Pakete verloren gehen, wechselt TCP unter Umständen für diese Verbindung in den Überlastungsvermeidungsmodus. Nach einigen Sekunden sollte die Verbindung wieder mit der normalen Geschwindigkeit verlaufen. File Copy, Telnet, Terminalserver und andere TCP-basierte Anwendungen sollten diese wenigen verloren gegangenen Pakete in der Regel nicht registrieren. Es kann jedoch vorkommen, dass TCP eine große Zahl an Paketen in einer schnellen Verbindung verliert, so dass die Verbindung zurückgesetzt werden muss. Wenn die Verbindung zurückgesetzt wird, wird der Socket beendet und die Anwendung über die Verbindungsunterbrechung benachrichtigt, was zu einer Unterbrechung der Dateiübertragung führen kann.

Die häufigste Ursache für diesen Fehler ist ein bekanntes Problem unter Windows 2000, das die Synchronisierungsmethode von IKE für den Schlüsselaustausch bei der IPSec-Sicherheitszuordnung (IPSec-SA) betrifft. Wenn ein Initiator im IKE-Schnellmodus schneller agiert als der Responder, kann der Initiator neue, durch IPSec-SA gesicherte Pakete senden, bevor der Responder bereit ist, diese zu empfangen. Wie in den RFC-Dokumenten (Request for Comment) der Internet Engineering Task Force (IETF) angegeben, muss der Initiator die neue ausgehende IPSec-SA für die Datenübertragung verwenden, so dass der langsamere Responder den IPSec-geschützten Datenverkehr erhält, den er noch nicht erkennt, wenn IKE ein neues IPSec-Sicherheitsverhandlungspaar erstellt. Da der erneute Schlüsselaustausch durch IKE sowohl von der verstrichenen Zeit als auch von der Menge an Daten abhängt, die unter dem Schutz einer IPSec-SA gesendet werden, können Ereignisse in Verbindung mit beschädigten SPIs wiederholt auftreten (wenn auch nicht notwendigerweise in bestimmten Zeitabständen).

In Szenarien mit Clients von Drittanbietern kann ein Fehler bezüglich eines beschädigten SPI signalisieren, dass ein IPSec-Peer eine Meldung, die einen Löschvorgang betrifft, nicht akzeptiert und verarbeitet hat oder dass Probleme beim Abschließen des letzten Schritts der IKE-Verhandlung im Schnellmodus bestehen. Der Fehler kann auch darauf hinweisen, dass ein Angreifer massenweise gefälschte oder eingeschleuste IPSec-Pakete an den Computer sendet. Der IPSec-Treiber registriert diese Ereignisse und protokolliert sie, um Daten zu Aktivitäten aufgrund von beschädigten SPIs beizubehalten.

Der Registrierungsschlüssel LogInterval kann verwendet werden, um diese Ereignisse zu untersuchen und zu minimieren. Bei der Problembehandlung wird dieser auf den Mindestwert gesetzt (alle 60 Sekunden), so dass die Ereignisse schnell registriert werden. Unter Windows 2000 können Sie den Dienst "IPSec-Richtlinien-Agent" beenden und neu starten, um den IPSec-Treiber erneut zu laden. Unter Windows XP und Windows Server 2003 muss ein Neustart des Computers durchgeführt werden, um die TCP/IP- und IPSec-Treiber erneut zu laden.

Unter Windows 2000 können diese Ereignisse derzeit nicht durch Einstellungen für Registrierungsschlüssel oder Patches eliminiert werden. Bei Verwendung der Standardeinstellungen unter Windows XP und Windows Server 2003 wird kein Bericht zu diesen Ereignissen ausgegeben. Die Berichterstellung für diese Ereignisse kann über die Konfiguration der IPsec-Diagnose mithilfe der Befehlszeilenoption "netsh ipsec" oder direkt über den Registrierungsschlüssel vorgenommen werden.

Mit folgenden Techniken können Sie diese Fehler minimieren:

• Passen Sie die IPSec-Richtlinieneinstellungen an. Erhöhen Sie die Gültigkeitsdauer für den Schnellmodus (sofern die Sicherheitsanforderungen dies zulassen) auf 21 oder 24 Stunden (ungenutzte IPSec-SAs werden gelöscht, nachdem sie fünf Minuten lang nicht verwendet wurden). Um potenzielle Sicherheitsprobleme zu vermeiden, die durch eine Verschlüsselung zu vieler Daten über denselben Schlüssel entstehen, wählen Sie für die Gültigkeitsdauer bei Verwendung der ESP-Verschlüsselung keinen höheren Wert als 100 MB.
• Verwenden Sie den Hauptmodus oder Schnellmodus mit Perfect Forward Secrecy (PFS). Dadurch wird das Problem für diese IPSec-SA, für die die Verhandlung durchgeführt wird, vermieden. Dies erhöht jedoch in beiden Modi beträchtlich die Auslastung des Computers, auf dem Dienste für viele Clients ausgeführt werden, und kann somit zu Verzögerungen bei Antworten auf andere Verhandlungen führen.
• Erhöhen Sie die Kapazität der CPU oder sonstiger Hardware, um die Leistung zu steigern bzw. um die Auslastung durch die Anwendungen zu verringern.
• Installieren Sie eine Netzwerkkarte zur IPSec-Hardwarebeschleunigung, sofern noch keine installiert ist. Diese Karten tragen in hohem Maß zu einer Verringerung der CPU-Auslastung bei, so dass für IPSec eine höhere Datendurchsatzrate zur Verfügung steht.
• Wenn die CPU-Auslastung weiterhin hoch ist, untersuchen Sie, ob durch Hardwarebeschleuniger die Rate für Diffie-Hellman-Berechnungen erhöht werden kann. Bei diesen Beschleunigern handelt es sich meist um PCI-Karten mit einer Diffie-Hellman-Auslagerungsfunktion, die die Diffie-Hellman-Berechnungen beschleunigen. Diese Beschleunigung unterstützt darüber hinaus öffentliche und private Schlüsseloperationen für Zertifikate, die das SSL-Protkoll (Secure Sockets Layer) verwenden. Vergewissern Sie sich beim Anbieter dieser Karte, ob diese die Funktion "ModExpoOffload interface in CAPI for Diffie-Hellman calculations" unterstützt.
• Falls möglich, erstellen Sie einen Filter, der bestimmten Hochgeschwindigkeitsdatenverkehr zulässt, für den keine IPSec-Unterstützung erforderlich ist (beispielsweise Server-Sicherungsdatenverkehr über ein bestimmtes LAN).

Wenn diese Optionen nicht funktionieren und ein Upgrade auf Windows XP SP2 oder Windows Server 2003 nicht möglich ist, wenden Sie sich an die Microsoft Product Support Services, um zu erfragen, ob derzeit andere Optionen verfügbar sind.

Ereignisfehler 4284

Ereignistitel: Es wurden Pakete unverschlüsselt empfangen, die verschlüsselt sein sollten

Dieses Ereignis gibt an, dass eine IPSec-Sicherheitszuordnung zu einem Zeitpunkt erstellt wurde, als Pakete in Klartext empfangen wurden, die sich innerhalb einer IPSec-Sicherheitszuordnung befinden sollten. Diese Pakete werden verworfen, um Paketinjektionsangriffe in IPSec-gesicherten Verbindungen zu vermeiden. Auch wenn sich der IP-Indikator für Empfangene Datagramme verworfen erhöht, hat IPSec keinen Indikatorwert für Pakete, die aus diesem Grund entfernt wurden. Diese Störung kann nur über das Fehlerereignis 4284 im Systemprotokoll ermittelt werden, dass wie folgt lautet:

"Es wurde(n) <Anzahl> Paket(e) unverschlüsselt von <IP-Adresse> empfangen, die verschlüsselt sein sollten.

Dies könnte ein temporärer Fehler sein. Sollte dieser Zustand andauern, halten Sie den Dienst für den IPSec-Richtlinien-Agent an, und starten Sie ihn neu."

Wie bei den vorherigen Fehlern sollte der im Ereignis vorgeschlagene Lösungsweg nicht durchgeführt werden. Der Fehler kann vermutlich nicht durch einen Neustart des IPSec-Dienstes behoben werden.

Die Fehlerursache liegt wahrscheinlich in einem Konfigurationsproblem, das von einer Seite beim Senden von unverschlüsseltem Datenverkehr verursacht wird, da ein spezifischerer Filter ausgehenden Datenverkehr blockiert. Wenn ein Client beispielsweise über einen Filter verfügt, der sämtlichen Datenverkehr eines Servers sichert und die Serverrichtlinie einen spezifischeren Filter zum Zulassen von HTTP-Antworten in Klartext umfasst, sichert der Server den gesamten, an den Client gesendeten Datenverkehr mit Ausnahme der ausgehenden HTTP-Pakete. Der Client empfängt diese Pakete und verwirft sie aus Sicherheitsgründen, da er erwartet, dass sämtlicher Datenverkehr an und vom Server innerhalb des IPSec-SA-Paars gesichert wird.

Dieses Ereignis kann auch während des normalen Betriebs und während der Interoperabilität mit einem Client eines Drittanbieters auftreten, wenn ein Peer eine IPSec-Sicherheitszuordnung oder einen Filter im IPSec-Treiber entfernt, während Datenverkehr zwischen diesen Computern übertragen wird. Eine Seite kann beispielsweise die Zuweisung einer IPSec-Richtlinie aufheben oder ein Update einer Richtlinie erhalten, durch das die IPSec-SAs und Filter gelöscht werden. Da ein Peer den Filter bereits während einer aktiven Protokollkommunikation in einer höheren Ebene gelöscht hat, erreicht die IKE-Meldung zum Löschvorgang den anderen Peer eventuell nicht und kann von diesem nicht bearbeitet werden, bevor die Klartextpakete empfangen werden, was zu einem Fehler führt. Darüber hinaus richtet sich die Zeitdauer, die der Prozess zum Löschen der Meldung benötigt, nach der derzeitigen Auslastung des Peercomputers.

Die Fehlermeldung kann auch auftreten, wenn eine umfangreiche Richtlinie geladen wird, da die IPSec-Sicherheitszuordnungen eventuell erstellt werden, bevor der gesamte Filtersatz auf den IPSec-Treiber angewendet wird. Wenn dieser Fall eintritt, können IPSec-SAs eventuell Verhandlungen für Datenverkehr vornehmen, der als Ausnahme definiert wird, nachdem die Richtlinie vollständig geladen ist.

Die Fehlermeldung kann auch auf einen Injektionsangriff hinweisen, bei dem Datenverkehr in Klartext gesendet wird, der (entweder beabsichtigt oder unbeabsichtigt) mit dem Datenverkehr übereinstimmt, der für eine bestimmte aktive Sicherheitszuordnung für eingehenden Datenverkehr ausgewählt wurde.

Dieses Problem erfordert eine Eskalation zu der Person, die die IPSec-Richtlinie erstellt hat.

Überschreitung von Zeitlimits für IPSec-NAT-T während einer Verbindung über drahtlose Netzwerke

Es wurde kürzlich ein Problem festgestellt, das eine Überschreitung von Zeitlimits für Verbindungen verursacht, wenn Windows Server 2003 oder Windows XP-basierte Clientcomputer versuchen, eine Verbindung zu einem drahtlosen Netzwerk herzustellen, in dem IPSec-NAT-T verwendet wird. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 885267 unter https://support.microsoft.com/?kbid=885267.

Überprüfen der korrekten IPSec-Richtlinie

Dieser Abschnitt erläutert die Schritte zum Ermitteln von Problemen bei der IPSec-Richtlinienzuordnung und -interpretation. Es müssen Filter einer korrekt interpretierten IPSec-Richtlinie im IPSec-Treiber vorhanden sein, um Pakete zuzulassen und zu blockieren und um IKE-Verhandlungen von IPSec-SAs mit Remote-IP-Adressen für sicheren Datenverkehr zu veranlassen. Es müssen entsprechende Filter vorhanden sein, anhand derer IKE die Rolle eines Responders annehmen kann. In dieser Lösung muss bei der Erstellung der IPSec-Richtlinie eine Sicherung des gesamten Datenverkehrs (mit Ausnahme von ICMP) durch IPSec berücksichtigt werden. Die Richtlinie umfasst darüber hinaus Filter für alle IP-Adressen in der Ausnahmeliste.

Supporttechniker müssen mit der Verwendung von Gruppenrichtlinien durch IPSec, mit der Prioritätsreihenfolge für IPSec-Richtlinien und mit der Interpretation von IPSec-Richtlinien vertraut sein. Verweise auf Informationen zu diesen Themen finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels.

Problembehandlung für Gruppenrichtlinien bei IPSec

Gruppenrichtlinien stellen einen Mechanismus zum Zuweisen einer domänenbasierten IPSec-Richtlinie zu einem Mitglied einer Domäne bereit. Durch Abrufen der zugewiesenen Gruppenrichtlinienobjekte (Group Policy Object, GPO) vom Domänenmitglied wird die IPSec-Richtlinienzuweisung an einen Hostcomputer gesendet. Daher führen alle Probleme beim Abrufen der GPO dazu, dass Computer nicht die korrekte IPSec-Richtlinie anwenden. Zu den häufigen Störungen bei Gruppenrichtlinien für die Verwaltung von IPSec-Richtlinien gehören Folgende:

• Replikationsverzögerungen von unterschiedlichen Konfigurationskomponenten in Active Directory
• Probleme mit der Abfrage der Gruppenrichtlinie und dem Downloadprozess
• Unklarheit darüber, welche Version der IPSec-Richtlinie zugewiesen wurde
• IPSec-Dienst wird nicht ausgeführt
• IPSec-Richtlinie in Active Directory kann nicht abgerufen werden, so dass stattdessen eine Kopie des Cachespeichers verwendet wird
• Verzögerungen durch Abfrage der IPSec-Richtlinie zum Abrufen der derzeit zugewiesenen IPSec-Richtlinie

Die Replikation kann Verzögerungen aufweisen, die durch die Anzahl der IPSec-bezogenen Objekte in Active Directory verursacht werden, wie IPSec-Richtlinien, GPOs, Attributsänderungen für Zuweisungen der GPO-IPSec-Richtinien und für IPSec-Richtlinien und Informationen zu Sicherheitsgruppenmitgliedschaften. Es ist eine sorgfältige Planung erforderlich, um die Auswirkungen einer IPSec-Konfigurationsänderung zu bewerten, da diese mit der Zeit auch Domänenmitglieder betreffen.

Informationen zu Problembehandlungsverfahren für Gruppenrichtlinien finden Sie in den folgenden Whitepapers:

• White-Paper: bei Gruppenrichtlinie der Problembehandlung bei Richtlinie in Windows 2000 unter https://support.microsoft.com/?kbid=810739.
• Troubleshooting Group Policy in Microsoft Windows Server unter www.microsoft.com/downloads/details.aspx?
  FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en (in englischer Sprache).

Bei einer domänenbasierten Zuweisung einer IPSec-Richtlinie erfolgt eine Implementierung in zwei Komponenten:

• Im MMC-Snap-In für die IPSec-Richtlinienverwaltung (in Erweiterung des MMC-Snap-Ins für die Sicherheitsrichtlinie) zur Zuweisung einer IPSec-Richtlinie im GPO
• In der clientseitigen Erweiterung (Client Side Extension, CSE) der Gruppenrichtlinie für IPSec (implementiert in gptext.dll), die IPSec-bezogene Informationen im GPO verarbeitet

Mit dem MMC-Snap-In für die IPSec-Richtlinienverwaltung erfolgt die Zuweisung einer Richtlinie an ein GPO, indem die ausgewählten IPSec-Richtlinieninformationen in der IPSec-Komponente für das GPO gespeichert werden, auf das als LDAP-DN (Distinguished Name, definierter Name) verwiesen wird:

CN=IPSEC,CN=Windows,CN=Microsoft,CN=Machine,CN={GPOGUID},
CN=Policies,CN=System,DC=domain,DC=Woodgrove,DC=com

Der LDAP-DN der zugewiesenen IPSec-Richtlinie wird im GPO-Attribut "ipsecOwnersReference" gespeichert.

Wenn die Gruppenrichtlinie die Liste der GPOs erhält, die auf den Computer angewendet werden, werden die GPOs, die die IPSec-Richtlinienzuordnungen enthalten, in der Registrierung unter der GUID für die IPSec-clientseitige Erweiterung unter diesem Pfad gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Group Policy
\History\{e437bc1c-aa7d-11d2-a382-00c04f991e27}

Die IPSec-CSE wird durch die Sicherheitsrichtlinien-CSE aktiviert, wenn in einem GPO eine IPSec-Richtlinienzuweisung enthalten ist. Wenn Probleme beim Verarbeiten der Sicherheitsrichtlinie bestehen, können auch Probleme beim Verarbeiten der IPSec-Richtlinie auftreten. Die GUID für die einzelnen Gruppenrichtlinienerweiterungen finden Sie in der Registrierung unter folgendem Pfad:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\WinLogon\GPExtensions

Die GUIDs für Gruppenrichtlinien-CSEs, die sich auf die Bereitstellung von IPSec beziehen, sind folgende:

• Sicherheit. {827D319E-6EAC-11D2-A4EA-00C04F79F83A}
• IP-Sicherheit.{E437BC1C-AA7D-11D2-A382-00C04F991E27}
• Skripts. {42B5FAAE-6536-11D2-AE5A-0000F87571E3}

Die IPSec-CSE kopiert den LDAP-DN und zugehörige Informationen zur zugewiesenen IPSec-Richtlinie in den folgenden Registrierungsschlüssel:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

Wenn mehrere GPOs IPSec-Richtlinienzuweisungen enthalten, wird für jedes GPO eine CSE angefordert. Die Prioritätsfolge für GPO-Regeln entspricht der Reihenfolge, in der die IPSec-CSE die GPOs zur Verarbeitung erhält. Die Reihenfolge kann auch durch die Einstellungen in den GPOs selbst und von den Lese-Zugriffskontrolllisten (Access Control List, ACL) beeinflusst werden, die das Abrufen einiger zugewiesener GPOs verhindern. Jedes Mal, wenn eine IPSec-CSE angefordert wird, werden die IPSec-bezogenen Informationen im GPO (einschließlich DN) in diesem Registrierungsschlüssel überschrieben. Wenn alle GPOs verarbeitet wurden, signalisiert die CSE dem IPSec-Dienst, dass eine domänenbasierte IPSec-Richtlinie zugewiesen wurde. Der IPSec-Dienst liest dann den Wert GPTIPsecPolicy\DSIPSECPolicyPath, um die korrekte IPSec-Richtlinie abzurufen.

Der IPSec-Dienst ruft weiterhin Änderungen der zugewiesenen IPSec-Richtlinie ab, die auf dem Zeitpunkt des letzten Updates für alle zugewiesenen Verzeichnisobjekte der IPSec-Richtlinie basieren. Der Dienst behält die IPSec-Richtlinie der Cache als letzte Domänenrichtlinie bei.

Es besteht ein bekanntes Problem, das zulässt, dass der Name der zugewiesenen IPSec-Richtlinie nicht mit dem Namen der tatsächlich verwendeten IPSec-Richtlinie (die sich im Cachespeicher befindet) synchronisiert wird. Der IPSec-Dienst aktualisiert diese Informationen nicht im Registrierungsschlüssel GPTIPsecPolicy, wie beispielsweise DSIPSECPolicyName, und der Name der IPSec-Richtlinie ändert sich nur dann, wenn die IPSec-CSE angefordert wird. Die IPSec-CSE wird jedoch nur dann angefordert, wenn Änderungen im DN-Attribut der IPSec-Richtlinienzuweisung im GPO bestehen. Dieser Registrierungswert wird vom MMC-Snap-In für den IPSec-Monitor und von den Befehlszeilenprogrammen verwendet, um einen Bericht mit dem Namen der derzeit zugewiesenen IPSec-Richtlinie zu erstellen. Daher kann im Bericht der IPSec-Tools ein IPSec-Richtlinienname aufgeführt werden, der zuletzt von der CSE verarbeitet wurde, und nicht der, der derzeit verwendet wird. Es gibt mehrere Möglichkeiten, diesen Fehler zu umgehen; weitere Informationen finden Sie in diesem Leitfaden in Kapitel 5 "Erstellen von IPSec-Richtlinien für Isolierungsgruppen" im Abschnitt "Versionskontrolle für Richtlinien".

Wenn keine korrekte IPSec-Richtlinie zugewiesen wurde, auch wenn die Aktualisierung der Gruppenrichtlinie erzwungen wurde, weisen Fehler im Anwendungsprotokoll der Quellen Userenv oder SceCli auf Verarbeitungsprobleme mit der Gruppenrichtlinie hin. Die Protokollierung der Gruppenrichtlinie muss aktiviert sein, um dieses Problem genauer untersuchen zu können. Es gibt viele unterschiedliche Protokolltypen für Gruppenrichtlinien und Protokollierungsebenen. Protokolle für die Sicherheits-CSE sind erforderlich, um Fehler bei der Verarbeitung der Sicherheitsrichtlinie anzuzeigen sowie sämtliche Fehler, die von der Berichterstellung der IPSec-CSE erfasst werden. Für die IPSec-CSE steht kein bestimmtes Protokoll zur Verfügung. Es kann eine Netzwerkmonitorverfolgung erforderlich sein, um Datenverkehr zu der Zeit zu erfassen, zu der die Gruppenrichtlinie aktualisiert wurde, um zu überprüfen, welche IP-Adresse des Domänencontrollers zum Abrufen der einzelnen Objekte verwendet wird. Die Probleme können Folgendes umfassen:

• Replikationsprobleme oder Verzögerungen, die dazu führen, dass die Objekte nicht gefunden werden
• Die logische Struktur des Lastenausgleichs des Domänencontroller-Locators, die dazu führen kann, dass ein GPO von einem Domänencontroller abgerufen wird, während die LDAP-Anforderung für die zugewiesene IPSec-Richtlinie von einem anderen Domänencontroller desselben Standorts abgerufen wird.

Verwenden Sie zum Erstellen einer detaillierten Protokolldatei für die Sicherheits-CSE den folgenden Registrierungsschlüssel:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\WindowsNT\CurrentVersion\CurrentVersion\Winlogon
\GpExtensions\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\

Setzen Sie für den Eintrag ExtensionDebugLevel den REG_DWORD-Wert "0x2".

Die Protokolldatei wird erstellt unter %windir%\Security\Logs\Winlogon.log.

Problembehandlung für den IPSec-Dienst

Es ist nicht erforderlich, den IPSec-Dienst auszuführen, um das MMC-Snap-In für die IPSec-Richtlinienverwaltung zu verwenden. Wenn ein Administrator jedoch eine Zuweisung einer lokalen Richtlinie vornimmt, wird in der Spalte Richtlinie zugewiesen ein Fehler angezeigt.

Folgende Probleme sind häufige Ursachen für einen fehlgeschlagenen Start des IPSec-Dienstes:

• Der Computer wurde im abgesicherten Modus oder im Wiederherstellungsmodus von Active Directory gestartet. In diesen Fällen lässt der IPSec-Treiber standardmäßig eine statusbezogene eingehende Kommunikation zu, wenn eine IPSec-Richtlinie zugewiesen wurde. Die eingehende Konnektivität wird blockiert, sofern ein Startausnahmebefehl konfiguriert wurde.
• IKE kann keine alleinige Steuerung von UDP-Port 500 und Port 4500 erreichen. Verwenden Sie "netstat bov", um die Prozesse und Codemodule für die einzelnen Ports anzuzeigen. Über den Befehl "portqry local v" werden noch detailliertere Informationen ausgegeben. Es sind eventuell einige Winsock Layered Service Providers (LSP) installiert, die IPSec stören. Weitere Informationen zu LSPs und IPSec finden Sie weiter unten in diesem Kapitel imAbschnitt "Behandlung von anwendungsbezogenen Problemen".
• Beschädigte IPSec-Richtlinie. Die zugewiesene IPSec-Richtlinie kann nicht vollständig gelesen oder angewendet werden, was dazu führt, dass der IPSec-Dienst Berichte zu mehreren Fehlern erstellt. Diese Fehler verursachen nicht das Fehlschlagen des Dienstes selbst, können jedoch zu zahlreichen Kommunikationsfehlern führen, etwa zur Blockierung von Gruppenrichtlinien und des Abrufens der korrekten Richtlinien durch den IPSec-Dienst. Unter Windows XP und Windows Server 2003 muss auf eine permanente Richtlinie oder lokale Richtlinie geachtet werden, die als "sichere" Richtlinie im Falle von Fehlern angewendet wird, die bei der Anwendung einer domänenbasierten Richtlinie auftreten. Sowohl die permanente Richtlinie als auch die Richtlinie zum Starten des Computers (Bootausnahmen) sollten in eine Überprüfung bei der Problembehandlung eingeschlossen werden. Diese Richtlinien sollten einen Remotezugriff auf den Computer über andere Methoden zulassen, für den Fall, dass nur Richtlinien für andere Fehlerbedingungen angewendet wurden.

Bei der IPSec-Implementierung unter Windows 2000 wird ein Modul mit der Bezeichnung IPSec-Richtlinienspeicher (polstore.dll) verwendet, so dass der IPSec-Richtlinien-Agent und das MMC-Snap-In für die IPSec-Richtlinienverwaltung ein Modul für den Zugriff auf alle drei unterstützten Speicherorte verwenden kann: lokal, Remotecomputer und Active Directory. Dieses wurde für Windows XP und Windows Server 2003 modifziert und verbessert, indem neue IPSec-Richtlinientypen (Startrichtlinie und permanente Richtlinie) und die Sicherheitsrichtlinien-Datenbankkomponente (Security Policy Database, SPD) hinzugefügt wurden, die den Laufzeitstatus der IPSec-Richtlinie für IPSec-Monitoranforderungen und IKE-Anfragen verwaltet. Diese Modifikationen der Architektur bedeuten, dass sich der Text der protokollierten IPSec-Ereignisse von Windows 2000 unter Windows XP und Windows Server 2003 geändert hat. Diese Modifikationen der Architektur erforderten darüber hinaus umfassende Änderungen an den RPC-Schnittstellen, die für eine Remoteverwaltung verwendet werden. Für Windows Server 2003 wurden auch umfassende Updates an diesen RPC-Schnittstellen vorgenommen. Folglich ist das MMC-Snap-In für die IPSec-Richtlinienverwaltung nicht in der Lage, eine Verbindung zu Remotecomputern herzustellen, auf denen nicht dasselbe Betriebssystem installiert ist. Zusätzlich wurde das Sicherheitsmodell für Windows XP SP2 und Windows Server 2003 SP1 grundlegend geändert, um Remote-RPC-Verbindungen zu reduzieren und die Windows-Firewall standardmäßig zu aktivieren. Weitere Informationen finden Sie unter Changes to Functionality in Microsoft Windows XP Service Pack 2 - Part 2: Network Protection Technologies unter www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx (in englischer Sprache).

Aufgrund dieser Änderungen wurden diese Remoteschnittstellen für den IPSec-Dienst aus Sicherheitsgründen deaktiviert. Daher sind die MMC-Snap-Ins für den IPSec-Monitor und die IPSec-Richtlinienverwaltung nicht in der Lage, eine Remoteüberwachung auf diesen Computern auszuführen. Die Remoteverwaltung für IPSec muss über Remotedesktopverbindungen (Terminalserver) durchgeführt werden, über die die IPSec-MMC-Snap-Ins als lokale Prozesse ausgeführt werden.

Unter Windows 2000 wird der IPSec-Treiber standardmäßig am Ende des Startvorgangs vom Dienst "Richtlinien-Agent" geladen. Der IPSec-Treiber ist so lange nicht an der IP-Paketverarbeitung beteiligt, bis der Richtlinien-Agent den IPSec-Treiber über eine aktive Richtlinie informiert. Wenn keine aktive IPSec-Richtlinie besteht, ist der IPSec-Treiber nicht an der Verarbeitung von ausgehendem und eingehendem Datenverkehr beteiligt. Unter Windows XP und Windows Server 2003 wurden dazu Verbesserungen vorgenommen, so dass der IPSec-Treiber während des Startens vom TCP/IP-Treiber geladen wird. Der Treiber verarbeitet Pakete erst dann, wenn er Filter über den IPSec-Dienst geladen hat.

Unter Windows 2000 können über den IPSec-Richtlinien-Agenten Fehlerprotokolle zu Problemen mit dem Starten des Dienstes erstellt werden. Zu diesen Fehlern gehören u. a.:

• Der IP-Sicherheitsrichtlinien-Agent konnte nicht gestartet werden. IP-Sicherheitsrichtlinie wird nicht auferlegt. Dieser Fehler wird wahrscheinlich durch Probleme verursacht, die beim IPSec-Richtlinien-Agenten während der Registrierung für das RPC-Subsystem aufgetreten sind. Der Fehler kann auch bei einer fehlgeschlagenen Initialisierung von IKE aufgrund von Winsock-LSPs von Drittanbietern auftreten.

• Der Richtlinien-Agent-RPC-Server...

  • konnte die Protokollsequenz nicht registrieren.
  • konnte die Schnittstelle nicht registrieren.
  • konnte die Schnittstellenbindung nicht registrieren.
  • konnte den Schnittstellenendpunkt nicht registrieren.
  • konnte den Authentifizierungsvorgang nicht registrieren
  • kann keine Verbindung aufbauen.

  Sämtliche dieser Fehler können durch Änderungen an den erweiterten Einstellungen oder durch Probleme innerhalb des RPC-Dienstes verursacht werden, wegen derer der IPSec-Richtlinien-Agent während des Startvorgangs für den Dienst nicht korrekt initialisiert werden konnte. Somit wird der IPsec-Richtlinien-Agent nicht korrekt ausgeführt, was dazu führen kann, dass er blockiert oder beendet wird.

• Der Richtlinien-Agent konnte nicht gestartet werden. Die SCM-Datenbank konnte nicht angesprochen werden. Fehler: <Nummer>. Der IPSec-Dienst kann die Datenbank des Dienststeuerungs-Managers nicht öffnen. Dieser Fehler kann auftreten, wenn der IPSec-Dienst als Dienstkonto ohne Berechtigungen konfiguriert wurde. Er muss als lokales System ausgeführt werden. Untersuchen Sie andernfalls Probleme im Zusammenhang mit dem Dienst-Steuerungsmanager.

• Der Richtlinien-Agent konnte nicht mit dem IPSEC-Treiber verbunden werden. Der IPSec-Treiber konnte nicht erfolgreich geladen und mit dem TCP/IP-Stapel verbunden werden. Windows 2000 ist so konzipiert, dass dieser Vorgang beim Starten des IPSec-Dienstes ausgeführt wird. Die Verbindungsherstellung wird eventuell durch eine Software von Drittanbieten verhindert, oder es fehlen unter Umständen Codemodule im Betriebssystem, die für diese Funktionalität erforderlich sind.

• Die IPSEC-Richtlinien konnten vom Richtlinien-Agenten nicht geladen werden. Während des Ladens sämtlicher Filter in den Treiber unter Verwendung des IPSec-Richtlinien-Agenten ist ein Fehler aufgetreten. Dieser Fehler kann eventuell durch einen unzureichenden Kernelspeicher oder durch eine nicht korrekte Initialisierung des IPSec-Treibers verursacht werden. Wenn das Problem weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.

• Der Richtlinien-Agent konnte den ISAKMP-Dienst nicht starten. Dieser Fehler tritt in der Regel dann auf, wenn IKE keine alleinige Steuerung von UDP-Port 500 oder Port 4500 erreichen kann, da diese Ports bereits von einem anderen Dienst verwendet werden. Der Fehler kann auch durch eine Software eines Drittanbieters verursacht werden, die die Netzwerkportzuordnung verhindert, oder der IPSec-Dienst wird eventuell nicht im lokalen Systemkontext ausgeführt.

• Der SSPI-Name für den ISAKMP/Oakley-Dienst (QueryCredentialsAttributes) konnte nicht bestimmt werden. Windows 2000 protokolliert diese Meldung, wenn das Aufrufen des Dienstes "QueryCredentialsAttributes" über die Sicherheitsunterstützungs-Anbieterschnittstelle (Security Support Provider Interface, SSPI) fehlschlägt. Dies kann darauf hinweisen, dass der Computer sich nicht erfolgreich bei der Domäne anmelden kann.

• Der ISAKMP/Oakley-Dienst hat keine Anmeldeinformationen des Kerberos-Servers erhalten. Diese Fehlermeldung unter Windows 2000 wird häufig dann angezeigt, wenn der IPSec-Dienst in einem Remotenetzwerk gestartet wird (etwa beim Starten des Computers), dem eine IPSec-Richtlinie zugewiesen wurde (beispielsweise von einem Registrierungscache einer Domänenrichtlinie), die eine Kerberos-Authentifizierung erfordert und für die kein Domänencontroller verfügbar ist. Dies führt zu einem Fehlschlagen der Kerberos-Authentifizierung. In einem internen Netzwerk wird für dieses Ereignis ein Protokoll auf einem Computer erstellt, der nicht Mitglied der Domäne ist oder der nicht auf die Domänencontroller über das Kerberos-Protokoll zugreifen kann, während der IPSec-Dienst initialisiert wird.

• Es konnte keine sichere Kommunikationsrichtlinie erzwungen werden, da der IP-Sicherheitstreiber nicht gestartet werden konnte. Wenden Sie sich sofort an Ihren Systemadministrator. Dieser Fehler wird verursacht, wenn ein Problem mit dem IPSec-Treiber besteht, das das Laden des IPSec-Treibers, das Binden des Treibers an den TCP/IP-Stapel oder das Initialisieren des Treibers vor dem Versuch, ihm Richtlinien hinzuzufügen, betrifft. Die Ursache dafür können beschädigte Dateien oder fehlende Berechtigungen sein. Überprüfen Sie die Sicherheitseinstellungen oder die Sicherheitssoftware von Drittanbietern, die das Laden des Treibers verhindern können. Wenn die internen Signaturen FIPS.sys während der Initialisierung nicht überprüft werden können, schlägt sowohl das Laden der Signaturen als auch das Laden des IPSec-Treibers fehl. Bei Signaturfehlern für FIPS.sys ist eine Ersetzung der ursprünglichen, signierten Binärdatei oder eine neue Binärdatei von Microsoft erforderlich. Starten Sie den Computer neu. Wenn das Problem weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.

Unter Windows XP und Windows Server 2003 geben die folgenden Fehlerereignisse zu IPSec-Diensten an, dass der Dienst nicht gestartet werden kann:

• Die IPSec-Dienste konnte den IPSec-Treiber nicht initialisieren. Fehlercode: <Nummer>. Die IPSec-Dienste konnten nicht gestartet werden. Das Laden des IPSec-Treibers ist aus irgendeinem Grund fehlgeschlagen. Wenn das Problem weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.
• Die IPSec-Dienste konnte das IKE-Modul nicht initialisieren. Fehlercode: <Nummer>. Die IPSec-Dienste konnten nicht gestartet werden. Häufige Ursachen für dieses Problem sind Winsock-LSPs von Drittanbietern, die die Verwendung von bestimmten Socket-Optionen durch IKE verhindern. Dieser Fehler wird auch dann ausgegeben, wenn für IKE keine alleinige Steuerung der UDP-Ports 500 und 4500 möglich ist.
• Die IPSec-Dienste konnte den RPC-Server nicht initialisieren. Fehlercode: <Nummer>. Die IPSec-Dienste konnten nicht gestartet werden. Der IPSec-Dienst hängt vom RPC-Subsystem für die Kommunikation zwischen den Prozessen für IKE, SPD und dem Richtlinien-Agenten ab. Verwenden Sie die RPC-Problembehandlungsverfahren, um zu überprüfen, ob RPC korrekt ausgeführt wird. Wenn das Problem nach einem Neustart des Computers weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.
• Die IPSec-Dienste haben einen kritischen Fehler ermittelt und wurden mit folgendem Fehlercode beendet: <Nummer>. Beenden der IPSec-Dienste kann die Sicherheit des Computers stark beeinträchtigen. Wenden Sie sich an den Computeradministrator, um die Dienste erneut zu starten. Beim IPSec-Dienst ein Fehler aufgetreten, der durch die <Nummer> im Ereignistext angegeben wird. Dieser Dienst kann nicht mehr ausgeführt werden. Der IPSec-Treiber wird dennoch geladen und kann entweder im normalen Modus (erzwingen der IPSec-Richtlinienfilter) oder im gesperrten Modus ausgeführt werden. Ein anderes Ereignis gibt gegebenenfalls an, ob der Treiber in den gesperrten Modus versetzt wurde. Wenn der Treiber im normalen Modus betrieben wird, werden die Filteraktionen zum Zulassen und Blockieren weiterhin wie gewohnt ausgeführt. Bei der Verwendung von Filtern mit einer Verhandlungsaktion wird der Datenverkehr einfach entfernt, da IKE nicht verfügbar ist.
• IPSec-Dienste haben den IPSec-Treiber aufgrund von vorherigen Fehlern in den gesperrten Modus versetzt. Fehlercode: <Nummer>. Diese Meldung ist eine Benachrichtigung darüber, dass der IPSec-Treiber aufgrund des Failsafe-Verhaltens in den gesperrten Modus versetzt wurde, da Fehler beim Verarbeiten der IPSec-Richtlinie festgestellt wurden. Dieses Verhalten tritt nur unter Windows Server 2003 auf. Der gesperrte Modus lässt jedoch noch eingehende Ausnahmen zu, die unter Verwendung des Befehls "netsh ipsec" konfiguriert wurden.

Problembehandlung beim Abrufen von IPSec-Richtlinien

Der IPSec-Dienst verwendet für alle Plattformen eine authentifizierte und verschlüsselte TCP-LDAP-Anfrage für den Download der zugewiesenen IPSec-Richtlinie. Es bestehen Optionen für die Signatur und das Versiegeln von LDAP über den Kerberos-Sitzungsschlüssel. Daher muss der IPSec-Dienst, der im Kontext des lokalen Systems ausgeführt wird, in der Lage sein, ein Kerberos-Dienstticket für den LDAP-Dienst auf dem Active Directory-Server abzurufen. Wenn das Speichern der korrekten, zugewiesenen IPSec-Richtlinie durch die IPSec-CSE unter dem Registrierungsschlüssel GPTIPsecPolicy bestätigt und der Dienst ausgeführt wird, können die folgenden Störungen ein Abrufen der Richtlinie von Active Directory durch den IPSec-Dienst verhindern:

• Kommunikationsprobleme mit Domänencontrollern

• Probleme mit der Anmeldung des Computerkontos bei einem Domänencontroller

• Probleme beim Ausgeben der Kerberos-Tickets

• Probleme mit der Verfügbarkeit des LDAP-Dienstes

• Probleme beim Auffinden der IPSec-Richtlinien- oder Komponentenobjekte, die in der SDAP-Anfrage angefordert werden

• Probleme mit den Leseberechtigungen für eines der angeforderten IPSec-Richtlinienobjekte

• Beschädigte Richtlinien aufgrund von Problemen beim Ablegen von Objekten im Speicher durch unbeabsichtigtes oder beabsichtigtes Löschen von Objekten aus dem Speicher

  Hinweis

  
  Eine IPSec-Richtlinie, die unter Windows XP oder Windows Server 2003 erstellt wird und neue, für diese Versionen verfügbare Funktionen verwendet, entfernt unter Umständen diese Funktionen unbemerkt, wenn die Richtlinie später über das MMC-Snap-In für die Windows 2000-IPSec-Richtlinienverwaltung bearbeitet und gespeichert wird. Wenn ein Windows 2000-System jedoch eine IPSec-Richtlinie mit zusätzlichen Funktionen abruft, werden diese einfach ignoriert, was eventuell zu Änderungen des Verhaltens der IPSec-Richtlinie führen kann, wenn diese im Windows 2000-System aktiviert wird.
  

Es besteht ein bekanntes Problem mit dem MMC-Snap-In für die IPSec-Richtlinienverwaltung bei der Verwaltung von IPSec-Richtlinien in Active Directory oder auf einem Remotecomputer. Wenn das MMC-Snap-In über eine langsame Verbindung ausgeführt wird, kann es für eine umfassende Richtlinie eventuell einige Zeit dauern, bis alle Änderungen gespeichert werden. Wenn das Fenster des MMC-Snap-Ins geschlossen wird, gehen alle IPSec-Richtlinienobjekte oder -änderungen, die noch nicht gespeichert wurden, verloren. Dies kann zu einer beschädigten IPSec-Richtlinie führen. Wenn das MMC-Snap-In für die IPSec-Richtlinienverwaltung über eine langsame Verbindung ausgeführt wird, verwenden Sie eine Remotedesktop-Sitzung, um das Snap-In als lokalen Prozess auszuführen.

Sämtliche Skripts zu Befehlszeilenprogrammen, die IPSec-Richtlinien erstellen, erfordern generell eine Überprüfung. Erstellen Sie dafür eine Richtlinie im lokalen Speicher, und zeigen Sie diese unter Verwendung des MMC-Snap-Ins für die IPSec-Richtlinienverwaltung an, um dessen Integrität zu überprüfen. Die Testcomputer müssen die lokale IPSec-Richtlinie anwenden und die Details im MMC-Snap-In für den IPSec-Monitor überprüfen, um die erwartete Filterreihenfolge zu bestätigen.

Die Verfahren zur Problembehandlung und -behebung von Lesefehlern für IPSec-Richtlinien und beschädigte Richtlinien richten sich nach dem Speicherort. In dieser Lösung wird nur eine domänenbasierte IPSec-Richtlinie verwendet; die Konfiguration von anderen IPSec-Richtlinientypen kann jedoch ebenfalls zu Problemen führen.

Im übrigen Teil dieses Abschnitts werden die Problembehandlungsverfahren für die einzelnen Richtlinientypen erläutert. Der Support der Ebene 2 muss generell dazu in der Lage sein, entweder über Befehlszeilenprogramme oder über Tools der grafischen Benutzeroberfläche ein korrektes Abrufen und eine korrekte Interpretation der IPSec-Richtlinie sicherzustellen. Im Folgenden werden die erforderlichen Schritte zum Löschen der einzelnen Richtlinientypen aufgeführt, so dass davon ausgegangen wird, dass bei einer Aktualisierung der Richtlinien eine korrekte Installation der Richtlinien erfolgt. Wenn kein Abrufen oder Installieren einer korrekten Richtlinie von den Skripts erfolgen kann, wird das Problem an den Support der Ebene 3 eskaliert.

IPSec-Startrichtlinie

Das Dienstprogramm "Netsh" ermöglicht die Konfiguration der Optionen für den Bootmodus und für Bootausnahmen, die nur unter Windows Server 2003 unterstützt werden. Die Konfiguration wird in folgenden Registrierungsschlüsseln mit den jeweils angezeigten Standardwerten gespeichert:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\

  OperationMode=3 (statusbehaftet)

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSec\

  BootExemptList = (Ausnahme für eingehendes DHCP, siehe unten)

Der Standardwert OperationMode erfordert ein statusbehaftetes Filtern von ausgehendem Datenverkehr durch den IPSec-Treiber. Wenn der IPSec-Dienst ausgeführt wird, verwenden Sie den Befehl
Netsh ipsec dynamic show config zum Anzeigen der Startkonfiguration. Wenn der IPSec-Dienst nicht ausgeführt wird (wenn beispielsweise der abgesicherte Modus gestartet wurde), kann der Registrierungsschlüsselwert über Registrierungstools überprüft und geändert werden.

Um Datenverkehrsprobleme, die möglicherweise durch eine statusbehaftete IPSec-Filterfunktion während des Startens verursacht werden, zu behandeln, setzen Sie die Einstellungen für den IPSec-Treiber so, dass Datenverkehr beim Startvorgang zugelassen wird, statt ein statusbehaftetes Filtern auszuführen. Wenn der IPSec-Dienst ausgeführt wird, verwenden Sie den Befehl
netsh ipsec dynamic set config bootmode value=permit zum Einstellen des Startmodus zum Zulassen von Datenverkehr. Wenn der IPSec-Dienst nicht ausgeführt wird, verwenden Sie ein Registrierungstool, um dem Modus OperationsMode=1 so zu ändern, dass Datenverkehr zugelassen wird. Der IPSec-Treiber wendet den Startsicherheitsmodus auch nicht an, wenn der IPSec-Dienst so konfiguriert ist, dass er manuell gestartet wird, oder wenn der Dienst deaktiviert ist. Nachdem der Dienst für einen manuellen Start konfiguriert oder deaktiviert wurde, ist ein Neustart des Computers erforderlich, um den Modus zum Zulassen von Datenverkehr zu laden.

Permanente IPSec-Richtlinie

Permanente Richtlinien werden unter Windows XP und Windows Server 2003 unterstützt. Eine häufige Fehlersituation tritt dann auf, wenn eine bestehende permanente Richtlinie nicht gelöscht wird, bevor eine neue permanente Richtlinie definiert wird, und die neue Richtlinie zu einem Konflikt mit anderen Einstellungen führt, die bereits zugewiesen wurden. In der in diesem Leitfaden erläuterten Lösung werden keine permanenten Richtlinien verwendet. Da diese jedoch in einigen Umgebungen eingesetzt werden können, werden in diesem Kapitel Anweisungen zur Problembehandlung bereitgestellt.

Der Registrierungsschlüssel für permanente Richtlinien ist standardmäßig bereits vorhanden. Dieser ist leer:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Persistent

Unter Windows XP kann eine permanente Richtlinie am schnellsten ermittelt werden, indem überprüft wird, ob der Registrierungsschlüssel nicht leer ist. Über den Befehl "ipseccmd show" wird ein Bericht zu einer aktiven Richtlinie ausgegeben, die im IPSec-Dienst enthalten ist. Es wird kein Bericht über eine bestimmte Einstellung ausgegeben, die von der permanenten Richtlinie stammt. Der IPSec-Dienst verwirft Namen für die bestehenden Richtlinienregeln, wenn eine Interpretation der Richtlinie für die aktiven Einstellungen erfolgt. Da über "ipseccmd" keine Namen zu Filtern oder Filteraktionen ausgegeben werden, können keine Benennungskonventionen zum Angeben von Filtern und Filteraktionen verwendet werden, die von einer permanenten Richtlinie stammen. Filter verfügen über Benennungen des Typs "text2pol{GUID}", wenn diese über die Befehlszeilenprogramme ipsecpol.exe oder ipseccmd.exe erstellt wurden, die Einträge von permanenten Richtlinien beinhalten. Lokale oder Domänenrichtlinien, die unter Verwendung von Skripts erstellt wurden, können jedoch ebenfalls über diese Namen verfügen.

Die permanente Richtlinie wird zuerst angewendet und mit der lokalen oder domänenbasierten IPSec-Richtlinie zusammengeführt. Daher muss die Anwendung der lokalen und der Domänenrichtlinie zuerst aufgehoben werden, um nur die permanenten Einstellungen anzeigen zu können. Verwenden Sie ipseccmd show all zum Anzeigen sämtlicher aktiven Richtlinien, einschließlich der permanenten Einstellungen, wenn der IPSec-Dienst gestartet wird.

Um sämtliche Objekte (Regeln, Filterlisten und Filteraktionen) zu löschen, die einer bestimmten permanenten Richtlinie zugewiesen sind, geben Sie den Namen der permanenten Richtlinie im folgenden Befehl an:

ipseccmd.exe -w PERS -p "policy name" –o

Die einfachste Möglichkeit sicherzustellen, dass sämtliche permanenten Richtlinien gelöscht werden, besteht darin, unter dem Schlüssel Persistent sämtliche Unterschlüssel zu löschen. Wenn Sie jedoch den Schlüssel Persistent selbst löschen, schlagen die Befehle "ipseccmd" fehl, wenn zu einem späteren Zeitpunkt versucht wird, eine permanente Richtlinie zu erstellen. Um Probleme durch beschädigte permanente Richtlinien und Richtlinienkonflikte zu beheben, löschen Sie alle Objekte im Speicher der permanenten Richtlinie, und führen Sie das Skript "ipseccmd" erneut aus, um die Richtlinien zu erstellen.

Unter Windows Server 2003 verfügt die permanente Richtlinie über vollständige Verwaltungsfunktionen, ähnlich der lokalen und domänenbasierten IPSec-Richtlinie. Die permanente Richtlinie wird unter demselben Registrierungsspeicherort wie oben angegeben gespeichert. Das folgende Befehlskript "Netsh" zeigt die konfigurierte permanente Richtlinie an, indem die Befehle in der Datei show_persistent.netsh verwendet werden:

    Netsh –f show_persistent.netsh 

Die Datei show_persistent.netsh ist eine Textdatei, die die folgenden Zeilen umfasst:

Pushd ipsec static
Set store persistent
show all
exit

Das folgende Befehlsskript "Netsh" kann verwendet werden, um sämtliche permanenten Richtlinien zu löschen:

pushd ipsec static
set store persistent
delete all
exit

Lokale IPSec-Richtlinie

Lokale IPSec-Richtlinien werden unter Windows 2000, Windows XP und Windows Server 2003 unterstützt und unter folgendem Registrierungsschlüssel gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local

Wenn eine Zuweisung einer lokalen Richtlinie erfolgt ist, wird die zugewiesene Richtlinie im Schlüssel wie folgt gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Local\ActivePolicy

Wenn keine Zuweisung einer Domänenrichtlinie erfolgt ist, wird die zugewiesene lokale Richtlinie zu einer konfigurierten permanenten Richtlinie als aktive Richtlinie hinzugefügt. Um eine erhebliche Vereinfachung der Problembehandlung zu erreichen, sollte die Bearbeitung von IPSec-Richtlinien, die über die Skripts "ipsecpol" oder "ipseccmd" erstellt werden, unter Verwendung des MMC-Snap-Ins für die IPSec-Richtlinienverwaltung erfolgen, um Filternamen für jeden Filter festzulegen, bevor diese in den Produktionsumgebungen eingesetzt werden. Es besteht auch die Möglichkeit, den Befehl netsh ipsec zum Erstellen der Richtlinie auf einem Computer unter Windows Server 2003 zu verwenden. Die Richtlinie kann dann in eine Datei exportiert werden, die wiederum auf Computer, auf denen Windows 2000 oder Windows XP ausgeführt wird, bzw. in eine Domäne importiert werden kann, nachdem die Richtlinie überprüft wurde.

Verwenden Sie unter Windows 2000 den Befehl netdiag /test:ipsec /debug zum Anzeigen der Zuweisungsinformationen und der Details zur aktiven Richtlinie. Das MMC-Snap-In für die IPSec-Richtlinienverwaltung oder die Registrierungstools sollten zum Löschen von IPSec-Richtlinienobjekten aus dem lokalen Speicher verwendet werden. Um ein erneutes Laden der zugewiesenen IPSec-Richtlinie zu erzwingen, beenden Sie den Dienst, und starten Sie ihn erneut.

Verwenden Sie unter Windows XP den Befehl ipseccmd show gpo oder die Befehle netdiag /test:ipsec zum Anzeigen der Zuweisungsinformationen und der Details zur aktiven Richtlinie. Verwenden Sie das MMC-Snap-In für die IPSec-Richtlinienverwaltung, Registrierungstools oder den Befehl
ipseccmd.exe -w REG -p "<policy_name>" –o zum Anzeigen der benannten IPSec-Richtlinie. Um alle lokalen Richtlinien schnell zu entfernen, löschen Sie alle Unterschlüssel am vorher angegebenen Speicherort.

Um ein erneutes Laden der Richtlinie durch den IPSec-Dienst zu erzwingen, beenden Sie den IPSec-Dienst, und starten Sie ihn erneut, oder heben Sie die Zuweisung der IPSec-Richtlinie auf, und führen Sie eine neue Zuweisung durch, indem Sie das MMC-Snap-In für die IPSec-Richtlinienverwaltung verwenden. Zum erneuten Laden der Richtlinie kann auch der Befehl sc policyagent control 130 verwendet werden. Wenn die Richtlinie erneut geladen wurde, wurden alle IPSec- und IKE-SAs gelöscht, was zu Konnektivitätsverzögerungen oder -unterbrechungen mit den Computern führen kann, die für die Übertragung und den Empfang von Datenverkehr IPSec-SAs aktiv verwendet haben.

Verwenden Sie unter Windows Server 2003 den Befehl
netsh ipsec static show gpoassignedpolicy bzw. das MMC-Snap-In für die IPSec-Richtlinienverwaltung oder den Knoten für den IPSec-Monitor der aktiven Richtlinie, um die derzeit zugewiesene lokale Richtlinie anzuzeigen.

Verwenden Sie den Befehl netsh ipsec dynamic show all zum Anzeigen der derzeit aktiven Richtlinienkonfiguration. IPSec-Monitor kann auch verwendet werden, um unterschiedliche Teile der aktiven Richtlinie zu untersuchen.

Verwenden Sie zum Löschen und erneuten Laden der lokalen Richtlinie unter Windows Server 2003 dieselben Befehle, die für Windows XP aufgeführt wurden. Der Befehl netsh ipsec kann zum Zuweisen, zum Aufheben der Zuweisung und zum Löschen von Richtlinien verwendet werden.

IPSec-Richtlinie in Active Directory

Diese Richtlinie wird unter Windows 2000, Windows XP und Windows Server 2003 unterstützt. Die zugewiesene domänenbasierte IPSec-Richtlinie wird in der lokalen Registrierung unter diesem Pfad gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\GPTIPSECPolicy

Der lokale Registrierungscache für die Domänenrichtlinie wird unter diesem Pfad gespeichert:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
IPSec\Policy\Cache

Die Verwaltung des Verzeichnisspeichers sollte über das MMC-Snap-In für die IPSec-Richtlinienverwaltung oder den Befehl "netsh ipsec" erfolgen, die als lokale Prozesse unter Verwendung von Active Directory ausgeführt werden. Es steht kein Tool zur Verfügung, über das der Inhalt des Cachespeichers direkt angezeigt werden kann. Dafür muss ein Registrierungstool verwendet werden, mit dem ermittelt wird, ob der Cachespeicher existiert und ob dieser die korrekten Inhalte enthält. Analog dazu werden Registrierungstools zum Löschen der Domänenrichtlinie verwendet, indem die Registrierungsschlüssel GPTIPsecPolicy und Cache gelöscht werden. Danach muss entweder der IPSec-Dienst neu gestartet werden, oder es muss der Dienststeuerungsbefehl verwendet werden, um zu erzwingen, dass eine IPSec-Richtlinie ohne die Domänenrichtlinie erneut geladen wird.

Um die domänenbasierte IPSec-Richtlinienzuweisung zu aktualisieren, die IPSec-Richtlinie erneut zu laden und die Cacheinhalte zu aktualisieren, verwenden Sie den Befehl gpudpate /force.

Um die Anwendung der Domänenrichtlinie auf den lokalen Computer temporär zu blockieren, können Sie die Berechtigungen für die beiden Registrierungsschlüssel GPTIPsecPolicy und Cache so konfigurieren, dass der Lesezugriff auf das lokale Systemkonto verweigert wird. Das MMC-Snap-In für den IPSec-Sicherheitsmonitor und die Befehlszeilenprogramme zeigen die Domänenrichtlinie als zugewiesen an, da diese Tools die GPTIPsecPolicy-Informationen lesen, die im Kontext des lokalen Administratorbenutzers ausgeführt werden. Für eine längerfristige Blockierung der domänenbasierten IPSec-Richtlinie muss der Computer am Lesen des entsprechenden GPOs in Active Directory gehindert werden.

Unter Windows 2000 können folgende Fehlermeldungen angezeigt werden, wenn Probleme mit der Richtlinie auftreten:

• Es wurde keine Bindung mit dem Active Directory-Schema hergestellt. Der Dienst "IPSec-Richtlinien-Agent" konnte keine Bindung für ein authentifiziertes LDAP mit dem Active Directory-IP-Sicherheitsrichtlinien-Container herstellen. Dieser Fehler wird wahrscheinlich durch eine fehlgeschlagene Anmeldung des Computerkontos und den Empfang von Kerberos-Anmeldeinformationen verursacht. Er kann darüber hinaus auftreten, wenn das Ausgeben des LDAP-Diensttickets an den IPSec-Richtlinien-Agenten durch das Kerberos-Protokoll fehlschlägt.
• Es wurde keine Bindung mit dem IPSec-Richtlinienspeicherobjekt hergestellt. Es wurde ein Objekt in der IPSec-Richtlinie definiert (wie eine Regel oder eine Filterliste), das derzeit nicht existiert. Es kann die IPSec-Richtlinie oder die Active Directory-Speicherrichtlinie beschädigt worden sein, oder das Objekt wurde eventuell gelöscht (obwohl bestehende IPSec-Richtlinien noch auf das Objekt verweisen). Untersuchen Sie die IPSec-Richtlinie, indem Sie das MMC-Snap-In für die IPSec-Richtlinienverwaltung verwenden, um zu überprüfen, ob alle Richtlinienregeln intakt erscheinen und ob die Eigenschaften Schlüsselaustausch (auf der Registerkarte Allgemein) korrekt angezeigt werden können.
• Der Domänencontroller wurde nicht gefunden. Stellen Sie sicher, dass der Computer Mitglied der Domäne ist und überprüfen Sie die Netzwerkfunktionalität. Das Speichermodul für die IPSec-Richtlinie konnte kein LDAP-Verzeichnis finden, von dem aus domänenbasierte IPSec-Richtlinien abgerufen werden können.
• Es konnte keine Kommunikation mit dem Verzeichnisdienst auf dem Domänencontroller aufgenommen werden. Wenden Sie sich an den Systemadministrator. Das IPSec-Speichermodul konnte keine erfolgreiche LDAP-Signatur und -Versiegelung zum Download der zugewiesenen IPSec-Richtlinie verwenden.
• Das Objekt wurde nicht im Speicher gefunden. Dieser Fehler ist in der Regel schwer wiegend, da die IPSec-Richtlinie nicht vollständig abgerufen werden kann und daher nicht korrekt funktioniert. Das Speichermodul der IPSec-Richtlinie konnte die GUID für das Objekt (Regel, Filterliste, Filteraktion oder ISAKMP-Einstellungen), das in der IPSec-Richtlinie oder einer der Regeln enthalten ist, nicht finden, indem entweder ein LDAP- oder ein Remoteregistrierungsaufruf verwendet wurde. Der Fehler kann eine der folgenden Ursachen haben:
  • Replikationsverzögerungen, bei denen das verweisende Objekt vor dem Objekt, auf das verwiesen wird, ankommt, oder Ankunft der Anfragen bei zwei unterschiedlichen Domänencontrollern.
  • Das Objekt wurde eventuell gelöscht, während es von der IPSec-Richtlinie verwendet wurde.
  • Das Objekt verfügt eventuell über Berechtigungen, die das Auflisten oder Lesen verhindern, oder der IPSec-Richtlinienspeicher wurde zu einem Zeitpunkt zurückgesetzt, als das Objekt noch nicht existierte.
  • Die beschädigte IPSec-Richtlinie verursacht eventuell eine ungültige GUID in der Anfrage.
  • Die Netzwerkadresse ist eventuell nicht für die IP-Zieladresse verfügbar.
  • Der LDAP- oder der Remoteregistrierungsdienst ist eventuell nicht verfügbar.
• Der angeforderte Vorgang konnte nicht abgeschlossen werden. Der Richtlinienspeicher ist nicht geöffnet. Der Speicher in Active Directory, auf dem Remotecomputer oder auf dem lokalen Computer kann nicht geöffnet werden. Der Fehler wird in der Regel durch einen Berechtigungs- oder Authentifizierungsfehler verursacht.
• Es wird die aktive Richtlinie der lokalen Registrierung verwendet, weil (a) keine Active Directory-Speicherrichtlinie verfügbar ist, oder (b) die Active Directory-Speicherrichtlinie nicht erfolgreich angewendet werden konnte, und keine zwischengespeicherte Richtlinie verfügbar ist. Dieses Ereignis gibt an, dass eine IPSec-Richtlinie auf dem Computer lokal definiert ist und dass die domänenbasierte Richtlinie nicht angewendet werden konnte, um diese zu überschreiben.
• Es wird keine IPSec-Richtlinie verwendet, weil (a) keine Active Directory-Speicher- oder aktive lokale Registrierungsrichtlinie verfügbar ist, oder (b) die Active Directory-Speicherrichtlinie nicht erfolgreich angewendet werden konnte und keine zwischengespeicherte Richtlinie oder aktive lokale Registrierungsrichtlinie verfügbar ist. Dieses Ereignis identifiziert einen Standardstatus, für den dem Computer keine Richtlinie zugewiesen ist.

Unter Windows XP und Windows Server 2003 geben die folgenden Ereignisse an, dass der IPSec-Dienst einen bestimmten Richtlinientyp nicht abrufen konnte. Wenn eine lokale Richtlinie nicht erfolgreich unter Windows Server 2003 und Windows XP SP2 gelesen werden kann, wird die Richtlinie ignoriert, und die nächste Richtlinie wird gemäß der Reihenfolge der Beständigkeit gelesen.

• PAStore-Modul konnte die permanente Speicher-IPSec-Richtlinie auf dem Computer für "<Richtlinienname>" nicht laden. Fehlercode: <Nummer>. Der IPSec-Dienst hat ermittelt, dass eine permanente Richtlinie zugewiesen und in der lokalen Registrierung gespeichert wurde, das Lesen der Inhalte von mindestens einem Objekt der permanenten Richtlinie ist jedoch fehlgeschlagen. Überprüfen Sie die Berechtigungen für alle Registrierungsschlüssel. Die Richtlinie wurde eventuell beschädigt. Versuchen Sie, alle permanenten Richtlinien zu löschen und diese dann erneut zu erstellen.
• PAStore-Modul konnte die lokale Speicher-IPSec-Richtlinie auf dem Computer für "<Richtlinienname>" nicht laden. Fehlercode: <Nummer>. Der IPSec-Dienst hat ermittelt, dass eine lokale Richtlinie zugewiesen wurde, und hat versucht, die Richtlinie zu lesen. Beim Lesen von mindestens einem der Objekte, die der zugewiesenen Richtlinie zugeordnet sind, ist jedoch ein Fehler aufgetreten. Überprüfen Sie die Berechtigungen für alle Registrierungsschlüssel. Die Richtlinie wurde eventuell beschädigt und muss gelöscht und anschließend erneut erstellt werden.
• PAStore-Modul konnte die Verzeichnisspeicher-IPSec-Richtlinie auf dem Computer für "<Richtlinienname>" nicht laden. Fehlercode: <Nummer>. Der IPSec-Dienst hat beim Lesen der zugewiesenen IPSec-Richtlinie von Active Directory mindestens einen Fehler festgestellt. Dieser Fehler wurde eventuell durch eine Unterbrechung der Netzwerkkonnektivität verursacht, bevor alle Richtlinienobjekte abgerufen wurden, bzw. durch fehlende IPSec-Richtlinienobjekte oder Objekte, für die keine Leseberechtigungen gewährt werden.
• Das Modul "PAStore" hat die Active Directory-IPSec-Richtlinie auf Änderungen überprüft und hat ermittelt, dass das Active Directory nicht verfügbar ist und hat daher die zwischengespeicherte Kopie der Active Directory-IPSec-Richtlinie verwendet. Sämtliche Änderungen seit der letzten Umfrage an die Active Directory-IPSec-Richtlinie konnten nicht angewendet werden. Diese Meldung weist lediglich darauf hin, dass der IPSec-Dienst bei einem regulären Umfrageintervall keine erfolgreiche Verbindung zu Active Directory herstellen konnte (da beispielsweise kein DNS-Dienst mehr vorhanden ist) und dass keine Änderungen an der aktiven IPSec-Richtlinie vorgenommen wurden. Ursprünglich bestand eine Verbindung zu Active Directory, als die aktive Richtlinie angewendet wurde, und der Dienst hat die neueste Version im Cachespeicher abgerufen und gespeichert. Daher wird der Registrierungscache der IPSec-Domänenrichtlinie vom IPSec-Dienst nun als vorrangige Quelle für die Richtlinien betrachtet. Beim Versuch, auf das Verzeichnis zuzugreifen, werden die Umfragen fortgesetzt.

Problembehandlung bei der Interpretation von IPSec-Richtlinien

Die Interpretation von IPSec-Richtlinien erfolgt, nachdem die gesamte Richtlinie erfolgreich vom entsprechenden Speicherort abgerufen wurde. Die aktuellen IP-Adressen der Netzwerkschnittstelle werden zum Erweitern der generischen Richtlinienfilter für spezifische Filter verwendet. Die Liste der spezifischen eingehenden und ausgehenden Filter wird dann in den IPSec-Treiber zur Paketverarbeitung geladen. Ereignisse zu Schnittstellenänderungen werden an den IPSec-Dienst ausgegeben, der gegebenenfalls so schnell wie möglich die IPSec-Filterkonfiguration anpasst (beispielsweise für die Filter "Eigene IP-Adresse").

Unter Windows 2000 können die folgenden Meldungen auf ein Problem mit einer korrekten Interpretation oder Konfiguration für die IPSec-Komponenten hinweisen, das das Ausführen der Richtlinie verhindert:

• Das Datentypattribut gibt ein unbekanntes Datenformat an. Ein Teil der IPSec-Richtlinie enthält ein Datenformat, das vom Speichermodul der Richtlinie nicht erkannt wird. Dieser Fehler weist auf eine beschädigte Richtlinie oder auf ein mögliches zukünftiges Richtlinienversionsproblem hin. IPSec-Richtlinienfunktionen unter Windows XP und Windows Server 2003 wurden so erstellt, dass sie für den IPSec-Richtlinien-Agenten unter Windows 2000 transparent sind.
• Daten des Abschnitts konnten nicht gelesen werden. Es wurde ein unerwartetes Datenformat für das IPSec-Attribut in einem IPSec-Richtlinienobjekt ermittelt. Dieser Fehler weist fast immer auf eine beschädigte Richtlinie oder auf ein Versionsproblem hin. Dieser Fehler muss behoben werden, bevor alle IPSec-Richtlinieneinstellungen wie beabsichtigt erfolgreich angewendet werden können.
• Es ist keine Schnittstellenliste für den Richtlinien-Agenten vorhanden. Der IPSec-Richtlinien-Agent konnte keine zu filternden IP-Netzwerkschnittstellen finden. Beachten Sie, dass dieser Fehlermeldungstext direkt aus dem Windows-Quellcode stammt und wie hier angegeben angezeigt wird.
• Das öffentliche IP-Hilfs-API konnte die Schnittstellentabelle nicht ermitteln. Schnittstellenbasierte Filter werden nicht expandiert und dem IPSec-Treiber nicht hinzugefügt. Es ist ein Fehler bei dem Versuch des IPSec-Richtlinien-Agenten aufgetreten, die Schnittstellenliste auf dem Computer aufzulisten. Es sind eventuell keine Netzwerkschnittstellen vorhanden, oder es ist ein interner Fehler innerhalb des Netzwerkschnittstellenmanagers aufgetreten. Ursachen können Geräte, die nicht vollständig PnP-konform sind, beschädigte Dateien oder Probleme innerhalb des Netzwerkkartentreibers oder mit den zugehörigen Windows-Netzwerkkomponenten sein. IPSec-Filter, die auf dem Schnittstellentyp basieren, wie die in einer Regel für einen bestimmten Verbindungstyp (beispielsweise für Remotezugriff) statt für alle Verbindungen konfigurierte Filter, können ebenfalls zu diesem Fehler führen. Wenn das Problem nach einem Neustart weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.
• Das öffentliche IP-Hilfs-API konnte die IP-Adressentabelle nicht ermitteln. Schnittstellenbasierte Filter werden nicht expandiert und dem IPSec-Treiber nicht hinzugefügt. Es ist ein Fehler bei dem Versuch des IPSec-Richtlinien-Agenten aufgetreten, alle IP-Adressen auf dem Computer über einen Funktionsaufruf in der IP-Hilfs-API aufzulisten. Es ist eventuell keine IP-Adresse konfiguriert, oder es bestehen unter Umständen ähnliche Probleme wie oben aufgeführt.
• Der IP-Adresseneintrag wurde in der Schnittstellentabelle nicht gefunden. Die IP-Adresse wird verworfen. Der IPSec-Richtlinien-Agent bestätigt, dass alle IP-Adressen in der Liste der Netzwerkschnittstellen aufgeführt werden. Dieses Problem kann durch kurzzeitige Schwierigkeiten verursacht werden, die beim Hinzufügen oder Entfernen einer Netzwerkschnittstelle auftreten. Die Meldung gibt an, dass der IPSec-Dienst keine spezifischen Filter für diese verworfene IP-Adresse bezüglich generischer Filter für die "Eigene IP-Adresse" in der Richtlinie erstellt. Dies kann dazu führen, dass ein temporäres unerwartetes Konnektivitätsverhalten beim Verwenden dieser IP-Adresse angezeigt wird. Andernfalls weist dieser Fehler auf ein Problem mit dem internen Status der IP-Schnittstellenkonfiguration hin, das eventuell eine genauere Untersuchung durch die Microsoft Product Support Services erfordert. Da die IP-Adresse vom IP-Sec-Richtlinien-Agenten (und nicht vom TCP/IP-Stapel) verworfen wird, werden keine IPSec-Filter für diese IP-Adresse erstellt. Daher werden für den Datenverkehr, der diese IP-Adresse verwendet, keine Sicherheitsaktionen (wie "Zulassen" oder "Blockieren") und keine Verhandlung der IPSec-SAs für Datenverkehr durchgeführt.
• In der Filterliste befindet sich ein übereinstimmender, gespiegelter Filter. Dieser Fehler weist auf doppelte Filterbedingungen in der IPSec-Richtlinie hin. Es ist eine Analyse der IPSec-Richtlinie erforderlich, um sicherzustellen, dass keine spezifischen Filter für den Schnellmodus in eingehender und ausgehender Richtung doppelt vorhanden sind.
• Der Hauptfilterliste wurden keine Filter hinzugefügt. Der IPSec-Richtlinien-Agent hat keine Filter in der IPSec-Richtlinie gefunden, die vom Speicher abgerufen wurde. Die IPSec-Richtlinie enthält eventuell nur die Standardantwortregel, oder es sind Fehler beim Lesen der Regeln oder Filterlisten aufgetreten.
• Keine Angebote von Phase 1. Die ISAKMP-Richtlinie wird verworfen. Die IPSec-Richtlinie ist wahrscheinlich beschädigt, wenn keine IKE-Sicherheitsmethoden für den Hauptmodus (ISAKMP-Richtlinienobjekte) gefunden wurden.
• Keine Angebote von Phase 2. Die Verhandlungsrichtlinie wird verworfen. Ohne Filteraktionssicherheitsmethoden (Angebote des IKE-Schnellmodus von Phase 2), schlagen die IKE-Verhandlungen im Schnellmodus für den Datenverkehr fehl, für den eine Übereinstimmung der zugehörigen Filter besteht. Die IPSec-Richtlinie ist wahrscheinlich beschädigt.
• Die Richtlinie enthält keine gültigen Ausdrücke. Die IPSec-Richtlinie enthält keine gültigen Sicherheitsmethoden in der Filteraktion einer Regel, oder sie enthält keine Einstellungen für den IKE-Hauptmodus (Einstellungen "Schlüsselaustausch" auf der Registerkarte "Allgemein").
• Es wurde versucht durch den Richtlinien-Agenten einen vorhandenen Filter in IPSEC einzufügen. Der IPSec-Treiber hat zwei identische Filter festgestellt und verwirft das Duplikat. Diese Situation ist eventuell unkritisch, wenn das Filterduplikat dieselbe Aktion ausführen soll wie die, die bereits vom IPSec-Treiber ausgeführt wurde. Wenn es sich jedoch um unterschiedliche Filteraktionen handelt, besteht eine nicht unterstützte IPSec-Richtlinienerstellung. Die Resultate daraus können nach Ablauf einer bestimmten Zeitdauer variieren und hängen von der Reihenfolge ab, in der die Richtlinienänderungen verarbeitet werden. Die IPSec-Richtlinie muss so erstellt werden, dass doppelte Filter vermieden werden.
• Ein Eintrag konnte nicht der IPSEC-Richtlinientabelle hinzugefügt werden. Es konnte kein neuer Filter zum IPSec-Treiber durch den IPSec-Richtlinien-Agent hinzugefügt werden. Dieser Fehler weist darauf hin, dass der gesamte Datenverkehr, für den eine Übereinstimmung mit diesem Filter besteht, nicht gesichert wird. Dieser Fehler kann durch Kernel-Speichermangel verursacht werden. Wenn der Fehler weiterhin besteht, wenden Sie sich an die Microsoft Product Support Services.
• Der Richtlinien-Agent konnte einen Filter in IPSEC nicht einfügen oder aktualisieren. Wie in der vorherigen Meldung zum Hinzufügen eines Filters, entspricht die Filterliste im IPSec-Treiber nicht den Anforderungen der zugewiesenen IPSec-Richtlinie. Daher wird nicht die gewünschte Sicherheit gewährleistet.
• Es wurde eine zwischengespeicherte Richtlinie verwendet, da die Active Directory-Speicherrichtlinie nicht erfolgreich angewendet werden konnte (keine verfügbare Netzwerkverbindung, ungültige Richtlinienintegrität, usw.). Wenn eine domänenbasierte IPSec-Richtlinie zugewiesen wurde, versucht der IPSec-Richtlinien-Agent zuerst, die neueste Richtlinie aus Active Directory zu lesen. Diese Meldung gibt an, dass die IPSec-Richtlinie nicht aus dem Verzeichnis abgerufen werden konnte und daher die Richtlinie von der letzten Domänenrichtlinie angewendet wird, die sich in der Registrierung im Cachespeicher befindet.

Unter Windows Server 2003 weisen die folgenden Ereignisse auf ein mögliches Problem beim Interpretieren von IPSec-Richtlinien hin. In den meisten Fällen, wird unter Windows XP derselbe Ereignistext verwendet. Diese Störungen müssen behoben werden, damit die IPSec-Richtlinienfunktion korrekt ausgeführt werden kann.

• PAStore-Modul konnte die permanente Speicher-IPSec-Richtlinie auf dem Computer für "<Richtlinienname>" nicht anwenden. Fehlercode: <Nummer>. Der IPSec-Dienst hat ermittelt, dass permanente Richtlinien in der Registrierung konfiguriert sind, konnte diese jedoch nicht alle erfolgreich anwenden. Alle permanenten Richtlinien, die bereits angewendet wurden, werden entfernt, und der IPSec-Treiber wird mittels Programmcode auf dem Blockierungsmodus (mit Bootzeitausnahmen) eingestellt, wie in einer getrennten Meldung angegeben.
• Das Modul "PAStore" konnte die IPSec-Richtlinie des lokalen Registrierungsspeichers auf dem Computer für "<Richtlinienname>" nicht anwenden. Fehlercode: <Nummer>. Diese Meldung weist darauf hin, dass der Dienst mindestens einen Fehler beim Anwenden der lokalen IPSec-Richtlinie von der lokalen Registrierung festgestellt hat. Diese Meldung kann ein Hinweis darauf sein, dass die Richtlinie beschädigt oder Berechtigungen nicht korrekt sind.
• Das Modul "PAStore" konnte die IPSec-Richtlinie des Active Directory-Speichers auf dem Computer für DN "<CN=ipsecPolicy{GUID}" nicht anwenden. Fehlercode:<Nummer>. Der IPSec-Dienst hat eine Domänenrichtlinie gefunden, die vom DN im Registrierungsschlüssel GPTIPsecPolicy angegeben ist, konnte diese jedoch nicht anwenden. Diese Meldung dient zur Information und ist häufig ein Hinweis darauf, dass der Domänencontroller nicht für mobile Clients erreichbar ist; auf diese Meldung muss eine erfolgreiche Anwendung einer Richtlinie aus dem Cachespeicher erfolgen (sofern vorhanden). Diese Meldung kann jedoch auch darauf hinweisen, dass ein GPO eine IPSec-Richtlinie bereitstellt, die nicht existiert oder nicht gelesen werden kann, oder dass die Richtlinie beschädigt ist.
• Das Modul "PAStore" konnte die lokal zwischengespeicherte Kopie der IPSec-Richtlinie des Active Directory-Speichers auf dem Computer für "<Richtlinienname>" nicht anwenden. Fehlercode:<Nummer>. Diese Meldung weist darauf hin, dass der IPSec-Dienst über Informationen darüber verfügt, dass eine Domänenrichtlinie zugewiesen werden soll, und dass das Anwenden der Richtlinie, die von Active Directory abgerufen wurde, fehlgeschlagen ist. Nun wurde mindestens ein Fehler beim Anwenden der Kopie im Cachespeicher der zugewiesenen Richtlinie von der lokalen Registrierung festgestellt. Dieser Fehler kann ein Hinweis darauf sein, dass der Cachespeicher beschädigt ist oder fehlerhafte Berechtigungen vorlagen. Diese Situation ist schwer wiegend, da keine der domänenbasierten Richtlinien angewendet werden können, was meist zu Beeinträchtigungen der Konnektivität mit anderen Isolierungsdomänenmitgliedern führt. Die lokale Richtlinie (sofern festgelegt) ist dann die nächste in der Prioritätsreihenfolge.
• Das Modul "PAStore" konnte einige Regeln der aktiven IPSec-Richtlinie "<Richtlinienname>" auf dem Computer nicht anwenden. Fehlercode: <Nummer>. Führen Sie das IPSec-Monitor-Snap-In aus, um weiter Fehlerinformationen anzuzeigen. Dieses Problem tritt in der Regel zusammen mit anderen hier erläuterten Problemen auf, beispielsweise beim Fehlen von Sicherheitsmethoden für den Schnellmodus (Angebote).
• Die IPSec-Dienste konnten die vollständige Liste der Netzwerkschnittstellen auf diesem Computer nicht ermitteln. Dies kann die Sicherheit des Computers stark beeinträchtigen, da die Schutzfunktionen des IPSec-Filters auf einigen Netzwerkschnittstellen nicht angewendet werden können. Führen Sie das IP-Sicherheitsmonitor-Snap-In aus, um weitere Fehlerinformationen anzuzeigen. Diese Meldung ersetzt mehrere IP-Hilfs-API-Meldungen, die unter Windows 2000 verwendet wurden. Dieser Fehler ist unkritisch, wenn Schnittstellen hinzugefügt oder entfernt werden oder wenn der Verbindungsstatus geändert wird, wenn sich beispielsweise ein drahtloses Netzwerk nicht mehr in der gültigen Reichweite befindet. Er ist ebenfalls dann unkritisch, wenn er während der Wiederaufnahme des normalen Modus nach einen Betrieb im Standby- oder Ruhezustandsmodus auftritt und eine andere Netzwerkschnittstellenkonfiguration während dieser Wiederaufnahme ermittelt wird.

Richtlinienkonfigurationsprobleme mit RRAS-VPN

Wie weiter oben in diesem Kapitel für den Support der Ebene 1 erläutert, ist der RRAS-Dienst in einigen Organisationen eine häufige Ursache für IPSec-Richtlinienkonflikte. Dieser Abschnitt erläutert, warum die integrierte IPSec-Richtlinie für L2TP/IPSec-VPN-Server zu einem Konflikt mit der in dieser Lösung verwendeten Domänenrichtlinie führt. Diese Situation ist ein Beispiel für ein durch doppelte Filter verursachtes Problem.

Im folgenden Szenario werden die für das Fallbeispiel der Woodgrove Bank eingerichteten IPSec-Richtlinien verwendet, um die Probleme zu veranschaulichen. Diese Prinzipien können jedoch auf viele unternehmensweite IPSec-Umgebungen zutreffen.

Die IPSec-Richtlinie für L2TP/IPSec-Server wird automatisch vom RAS-Verwaltungs-Dienst (RASMAN) erstellt und umfasst die folgenden Filter:

• Von "Beliebige IP-Adresse" zu "Eigene IP-Adresse", UDP, Quelle 1701, Ziel "Beliebig" (eingehend)

• Von "Eigene IP-Adresse" zu "Beliebige IP-Adresse", UDP, Quelle "Beliebig", Ziel 1701 (ausgehend)

  Hinweis

  
  Weitere Informationen zu dieser Richtlinie finden Sie im Knowledge Base-Artikel 248750, "Beschreibung der für L2TP/IPSec erstellten IPSec-Richtlinie" unter https://support.microsoft.com/?kbid=248750.
  

Daher ist der für den Hauptmodus spezifische Filter, der die Antwort der IKE-Verhandlung für diesen Server steuert, der Adressteil des eingehenden Filters:

• Von "Beliebige IP-Adresse" zu "Eigene IP-Adresse" -> Zertifikatauthentifizierung

Beachten Sie, dass die Verwendung von "Eigene IP-Adresse" dazu führt, dass der eingehende Filter für alle IP-Adressen auf dem VPN-Server erweitert wird. Wenn der VPN-Server über eine externe IP-Adresse für die Internetkonnektivität und eine interne Schnittstelle für die LAN-Konnektivität verfügt, sind die IKE-spezifischen Filter für den Hauptmodus folgende:

• Von "Beliebige IP-Adresse" zu <IP-Adresse der externen Schnittstelle> -> Zertifikatauthentifizierung
• Von "Beliebige IP-Adresse" zu <IP-Adresse der internen LAN-Schnittstelle> -> Zertifikatauthentifizierung

Der zweite Filter, der für die interne LAN-Schnittstelle verwendet wird, ist spezifischer als der eingehende Filter für den Server- und Domänenisolierungs-IKE-Modus. Dieser lautet wie folgt:

• Von "Beliebige IP-Adresse" zu Subnetz -> Kerberos-Authentifizierung

Wenn ein also Administrator einen vertrauenswürdigen Client für die Verwaltung des VPN-Servers verwendet, wird er IKE mit der internen IP-Adresse des VPN-Servers initiieren. Das eingehende IKE-Richtlinien-Lookup stimmt mit dem spezifischeren Hauptmodusfilter überein und berücksichtigt die IKE-Hauptmoduseinstellungen für L2TP. Für diese Lösung wurde eine Zertifikatauthentifizierung statt der Kerberos-Authentifizierung verwendet.

Ein weiterer Konflikt kann dann auftreten, wenn der Internet-VPN-Client die Quarantänefunktionen des Verbindungs-Managers verwendet. Der Quarantäneclient muss einen "Quarantäneschlüssel" an die interne LAN-IP-Adresse des VPN-Servers weiterleiten, um die Quarantäne zu beenden und wieder einen vollständigen VPN-Zugriff auf das Netzwerk zu erlangen. In diesem Szenario wird die Domänen-IPSec-Richtlinie des VPN-Clients vom Cachespeicher angewendet, sobald der Laptop gestartet wird. Wenn die VPN-Quarantäneverbindung erfolgreich hergestellt wurde, wird dem VPN-Client eine interne IP-Adresse zugewiesen. Die interne IP-Adresse des Clients wird durch einen der Subnetzfilter abgedeckt ("Beliebig <-> Internes Subnetz"), der in der Domänenisolierungs-IPSec-Richtlinie definiert ist. Dieser Filter ist erforderlich, damit die VPN-Clients über einen IPSec-authentifizierten End-to-End-Zugriff über den VPN-Tunnel auf interne Server und andere erforderliche Arbeitsstationen verfügen.

Die Subnetzfilter in dieser Lösung initiieren jedoch eine IKE-Verhandlung von der internen IP-Adresse der virtuellen Schnittstelle des Client-VPN-Tunnels zur internen LAN-Schnittstelle des VPN-Servers. Der IKE-Hauptmodus schlägt fehl, da der Server antwortet, dass nur die Zertifikatauthentifizierung akzeptiert wird, die nicht mit der für die Domänen- und Serverisolierung verwendeten Richtlinie kompatibel ist. Auch wenn die Richtlinie eine Zertifikatauthentifizierung zugelassen hat, schlägt der IKE-Schnellmodus des Clients den Filter für den gesamten Datenverkehr vor, und die Verhandlung schlägt in diesem Fall für den VPN-Server fehl, da der vorgeschlagene Filter zu allgemein ist. Der VPN-Server akzeptiert nur Schnellmodusfilter, die für L2TP spezifisch sind: UDP-Quelle 1701, Ziel "Beliebig" oder UDP-Quelle 1701, Ziel 1701.

Die folgenden Maßnahmen können zum Lösen eines Konflikts zwischen der RRAS-Server-L2TP/IPSec-Richtlinie und der Isolierungsrichtlinie verwendet werden:

• Schließen Sie die internen LAN-IP-Adressen des RRAS-Servers in die Ausnahmeliste ein.

• Deaktivieren Sie die L2TP-Ports auf den VPN-Servern. Verwenden Sie ausschließlich PPTP.

• Deaktivieren Sie die automatische IPSec-Richtlinie für L2TP, indem Sie den Registrierungsschlüssel ProhibitIPsec für RASMAN verwenden. Passen Sie die IPSec-Richtlinienkonfiguration für L2TP so an, dass ausschließlich die externe IP-Adresse für die Zertifikatauthentifizierung für UDP 1701-Datenverkehr und nur die Kerberos-Authentifizierung für den gesamten Datenverkehr für die Domänenisolierung über die interne IP-Adresse verwendet wird.

  Hinweis

  
  Informationen zu dieser Konfiguration finden Sie im Knowledge Base-Artikel 240262, Konfiguration: L2TP/IPSec-Verbindungen mit vorinstall. Schlüssel, unter https://support.microsoft.com/kb/240262.
  

Die einfachste Lösung in dieser Liste ist die erste Lösung. Sie nimmt die interne Netzwerkkarte des RRAS-Servers von der Verwendung von IPSec aus.

Problembehandlung für IKE

IKE und IPSec schlagen meist bei der ersten Bereitstellung fehl, da die Netzwerkfilterfunktion keine UDP 500- oder IPSec-Protokollpakete zulässt. Daher kann es sinnvoll sein, eine statische IP-Arbeitsstation oder einen statischen IP-Server für Testzwecke einzurichten, der bzw. dem eine einfache Richtlinie zugewiesen ist, etwa eine vordefinierte Beispiel-Serverrichtlinie (Anforderung), die einen vorinstallierten Schlüssel verwendet. Es ist eine Überwachung erforderlich, um IKE-Überwachungsereignisse zu erfassen. Eine Standarddomänen-IPSec-Richtlinie wurde für alle Domänenmitglieder bereitgestellt, die Authentifizierungen mit demselben vorinstallierten Schlüssel durchführt und eine Regel mit einem Filter für den gesamten Datenverkehr (einschließlich ICMP) für die Überprüfung der IP-Adresse des Computers enthält.

Das Domänenanmeldeskript wird dann bereitgestellt, um einen Ping-Vorgang an <testserver> oder
nbtstat –n *<testserver>*auszuführen, wodurch die IKE-Verhandlung von allen Domänenmitgliedern ausgelöst wird, um den Server zu überprüfen. Indem die IP-Adressen in der Erfolgsüberswachung des IKE-Hauptmodus analysiert und zusammengefasst werden, können Sie ermitteln, ob alle Computer Richtlinien empfangen können, und überprüfen, ob alle Bereiche Ihres Netzwerks auf den Testcomputer unter Verwendung von IKE und IPSec-Protokollen zugreifen können.

Eine erweiterte Überprüfung stellt sicher, dass die IPSec-Kapselung mit der Fragmentierung für jeden Bereich des Netzwerks funktioniert, indem ping –l 5000 <IP address> vom Testserver für die Computer verwendet wird, die sich in den einzelnen Bereichen befinden. Die Option " l 5000" bewirkt, dass der Ping-Vorgang ein 5000-Byte-ICMP-Paket als Nutzlast erstellt. Dieses vollständige IP-Paket wird vom IPSec-Protokoll gekapselt und dann durch die IP-Schicht fragmentiert, bevor es über die Verbindung gesendet wird. Alle Fragmente müssen am Ziel empfangen werden, und eine Antwort, die aus derselben Anzahl an Fragmenten besteht, wird zurückgesendet. Erfahrungsgemäß treten Probleme beim Durchlass von Fragmenten bei Geräten auf, die überlastet sind oder die als Grenze zwischen Netzwerken mit unterschiedlichen Geschwindigkeiten (beispielsweise zwischen 1-Gigabit- und 100-Megabit-Ethernet) dienen. Ebenso erfordern Hosts, die sich in verschiedenen MTU-Verbindungen befinden (wie asynchroner Übertragungsmodus (Asynchronous Transfer Mode, ATM), FDDI (Fiber Distributed Data Interface) und Token Ring) ICMP-PMTU-Meldungen, um den Netzwerkpfad MTU für IPSec-geschützte TCP-Pakete ermitteln zu können. Informationen zu verschiedenen Netzwerk-MTU-Standards finden Sie im Knowledge Base-Artikel 314496, "MTU-Standardgröße für verschiedene Netzwerktopologien" unter https://support.microsoft.com/kb/314496.

Problembehandlung für die IKE-Verhandlung

Die Problembehandlung für IKE kann Schwierigkeiten bereiten, da Fehler eventuell nur unter bestimmten Bedingungen auftreten, wie beispielsweise dann, wenn der IKE-Schnellmodus von einem Computer aus initiiert wird, der meistens als Responder fungiert. Fehler können auch durch fehlgeschlagene Vorgänge im Authentifizierungssystem auftreten, wie bei Kerberos-Protokollfehlern, oder dann, wenn eine nicht kompatible Richtlinienerstellung oder eine bereits bestehende Richtlinie mit der Domänenrichtlinie zusammengeführt wird. IKE-Fehler führen dazu, dass der Computer, bei dem der Fehler auftritt, nicht mehr an der IKE-Verhandlung teilnehmen kann; bei dem anderen Computer, mit dem die Verhandlung ausgeführt wird, wird dann meist der Grenzwert für alle neuen Verhandlungsversuche und die Zeitüberschreitung erreicht. Wenn IKE fehlschlägt, versuchen Sie, den Fehler zu untersuchen und Protokolle zu erfassen, ohne Änderungen vorzunehmen. Eine standardmäßige Überwachung kann dynamisch aktiviert werden, ohne Änderungen an der IPSec-Konfiguration oder am derzeitigen Status des Dienstes vorzunehmen. Unter Windows 2000 ist jedoch ein Neustart des IPSec-Dienstes erforderlich, um die detaillierte IKE-Protokollierung in der Datei Oakley.log zu aktivieren, unter Windows XP SP2 und Windows Server 2003 kann die IKE-Protokollierung über die Befehlszeile aktiviert und deaktiviert werden, falls erforderlich.

In einigen Fällen kann es erforderlich sein, den IPSec-Dienst zu beenden und erneut zu starten, um den Netzwerkdatenverkehr zu überprüfen und die Ergebnisse in einer leeren Datei Oakley.log zu erfassen. Wenn der IPSec-Dienst manuell oder in Verbindung mit einem Neustart oder dem Herunterfahren eines Computers beendet wird, versucht IKE Meldungen zum Löschvorgang zu senden, um den IPSec-SA-Status auf allen Peers zu bereinigen, für die derzeit eine aktive Verbindung besteht. Es kann vorkommen, dass das Betriebssystem die Möglichkeit zum Senden von Paketen deaktiviert, bevor IKE das Senden von Meldungen zum Löschvorgang an alle aktiven Peers abgeschlossen hat. Das führt dazu, dass der IPSec-SA-Status auf dem Peer aktiviert bleibt. In diesem Fall geht der Peer davon aus, dass eine sichere Verbindung zu dem Computer besteht, der gestartet wird. Wenn der Computer nach dem Neustart keine neue IKE-Verhandlung mit dem zugehörigen Peer initiiert, muss der Peer fünf Minuten lang auf das Überschreiten des Zeitlimits der IPSec-SAs warten, bevor versucht werden kann, die IPSec-SAs erneut zu erstellen. Um SAs erneut zu erstellen, muss zunächst eine Minute lang versucht werden, eine Schnellmodusverhandlung auszuführen, bevor die Initiierung des IKE-Hauptmodus erfolgt.

Für die IKE-Protokollierungsfunktion wurden seit Windows 2000 mit jeder Version Verbesserungen vorgenommen. Die in diesem Abschnitt dokumentierten Ereignisse gelten für Windows XP und Windows Server 2003, die Ereignisse unter Windows 2000 sind jedoch ähnlich.

Der empfohlene Ausgangspunkt für den Versuch, die Ursache für eine fehlgeschlagene IKE-Verhandlung zu ermitteln, ist das Windows-Sicherheitsprotokoll. Um IKE-Ereignisse anzuzeigen, muss eine Überwachung auf eine erfolgreiche oder fehlgeschlagene Ausführung der Einstellung für die Gruppensicherheitsrichtlinien "Anmeldeereignisse überwachen" aktiviert werden. Nachdem die Überwachung aktiviert ist, erstellt der IKE-Dienst Überwachungseinträge und stellt eine Erläuterung dazu bereit, warum die Verhandlung fehlgeschlagen ist. Die Erläuterung bezüglich der fehlgeschlagenen IKE-Verhandlungen wird in der Regel als Ereignisfehler 547 angegeben, und dieser Fehlermeldung können mehrere mögliche Ursachen zugrunde liegen. Die Liste der Ereignisfehler 547 und möglichen Ursachen werden genauer in den folgenden Abschnitten erläutert.

Unter Windows XP SP2 und Windows Server 2003 können alle IKE-Überwachungen über einen Registrierungsschlüssel DisableIKEAudits deaktiviert werden. Stellen Sie sicher, dass dieser Wert auf allen Computern überprüft wird, die untersucht werden sollen. IKE-Überwachungen können deaktiviert werden, wenn die IKE-Überwachung so viele Erfolgs- oder Fehlerereignisse generiert, dass andere Anmelde-/Abmeldeereignisse nicht mehr korrekt überwacht werden können.

Berichte zu Fehlercodewerten werden häufig in IKE-Überwachungsereignissen und Protokolldetails erstellt. Erläuterungen dieser Fehlercodes sind in englischer Sprache über Microsoft MSDN® auf der Seite System Code Errors (12000-15999) unter dieser Adresse verfügbar: https://msdn.microsoft.com/library/en-us/debug/base/system\_error\_codes\_\_12000-15999\_.asp.

Eine Problembehandlung für die IKE-Verhandlung erfordert umfassende Kenntnisse über das erwartete Verhalten der erstellten IPSec-Richtlinie, über den IKE-Verhandlungsprozess und IKE-Fehlerereignisse. Dieser Abschnitt versucht, Erläuterungen zu den häufigsten Ereignissen in Verbindung mit dem Domänenisolierungsszenario der Woodgrove Bank zu bieten. Es werden nicht alle IKE-Überwachungsereignisse oder Fehlerbedingungen behandelt.

Nachdem umfassende Informationen zum IKE-Verhandlungsprozess gesammelt und ausgewertet wurden, muss eine Netzwerkverfolgung von mindestens einer Seite der Kommunikation erfolgen (sofern möglich), um Probleme innerhalb von IKE zu identifizieren, bevor versucht wird, eine Oakley.log-Datei zu erhalten. Server, die in server- und domänenbasierten Szenarien bereitgestellt werden, sollten in der Lage sein, eine Verfolgung über den Netzwerkmonitor zu erfassen.

Die Datei Oakley.log ermöglicht die detailgenaueste verfügbare Protokollierfunktion und kann von beiden Seiten der Verhandlung (mit Synchronisierungszeiten) erforderlich sein. Eine Aktivierung dieses Protokolls kann jedoch die IKE-Verhandlung verzögern, wodurch die zeitlichen Bedingungen beeinflusst werden und eventuell alle bestehenden Statuseinstufungen verloren gehen können, wenn der Dienst erneut gestartet und der Registrierungsschlüssel erneut gelesen wird (erforderlich unter Windows 2000 und Windows XP SP1). Derzeit ist keine veröffentlichte Anleitung zur Interpretation der Datei Oakley.log verfügbar. Im Rahmen dieses Leitfadens wird eine solche Interpretation den Aufgaben von Ebene 3 zugeteilt. Aus Platzgründen werden hier nur kurze Auszüge von Protokolldetails für nur einige wenige Fehler angegeben. Wenn Sie Unterstützung bei der Interpretation der Datei Oakley.log benötigen, wenden Sie sich an den Microsoft Product Support.

Es werden die folgenden vier detaillierten Protokolldateien für IKE verwaltet:

• Oakley.log. Derzeitiges Protokoll für IKE, beschränkt auf 50.000 Zeilen.
• Oakley.log.bak. Nachdem in der Datei Oakley.log 50.000 Zeilen erstellt wurden, wird diese Datei erstellt und eine neue, leere Datei Oakley.log gestartet. Diese Datei wird im weiteren Verlauf weiterhin von der neueren Datei Oakley.log überschrieben, solange der IPSec-Dienst ausgeführt wird.
• Oakley.log.sav. Die vorherige Datei Oakley.log wird unter diesem Namen gespeichert, wenn der IPSec-Dienst gestartet wird.
• Oakley.log.bak.sav. Die vorherige Datei Oakley.log.bak wird unter diesem Namen gespeichert, wenn der IPSec-Dienst gestartet wird.

Ein häufiger Fehler während der Problembehandlung besteht in einer fehlenden Synchronisierung der Zeit für die beiden Computer, während der die Protokollierung und die Netzwerkverfolgung erfasst wird. Dadurch wird die Abstimmung der Protokolle schwieriger, jedoch nicht unmöglich. Die Abstimmung der IKE-Meldungen für Pakete in einer Netzwerkverfolgung erfordert eine gegenseitige Überprüfung unter Verwendung der Cookies des ISAKMP-Headers und den ID-Feldern der IKE-Schnellmodusmeldung.

Erwartetes IKE-Verhalten

Wenn die Initialisierung des IKE-Hauptmodus vom Netzwerk blockiert wird, so dass die gewünschte Ziel-IP-Adresse nicht erreicht werden kann, kann keine Verhandlung einer durch IPSec gesicherten Kommunikation erfolgen. Wenn der Initiator nicht so konfiguriert ist, dass ein Zurückgreifen auf eine unsichere Verbindung möglich ist, wird das Fehlschlagen des Zugriffs auf das Ziel im Sicherheitsprotokoll als Überwachungsereignis 547 mit einem der folgenden Texteinträgen angezeigt:

• Peer antwortet nicht
• Verhandlung hat Zeitlimit überschritten
• IKE-Sicherheitszuordnung wurde gelöscht, bevor Herstellung abgeschossen war

Für Domänenisolierungsclients wird diese Bedingung eventuell jedoch nicht als Fehler angezeigt, wenn die zugehörige Richtlinie das Zurückgreifen auf eine unsichere Verbindung zulässt. Es wird ein Ereignis 541 zu einem erfolgreichen IKE-Hauptmodus erstellt, wenn eine schwache SA hergestellt wurde. Das Ereignis 541, das eine schwache SA anzeigt, weist darauf hin, dass die ausgehende SPI den Wert Null aufweist und alle Algorithmen als "None" angezeigt werden. Das folgende Beispiel zeigt, wie diese Parameter in einem Ereignis 541 dargestellt werden:

ESP Algorithm None
HMAC Algorithm None
AH Algorithm None
Encapsulation None
InboundSpi 31311481 (0x1ddc679)
OutBoundSpi 0 (0x0)
Lifetime (sec) <whatever is configured for QM lifetime>
Lifetime (kb) 0

Es treten Verbindungsverzögerungen von einer Minute auf, wenn zwei Computer in Bezug auf einen bestehenden, aktiven IKE-Hauptmodus zwischen den beiden Geräten nicht mehr synchronisiert sind. Es können Verzögerungen von fünf Minuten auftreten, wenn ein Computer davon ausgeht, dass ein aktives IPSec-SA-Paar zwischen beiden Geräten besteht und der andere Computer (beispielsweise ein Server) diese SAs gelöscht hat und keinen erneuten Schlüsselaustausch im Schnellmodus initiiert. Unter Windows 2000 hat IKE einzelne Meldungen zum Löschvorgang unterstützt, die manchmal verloren gingen. Unter Windows XP und Windows Server 2003 wurde eine Funktion hinzugefügt, die ein "zuverlässiges" Löschen unterstützt, so dass mehrere Meldungen zum Löschvorgang als Sicherheitsmaßnahme gegen entfernte Pakete erstellt werden.

Das häufigste Szenario ist eine Situation, in der ein Laptopbenutzer in einer Domänenisolierung seinen Laptop aus einer Dockingstation entfernt, um an einem Meeting teilzunehmen. Die Dockingstation verfügt über eine drahtgebundene Ethernetverbindung, und beim Entfernen erfordert diese Netzwerkschnittstelle das Löschen aller Filter, die dieser Schnittstelle zugeordnet sind (wenn Filter von "Eigene IP-Adresse" erweitert wurden).

Keiner dieser Filter mit einer Verhandlungsaktion verwendet jedoch in der Domänenisolierungslösung die "Eigene IP-Adresse" sie verfügen alle über die Filterfunktion "Beliebig <-> Subnetz". Somit bleiben die IPSec-SA- und IKE-SA-Statuszuordnungen im Laptop aktiv, da diese Filter nicht bei jeder Adressenänderung gelöscht werden. Würden die Filter für "Eigene IP-Adresse" erweitert, würden diese Filter gelöscht werden, wenn die IP-Adresse nicht mehr vorhanden ist.

Wenn ein Filter eines beliebigen Typs im IPSec-Treiber gelöscht wird, informiert der Treiber IKE darüber, dass alle IKE-SAs und IPSec-SAs, die diese IP-Adresse verwenden, ebenfalls gelöscht werden müssen. IKE versucht, Meldungen zum Löschvorgang für diese SAs zu senden, und löscht diese SAs intern. Diese Meldungen zum Löschvorgang verfügen über dieselbe Quell-IP, die für die IKE-SA verwendet wurde, auch wenn zu der Zeit eine andere Quell-IP in der verbundenen Schnittstelle vorhanden sein sollte, als der Löschvorgang gesendet wurde. Die Quell-IP-Adresse spielt für den Remotecomputer keine Rolle, wenn das Cookiepaar im ISAKMP-Header erkannt wird und die Verschlüsselungsüberprüfungen für die Pakete gültig sind. Häufig werden jedoch keine Meldungen zum Löschvorgang gesendet, da während der Sekunden nach dem Trennen der Verbindung keine Netzwerkverbindung besteht (der Laptop wird entfernt).

In diesem Beispiel für die Filter "Beliebig <-> Subnetz" werden die Filter zu keinem Zeitpunkt gelöscht, so dass die IKE- und IPSec-SAs nicht sofort gelöscht werden. In der Zwischenzeit ist die Zeit für die IPSec-SAs auf den Remotecomputern, zu denen vorher eine Verbindung bestand, überschritten, und Meldungen zum Löschvorgang des IKE-Schnellmodus werden an die vorherige Adresse des Laptops gesendet. Es besteht eine weitere Standardlebensdauer von acht Stunden für die SAs des IKE-Hauptmodus auf diesen Computern, diese können jedoch jederzeit bereits vorher aus internen Ursachen, die im IKE vorgegebenen sind, gelöscht werden. Es ist natürlich nicht möglich, für den Laptop diese IKE-SA-Meldungen zum Löschvorgang über seine vorherige IP-Adresse zu empfangen. Wenn der Laptop schließlich wieder an die Dockingstation angeschlossen wird, erhält er erneut dieselbe IP-Adresse. Dateifreigaben, E-Mail-Clients und andere Anwendungen stellen in der Regel eine erneute Verbindung zu denselben Zielen her. Jetzt bestehen jedoch unter Umständen unterschiedliche IKE-Statuseinstufungen zwischen dem Laptop und diesen Remotezielen. Wenn der Laptop immer noch über einen IKE-Hauptmodus verfügt, versucht er, eine IKE-Schnellmodusverhandlung auszuführen. Der Schnellmodus verwendet einen Verschlüsselungsstatus, den der Remotepeer gelöscht hat, so dass diese Meldungen nicht erkannt werden und keine Antwort darauf gesendet wird. Auf dem Laptop läuft das Zeitlimit für erneute Versuche nach einer Minute für IKE ab, und IKE versucht, eine neue IKE-Hauptmodusverhandlung auszuführen, die jetzt erfolgreich ist. Entsprechend verzeichnet der Laptopbenutzer eventuell eine einminütige Verzögerung bei der erneuten Verbindung mit den Remoteressourcen. Microsoft erwartet, für zukünftige Updates aller Windows-Versionen, die IPSec unterstützen, Verbesserungen an diesem Verhalten vornehmen zu können.

Die IKE-Verhandlung kann aus unterschiedlichen Ursachen eine Überschreitung des Zeitlimits ausgeben. Das Ereignis "Verhandlung hat Zeitlimit überschritten" tritt dann auf, wenn ein Schritt einer IKE-Verhandlung (mit Ausnahme des Zurückgreifens auf eine unsichere Verbindung) fehlschlägt, da das Zeitlimit überschritten wurde. Dies trifft nicht zu, wenn IKE die Verhandlung mit einem Ereignis "IKE-Sicherheitszuordnung wurde gelöscht, bevor Herstellung abgeschossen war" abschließt. Diese beiden Ereignisse sind im Grunde identisch. Sie sind in der Regel häufig, unkritisch und treten während des normalen Betriebs bei oft bei mobilen Clients auf, deren Netzwerkkonnektivitätstatus oft und schnell geändert werden, wenn Folgendes zutrifft:

• Benutzer verbinden Laptopcomputer mit Dockingstationen oder entfernen sie daraus.
• Benutzer trennen eine drahtgebundene Verbindung.
• Laptopcomputer wechseln in den Ruhezustand oder in den Standby-Modus.
• Computer verlassen die Reichweite einer drahtlosen Verbindung.
• Eine VPN-Verbindung wird getrennt.
• Eine PCMCIA-Netzwerkkarte wird entfernt, während eine Verbindung zu dieser bestand.

Für einen Remotecomputer sind sämtliche dieser Ereignisse gleichbedeutend mit dem Entfernen des Peercomputers aus dem Netzwerk. Der Remotecomputer versucht, einen erneuten Schlüsselaustausch oder eine erneute Verhandlung auszuführen, bis das Zeitlimit für die IKE-Verhandlungsschritte überschritten wird.

Unter Windows Server 2003 wurden Verbesserungen bezüglich der Zeitüberschreitungsfehler bei Verhandlungen vorgenommen, so dass ermittelt wird, wo in der IKE-Verhandlung das Zeitlimit erreicht wird, indem der letzte erfolgreiche Verhandlungsschritt identifiziert wird. Diese Ereignisse können darüber hinaus auftreten, wenn eine Netzwerkadressübersetzung (Network Address Translation, NAT) vorhanden ist und IKE-Verhandlungen ohne die NAT-T-Funktionalitäten ausführt. Es kommt jedoch auch dann zu einer Überschreitung des Zeitlimits für die IKE-Verhandlung, wenn die IKE-Verhandlung aus irgendeinem Grund für den Remotepeer fehlschlägt.

Wenn daher Verhandlungszeitlimits und Ereignisse wie "IKE-Sicherheitszuordnung wurde gelöscht, bevor Herstellung abgeschossen war" auftreten, muss der Support der Ebene 2 ermitteln, ob die Verhandlung für den Remotecomputer tatsächlich fehlgeschlagen ist, indem Ereignisse 547 zu fehlgeschlagenen Überwachungen auf diesem Computer eine Minute vor dem Protokollieren des Zeitlimits durch IKE überprüft werden.

Erfolgsereignisse für IKE-Verhandlungen

Wenn die IKE-Verhandlung erfolgreich ist, werden IKE-Hauptmodus-SAs im MMC-Snap-In für den IPSec-Monitor und über Befehlszeilenabfragetools angezeigt.

So zeigen Sie eine Liste der aktuellen IKE-Hauptmodus-SAs an

• Für Windows 2000:

  ipsecmon.exe, netdiag /test:ipsec /v 
  

  Hinweis

  
  Dieser Befehl zeigt nur IPSec-SAs, nicht IKE-Hautpmodus-SAs an.

• Für Windows XP:

  IPsec monitor snapin, ipseccmd show sas
  

• Für Windows Server 2003**:**

  Hinweis

  
  Die Zeile wurde zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt. Wenn Sie jedoch versuchen, diese in einem System anzuwenden, müssen Sie diese in einer Zeile ohne Zeilenumbrüche eingeben.

  IPsec monitor snapin, netsh ipsec dynamic 
  show [mmsas | qmsas]
  

Erfolgreiche Hauptmodus- und Schnellmodus-SAs erzeugen im Sicherheitsprotokoll die folgenden Ereignisse, wenn eine Überwachung aktiviert ist.

• 541. IKE-Hauptmodus oder -Schnellmodus hergestellt
• 542. IKE-Schnellmodus wurde gelöscht
• 543. IKE-Hauptmodus wurde gelöscht

Protokolleinträge für den IKE-Hauptmodus

Um zu ermitteln, ob ein Problem mit dem Austausch den Hauptmodus besteht, sehen Sie sich die folgenden protokollierten Ereignisse in den Ereignisprotokollen der Computer an:

Tabelle 7.5: Protokollmeldungen für den IKE-Hauptmodus

Protokolltext	Beschreibung
Neue Richtlinie hat Sicherheitszuordnungen ungültig gemacht, die mit der alten Richtlinie erstellt wurden	Eine Windows 2000-Meldung, die angibt, dass eine Änderung an einer IPSec-Richtlinie das Löschen der aktuellen IKE- oder IPSec-SAs verursacht hat. Dieser Fehler ist unkritisch. Basierend auf dem aktuellen Datenverkehr werden neue IPSec-SAs erstellt, die die neue IPSec-Richtlinie verwenden.
IKE hat eine hohe Anzahl an ausstehenden Sicherheitszuordnungs-Herstellungsanforderungen und wechselt daher in den Diensteverweigerungs-Schutzmodus	Bei hoher Systemauslastung und/oder einer hohen Anzahl an angeforderten Clientverbindungen ist dies normal. Mögliche Ursache könnte aber auch das Ergebnis eines Dienstverweigerungsangriffs gegen IKE sein. In diesem Fall werden viele Überprüfungen auf fehlgeschlagene IKE-Verhandlungen an unzulässige IP-Adressen durchgeführt. Ansonsten ist der Computer einfach stark ausgelastet. Gibt an, dass IKE ein Systemauslastung durch eine hohe Anzahl an SA-Herstellungsanforderungen vermutet, so dass viele dieser Anforderungen im Rahmen einer Strategie zum Schutz vor Dienstverweigerungs-Angriffen (Denial-of-Service) entfernt werden.
IKE wird nach Ausführung im Dienstverweigerungs-Schutzmodus wieder normal ausgeführt	IKE hat den Schutzmodus wegen des vermuteten Dienstverweigungs-Angriffs beendet und den normalen Betrieb wiederhergestellt.

Solche Einträge weisen nicht auf Kommunikationsfehler hin. Diese Einträge dienen der Information und können verwendet werden, um zusätzliche Informationen zum Ermitteln der tatsächlichen Problemursache zu gewinnen.

Fehlerereignisse 547 für IKE-Hauptmodusverhandlungen

Die folgenden IKE-Fehlerereignisse können auftreten, wenn eine IKE-Hauptmodusverhandlung fehlschlägt:

• Peer antwortet nicht. Dieses Ereignis tritt erwartungsgemäß bei ausgehenden Verbindungen mit Computern auf, die kein IPSec verwenden und nicht Mitglied der Ausnahmeliste sind. Der Support der Ebene 2 muss jedoch auf Konnektivitätsprobleme achten, die eine IKE-Verhandlung blockieren, die ebenfalls zu diesem Ereignis führen.
• Keine Richtlinie konfiguriert. Dieses Ereignis weist auf ein Problem hin, wenn es sich bei der Quell-IP-Adresse um eine Adresse innerhalb des internen Subnetzes handelt oder ein Filtersatz vorhanden ist, für den keine Übereinstimmung besteht. Andernfalls wird eventuell erwartet, dass Computer nicht über eine Regel zur Verhandlung von bestimmten Adressbereichen oder Subnetzen verfügen. Computer in solchen Subnetzen versuchen eventuell, eine IKE-Verhandlung durchzuführen, erhalten jedoch keine Antwort, da keine Richtlinie konfiguriert ist.
• IKE-Sicherheitsattribute sind nicht akzeptabel. Dieses Ereignis darf auf korrekt konfigurierten Systemen nicht auftreten. Führen Sie alle im Abschnitt "Überprüfen der korrekten IPSec-Richtlinie" erläuterten Schritte aus, um das Problem genauer zu untersuchen.

Alle der folgenden Meldungen "Verhandlung hat Zeitlimit überschritten" werden eventuell durch die oben erläuterten, erwarteten Bedingungen verursacht. Die Meldungen können auch auf ein Fehlschlagen der IKE-Verhandlung des Remotecomputers hinweisen. Der Support der Ebene 2 konzentriert sich in der Regel darauf, IKE-Fehler auf dem Remotecomputer statt Verhandlungszeitlimits zu untersuchen, die häufig bei Computern ohne Verbindung auftreten, sowie auf die Inkompatibilität von Richtlinienerstellungen, bei der der Responder auf eine Verhandlung im IKE-Hauptmodus oder IKE-Schnellmodus keinen spezifischen Filter finden kann, der der eingehenden Anforderung entspricht.

• Verhandlung hat Zeitlimit überschritten
• Verhandlung hat Zeitlimit überschritten Zuerst verarbeitete Nutzlast (SA) Antwort Wartezeit 63
• Verhandlung hat Zeitlimit überschritten Als zweites verarbeitete Nutzlast (KE) Initiator Wartezeit 63
• Verhandlung hat Zeitlimit überschritten Als zweites verarbeitete Nutzlast (KE) Initiator

Überwachungsfehler für den IKE-Schnellmodus (547)

Die folgenden IKE-Fehlerereignisse können auftreten, wenn eine IKE-Schnellmodusverhandlung fehlschlägt:

• Keine Richtlinie konfiguriert Als drittes verarbeitete Nutzlast (ID) Initiator
• Die Sicherheitszuordnung ist aufgrund von nicht übereinstimmenden Attributen fehlgeschlagen
• Allgemeiner Verarbeitungsfehler
• Es konnte keine neue SPI für eingehende Sicherheitszuordnungen vom IPSec-Treiber erlangt werden
• Der IPSec-Treiber kann die Oakley-Negotiation nicht erfüllen, da kein Filter vorhanden ist
• Sicherheitszuordnung konnte nicht zum IPSec-Treiber hinzugefügt werden
• Verhandlung hat Zeitlimit überschritten

Der IKE-Schnellmodus darf bei korrekt erstellten IPSec-Richtlinien und unter einer normalen Betriebsauslastung nicht fehlschlagen. Wenn einer dieser Fehler auftritt, muss der Support der Ebene 2 zunächst die im Abschnitt "Überprüfen der korrekten IPSec-Richtlinie" erläuterten Schritte ausführen. Dann muss der Support der Ebene 2 versuchen, diese Ereignisse mit ungewöhnlichen Auslastungsbedingungen in Verbindung zu bringen, wie eine 100-prozentige CPU-Auslastung oder einen sehr niedrigen Kernel-Speicher.

Beachten Sie, dass bei Fehlern des IKE-Schnellmodus beim Überschreiten des Verhandlungszeitlimits zu erwarten ist, dass der Computer seine frühere IP-Adresse aus den oben genannten Gründen nicht mehr verwendet.

Problembehandlung für IKE bei Authentifizierungsfehlern

Die folgenden Meldungen beziehen sich auf IKE-Authentifizierungsfehler:

• Das angegebene Ziel ist unbekannt oder nicht erreichbar / Es konnte keine Instanz zwecks Authentifizierung kontaktiert werden
• Das angegebene Ziel ist unbekannt oder nicht erreichbar Zuerst verarbeitete Nutzlast (SA) Initiator. Wartezeit 0
• IKE-Authentifizierung-Anmeldeinformationen sind nicht akzeptabel
• Der Anmeldeversuch ist fehlgeschlagen
• Authentifizierung unter Verwendung von Kerberos ist fehlgeschlagen
• IKE konnte kein gültiges Computerzertifikat finden

Die ersten beiden Meldungen geben an, dass die Kerberos-Identität auf dem Remotecomputer nicht zum Abrufen eines Diensttickets für den Remotecomputer verwendet werden kann. Diese Situation kann dann vorkommen, wenn keine Domänenvertrauensstellung besteht oder keine Domänencontroller verfügbar sind.

Wenn eine eingehende IKE-Verhandlung aufgrund der Einstellungen für die Option "Auf diesen Computer vom Netzwerk aus zugreifen" fehlschlägt, gibt die IKE-Verhandlung auf der Seite, die die Zugriffsberechtigungen erzwingt, einen Ereignisbericht 547 "Authentifizierung unter Verwendung von Kerberos ist fehlgeschlagen" wie oben erläutert aus. Dieses Ereignis ist kein spezifischer Hinweis darauf, dass das Problem durch ein Fehlschlagen bei der Überprüfung der Berechtigungen für die Einstellung "Auf diesen Computer vom Netzwerk aus zugreifen" verursacht wird, daher muss eine Oakley.log-Datei vom Server abgerufen werden, um den spezifischen Fehler anzuzeigen. Es muss eine Überprüfung der Gruppenmitgliedschaft des IKE-Initiators erfolgen, um sicherzustellen, dass es sich tatsächlich um ein Mitglied einer autorisierten Gruppe handelt. Wenn der Computer ein Mitglied einer Gruppe mit autorisiertem Zugriff ist, verfügt der Computer eventuell nicht über Kerberos-Tickets, die die neue Mitgliedschaft angeben. Es kann auch sein, dass der Computer nicht in der Lage ist, die korrekten Kerberos-Tickets abzurufen. Führen Sie die gesamten Schritte aus, die im Abschnitt "Überprüfen der Konnektivität und Authentifizierung mit Domänencontrollern" weiter oben in diesem Kapitel erläutert werden.

Behandlung von anwendungsbezogenen Problemen

Dieser Abschnitt erläutert, wie sich die Anwendungserstellung auf die Nutzung von IPSec unter Microsoft Windows auswirken kann. Die für die Erstellung der IPSec-Richtlinie verantwortliche Person muss mit diesen Auswirkungen vertraut sein, und die Supportmitarbeiter müssen wissen, dass solche Auswirkungen bestehen, so dass sie das Problem schnell klassifizieren und identifizieren können. Die Anwendung von IPSec-Richtlinien muss größtenteils für Anwendungen transparent sein. Unter bestimmten Bedingungen kann das Zuweisen von IPSec-Richtliniein oder Schützen von Datenverkehr dazu führen, dass sich Anwendungen nicht wie erwartet verhalten. Die folgenden Abschnitte heben diese Bedingungen im Kontext der Domänenisolierungslösung der Woodgrove Bank hervor.

ICMP zugelassen, TCP und UDP erfordern jedoch IPSec

Einige Anwendungen verwenden eine Echoanforderungsmeldung (Ping), um zu ermitteln, ob eine Zieladresse erreichbar ist. IPSec schützt ICMP-Datenverkehr beispielsweise nicht in dieser Lösung, so dass eine Anwendung eine ICMP-Antwort von einem Ziel erhalten kann. Die Anwendung ist jedoch unter Umständen nicht in der Lage, eine Verbindung zum Ziel über IPSec-geschützten TCP- und UDP-Datenverkehr herzustellen, wenn die IKE-Verhandlung fehlschlägt.

Verbindungsverzögerungen bei der erstmaligen Verbindungserstellung

Die IKE-Verhandlung erfordert eine aufwändigere Verarbeitung und mehr Zeit, um einen Dreiwege-Handshake für TCP oder eine nicht authentifizierte Einzelpaketanforderung und -antwort über "Nbtstat" durchzuführen. Anwendungen, die eine schnelle TCP- oder UDP-Verbindungsantwort von einem Ziel erwarten, gehen eventuell davon aus, dass das Ziel nicht antworten kann, und ergreifen andere Maßnahmen, wie die Erstellung eines Fehlerberichts oder den Versuch, eine Verbindung mit einem anderen Ziel herzustellen. IKE-Verhandlungen unter Verwendung der Kerberos-Authentifizierung werden in der Regel innerhalb von einer bis zwei Sekunden erfolgreich abgeschlossen. Diese Zeitdauer hängt jedoch von mehreren Faktoren ab, insbesondere von der CPU-Auslastung auf beiden Computern und dem Netzwerkpaketverlust. Nach einem Zurückgreifen auf eine unsichere Verbindung besteht immer eine Verzögerung von drei Sekunden, bevor das erste Paket des TCP-Handshakes ungesichert gesendet werden kann.

Anwendung ist beim Warten auf Netzwerkantwort blockiert

Einige Anwendungen wurden unter der Annahme erstellt, dass die benötigte Zeit zum Herstellen einer Verbindung oder für den Erhalt einer Fehlermeldung sehr kurz ist. Diese Anwendungen warten noch auf die Fertigstellung der Verbindung (also auf die Fertigstellung der Socketverbindung), bevor sie Änderungen auf der Benutzeroberfläche anzeigen. Wenn dieser Anwendungsdatenverkehr durch IPSec geschützt ist, wird die Anwendung während erfolgreicher Verbindungen eventuell für kurze Zeit blockiert. Die Blockierung der Anwendung bleibt unter Umständen bestehen, bis die Anwendung beendet wird oder weitere ungewöhnliche Fehler auftreten, wenn die Verbindung wegen eines IKE-Verhandlungsfehlers oder eines IPSec-Blockierungsfilters nicht erfolgreich ist. Die Netzwerksocketschicht erkennt nicht, dass IPSec-Filter bestehen oder dass IKE Sicherheitsverhandlungen für den Datenverkehr vornimmt. Die Anwendung interpretiert als Ursache für diese Bedingungen in der Regel eine fehlende Aktivität des Remotehosts oder einen Netzwerkfehler. Anwendungen können bei fehlgeschlagenen Verbindungen zu Domänencontrollern als Ursache jedoch auch eine fehlende Verfügbarkeit des Zielcomputers oder eine verweigerte Verbindung interpretieren.

Beeinträchtigte Paketverarbeitung im Kernel-Modus

Anwendungen, die Netzwerktreiber oder eine Paketverarbeitung auf Kernel-Ebene umfassen, werden bei der Sicherung von Datenverkehr durch IPSec eventuell nicht korrekt ausgeführt. Diese Anwendungen nehmen unter Umständen Änderungen am Paket vor, die dazu führen, dass das Paket durch IPSec entfernt wird. Es kann auch vorkommen, dass die Anwendung durch die IPSec-Änderungen keine klaren Informationen mehr erhält. Die Folge kann ein Systemfehler (Bluescreen) sein.

Beeinträchtigte Netzwerkscans von Hosts in Isolierungsdomänen

Hostbasierte Tools, die eine schnelle Suche nach Remote-IP-Adressen oder offenen Ports im Netzwerk durchführen müssen, werden unter Umständen viel langsamer ausgeführt, wenn IPSec versucht, den entsprechend durchsuchten Datenverkehr zu schützen. Der durchsuchte Datenverkehr kann zu einem Denial-of-Service auf dem lokalen Host führen, indem IKE dazu veranlasst wird, hunderte von IP-Adressen innerhalb von wenigen Sekunden oder Minuten auszugeben. Einige SNMP-basierte Tools richten sich nach SNMP-Trap-Ereignissen, die an nicht vertrauenswürdige Hosts gesendet werden, die zum Sammeln von Ereignissen dienen. Auch wenn für IPSec ein Zurückgreifen auf unsichere Verbindungen zulässig ist, werden die ausgehenden SNMP-Trap-Pakete eventuell vom IPSec-Treiber verworfen, bevor die schwache SA erstellt wird. Auch warten einige UDP-basierte Anwendungen (wie NTP und der Windows Domänencontroller-Locatordienst) nur drei Sekunden lang auf den Erhalt einer Antwort, was zu Anwendungsfehlern oder fehlerhaften Berichten zur Nichterreichbarkeit eines Ziels führt

Probleme mit Winsock Layered Service Provider

Einige zulässige Anwendungen (wie persönliche Firewalls) und einige böswillige Anwendungen (wie Spyware) können Probleme verursachen, indem ihre eigenen Funktionen zur Überwachung des Netzwerkdatenverkehrs eingefügt werden, die als Winsock Layered Service Provider (LSPs) bezeichnet werden. Die IKE-Komponente der Microsoft-Implementierung von IPSec verwendet eine erweiterte Winsock API-Funktion, deren Funktionszeiger durch den Aufruf von "WSAIoctl()" bestimmt wird. Wenn für diesen Funktionsaufruf kein Durchlass durch einen installierten LSP zugelassen wird, kann IKE die erforderlichen UDP-Ports nicht überwachen. Unter Windows Server 2003 wird das von IPSec als Komponentenfehler beim Erzwingen der erforderlichen Sicherheitsrichtlinie interpretiert. IPSec reagiert mit Schutzmaßnahmen. Es wird die Funktion "Fail to a Secure Mode" aufgerufen, und der IPSec-Treiber wird in den gesperrten Modus versetzt. Es muss ein Administrator über eine Desktopanmeldung angemeldet sein, um den IPSec-Dienst zu beenden und die Konnektivität wiederherzustellen. Wenn der IPSec-Dienst nicht auf die Anforderung zum Anhalten reagiert, muss der IPSec-Dienst als deaktiviert konfiguriert und der Computer neu gestartet werden.

Auch wenn IKE scheinbar über eine korrekte Initialisierung verfügt, ist das Senden und Empfangen von IKE- und IPSec-Protokollen für den Computer eventuell vom LSP oder einem anderen installierten Programm eines Drittanbieters gesperrt.

Für den Support der Ebene 2 besteht die Aufgabe bei der Problembehandlung für Winsock LSP darin, festzustellen, ob diese LSPs vorhanden sind. Der Support der Ebene 3 muss dann weitere Untersuchungen durchführen, um die Anwendung zu identifizieren, die von den LSPs installiert wurden, und diese neu anzuordnen oder zu entfernen, um zu ermitteln, ob für den IPSec-Dienst oder IKE keine weiteren Probleme auftreten. Zu den Tools zum Ermitteln der Winsock LSPs gehören:

• Sporder.exe. Ein Applet, das zum Anzeigen der LSPs in der Komponente Winsock 2.0 im Windows Platform Software Development Kit (SDK) verfügbar ist.
• Netdiag /debug.

IPSec-VPN-Clients von Drittanbietern

Es kann eine Reihe von Problemen auftreten, wenn eine IPSec-Implementierung eines Drittanbieters als Teil eines Remotezugriffs-VPN-Clients installiert ist. Die Clients deaktivieren in der Regel den IPSec-Dienst und führen zu keinen Konflikten mit dem systemeigenen Windows-IPSec. Für Mitglieder der vertrauenswürdigen Domäne in dieser Lösung ist der systemeigene IPSec-Dienst jedoch erforderlich. Daher können IPSec-Implementierungen von Drittanbietern aus folgenden Gründen zu Konflikten führen:

• Beide IKE-Implementierungen benötigen eventuell UDP Port 500.
• Für die IPSec-Kernel-Paketverarbeitung für beide Implementierungen ist eventuell das ESP-Protokoll erforderlich.
• Es sind Winsock LSP-Funktionen als Teil des Clients installiert.
• Die Firewallfunktionalität wird vom VPN-Client bereitgestellt.
• Es bestehen verschiedene Ebenen, die einen Durchlass von systemeigenen, gekapselten IKE- und IPSec-Paketen durch den IPSec-Tunnel des Drittanbieters verhindern.

Es wird empfohlen, sich an die VPN-Anbieter zu wenden, um Informationen dazu zu erhalten, ob eine Unterstützung des aktivierten, systemeigenen Windows-IPSec-Dienstes und eine End-to-End-Unterstützung des IPSec-geschützten Datenverkehrs über deren Remotezugriffsverbindung besteht. In einigen Fällen unterstützt das Gateway des VPN-Anbieters Windows 2000- und Windows XP-PPTP und L2TP/IPSec-VPN-Clients. Die systemeigenen Windows-VPN-Clients sind mit dem IPSec-End-to-End-Transportmodus über den VPN-Tunnel kompatibel.

Zum Seitenanfang

Problembehandlung der Ebene 3

Wenn mithilfe der Problembehandlung der Ebene 2 die Störungen nicht behoben werden können, sind Supportmitarbeiter mit spezifischeren Kenntnissen und Erfahrungen erforderlich, um das Problem zu analysieren und eine Lösung zu ermitteln. Die Supportmitarbeiter der Ebene 3 sollten über einen solchen Kenntnisstand verfügen. In vielen Fällen wird dieser Support von beauftragten IPSec-Experten oder Supportorganisationen bereitgestellt, etwa von den Microsoft-eigenen Product Support Services.

Für den IPSec-Support der Ebene 3 sind fundierte Kenntnisse zum Betrieb von IPSec und dem Microsoft-TCP/IP-Stapel erforderlich. Die Supportmitarbeiter von Ebene 3 müssen umfassend zu IPSec und dem Einsatz von IPSec in Server- und Domänenisolierungszenarien geschult werden. Die Kenntnisse und Fähigkeiten der Mitarbeiter der Ebene 3 ermöglichen es ihnen, Verantwortung für die Schulung von Supportmitarbeitern niedrigerer Ebenen und zum Entwickeln von unterstützender Dokumentation, wie technischen Kurzanleitungen, Whitepapers, Supportleitfäden, FAQs und Informationen zur IPSec-Architektur und -Taxonomie, zu übernehmen. Zu den Aufgabenbereichen des Supports der Ebene 3 kann auch die Erstellung und Dokumentation von Notfallwiederherstellungsplänen gehören.

Beauftragen der Microsoft Product Support Services

Wenn die in diesem Kapitel erläuterten Problembehandlungsverfahren nicht zur Lösung Ihres Problems beitragen oder Ihre Organisation nicht über den erforderlichen Kenntnisstand verfügt, um erweiterte Problembehandlungstechniken anzuwenden, müssen Sie das Problem eventuell an die Microsoft Product Support Services eskalieren. Dafür ist es wichtig, so viele Informationen zur Diagnose wie möglich zusammenzustellen, wie Protokolle und Netzwerküberwachungsdokumente, bevor Sie die Product Support Services beauftragen. Verwenden Sie diese Liste, um Informationen zusammenzustellen, die der Support der Ebene 3 oder die Microsoft Product Support Services zum Analysieren des Problems benötigen:

• Sicherheitsanforderungen für die eingehende und ausgehende Authentifizierung und Autorisierung für jeden Computer. Es sollte eine kurze Beschreibung dazu beigefügt werden, wie die Gruppenrichtlinie und IPSec-Konfiguration auf dem Computer diese Anforderungen erfüllt.
• Ein repräsentatives Diagramm des Szenarios, das die Namen der Quell- und Zielcomputer, deren IP-Adressen (zu der Zeit, zu der die Protokolldateien erstellt wurden) und Betriebssystemversionen (einschließlich Informationen zum Service Pack) angibt. Geben Sie darüber hinaus die IP-Adressen der DNS-Server, WINS-Server und Domänencontroller an.
• Netzwerkmonitorverfolgungen der Kommunikation, die von jeder Seite aus während der aktivierten IPSec-Richtlinie erfasst wurden; vorzugsweise sollte die Verfolgung simultan erfolgen, so dass für die Pakete schnell und einfach ein gegenseitiger Bezug durch einen Abgleich der beiden Verfolgungsdateien hergestellt werden kann. Die Netzwerkverfolgungen müssen den gesamten eingehenden und ausgehenden Datenverkehr auf jedem Computer erfassen (falls möglich), so dass Authentifizierungsanforderungen, DSN-Lookups und anderer zugehöriger Datenverkehr identifiziert werden können. Wenn die Kommunikation während einer aktivierten IPSec-Richtlinie fehlschlägt, die Kommunikation jedoch bei deaktivierter IPSec-Richtlinie oder angehaltenem Dienst erfolgreich ist, muss darüber hinaus eine Netzwerkverfolgung des Datenverkehrs erfolgen, während IPSec nicht aktiviert ist. Es muss unbedingt eine Synchronisierung der Systemzeit zwischen diesen Systemen vorgenommen werden, so dass ein gegenseitiger Bezug der Protokolle und Verfolgungsdateien hergestellt werden kann.
• Unter Windows 2000, Windows XP und Windows Server 2003 wird die Ausgabe des Protokolls
• netdiag /debug >netdiag-debug-computername.txt kurz vor oder kurz nach der Erfassung der Netzwerkverfolgung ausgeführt. (Über das Netzwerkdiagnosetool "netdiag" wird eine große Menge an Datenverkehr generiert, der nicht im Rahmen der Netzwerkverfolgung erfasst werden muss.) Führen Sie unter Windows XP und Windows Server 2003 auch diesen Befehl aus:
• portqry -v -local >portqry-v-computername.txt.
• IKE-Dateien Oakley.log von jeder Seite, die zu der Zeit erfasst werden, zu der das Problem aufgetreten ist und zu der die Netzwerkmonitorverfolgungen aufgezeichnet wurden. Die Namen dieser Dateien sollten auf den Computernamen verweisen. Bei Beteiligung eines Windows-RAS- oder VPN-Clients muss das RASDIAG-Tool zum Zusammenstellen der Informationen verwendet werden.
• Das gesamte Systemprotokoll, Sicherheitsprotokoll und Anwendungsprotokoll jedes Computers, zu der Zeit, zu der die Oakley.log-Dateien und die Netzwerkverfolgungen erfasst wurden.
• Sämtliche Protokolldateien, die speziell Gruppenrichtlinien erfassen und zu der Zeit erstellt wurden, zu der die Oakley.log und Netzwerkverfolungen erfasst wurden.
• Details zur IPSec-Richtlinie für jeden Computer. Wenn die auf jeden Computer angewendeten IPSec-Richtlinien einfach gespeichert werden können, müssen auch diese mit eingeschlossen werden. Die aktive IPSec-Richtlinie des Computers besteht jedoch häufig aus einer Kombination mehrerer IPSec-Richtlinienkonfigurationstpyen, nicht nur aus der Domänen- oder lokalen Richtlinie. Das beste Format für die Analyse der aktiven Richtlinie auf einem Computer ist eine Auflistung der für den IKE-Hauptmodus und für den IKE-Schnellmodus spezifischen Filter über das MMC-Snap-In für den IPSec-Monitor.

So erstellen Sie eine formatierte Textdatei dieser Filter

1. Klicken Sie mit der rechten Maustaste im rechten Bereich der Struktur auf den Knoten IKE Quick Mode Specific Filters.
2. Wählen Sie Liste exportieren.
3. Speichern Sie die durch Tabstopps getrennte Textdatei unter IKE-qm-<spezifischer-Computername>.txt oder mit einer ähnlichen Benennungskonvention, die den Computernamen umfasst.

Eine durch Tabstopps getrennte Textdatei kann zusammen mit sämtlichen Filterdetails in ein Tabellenkalkulationsprogramm oder ein Textverarbeitungsdokument importiert werden.

Zum Seitenanfang

Zusammenfassung

Dieses Kapitel bietet detaillierte Informationen zu Prozessen, die Unterstützung für den Support der Ebene 1 (Helpdeskmitarbeiter) und den Support der Ebene 2 (professionelle IT-Netzwerksupportmitarbeiter) beim Verständnis dessen bereitstellen, wie häufige IPSec-Kommunikationsprobleme behandelt werden müssen. Aufgrund der Komplexität der Bereiche IPSec und Netzwerksicherheit konnten nicht alle Variationen aufgeführt werden, und es ist es nicht möglich, sämtliche Informationen zu allen möglichen Fehlern anzugeben. Nach Möglichkeit haben die Autoren dieses Kapitels mögliche Optionen zusammengefasst, um die Anleitung auf die Bereiche zu konzentrieren, in denen das Auftreten von Problemen für die Server- und Domänenisolierungsumgebung am wahrscheinlichsten ist, die in diesem Leitfaden detailliert erläutert wurde.

Die in diesem Leitfaden angegebenen Beispielskripts wurden in der Implementierung der Testumgebung für das Szenario der Woodgrove Bank auf ihre Effektivität getestet. Diese Skripts wurden jedoch so entworfen und angepasst, dass sie die Anforderungen einer Organisation erfüllen, und werden daher nicht von Microsoft unterstützt.

Der Leser wird darauf hingewiesen, dass die Problembehandlung für IPSec ein technisch komplexer Vorgang ist, der neben IPSec Kenntnisse und Fähigkeiten in den unterschiedlichsten technologischen Bereichen erfordert, etwa in den Bereichen Netzwerktechnik, Active Directory und Gruppenrichtlinien. Anhand der Informationen in diesem Kapitel sollte der Leser jedoch in der Lage sein, mit Ausnahme der ungewöhnlichsten Probleme eine Behandlung aller Störungen, die eine Server- und Domänenisolierungslösung beeinträchtigen können, durchzuführen.

Wenn Sie Ihre Kenntnisse auf die Gebiete des Supports der Ebene 3 erweitern möchten, finden Sie im folgenden Abschnitt umfassendes weiterführendes Referenzmaterial, das genügend Lesestoff für die nächsten Jahre bietet!

Weitere Informationen

• Detaillierte Hintergrundinformationen zu IPSec finden Sie in der Windows Server 2003 Technical Reference How IPsec Works unter www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr\_IPsec\_how.asp (in englischer Sprache)
• Detaillierte Informationen zur Behandlung von TCP/IP-Problemen finden Sie in folgenden technischen Dokumentationen:
  • TCP/IP in Windows 2000 Professional unter www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/prork/prcc\_tcp\_slnb.asp (in englischer Sprache)
  • Kapitel TCP/IP Troubleshooting im Windows XP Resource Kit unter www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prcc\_tcp\_gfhp.asp (in englischer Sprache).
  • Problembehandlung bei TCP/IP-Verbindungen in Windows XP unter https://support.microsoft.com/?kbid=314067
  • Windows Server 2003 TCP/IP Troubleshooting unter www.microsoft.com/technet/prodtechnol/windowsserver2003/operations/system/tcpiptrb.mspx (in englischer Sprache)
• Onlinehilfen und Resource Kit-Dokumentationen, die sich gezielt mit der Problembehandlung für IPSec unter Windows 2000, Windows XP und Windows Server 2003 befassen, finden Sie unter folgenden Links:
  • "IPsec zu Problembehandlung in Microsoft Windows 2000 Server" unter
    https://support.microsoft.com/?kbid=257225
  • Microsoft Windows 2000 Advanced Documentation unter
    www.microsoft.com/windows2000/en/advanced/help/sag\_ipsectrouble.htm?id=3352
  • "Grundlegende Problembehandlung für L2TP/IPSec in Windows XP" unter
    https://support.microsoft.com/?kbid=314831
  • Windows Server 2003-Hilfe IPSec Problembehandlungstool unter
    www.microsoft.com/technet//prodtechnol/windowsserver2003/proddocs/standard/sag_ipsec_tools.asp?frame=true#iketrace_enable
  • Das Diagramm zur Architekturübersicht im Whitepaper Windows 2000 TCP/IP Implementation Details unter
    www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/tcpip\_implement.asp
  • Windows 2000 Network Architecture, Abbildung: B.1 at
    www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/cnet/cnad\_arc\_jypf.asp (in englischer Sprache).
  • How TCP/IP Works unter www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr\_tcpip\_how.asp (in englischer Sprache)
  • How IPSec Works unter www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/w2k3tr\_ipsec\_how.asp

Zum Seitenanfang

| Home | Technische Artikel | Community