Planungshandbuch - Sichern von Wireless LANs mit Zertifikatsdiensten

Auf dieser Seite

	Einführung
	IAS zur Verwaltung des Netzwerkzugriffs
	Vorraussetzungen für die Lösung
	Entwerfen der RADIUS-Infrastruktur
	Erstellen eines Verwaltungsplans
	Zusammenfassung

Einführung

In diesem Kapitel werden die Architektur und der Entwurf der in dieser WLAN-Lösung eingesetzten RADIUS-Infrastruktur (Remote Authentication Dial-In User Service) beschrieben. Die RADIUS-Infrastruktur verwendet die Microsoft-eigene RADIUS-Implementierung Microsoft® Internet Authentication Service (Internetauthentifizierungsdienst, IAS).

Zunächst werden in diesem Kapitel die Entwurfsentscheidungen beschrieben, die bei der IAS-Infrastruktur für diese Lösung getroffen werden müssen, sowie die Gründe für diese Entscheidungen.

Formulierungen wie "Bei dieser Lösung wird ... verwendet" oder "Dieser Entwurf verwendet ..." in diesem Kapitel beziehen sich auf Entscheidungen zum Lösungsentwurf, die dann in den späteren Kapiteln dieses Handbuchs, die sich mit dem Aufbau und dem Betrieb der Lösung befassen, implementiert werden.

Das zweite Ziel dieses Kapitels besteht darin, Ihnen bei der Bestimmung der Eignung des Entwurfs für Ihre konkrete Organisation zu helfen. Formulierungen wie "sollten Sie entscheiden ..." stehen an den Stellen, an denen Sie entsprechend den Anforderungen in Ihrer Organisation eine Entscheidung treffen müssen. Diese Entscheidungen sind im Allgemeinen dann erforderlich, wenn es um die Erweiterung der Lösung geht, um den wachsenden Sicherheitsanforderungen in Ihrer Organisation gerecht zu werden. Daher werden manche Themen ausführlicher diskutiert, damit Sie besser verstehen können, welche Implikationen die einzelnen Schritte haben, und Sie nicht zu Referenzzwecken auf andere Ressourcen zurückgreifen müssen.

Voraussetzungen für das Kapitel

Bevor Sie dieses Kapitel lesen, sollten Sie sich mit den RADIUS-Konzepten und den IAS-Bereitstellungsoptionen vertraut machen. Verweise auf nützliche Ressourcen zu diesen Themen finden Sie im Abschnitt "Weitere Informationen" am Ende dieses Kapitels. Nützliche Informationen finden Sie auch in den IAS-Kapiteln im Microsoft Windows Server 2003 Resource Kit und im Microsoft Windows Server 2003 Deployment Kit.

Kapitelüberblick

Das Kapitel ist in Themenbereiche untergliedert, die sich mit den verschiedenen Aspekten des Entwurfs einer RADIUS-Infrastruktur beschäftigen. Mit diesem Kapitel werden die folgenden Ziele verfolgt:

Die folgende Abbildung zeigt die Gliederung des Kapitels.

Abbildung 5.1: Planung einer IAS-Infrastruktur

Zum Seitenanfang

IAS zur Verwaltung des Netzwerkzugriffs

Der Internetauthentifizierungsdienst (IAS) in Microsoft Windows Server  2003 ist die Microsoft-Implementierung eines RADIUS-Servers und eines RADIUS-Proxyservers. Als RADIUS-Server führt IAS eine zentrale Authentifizierung, Autorisierung und Kontoführung bei unterschiedlichen Arten von Netzwerkverbindungen durch. Als RADIUS-Proxyserver leitet IAS RADIUS-Anforderungen an einen anderen RADIUS-Server zum Authentifizieren, Autorisieren und zur Kontoführung weiter. Sie können IAS zusammen mit VPN-Servern, wie z. B. dem Microsoft Windows® -basierten Routing- und RAS-Dienst (RRAS), oder mit einer anderen Infrastruktur für den Netzwerkzugriff, wie z. B. WLAN-Zugriffspunkten (WLAN-APs) und authentifizierenden Ethernet-Switches, verwenden.

Um eine IAS-basierte RADIUS-Infrastruktur optimal zu nutzen, sollte sich Ihre Organisation unternehmensweit für den Einsatz zentralisierter Dienste für die Verwaltung des Netzwerkzugriffs entscheiden. Dazu gehört die Verwendung einer zentralisierten Kontendatenbank, wie z. B. des Active Directory®-Verzeichnisdienstes, und die Zentralisierung der Richtlinienverwaltung für den Netzwerkzugriff auf den IAS-Servern. Durch die Zentralisierung der Verwaltung können die Kosten, die mit der Verwaltung der Informationen zur Netzwerkzugriffssteuerung auf verteilten Netzwerkzugriffsgeräten verbunden sind, erheblich reduziert werden. Darüber hinaus lassen sich mit zentralisierten Konten und Netzwerkzugriffsrichtlinien die mit dem Konfigurieren und Verwalten verteilter Geräte verbundenen Sicherheitsrisiken senken.

Die Planung und Bereitstellung einer IAS-Infrastruktur, die den aktuellen und zukünftigen Anforderungen Ihres Unternehmens entspricht, bedarf sorgfältiger Überlegungen. IAS ist nicht für den Zugriff auf ein einzelnes, isoliertes Netzwerk vorgesehen, sondern sollte vielmehr für die strategische Verwaltung des Netzwerkzugriffs für unterschiedliche Netzwerkzugriffsszenarien verwendet werden.

Identifizieren der Anforderungen für die Verwaltung des Netzwerkzugriffs

IAS in Windows Server 2003 unterstützt unter anderem die folgenden Szenarien für den Netzwerkzugriff:

Um optimalen Nutzen aus Ihrer Investition in IAS zu ziehen und künftig erforderliche Änderungen an der IAS-Infrastruktur so gering wie möglich zu halten, sollten Sie jedes dieser Szenarien auf die Verwendbarkeit in Ihrer Organisation prüfen. IAS wird zwar in dieser Lösung ausschließlich für den Zugriff auf das WLAN verwendet, Sie können diese Lösung aber auch so erweitern, dass sie eine Unterstützung für diese anderen Szenarien bietet. Informationen dazu, wie die RADIUS-Infrastruktur für die Unterstützung weiterer Szenarien erweitert werden kann, finden Sie in Kapitel 3, "Architektur der sicheren WLAN-Lösung".

IAS für die Verwaltung des Netzwerkzugriffs verwenden

Seit dem Erscheinen von Industriestandards wie IEEE 802.11 setzen sich WLANs mehr und mehr durch. WLANs ermöglichen die freie Bewegung innerhalb eines Gebäudes oder Firmengeländes bei gleichzeitigem automatischen Zugriff auf das lokale Netzwerk, sofern sich das Zugangsgerät in der Nähe eines WLAN-APs befindet.

WLANs sind zwar sehr bequem, weisen jedoch auch die folgenden Sicherheitsrisiken auf:

Um dem ersten Sicherheitsrisiko entgegenzuwirken, können Sie WLAN-APs als RADIUS-Clients einrichten und diese so konfigurieren, dass sie Zugriffsanforderungen und Kontoinformationen an einen zentralen RADIUS-Server senden, der IAS ausführt. Um dem zweiten Sicherheitsrisiko zu begegnen, können Sie die zwischen den drahtlosen Geräten und den WLAN-APs gesendeten Daten verschlüsseln.

IAS bietet in zweierlei Hinsicht eine erweiterte Sicherheit für WLANs: Er fungiert als RADIUS-Server für IEEE 802.1X-fähige WLAN-APs und Clientgeräte, und er stellt dynamische Verschlüsselungsschlüssel über zertifikatbasierte Authentifizierungsprotokolle wie EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) bereit.

Hinweis: In diesem Dokument werden WLAN-APs auch als RADIUS-Clients bezeichnet. Auch wenn WLAN-APs nicht die einzigen möglichen RADIUS-Clients sind, sind sie doch die einzigen RADIUS-Clients, um die es hier geht. Die beiden Begriffe sind daher hier austauschbar.

Zum Seitenanfang

Vorraussetzungen für die Lösung

Vor der Entwicklung einer Lösung für die Verwaltung des drahtlosen Zugriffs mit IAS sollten Ihnen die für Ihre Umgebung erforderlichen Voraussetzungen bekannt sein.

Active Directory

Diese Lösung wurde für Organisationen entwickelt, in denen Active Directory bereitgestellt wird und die auf ihren Domänencontrollern Windows 2000 Server oder höher ausführen. Diese Voraussetzungen müssen für diese Lösung erfüllt sein, da der RADIUS-Entwurf auf einer Reihe von Entscheidungen basiert, die Features voraussetzen, welche nur in Domänen mit dem "einheitlichen Modus" von Windows 2000 oder höher verfügbar sind. Die folgende Tabelle enthält Angaben zur Unterstützung einiger der in dieser Lösung verwendeten Features durch die verschiedenen Domänenfunktionsebenen.

Tabelle 5.1: Windows-Domänenfeatures, die in der Lösung verwendet werden

Hinweis: Für die Implementierung der Zertifikatsdienste für diese Lösung gelten ebenfalls Active Directory-spezifische Voraussetzungen. Weitere Informationen dazu finden Sie in Kapitel 4, "Entwerfen der Infrastruktur öffentlicher Schlüssel (PKI)".

Möglicherweise führt die Lektüre dieses Kapitels dazu, dass Sie sich entschließen, IAS auf Domänencontrollern bereitzustellen, auch wenn dies nicht zwingend erforderlich ist. Diese Lösung basiert auf IAS in Windows Server 2003. Daher müssen Sie für diese Lösung die Zieldomänencontroller auf diese Betriebssystemversion aktualisieren. Ausführlichere Informationen zur Installation von IAS auf Domänencontrollern finden Sie weiter unten in diesem Kapitel.

Vorhandene RADIUS-Infrastruktur

Diese Lösung enthält keine Hinweise zum Integrieren mit RADIUS-Servern, die in Ihrer Umgebung bereits vorhanden sind. Es ist jedcoh möglich, vorhandene IAS-basierte RADIUS-Server und RADIUS-Server anderer Hersteller mit dieser Lösung zu integrieren. Für Funktionen im Zusammenhang mit dem WLAN-Zugriff werden Sie in den meisten Fällen Windows Server 2003-IAS verwenden.

Sie können ältere Versionen von Windows-RADIUS-Servern auf Windows Server 2003 aktualisieren, um sie dann als RADIUS-Hauptserver in dieser Lösung einzusetzen. Sie können aber auch die vorhandenen RADIUS-Server so ändern, dass der RADIUS-Verkehr an die Windows Server 2003-basierten RADIUS-Server delegiert wird.

Eine umfassende Unterstützung für die Planung der Migration einer bereits vorhandenen RADIUS-Infrastruktur auf Windows Server 2003-IAS erhalten Sie bei Ihrem Microsoft-Partner oder bei Ihrem Microsoft Account Executive, der Ihnen den für Sie zuständigen Partner oder die entsprechenden Microsoft Consulting Services-Mitarbeiter nennen kann.

Zum Seitenanfang

Entwerfen der RADIUS-Infrastruktur

Wenn zur Unterstützung des 802.1X-basierten WLAN-Zugriffs IAS eingesetzt werden soll, sind eine Reihe von Entwurfsentscheidungen zu treffen. In diesem Abschnitt werden einige dieser Entscheidungen sowie die für diese Lösung gewählten Optionen beschrieben. Prüfen Sie bei jeder Entscheidung genau, inwieweit sie sich auf Ihre Umgebung übertragen lässt.

Festlegen der Rolle von IAS als RADIUS-Server

IAS-Server können eine der folgenden drei konzeptionellen RADIUS-Rollen übernehmen:

In der nachfolgenden Tabelle sind einige der Funktionen von mit diesen Rollen konfigurierten Servern aufgeführt, und es wird beschrieben, wie diese in der Praxis genutzt werden können.

Tabelle 5.2: RADIUS-Rollen von IAS-Servern

Nicht alle RADIUS-Rollen sind für alle Szenarien der Netzwerkzugriffsverwaltung erforderlich. Für die Verwaltung des WLAN-Zugriffs benötigen viele Unternehmen zum Beispiel lediglich die RADIUS-Serverrolle. Wenn Ihre Organisation jedoch plant, die WLAN-Infrastruktur für Benutzer und Geräte in mehreren Active Directory-Gesamtstrukturen zu verwenden, ist zusätzlich eine RADIUS-Proxyserverrolle zum Weiterleiten von Anforderungen an andere RADIUS-Server in den einzelnen Gesamtstrukturen nötig.

Der Einfachheit halber und aus Kostengründen beinhaltet die hier beschriebene Lösung ausschließlich IAS-Server, die als RADIUS-Server konfiguriert sind. Eine Implementierung von IAS als RADIUS-Proxyserver erfolgt dabei nicht.

Grundlegendes zu Server-Failover und Lastenausgleich

RADIUS stellt in jeder Lösung für die Verwaltung des 802.1X-basierten WLAN-Zugriffs eine kritische Komponente dar. Die Verfügbarkeit des WLAN für die Endbenutzer ist abhängig von der Verfügbarkeit der IAS-Server für WLAN-APs. Sie sollten daher sicherstellen, dass stets mindestens zwei IAS-Server für WLAN-APs zur Verfügung stehen. Bei den meisten modernen WLAN-APs können zwei RADIUS-Server für die Authentifizierung und zwei RADIUS-Server für die Kontoführung konfiguriert werden. Damit ist sichergestellt, dass sich der Verlust des Kontakts zu einem einzelnen RADIUS-Server nicht negativ auf die Dienstverfügbarkeit für die WLAN-Clients auswirkt.

Wenn aus Gründen der Ausfallsicherheit mehrere Server implementiert werden sollen, wählen viele Organisationen ein Schema, bei dem Anforderungen von den als RADIUS-Clients konfigurierten WLAN-APs gleichmäßig auf die RADIUS-Server verteilt werden, damit nicht ein einzelner Server auf eine Ressource beschränkt ist.

Bei der Auswahl einer Lastenausgleichsstrategie ist zu beachten, dass 802.1X zwischen den WLAN-APs und den RADIUS-Servern EAP-RADIUS (EAP innerhalb von RADIUS) implementiert. RADIUS verwendet zwar das verbindungslose UDP (User Datagram Protocol), EAP ist aber ein innerhalb von RADIUS getunneltes sitzungsorientiertes Protokoll. Das bedeutet praktisch, dass mehrere EAP-RADIUS-Pakete, die zusammen eine einzelne Authentifizierungsoperation ergeben, an denselben RADIUS-Server zurückgegeben werden müssen. Anderenfalls schlagen die Authentifizierungsversuche fehl.

In der folgenden Tabelle sind mehrere Optionen aufgeführt, mit deren Hilfe sichergestellt werden kann, dass die RADIUS-Clients sowohl für die Sicherstellung der Verfügbarkeit als auch für den Lastenausgleich der RADIUS-Anforderungen mehrere RADIUS-Server nutzen.

Tabelle 5.3: EAP-RADIUS-Optionen für Failover und Lastenausgleich

Unternehmen und große Netzwerkdienstanbieter sollten für die Annahme von Anforderungen von RADIUS-Clients und für die gleichmäßige Verteilung der Last auf RADIUS-Server, die in RADIUS-Servergruppen konfiguriert werden können, RADIUS-Proxys verwenden. Die Verteilung des Netzwerkverkehrs an die RADIUS-Server in den RADIUS-Servergruppen kann anhand verschiedener konfigurierbarer Elemente erfolgen. Zu diesen Elementen gehören der RADIUS-Verkehrstyp und die RADIUS-Attribute sowie Prioritäts- und Gewichtungswerte. Die RADIUS-Server in den einzelnen RADIUS-Servergruppen können dann die zentrale Authentifizierung und Autorisierung von Benutzern und Geräten in einer Domäne oder einer ganzen Gesamtstruktur übernehmen. Damit entsteht eine Frontend-/Backend-Architektur für die Bearbeitung von RADIUS-Anforderungen, die in Bezug auf Lastenausgleich und Skalierungsoptionen maximale Flexibilität bietet.

Abbildung 5.2: Failover und Lastenausgleich über RADIUS-Proxys

Die einfache Failover-Funktionalität von RADIUS-Servern in modernen WLAN-APs bietet jedoch für die meisten Organisationen ein ausreichendes Maß an Ausfallsicherheit. Falls nicht, lässt sich relativ problemlos eine Migration auf eine RADIUS-proxyserverbasierte Failover- und Lastenausgleichsstrategie bewerkstelligen. Ein Nachteil bei der Verwendung einer WLAN-AP-basierten Failover- und Lastenausgleichsstrategie besteht im Verwaltungsaufwand, der erforderlich ist, um die WLAN-APs mit den RADIUS-Servern zu verknüpfen, die gleichmäßige Belastung der RADIUS-Server zu überwachen und bei Bedarf Änderungen vorzunehmen. Ein weiterer Nachteil ist, dass einige WLAN-AP-Modelle kein Failback unterstützen. Von "Failback" wird gesprochen, wenn ein Zugriffspunkt, der im Rahmen eines Failovers auf einen sekundären RADIUS-Server umgeschaltet hat, wieder zum eigentlichen primären RADIUS-Server zurückschaltet, sobald dieser seinen Dienst wieder aufgenommen hat. Ohne Failback kann es passieren, dass alle WLAN-Zugriffspunkte auf ihre sekundären RADIUS-Server umschalten, ohne automatisch wieder zum primären Server zurückschalten zu können, so dass der Administrator eingreifen muss.

So lässt sich mit einer WLAN-AP-basierten Failover-Strategie mit mehreren lokal verfügbaren RADIUS-Servern ein gleichmäßiger Lastenausgleich erzielen:

•

Konfigurieren Sie die Hälfte der WLAN-APs an den einzelnen Standorten so, dass diese zunächst den primären RADIUS-Server verwenden und erst auf den sekundären RADIUS-Server zurückgreifen, wenn der primäre Server ausfällt.

•

Konfigurieren Sie die andere Hälfte der WLAN-APs an den einzelnen Standorten so, dass diese zuerst den sekundären RADIUS-Server verwenden und auf den primären RADIUS-Server nur zurückgreifen, wenn der sekundäre Server ausfällt. Hinweis: Die Begriffe "primär" und "sekundär" bedeuten nicht, dass die Server Unterschiede in ihrer Funktionalität aufweisen sie sind vollkommen gleichwertig. Die Begriffe dienen hier lediglich zur Unterscheidung der Server im Rahmen der Failover-Besprechung. Abbildung 5.3: Failover und Lastenausgleich auf WLAN-AP-Basis

Um mit einer WLAN-AP-basierten Failover-Strategie die Last in Zweigstellen gleichmäßig zu verteilen, in denen ein RADIUS-Server lokal und ein RADIUS-Server remote verfügbar ist, müssen Sie alle WLAN-APs in den Zweigstellen so konfigurieren, dass diese den lokalen RADIUS-Server als primären Server verwenden. Konfigurieren Sie dann den remoten RADIUS-Server als sekundären Server, der verwendet wird, wenn der primäre Server ausfällt.

Abbildung 5.4: Failover und Lastenausgleich auf WLAN-AP-Basis mit lokalen und remoten RADIUS-Servern
Bild in voller Größe anzeigen

Achten Sie in Zweigstellen darauf, dass die WLAN-APs den primären RADIUS-Server verwenden, sobald dieser wieder verfügbar ist. Anderenfalls müssen Sie die WLAN-APs manuell neu konfigurieren, um unnötigen WAN (Wide Area Network)-Datenverkehr für den RADIUS-Dienst zu vermeiden.

Hinweis: Erkundigen Sie sich beim Hersteller Ihrer Hardware, inwieweit dessen Produkte Failbackfunktionalität besitzen.

RADIUS-Server in Zweigstellen sind optional. Anstelle dieser Server können über ein WAN auch zentralisierte RADIUS-Server verwendet werden. Ohne einen lokalen RADIUS-Server und Domänencontroller sind aber Benutzer bei Ausfall des WAN nicht in der Lage, auf das lokale WLAN zuzugreifen.

In der hier beschriebenen Lösung wird mit AP-basiertem Server-Failover und manueller Konfiguration des Lastenausgleichs gearbeitet. Weitere Informationen zum Planen einer RADIUS-Infrastruktur, die RADIUS-Proxys für Server-Failover und Lastenausgleich verwendet, finden Sie im Kapitel "Deploying IAS" im Microsoft Windows Server 2003 Deployment Kit. Einen Verweis auf dieses Dokument finden Sie am Ende dieses Kapitels.

Protokollierungsanforderungen

Sie können IAS-Server so konfigurieren, dass sie zwei unterschiedliche Informationsarten protokollieren:

Erfolgreiche und abgelehnte Authentifizierungsereignisse von Geräten und Benutzern, die auf das WLAN zuzugreifen versuchen, werden von IAS standardmäßig im Systemereignisprotokoll von Windows Server 2003 aufgezeichnet. Die im Ereignisprotokoll gespeicherten Informationen zur Authentifizierung sind vor allem bei der Behebung von Authentifizierungsproblemen hilfreich, können aber auch zu Sicherheitsüberprüfungs- und Sicherheitswarnzwecken verwendet werden.

Anfänglich sollten Sie die Optionen für die Protokollierung von erfolgreichen und abgelehnten Zugriffsversuchen aktiviert lassen. Wenn sich das System stabilisiert hat, können Sie aber auch die Option für die Protokollierung von Erfolgreich-Ereignissen deaktivieren. Diese Vorgehensweise empfiehlt sich, weil die Protokollierung erfolgreicher WLAN-Zugriffe das Systemereignisprotokoll schnell füllen würde. Wenn die Option für die Protokollierung von RADIUS-Authentifizierungsanforderungen aktiviert ist, ist diese Option auch aus Sicherheitssicht nicht unbedingt erforderlich.

Große Unternehmen sollten Tools zur unternehmensweiten Überwachung, wie z. B. Microsoft Operations Manager (MOM), verwenden, um mit benutzerdefinierten Skripts auf IAS-Ereignisse im Systemereignisprotokoll reagieren zu können. So kann ein entsprechend angepasstes MOM-Skript beispielsweise eine Zunahme an IAS-Ereignissen mit abgelehnten Authentifizierungsversuchen erkennen und einen Administrator benachrichtigen, damit dieser eingreifen kann.

IAS bietet darüber hinaus die Möglichkeit, Informationen zu Authentifizierung und Netzwerkzugriffssitzung in Form von RADIUS-Anforderungsprotokollen zu speichern. Sie können dabei die Optionen einzeln aktivieren und deaktivieren und so die folgenden Informationen in Ihre RADIUS-Anforderungsprotokolle aufnehmen:

RADIUS-Anforderungsprotokolle sind besonders für Unternehmen wie Netzwerkdienstanbieter hilfreich, die ihren Kunden Gebühren entsprechend der Netzwerknutzung berechnen. Sie können die RADIUS-Anforderungsprotokolle aber auch zur Überwachung und Prüfung der Sicherheit verwenden. Mithilfe von RADIUS-Authentifizierungs- und -Kontoführungsprotokollen können Sicherheitsprüfer insbesondere Folgendes ermitteln:

Die Protokollierung durch IAS kann in Textprotokollen und in Microsoft SQL Server  2000-Datenbanken erfolgen. Textbasierte Protokollierung von Informationen zur RADIUS-Authentifizierung und RADIUS-Kontoführung ist in IAS standardmäßig deaktiviert. Vor der Aktivierung der textbasierten RADIUS-Protokollierung sollten Sie Folgendes beachten:

Für große Unternehmen, die RADIUS-Kontoführungsprotokolle benötigen, empfiehlt sich die Verwendung der SQL Server-Protokollierungsfunktionen von IAS. Sie können die RADIUS-Kontoführungsinformationen auf der MSDE (SQL Server Desktop Engine) auf den jeweiligen IAS-Servern protokollieren und dann diese Informationen auf einem zentralen SQL Server-Cluster replizieren. Mit dieser Strategie werden RADIUS-Kontoführungsdaten zur Erleichterung von Abfragen, der Berichterstattung und der Archivierung zentral und strukturiert gespeichert. Bei der SQL Server-Protokollierung in lokalen MSDE-Datenbanken entfällt außerdem das Risiko, dass IAS aufgrund von Netzwerkproblemen diese Informationen nicht protokolliert und dass Netzwerkzugriffsanforderungen, die auf den Kontoinformationen basieren, abgelehnt werden.

Auch Unternehmen ohne SQL Server 2000 bzw. ohne Mitarbeiter, die regelmäßig Abfragen durchführen, Berichte erstellen und RADIUS-Anforderungsprotokolle archivieren, sollten diese Informationen speichern, damit im Fall von Sicherheitsvorfällen entsprechende Nachforschungen möglich sind. In der vorliegenden Lösung wurden eine Reihe von Entwurfsentscheidungen zur RADIUS-Protokollierung getroffen. In der folgenden Tabelle finden Sie einen Überblick über diese Entscheidungen. Bestimmen Sie anhand dieser Informationen, welche Entscheidungen den Anforderungen in Ihrer Umgebung gerecht werden.

Tabelle 4: Entwurfsentscheidungen zur IAS-Protokollierung

Zentrale oder verteilte Server

Die Entscheidung, ob zentrale oder verteilte IAS-Server verwendet werden, hängt unter anderem von der geografischen Verteilung Ihrer Organisation und ihrer Bereitstellungsstrategie für die IT-Infrastruktur ab. Beachten Sie dabei, welche der folgenden drei Strategien für die IT-Infrastruktur Ihre Organisation am ehesten verfolgt:

Viele moderne IT-Organisationen bemühen sich darum, weniger, fehlerresistentere und zentralisiertere IT-Infrastrukturkomponenten bereitzustellen. Um dieses Ziel zu erreichen, sind erhebliche Investitionen in eine leistungsstarke und fehlerresistente WAN-Infrastruktur erforderlich, um sicherzustellen, dass Benutzern in den Zweigstellen in den Genuss derselben Dienstverfügbarkeit kommen wie Benutzer am Hauptsitz. Diese Strategie hat den Vorteil, dass Sie die Kosten einer verteilten Serverinfrastruktur auf die Netzwerkinfrastruktur und die Netzwerkbandbreite umleiten können. Darüber hinaus befindet sich die Serverinfrastruktur direkt dort, wo sich auch ausgebildete Datacenter-Mitarbeiter und -Techniker befinden, was der Verfügbarkeit zugute kommt.

Bei Organisationen mit ausfallsicheren Hochgeschwindigkeits-WANs kann die Zentralisierung der IAS-Server zur Senkung der Kosten einer 802.1X-WLAN-Lösung beitragen. Im Falle großer Organisationen sollte bei der Erstellung eines RADIUS-Serverentwurfs von einer solchen IT-Infrastrukturstrategie ausgegangen werden. Das RADIUS-Protokoll beansprucht nicht viel Netzwerkbandbreite und funktioniert gut über WAN-Verbindungen. Darüber hinaus müssen Sie bedenken, dass Protokolle wie DHCP beim Warten auf den Abschluss der 802.1X-Authentifizierung ihr Zeitlimit überschreiten können. Entscheidend ist auch, dass eine leistungsfähige Verbindung zwischen den IAS-Servern und den Domänencontrollern vorhanden ist, die die Benutzer und Gruppen umfassen, anhand derer in Ihrer Umgebung bestimmt wird, wer Zugriff auf das Netzwerk erhalten soll. Viele potenzielle Probleme mit 802.1X-Netzwerken können vermieden werden, indem sichergestellt wird, dass die IAS-Server und Active Directory über eine Hochgeschwindigkeitsverbindung miteinander in Kontakt bleiben.

Häufig jedoch sind IT-Organisationen die Kosten für Bandbreite, technisch hochwertige Netzwerkgeräte und redundante WAN-Verbindungen zu hoch, so dass sich ein Modell mit einer zentralisierten IT-Infrastruktur nicht trägt. Diese Organisationen verwenden stattdessen ein Modell mit einer dezentralisierten IT-Infrastruktur, bei der die Serverinfrastruktur auf Zweigstellen verteilt ist. Dieses Modell gewährleistet die ununterbrochene Verfügbarkeit des IT-Dienstes im Falle eines WAN-Ausfalls.

Eine dritte Strategie für die IT-Infrastruktur besteht in einer Mischung aus zentralisierter IT-Infrastruktur, wo dies möglich ist, und dezentraler IT-Infrastruktur in allen anderen Bereichen. Bei dieser Strategie kann der Großteil der IT-Infrastruktur in zentralen Standorten ("Hubs") konsolidiert werden, von denen aus sowohl die Benutzer am zentralen Standort als auch die Benutzer in den Zweigstellen bedient werden. Gleichzeitig erlaubt dieses Modell die Verteilung der Serverinfrastruktur auf Zweigstellen mit vielen Endbenutzern. Die folgende Abbildung zeigt ein Beispiel für eine Organisation mit solch einer gemischten IT-Infrastruktur.

Abbildung 5.5: Organisation mit einer Mischung aus zentralisierter und verteilter IT-Infrastruktur
Bild in voller Größe anzeigen

Die Lösung in diesem Handbuch berücksichtigt sowohl das zentralisierte als auch das dezentralisierte und gemischte Modell für die Bereitstellung der Serverinfrastruktur und bietet dabei Folgendes:

Festlegen der Anzahl und Standorte der Server

Jede unabhängige Active Directory-Gesamtstruktur muss über mindestens zwei IAS-Server verfügen, die für Benutzer und Geräte in der Gesamtstruktur als RADIUS-Server dienen. Auf diese Weise wird sichergestellt, dass Netzwerkzugriffsanforderungen auch dann weiter bearbeitet werden, wenn einer der RADIUS-Server ausfällt.

Standorte an einem Hauptsitz mit vielen Benutzern sind gute Kandidaten für zwei und mehr RADIUS-Server. Wenn zwischen mehreren Hubs mit RADIUS-Servern ausreichende Bandbreite vorhanden ist, können Sie Ihre WLAN-APs so konfigurieren, dass sie bei Bedarf ein Failover zu den RADIUS-Servern im WAN durchführen. Wenn Sie den Einsatz von RADIUS-Servern im WAN planen, sollten Sie jedoch prüfen, ob in Ihrer Umgebung eine adäquate Netzwerkverbindung zwischen den RADIUS-Servern und den Domänencontrollern vorhanden ist, von denen sie abhängig sind. Darüber hinaus sollten Sie die Zeitüberschreitungswerte der WLAN-APs und der Clientcomputer prüfen und bei Bedarf die AP-Parameter ändern. Wenden Sie sich zum Abschluss den RADIUS-Servern in der Stammdomäne Ihrer Gesamtstruktur zu, um den Kerberos-Betrieb zu optimieren.

Zweigstellen, die groß genug sind, um für den Einsatz von Domänencontrollern infrage zu kommen, ohne aber über ausreichend stabile WAN-Verbindungen zu den Hubs zu verfügen, bieten sich als Standorte für lokale RADIUS-Server an. Wenn in Ihrer Organisation kein ausreichend widerstandsfähiges WAN vorhanden ist, sollten Sie die Anfangs- und Folgekosten eines IAS-Zweigstellenservers mit den Kosten vergleichen, die dadurch entstehen, dass WLAN-Benutzer bei Nichtverfügbarkeit des WAN keinen Zugriff auf das WLAN haben.

Ausführen von IAS und anderen Diensten auf einem gemeinsamen Server

Aufgrund der intensiven Kommunikation zwischen IAS und den Active Directory-Domänencontrollern können Sie die Leistung erhöhen, indem Sie IAS auf demselben Server wie Ihre Domänencontroller ausführen (und so Probleme aufgrund von Kommunikationsverzögerungen im Netzwerk ausschalten). Sie sollten jedoch gut überlegen, welche Implikationen das gleichzeitige Ausführen von IAS auf Ihren Domänencontrollern hat. In der nachfolgenden Tabelle sind einige dieser Überlegungen aufgeführt.

Tabelle 5.5: Überlegungen zur Ausführung von IAS auf Domänencontrollern

Active Directory-Domänencontroller sind kritische IT-Infrastrukturkomponenten, die mit größter Sorgfalt behandelt werden müssen. In vielen großen Organisationen ist genau vorgegeben, wie viele zusätzliche Softwareprogramme oder Dienste zusätzlich auf Domänencontrollern ausgeführt werden dürfen, um die Zuverlässigkeit und Verfügbarkeit dieser Controller nicht zu beeinträchtigen.

Häufig haben der RADIUS-Administrator und der Active Directory-Administrator in diesen Organisationen getrennte Rollen. IAS ist eine optionale Komponente von Windows, und die Trennung von IAS-Administratoren und lokalen Windows-Administratoren ist nicht zwingend erforderlich. Aus diesem Grund sind bei einer Installation von IAS auf den Domänencontrollern die IAS-Administratoren auch Mitglieder der Sicherheitsgruppe "Domain Administrators".

Für diese Lösung wird die Windows Server 2003-Version von IAS benötigt. Sie müssen daher Ihre Domänencontroller auf Windows Server 2003 aktualisieren (sofern nicht bereits geschehen). Vor dem Aktualisieren Ihrer unter Windows 2000 Server laufenden Domänencontroller auf Windows Server 2003 müssen die folgenden Voraussetzungen erfüllt sein:

Tabelle 5.6: Voraussetzungen für das Aktualisieren von Domänencontrollern auf Windows Server 2003

Diese Lösung wurde so konzipiert, dass IAS und Active Directory bei Bedarf gemeinsam auf Ihren Domänencontrollern betrieben werden können. Beim Testen der Lösung wurde IAS an den Hubstandorten getrennt von Windows Server 2003-Domänencontrollern und in den Zweigstellen zusammen mit Windows Server 2003-Domänencontrollern ausgeführt.

Zu erwartende Belastung des RADIUS-Servers

IAS zeigt auf normaler Serverhardware gute Leistungen und kann mit zusätzlicher Hardware oder durch den Einsatz von RADIUS-Servergruppen beliebig skaliert werden. Es empfiehlt sich jedoch, die bei der IAS-Serverhardware durch WLAN-Clients hervorgerufene Last im Voraus zu ermitteln, um Engpässe bei Serverressourcen zu vermeiden, die sich negativ auf die Verfügbarkeit des Dienstes auswirken können.

Ein optimaler Entwurf sollte die für die Ausfallsicherheit mindestens erforderliche Anzahl von Servern beinhalten und dabei genügend Raum für künftige Erweiterungen lassen. Das ist besonders bei der Auswahl von Serverhardware für die Verwendung in einem WLAN-AP-basierten Lastenausgleichsmodell wichtig. Beim Wechsel von einem WLAN-AP-basierten Lastenausgleich zu einem RADIUS-proxyserverbasierten Lastenausgleich kann sich die Anzahl der mindestens erforderlichen Server von zwei auf fünf erhöhen (vorausgesetzt, die vorhandenen RADIUS-Server haben ihre maximale Kapazität erreicht).

Hinsichtlich der IAS-Serverlast muss Folgendes berücksichtigt werden:

Die Anzahl der Benutzer und Geräte, die Zugriff auf das WLAN benötigen, wird zum Ermitteln der IAS-Serverlast benötigt. Manche Unternehmen beschränken die Nutzung von WLANs auf eine bestimmte Gruppe von Benutzern wie z. B. Manager, während andere Unternehmen allen Benutzern Zugriff auf WLANs ermöglichen. Unabhängig von der Strategie Ihrer Organisation müssen Sie von dem Extremfall ausgehen, dass alle Benutzer und Geräte, die auf das WLAN zugreifen dürfen, innerhalb einer kurzen Zeitspanne authentifiziert und autorisiert werden müssen. Damit ist sichergestellt, dass IAS-Server für Zeiten hoher Last, zum Beispiel zu Hauptgeschäftszeiten oder kurz nach einem längeren Netzwerkausfall, gerüstet sind.

Die gewählten WLAN-Authentifizierungsoptionen wirken sich in großem Maße auf die IAS-Serverlast aus. Auf Zertifikaten basierende Protokolle, wie z. B. EAP-TLS, führen bei der ersten Anmeldung eine Authentifizierung mit öffentlichen Schlüsseln durch, die die CPU stark beansprucht. Danach wenden sie jedoch für alle nachfolgenden Anmeldungen die Strategie der schnellen Wiederherstellung der Verbindung an, bei der zwischengespeicherte Anmeldeinformationen verwendet werden. Diese Strategie wird eingesetzt, bis die Daten im Cache gelöscht werden (standardmäßig nach acht Stunden). Die vollständige erneute Authentifizierung findet immer dann statt, wenn ein WLAN-Client vom Einzugsgebiet eines Zugriffspunkts, der die Authentifizierung über einen bestimmten IAS-Server abwickelt, zum Einzugsgebiet eines anderen Zugriffspunkts wechselt, der zur Authentifizierung einen anderen IAS-Server verwendet (z. B. weil er sich in einem Gebäude an einen anderen Ort begibt). Diese servergespeicherte Neuauthentifizierung wird nur einmal zwischen jedem Client und IAS-Server durchgeführt und ist bei der Verwendung von EAP-TLS für den Endbenutzer transparent.

Sie können WLAN-Clients dazu zwingen, sich gegenüber den RADIUS-Servern erneut zu authentifizieren, um so die Verschlüsselungsschlüssel für die 802.11-WEP-Sitzung zu erneuern. Einige WLAN-AP-Modelle beinhalten Funktionen für die zeitgesteuerte Aktualisierung des WEP-Sitzungsschlüssels, ohne dass die RADIUS-Server die Clients zum regelmäßigen Neuauthentifizieren zwingen müssen. Dieses Feature ist herstellerspezifisch. Der WPA-Standard (WiFi Protected Access) umfasst erweiterte Verschlüsselungs- und Schlüsselverwaltungsfunktionen, die das Erzwingen einer regelmäßigen Neuauthentifizierung zum Erneuern der Sitzungsschlüssel überflüssig macht.

Daher sollte beim Entwerfen eines Modells für eine bestimmte Anzahl von Authentifizierungen, die jeder IAS-Server bearbeiten muss, das in der folgenden Tabelle aufgeführte Verhalten der verschiedenen Authentifizierungstypen berücksichtigt werden.

Tabelle 5.7: Verhalten der EAP-TLS-Authentifizierung

Die Anzahl von Authentifizierungen, die IAS bearbeiten kann, wird am besten in Authentifizierungen pro Sekunde angegeben. IAS kann auf einem Computer unter Windows Server 2003 mit Active Directory und einer Intel Pentium-4.2-GHz-CPU die unten angegebene Anzahl an Authentifizierungen bearbeiten.

Wichtig: Die Angaben in der folgenden Tabelle sind ohne Gewähr und stellen lediglich eine Richtlinie für die Planung der Kapazität dar. Sie sind nicht für einen Leistungsvergleich geeignet.

Tabelle 5.8: Authentifizierungen pro Sekunde

IAS kann so konfiguriert werden, dass datenträgerbasierte Textprotokolle mit unterschiedlichen Mengen an RADIUS-Anforderungsinformationen erstellt werden. Aufgrund des erhöhten Aufwands, der sich für die RADIUS-Server aus der RADIUS-Protokollierung ergibt, sollten Sie einen hochleistungsfähigen Datenträger zur Speicherung der RADIUS-Protokolle einplanen. Langsame Festplattensubsysteme können die IAS-RADIUS-Antworten an WLAN-APs verzögern. Dies wiederum kann zu Zeitüberschreitungen bei der Protokollierung und zu einer unnötigen Nutzung der sekundären RADIUS-Server durch die WLAN-APs im Rahmen einer Failover-Strategie führen.

Darüber hinaus bedeutet die Aktivierung der Ablaufverfolgungsfunktionen für Windows 2003 Server-Software eine zusätzliche Last für Ihre IAS-Server. Diese Funktionen werden jedoch gelegentlich zum Beheben von Fehlern beim Netzwerkzugriff benötigt. Skalieren Sie daher Ihre IAS-Server so, dass sie für begrenzte Zeiträume mit aktivierter Ablaufverfolgung arbeiten und die Produktionslast dennoch bewältigen können.

Festlegen der Server-Hardwareanforderungen

Wählen Sie in der Windows Server 2003-Hardwarekompatibilitätsliste (HCL) die Serverhardware für IAS aus. Auf diese Weise vermeiden Sie Probleme im Zusammenhang mit Ausfallsicherheit und Kompatibilität, die bei ungeprüfter Hardware und nicht getesteten Gerätetreibern auftreten können.

Stellen Sie sicher, dass Ihre IAS-Server die empfohlenen Hardwarevoraussetzungen für Windows Server 2003 erfüllen. Berücksichtigen Sie unbedingt auch andere Dienste, die ebenfalls auf dem System ausgeführt werden könnten, wie z. B. Active Directory. Es empfiehlt sich häufig, die IAS-Serverhardware so zu planen, dass sie auch das Doppelte der von Ihnen erwarteten Authentifizierungslast pro Server bewältigen kann. So gewährleisten Sie, dass die entsprechenden Serverressourcen bereitstehen, um mit Serverfailoverszenarien und ungewöhnlichen Netzwerkzuständen umzugehen.

Die folgende Abbildung stellt anhand des Serverlayouts des fiktiven Unternehmens Woodgrove Bank ein Beispiel für den IAS-basierten RADIUS-Serverentwurf dar. Aus der Abbildung gehen der Standort und die Anzahl der IAS-Server hervor, die für die erwartete Benutzerverteilung und Last im Unternehmen erforderlich sind. Für die Zwecke dieses Handbuchs wurde aber nur ein Teil dieser Infrastruktur (unter Verwendung des Hubs in London und der Regionalbüros in Johannesburg) getestet.

Hinweis: Die Woodgrove Bank ist ein fiktives Unternehmen, das als typisches Beispiel für ein mittelgroßes bis großes Unternehmen fungiert. Ihre Netzwerkarchitektur und -merkmale bildeten die Grundlage für eine Reihe von Entwurfsentscheidungen zur Implementierung dieser Lösung.

Abbildung 5.6: Verteilung der Benutzer, WLAN-APs und IAS-Server der Woodgrove Bank
Bild in voller Größe anzeigen

Diese Lösung wurde mit zwei RADIUS-Servern in einem Hauptsitz mit 6.742 Benutzern konzipiert. Nur 50 % der Benutzer hatten Zugang zum WLAN. Das bedeutet, dass sich 3.371 Benutzer und die 3.371 Geräte dieser Benutzer zu den Hauptgeschäftszeiten per EAP-TLS bei den beiden RADIUS-Servern authentifizieren können. Jeder Server kann also während der 30-minütigen Hauptanmeldezeit 3.371 Authentifizierungen vornehmen. Die Last der Hauptanmeldezeit entspricht in etwa zwei neuen EAP-TLS-Authentifizierungen pro Sekunde mit der Kapazität, im Falle eines Serverfailovers vier neue Authentifizierungen pro Sekunde durchführen zu können.

Der Server wurde so konfiguriert, dass RADIUS-Authentifizierungs- und -Kontoführungsanforderungen in Textdateien protokolliert werden. Bei diesem Server handelte es sich um einen dedizierten RADIUS-Server; für Domänencontrollerdienste wurden andere Server eingesetzt.  In die RADIUS-Serverhardwarespezifikation wurden von vornherein zusätzliche Kapazitäten für mögliche zukünftige Anforderungen an die Netzwerkzugriffssteuerung für Anwendungen wie VPN, drahtgebundene Netzwerke und DFÜ-Zugriff eingebaut.

Die folgende Tabelle gibt einen Überblick über die während des Tests dieser Lösung verwendete IAS-Serverhardware.

Tabelle 5.9: Getestete Serverhardware

Die Hardwareanforderungen für Ihre IAS-Server werden vermutlich von den hier aufgeführten abweichen. Ermitteln Sie daher Ihre konkreten Anforderungen anhand der spezifischen Variablen für Ihr Unternehmen.

Festlegen der Server-Softwareanforderungen

Sie müssen bestimmen, ob für die IAS-Server in Ihrer Umgebung Windows Server 2003 Standard Edition oder Enterprise Edition verwendet werden soll. Windows Server 2003 Standard Edition kann maximal 50 RADIUS-Clients (z. B. WLAN-APS) und zwei Serverroutinggruppen unterstützen.

Diese Lösung wurde mit Windows Server 2003 Enterprise Edition für die RADIUS-Server am Hubstandort und mit Windows Server 2003 Standard Edition für RADIUS-Server in der Zweigstelle getestet. Die Lösung funktioniert aber auch mit den zuvor genannten Einschränkungen der beiden Softwareversionen gleichermaßen gut.

Abhängig von Ihrer Umgebung und den in Ihrem Unternehmen geltenden Standards können noch weitere Softwarekomponenten erforderlich sein, wie z. B.:

Zum Seitenanfang

Erstellen eines Verwaltungsplans

IAS-basierte RADIUS-Server erfordern relativ wenig Wartung, um eine kontinuierliche Dienstverfügbarkeit und Netzwerksicherheit sicherstellen zu können. Sie sollten Ihre IAS-Verwaltungsstrategie jedoch bereits zu Beginn Ihres WLAN-Projekts festlegen, so dass Sie sicherstellen können, dass die entsprechenden Mitarbeiter für die Verwaltung der RADIUS-Infrastruktur geschult und ausgestattet werden.

Änderungs- und Konfigurationsverwaltung

Zum Sicherstellen der Dienstverfügbarkeit und der Netzwerksicherheit ist es überaus wichtig, einen als funktionierend bekannten Zustand der IAS-Server beizubehalten. IAS ermöglicht Transaktionsänderungen verschiedener Serverkonfigurationselemente über den Befehl netsh und macht daher ein einfaches Rollback für den Fall möglich, dass eine Änderung ein unvorhergesehenes Verhalten hervorruft.

Mithilfe des Befehls netsh können Sie die IAS-Konfiguration vollständig oder teilweise in Textdateien exportieren bzw. daraus importieren. Sie können diese Dateien verwenden, um IAS-Servereinstellungen zu replizieren und so Konfigurationsänderungen in großen Umgebungen schneller umzusetzen.

Die für die entsprechende Änderungs- und Konfigurationsverwaltung erforderlichen Aufgaben finden Sie in Kapitel 12, "Verwalten der RADIUS-Infrastruktur für die WLAN-Absicherung".

Planen der Dienstwiederherstellung

Um eine schnelle Wiederherstellung Ihres RADIUS-Dienstes nach einem Ausfall sicherstellen zu können, muss vorab eine sorgfältige Planung erfolgen. Zur Optimierung der Installation und Konfiguration von IAS stehen Ihnen die zusammen mit diesem Handbuch bereitgestellten Installationsskripts zur Verfügung. Mithilfe der ebenfalls bereitgestellten netsh-Skripts lassen sich die zum schnellen Wiederherstellen des IAS-Konfigurationsstatus notwendigen Schritte mühelos automatisieren. Weitere Informationen zu den Aufgaben im Zusammenhang mit der Wiederherstellung des Dienstes finden Sie in Kapitel 12, "Verwalten der RADIUS-Infrastruktur für die WLAN-Absicherung".

Planen von administrativen Berechtigungen

IAS ist eine optionale Komponente von Windows Server 2003 und erfordert daher kein anderes administratives Sicherheitsmodell als das des lokalen Servers. Die völlige Trennung der IAS-Verwaltung von der Verwaltung der lokalen Server ist nicht möglich. Eine gewisse Trennung können Sie durch eine benutzerdefinierte Entwicklung erreichen, indem Sie z. B. eine gesicherte Webanwendung erstellen, mit der über ein bevorzugtes Konto mit administrativen Berechtigungen für die lokalen Server Änderungen an der IAS-Konfiguration vorgenommen werden.

Dennoch ist es weiterhin wichtig, die erforderlichen Berechtigungen und Zugriffsanforderungen für die unterschiedlichen IAS-Ressourcen zu planen, um ein Modell mit möglichst wenigen Berechtigungen zu entwickeln. Die folgende Tabelle enthält Beispiele für Rollen und Aufgaben im Zusammenhang mit IAS-Servern.

Tabelle 5.10: Beschreibungen und Aufgaben von IAS-Rollen

Die folgende Tabelle gibt einen Überblick über die zum Durchführen der verschiedenen IAS-Serveraufgaben erforderlichen Ressourcenberechtigungen.

Tabelle 5.11: Für IAS-Serveraufgaben erforderliche Berechtigungen

Sicherheitsüberwachung und -prüfung

IAS ist eine Komponente Ihrer Sicherheitsinfrastruktur, die Sie proaktiv überwachen sollten. Untersuchungen in der Sicherheitsindustrie haben gezeigt, dass erfolgreichen Angriffen in der Regel eine Reihe nicht erfolgreicher Angriffe vorausgehen. Proaktive Sicherheitsüberwachung der IAS-Server und der dazu gehörenden Protokolle im Hinblick auf verdächtiges Verhalten ist erforderlich, wenn Sie erkennen möchten, ob Ihr Netzwerk angegriffen wird.

In der folgenden Tabelle finden Sie eine Auflistung möglicher Bedrohungen, auf die Sie Ihre IAS-Serverinfrastruktur überwachen sollten.

Tabelle 5.12: Bedrohungen für die IAS-Serverinfrastruktur

Neben der einfachen Sicherheitsüberwachung empfiehlt Microsoft, die IAS-Server regelmäßig auf potenzielle Sicherheitsprobleme zu prüfen und mithilfe Ihrer Überwachungstechnologie alle Anfälligkeiten, die Sie in Ihrer Netzwerkinfrastruktur gefunden haben, klar zu definieren und das daraus erwachsende Risiko zu mindern.

In der folgenden Tabelle sind potenzielle Bedrohungen für eine IAS-Serverinfrastruktur und die entsprechenden Technologien aufgeführt, anhand derer Sie Ihre IAS-Infrastruktur auf Sicherheitsprobleme überwachen können.

Tabelle 5.13: Proaktive Überwachung der IAS-Serverinfrastruktur auf Bedrohungen

Zum Seitenanfang

Zusammenfassung

In diesem Kapitel wurde der Prozess der Erarbeitung eines RADIUS-Infrastrukturentwurfs für die Unterstützung eines sicheren WLANs auf 802.1X-Basis beschrieben. Der in diesem Kapitel beschriebene Entwurf einer RADIUS-Infrastruktur ist so flexibel, dass er sich für eine Vielfalt zukünftiger Anforderungen erweitern lässt. Sie können den Infrastrukturentwurf auch für andere Arten der Netzwerkzugriffsverwaltung verwenden.

Der in diesem Kapitel beschriebene Entwurf bildet die Grundlage für die in den nächsten Kapiteln beschriebene Implementierung der RADIUS-Infrastruktur. Im folgenden Kapitel wird näher auf den generischen RADIUS-Entwurf eingegangen, um so die 802.1X-Einstellungen und die WLAN-Infrastruktur zu beschreiben, die für die Implementierung der verbleibenden Komponenten der WLAN-Sicherheitsinfrastruktur nötig sind.

Weitere Informationen

Weitere Informationen zum IAS finden Sie unter:

Weitere Informationen zu 802.1X-WLAN-Technologien finden Sie unter:

Zum Seitenanfang

5 von 6