802.1x - Zugang zum Netzwerk steuern

Sogar mit dem Windows Home Server ist es möglich einen IAS-Server zu betreiben
http://www.heise.de/netze/artikel/Windows-Home-Server-sichert-WLAN-1206446.html

Plug'n Play und DHCP ist nett, aber wenn sie ein Firmennetzwerk betreiben, dann ist es schon ein ungutes Gefühl, die offenen Netzwerkdosen oder Wireless Zugänge zu sehen. Ohne viel Arbeit kann jemand eine Verbindung herstellen und bekommt meist auch eine IP-Adresse samt Gateway, DNS-Server und per WPad vielleicht noch den Proxy Server. Niemand würde seine Haustür offen lassen und auf den Schutz der inneren Türen vertrauen.

Hier muss erst einmal das physikalische Netzwerk untersucht werden. Wenn ich mit meinem Notebook mich einfach an einen freien Port anschließen kann oder einen Mini-Hub in das Anschlusskabel eines anderen PCs oder Druckers einschleife, dann ist der Weg frei für interne Angriffe mit voller Brandbreite. Viele Firmen haben ja nur Angst vor Angriffen aus dem Internet. Das ist aber ein Irrtum.

Zugriffskontrolle auf Netzwerkebene

Bei Netzwerken setzt sich diese Ansicht aber erst langsam durch, weil viele Administratoren ein "einfaches" LAN lieben und oft mit einem Subnetz und einer Menge von Switches arbeiten. Plug'n Play eben. Beim ersten AccessPoint kann man auch noch gut den WPA-PSK Schlüssel den Mitarbeitern geben, aber irgendwann sollte es ihnen doch mulmig werden, dass allein das Wissen um den Schlüssel schon eine Verbindung erlaubt.

Gesucht wird eine Zugangskontrolle zum Netzwerk, ehe schon eine IP-Adresse vergeben ist.

Dazu gibt es mehrere verschiedene Optionen:

  • aktive/inaktive Anschlüsse/Ports
    Selbst wenn PCs heute nur noch einige hundert Euro kosten, so sind es dennoch Anlagegüter, die ordnungsgemäß verbucht und inventarisiert sein müssen. Da sollte es doch ein einfaches sein, auch den Anschluss eines PCs mit einem Switch zu verknüpfen und ungenutzte Ports zu sperren oder den Patch zu entfernen. Wenn Sie natürlich die "schnelle fliegende Verbindung" in Besprechungsräumen nutzen wollen, dann gibt es weitere Alternativen
  • MAC-Adressen Authentifizierung
    Eine ist z.B.: die Steuerung des Zugriffs über die MAC-Adresse. Diese Adresse ist pro Netzwerkkarte eindeutig (Ausnahmen gibt es leider doch z.B.: bei Nachbauten und diese Adresse kann leider auch per Software bei vielen Karten geändert werden). Der Zugriffschutz ist dabei daher eher schwach einzuschätzen. Allerdings sind nur sehr gute Angreifer so gut, ihre MAC-Adresse schon beim ersten Zugriff auf eine bekannte Adresse zu senden. Wenn ihr Switch daher unbekannte Adressen meldet und den Zugriff blockiert, bis Sie als Administrator diese als "erwünscht" aufführen, dann ist eine Freizügigkeit weiterhin innerhalb ihrer Firma möglich aber der Anschluss unbekannter Endgeräte ist zumindest erschwert.

Beide Verfahren haben aber da Problem, dass sie "statisch" sind und keine Antwort für drahtlose Verbindungen haben und auch aktive bestehende Ports nicht wirklich absichern können. Selbst MAC-Adressen kann heute schon jede Netzwerkkarte manuell pflegen:

Insofern ist eine MAC-Filterung nur eine kleine Hürde.

802.1x Authentifizierung

Viel besser ist es hier doch die sowieso vorhandenen Anmeldedaten des Clients (Computerkonto) oder des Anwenders zu verwenden, um nicht nur den Zugriff auf Server und Ressourcen zu steuern, sondern auch den Netzwerkzugriff. Und tatsächlich gibt es über das Verfahren 802.1x einen Weg, dass entsprechend taugliche Switches und WiFi-Accesspoints vom kompatiblen Client eine Anmeldung abfragen.

Der Client muss dann noch eher er eine IP-Adresse und Zugriff auf das LAN erhält, sich anmelden. Dazu werden MAC-Pakete verwendet, die nicht auf einem Protokoll wie TCP/IP, IPX o.��. basieren. Stark vereinfacht haben wir dazu folgendes Bild:

Am Beispiel eines "drahtgebundenen" PCs aktiviert dieser nach dem Einschalten den "Link". Der Switch erkennt, dass an dem Port ein Gerät aktiviert wurde und sendet ihm die Information, dass der Client sich bitte anmelden möge. Zudem sendet der Switch bei Bedarf auch ein Zertifikat mit, damit die Daten vom Client verschlüsselt werden können. Hier ein Auszug aus einem Netzwerk Monitor Mitschnitt:

Netmon 8021x

Der Switch (Im Beispiel ein Enterasys) fordert vom Client die Identifizierung an, die der Client auch sendet (nur Benutzername oder Identität). Allerdings reicht das nicht, so dass er Switch eine Anmeldung mit Zertifikaten anfordert (PEAP).

Sofern der Client diese Funktion unterstützt, gibt es für die Anmeldung zwei Optionen:

  1. Zertifikatbasierte Anmeldung
    Mit 802.1x ist es möglich, dem Client ein "Client Zertifikat" zu hinterlegen, welches er dann zu Anmeldung verwendet. Damit muss man auf dem Client kein Kennwort hinterlegen oder eingeben und wenn das Zertifikat fest im Gerät verankert ist, ist damit auch schon fast eine starke Anmeldung sicher gestellt.
  2. Benutzername und Kennwort
    Alternativ kann auch eine Angabe von Anmeldedaten (Benutzername, Kennwort, Domäne o.ä.) möglich sein. Das schließt je nach System aber eine automatische Anmeldung aus.

Die übermittelten Anmeldedaten gehen an den RADIUS-Server (Windows Administratoren können vielleicht eher den Dienst "Internet Authentication Service (IAS)". Hier kann dann über Gruppen und Profile die Antwort bestimmt werden. Der RADIUS-Server kann also nicht nur "JA" oder "NEIN" sagen, sondern auch Parameter mitgeben. Der Switch kann dann abhängig von den Parametern den Port sogar in ein passendes VLAN dynamisch patchen oder Port Security Regeln anwenden. So kann z.B. normalen Anwendern der Zugriff per RDP auf Server unterbunden werden.

802.1x ist bei "Wired"-LAN kein 100% Schutz, denn durch das Zwischenschalten eines Hubs kann ein PC sich am Switch anmelden und alle anderen Systeme am gleichen Hub dessen Berechtigungen nutzen. Dies kann aber (Mehrere MAC-Adressen an einem Port) bei vielen Switches verhindert werden.

802.1x schützt ausschließlich den Zugang zum physikalischen Netzwerk, aber nie den Datenverkehr als solches. ist hier eine Verschlüsselung erforderlich, dann sind IPSec, VPN oder ein Tunnel von Applikationsprotokollen über SSL (https, POP3S, SecureRTP bei VoIP.) erforderlich.

Der lange Anmeldeprozess

Auch wenn das vorige Kapitel in aller Kürze aufzeigt, wie die Anmeldung eines Clients am Switch zum Radius durchgereicht wird, so ist die nur die Kurzfassung. Die meisten Switches unterstützen nicht nur die Anmeldung per 802.1x sondern erlauben auch eine Anmeldung per MAC-Adresse und natürlich eine Einstellung, die für nicht authentifizierte Ports greift. Während ein PC hochfährt startet vielleicht eine PXE-Netzwerkkarte, die natürlich kein 802.1x kann und auf eine Fallback Option per MAC-Authentifizierung hofft, damit eine Erstinstallation oder Management möglich ist. Wenn dann Windows startet, kann der Computer sich nun "richig" anmelden.

Wenn wenn der Benutzer sich dann anmeldet und der Client entsprechend konfiguriert ist, wird die Anmeldung am Switch erneut geändert. Es kann dann sogar passieren, dass ich auf dem PC jemand "lokal" anmeldet und der PC damit wieder weniger Rechte hat, als wenn niemand angemeldet ist.

Zu beachten ist ebenfalls, dass der Computer oder primäre Account angemeldet und am Switch authentifiziert ist. Dienste, die mit einem anderen Benutzernamen laufen, haben nicht die dem Benutzer zugeordnete Netzwerkberechtigung.

802.1x und WiFi

Die Anmeldung mittels 802.1x ist besonders beim Einsatz von drahtlosen Verbindungen interessant, da hier der Zugriff über die Identität des Benutzers oder Computers und nicht mehr über einen gemeinsam genutzten Schlüssel (WEP, WPA-PSK o.ä.) erfolgt, d.h. der eigentliche Netzwerkverkehr ist zwar sicher mit WPA2/AES verschlüsselt, aber eben nicht mehr mit einem "Preshared" Key. Nach erfolgreicher Authentifizierung erhält der Anwender einen temporären Schlüssel. Die Details sind natürlich vom verwendeten Verfahren abhängig.

Früher waren solche Access-Points noch richtig teuer aber das ist schon länger nicht mehr der Fall. Das bislang günstigste Gerät, welches ich eigentlich als WiFi-Repeater gekauft habe, war ein EDIMAX BR-6428nS ( http://www.edimax.com/en/prodUCE_detail.php?pd_id=371&pl1_id=24&pl2_id=89 ) für unter 25€, der auch schon 300MBit mit 802.1x unterstützt hat und in weniger als 5 Minuten installiert war.

Natürlich fehlen so einem "Consumer-Gerät" ein paar nützliche Funktionen wie z.B. Meldungen per SYSLOG, Abfragen per SNMP, das Eintragen eines zweiten Radius-Servers zur besseren Verfügbarkeit. Zudem kann er nicht per "PowerOverEthernet" mit Strom versorgt werden und kann natürlich abhängig von der erfolgten Anmeldung die Clients auch nicht in verschiedene VLANs einsortieren, mehrere SSIDs anbieten oder sogar Firewallpolicies anwenden. Aber wer heute noch WEP/WPA/WPA2 mit "Preshared Key" macht, d.h. alle Mitarbeiter nutzen den gleichen WiFi-Key) kann sich langsam nicht mehr herausreden, dass es ja so schwierig und teuer wäre.

Kostengünstige Systeme, die ich selbst mit 802.1x in mein LAN integriert habe. Diese Liste ist weder vollständig noch repräsentativ und enthält nur "günstige" Systeme unter 100 Euro. Ich möchte Sie damit neugierig und zu Experimenten mit 802.1x animieren.

Gerät Preis Eckdaten Bemerkung

DLink DIR-655

80€

130MBit WiFi, 4x Gigabit, WAN-Port, USB

Zwei Radius-Server pflegbar. Aber braucht ein paar Firmware-Updates und ein Tausch, bis es stabil lief

Edimax 6428nS

24€

300MBit WiFi, 4x 100MBit, WANPort

Der bislang günstigste System, das ich eher zufällig

Weitere Geräte können folgen. Versuchen Sie damit aber nicht eine flächendeckende WiFi-Struktur in einem großen Umfeld aufzubauen. Dies ist entspricht eher dem SBS-Server und nicht einer Exchange Organisation mit vielen Standorten. Es gibt einen Markt für die "Enterprise-Lösungen".

802.1x Geräte

Die Unterstützung von 802.1x ist gar nicht mal so selten verbreitet. Viele modernen Betriebssysteme haben die Funktion von Hause aus eingebaut und teilweise sogar schon aktiviert.

Gerät/Betriebssystem Drahtlos Verkabelt

Windows 2000 SP4

Aktiv ?

Aktiv =?

Windows XP SP1 oder neuer

Aktiv ?

Aktiv =?

Windows Vista

Dienst muss gestartet werden

Aktiv

Windows 7

Aktiv

Aktiv

Ubuntu

?

?

Windows Mobile 6.5

Aktiv

entfällt

Drucker

Speziell höherwertige Drucker (Ricoh etc.) unterstützen auch 802.1x. Als Firma muss man sich hier schon frühzeitig seine Gedanken machen. Aber auch ohne 802.1x auf dem Drucker hat eine Firma immer noch die Wahl zwischen einem eigenen VLAN für Drucker, welches z.B. nur vom Druckerserver über Port 9100 (RAW) oder 515 (LPD) erreichbar ist oder die Authentifizierung per MAC-Adresse

802.1x und MAC-Fallback für inkompatible Geräte

Dennoch gibt es immer noch Geräte, die natürlich keine Authentifizierung unterstützen, z.B. Kassensysteme, Drucker, Scanner, Zeiterfassungssysteme etc. Es ist manchmal schon erstaunlich, wie viele Geräte heute schon einen Ethernet-Port oder eine WiFi-Schnittstelle haben.

Ebenso kann sich ein PC nur dann im LAN authentifizieren, wenn er auch Mitglied der Domäne ist. Wenn Sie aber einen per per RIS/Windows Deployment Services installieren wollen, dann kann er sich noch nicht anmelden. Denkbar ist dann z.B. der Weg, dass Sie die Installation entweder in einem eigenen "Installations-LAN" durchführen, auf dem Port 802.1x abschalten oder die MAC-Adresse als Schlüssel verwenden

Einige Switches unterstützen eine Funktion, mit der Systeme als Fallback anhand der MAC-Adresse an einem RADIUS-Server authentifiziert werden können. Wenn der angeschlossene Client kein gültige Anmeldung vorweist, dann nutzt der Switch die MAC-Adresse und versucht hiermit eine Anmeldung. Einige Switches nutzen dabei die MAC-Adresse als Benutzername und Kennwort (z.B. HP ProCurve nutzen als Kennwort die MAC-Adresse in klein Buchstaben Andere Switches nutzen die MAC-Adresse als Benutzername und ein vordefiniertes Kennwort. In beiden Fällen muss man dann im Active Directory die entsprechenden Benutzer (MAC-Adresse = SamAccountName) mit dem passenden Kennwort einrichten und über Gruppen und Radius-Richtlinien konfigurieren. Einige Switche unterstützen dann nur CHAP, so dass Sie das Kennwort im AD reversibel speichern müssen.

Die Anmeldung kann damit aber schon sehr kompliziert werden und der PC mehrfach einer anderen Policy unterworfen werden.

Alternativ können Sie natürlich immer noch pro Port ein festes VLAN vorgeben. Wenn ein Gerät so reduziert ist, dann muss es aber auch meist nicht direkt im "Haus-LAN" angeschlossen sein. Meist sind die Kommunikationsverbindungen solcher Systeme klar bekannt und Sie können Sie in ein eigenes VLAN verbannen, welches über eine Firewall oder einen Router mit Portfiltern einen Einbruch erschwert.

Benutzer und Computeranmeldung

Startet ein Computer, z.B.: unter Windows, dann ist im ersten Moment ja noch niemand angemeldet. Der Computer selbst hat aber auch ein gültiges Computerkonto und wenn Sie die Anmeldung entsprechend konfiguriert haben, dann hat der Computer auch ein Zertifikat bekommen (Auto Enrollment) und meldet sich am Netzwerk an. Das ist sehr nützlich, denn zum einen kann so ein Helpdesk schon auf das System zugreifen, Software Verteilen oder Patches und Virenscanner prüfen. Aber erforderlich ist dies auch, damit sich an dem PC überhaupt an Anwender erstmalig anmelden kann. Ohne Verbindung zum DC kann können Anmeldung aber auch Gruppenrichtlinien gar nicht greifen.

Aber oft ist es ja gar nicht gewünscht, dass der Anwender nach der Anmeldung an Windows eine neue 802.1x Authentifizierung anstößt (und z.B. aufgrund von Zertifikaten gar nicht machen kann). Bei Windows Vista und Windows 7 kann dies in den Eigenschaften einstellt werden:

Bei Windows XP geht das nicht so einfach, da die entsprechende GuI fehlt. Hier hilft dann entweder ein Registrierungsschlüssel:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global]
"AuthMode"=dword:00000002

Dabei bedeutet 2 = nur Computeranmeldung, 1=Benutzeranmeldung erforderlich und 0 = Default

  • 929847 How to enable computer-only authentication für an 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack 3

Eleganter ist aber auch hier der Weg über die Gruppenrichtlinien von Windows 2008, die über die Erweiterungen diese Einstellungen pro SSID einstellen können:

Laufen auf einem Computer übrigens Dienste mit eigenem Dienstkonto, dann melden sich diese nicht an, da ein Switch-Port erst mal nur einer Policy und Authentifizierung gehorcht. (Was nicht ganz richtig ist, da einige Telefone mit durch geschleiften Port dies können.

Systeme, die nicht an einem Port mit 802.1x betrieben werden sollten.

Sie sollen genau prüfen, auf welchen Ports ihres Switch sie 802.1x erzwingen. 802.1x schützt den Zugang zum Netzwerk um über den Weg den Zugang zu Servern zu erschweren. Wenn ich sowieso schon vor dem Server stehe, dann wird mich auch kein Netzwerkschutz vor dem Zugriff abhalten. Aber auch aus Betriebsaspekten sollten sie z.B. folgende Ausnahmen machen:

  • Server und DCs
    Nicht nur dass Server besser statisch in VLANs konfiguriert werden und die 802.1x Anmeldung unterbleiben kann. Stellen sie sich vor sie haben aus Versehen den Port mit dem RADIUS-Server aktiviert. Dann kann der Switch selbst nicht mehr die Anmeldungen prüfen etc. Insofern sollten sie "gesicherte Ports und Verbindungen" im Rechenzentrum selbst vielleicht ausnehmen
  • Uplinks und Trunks
    Auch die Verbindung zwischen Switches und Routern sollten Sie ausnehmen, da die Geräte sich sowieso nicht gegeneinander anmelden können und auch Steuerungsprotokolle (z.B. Spanning Tree) nicht immer korrekt damit umgehen können
  • Management und Monitoring Ports
    In Servern sind oft Überwachungsfunktionen eingebaut. Auch Netzwerkgeräte werden oft über ein separates Netzwerk verwaltet, so dass Management von Nutzdaten getrennt sind. Diese Ports sind natürlich auch nicht 802.1x-Relevant. Das gleiche gilt natürlich für "Mirror-Ports", welche sie auf einem Switch für Diagnosezwecke verwenden.

Allgemein sollten Sie also primär die Ports absichern, welche außerhalb des "gesicherten Rechenzentrums" überhaupt das Potential haben, mit fremden Geräten verbunden zu werden.

802.1x mit VLAN-Change oder Port Security

Wer schon den Schritt getan hat, die Endgeräte zu identifizieren muss natürlich auch Schritte unternehmen, um unbekannte oder nicht zugelassene Endgeräte zu behandeln. Den Port abzuschalten ist keine Lösung, da dann der Switch auch ein legitimes Endgerät nicht mehr erkennen könnte. Aber die meisten Switches erlauben eine dynamische Konfiguration des Ports abhängig von der erfolgten Anmeldung und den Rückmeldungen des Radius-Server:

  • Port Security (ohne IP-Change)
    Es gibt Switches, welche quasi "Firewall-regeln" pro Port einsetzen können. Auch wenn sie netzwerktechnisch weiterhin "nur" ein Layer-2 Gerät sind, die Pakete anhand der MAC-Adresse weiter leiten, können einige auch TCP verstehen und anhand der IP-Adressen und Protokoll-Ports Pakete verwerfen. Oft sind solche Switche in Verbindung mit einem IDS (Intrusion Detection System) und einer zentralen Verwaltung sinnvoll zu betreiben. Nur die harten Administratoren pflegen wird Firewall-Regeln pro Switch-Port über einen TELNET und die Kommandozeile.
  • VLAN Change (mit IP-Change)
    Eine andere und einfachere Umsetzung ist die Zuordnung eines Switch-Ports zu einem VLAN. Abhängig von der Anmeldung des Clients wird der Port von dem Status "unbekannt" in das konfigurierte VLAN konfiguriert. Ein VLAN-Wechsel bedeutet aber auch, dass der Client eventuell einen Wechsel der IP-Adresse durchführt. Das kann natürlich während einer bereits aktiven Verbindung (z.B. Kerberos, NETLOGON, SYSVOL etc.) sehr störend sein.

Das Wechsel der IP-Adresse ist tatsächlich ein nicht zu vernachlässigendes Problem beim Einsatz von Port Security mit 802.1x da ein PC ja drei verschiedene Zustände haben kann: (vereinfacht)

Ein System, welches 802.1x nicht unterstützt oder sich nicht anmelden kann (z.B.: ein Gast), muss ja nicht unbedingt "ausgesperrt" sein. Er kann ja durchaus Mitglied in einem "Gäste-VLAN" sein, um z.B. Zugriffe auf ausgewählte Internetseiten zuzulassen oder über eine weitere Proxy-Anmeldung dem Gast einen Zugang zu gewähren. Aber denken Sie auch an neue Computer, die sie gerade aufsetzen oder ein "Problem" haben und daher nicht angemeldet werden oder sie mit "NAP" arbeiten, um nur Systeme mit einem Mindestpatchstand zuzulassen. So ist es durchaus sinnvoll, aus dem Standard-Zugang einen Zugriff auf einen WSUS-Server, eine Möglichkeit der Fernwartung, Softwareverteilung und Inventarisierung zu erlauben.

Damit sich ein Computer oder der Anwender überhaupt anmelden kann, müssen auch grundlegende Active Directory Funktionen (NTP, DNS, Kerberos, GC, LDAP) weiterhin angeboten werden, es sei denn Sie trennen die Netzwerkanmeldung von der Active Directory Anmeldung. Technisch ist dies möglich.

Arbeiten Sie mit VLANS (und wechselnder IP-Adresse) so kann es passieren, dass ein PC eingeschaltet wird und erst mal im "GAST-VLAN" mit einer IP-Adresse versehen wird, ehe er sich per 802.1x als Computer anmeldet und dann in das "angemeldete Computer"-VLAN wechselt.

Achtung:
Die Bereitstellung einer "Gast-Verbindung" kann dazu führen, dass die IP-Adressen für Gäste durch eigene Clients aufgebraucht werden, besonders wenn ein Netzwerkausfall die normale Funktion und Anmeldung der Clients verhindert.

Meldet sich dann ein Benutzer auf dem Computer an, dann wechselt er erneut dann in das entsprechende Benutzer-VLAN. Ein Wechsel einer IP-Adresse macht aber in den meisten Fällen Probleme, da der Client noch im Computer-VLAN eine Verbindung zu DC aufrecht erhält, die aber nach der erfolgreichen Anmeldung (aber noch vor der Ausführung des Anmeldeskripts) getrennt wird.

Denken Sie dann auch an Server und vor allem Terminal Server. Es ist natürlich auch möglich, 802.1x auf den Serveranschlüssen zu aktivieren. Aber zumindest auf dem Radius-Server führt dies definitiv zu Problemen, weil er sich dann selbst nicht mehr anmelden kann. Auch beim Einsatz von Terminal Servern gilt die Einschränkung, dass es nur eine Netzwerkkarte gibt und mehrere Benutzer den Server gleichzeitig benutzen. Noch hat nicht jeder Benutzer seine eigene Netzwerkkarte mit passendem VLAN und selbst dann würde ja die Verbindung vom RDP/ICA-Client zum Server auch den Netzwerkwechsel nicht überleben.

Zuletzt gibt es natürlich noch DNS und WINS-Cached und Replikationen, die einen Wechsel der IP-Adresse nicht sofort auf allen Systeme auch bekannt werden lässt.

VLANs mit eigenen Subnetzen haben aber den Vorteil, dass der Support allein anhand der IP-Adresse erkennen kann, welche 802.1x-Richtlinie wohl nun an dem PC anliegt. Arbeitet der Switch hingegen mit "Firewall-Regel", dann ist das für den Support nicht mehr am Client erkennbar. Gute Systeme erlauben hier ein Nachschlagen der aktuellen Einstellungen z.B.: über einen Webbrowser. Moderne Switches wissen nicht nur, welche MAC an welchem Port anliegt, sondern können meist auch die dort verwendeten IP-Adressen und natürlich 802.1x Anmeldedaten.

Im ISA/NPS ist das das Feld "Tunnel-Pvt-Group-ID" bei den meisten Switches für die Zuordnung des VLANs zuständig.

Andererseits muss man natürlich zwischen verschiedenen Switches dann alle VLANs in die verschiedenen Stockwerte über die Trunks und uplinks bringen.

Alle Ports die "untagged" sind, erwarten von den Clients und senden an die Clients die Ethernet Pakete ohne VLAN-Tag, d.h. der Switch bestimmt dann, in welches VLAN der Port gehört. Zwischen Switches oder Netzwerkkarten, die selbst mehrere VLANs unterstützen, muss der Port dann "Tagged" sein und auch für die Liste der VLANs über diesen Port konfiguriert sein. Die Beschreibung von 3Com zeigt das gut auf.

802.1x Zertifikate

Weiter oben habe ich schon beschrieben, dass die Anmeldung via 802.1x auch über Zertifikate erfolgen kann. Dabei gibt es wieder einmal zwei Seiten zu unterscheiden:

  • Radius-Zertifikat
    Auf dem Radius-Server muss zur Verwendung von EAP oder PEAP ein entsprechendes Zertifikat installiert werden. Dieses Zertifikat muss ein "Radius/RemoteAccess-Zertifikat" sein. Der Radius-Server zeigt nur die Zertifikate an, die auch für Radius vorgesehen sind. Zudem darf der Anzeigename des Zertifikats nicht leer sein.

Achtung: Eine Zertifizierungsstelle auf einem Windows Standard Server unterstützt nicht das Template für IAS/RADIUS-Zertifikate. Es muss also ein anderes Zertifikat oder eine Windows Enterprise Version sein. Sie können aber mit OpenSSL natürlich auch ein Selbst-Zertifikat erstellen oder gleich ein offizielles Zertifikat kaufen.
Allerdings scheint ein DomainController-Zertifikat, welches auch eine Standard-CA für einen DC erstellt, für Radius gültig zu sein. In einer kleineren Umgebung reicht daher auch die Installation des Radius auf einem Domain Controller.

  • Client-Zertifikat
    Wenn auch der Client sich mittels Zertifikate anmelden soll, dann benötigt er natürlich auch ein einsprechendes Client Zertifikat.

Meist kommt in solchem Umfeldern eine eigene private Zertifizierungsstelle (Windows CA oder OpenSSL) zum Einsatz, da kaum jemand für jeden Computer kommerzielle Zertifikate beschaffen wird. Allerdings kann es sinnvoll sein, zumindest das Zertifikat auf dem Server von einer vertrauenswürdigen Zertifizierungsstelle zu kaufen, damit auch Clients ohne Warnungen arbeiten können, die nicht das Stammzertifikat ihrer Organisationszertifizierungsstelle haben.

802.1x auf Windows Domainclients

Eine Schritt für Schritt Anleitung zur Einrichtung eines Netzwerks mit Radius, Switch, Zertifizierungsstelle etc. würde den Rahmen der MSXFAQ sprengen und im Bezug auf einen verwendeten Switch nur einen kleinen Teil abdecken. Wenden Sie sich hierzu entweder an ihre IT-Abteilung, ihren Dienstleister für die Netzwerkinfrastruktur oder ein anderes Systemhaus, dem Sie die Umsetzung zutrauen.

Allerdings sind die Einstellungen auf dem Windows Client schon allgemein gültig:

  • Windows Vista
    Bei Vista wurde die 802.1x Authentifizierung in zwei Dienste aufgeteilt. Um die Authentifizierung auch über Ethernet zu aktivieren, muss der Dienst gestartet werden, welcher normalerweise auf "manuell" steht

    Eine Gruppenrichtlinie kann dies zentral steuern, wie auch die anderen 802.1x Parameter
  • Windows XP
    Auch bei Windows XP wurde die 802.1x Authentifizierung für kabelgebundene Verbindungen in einen eigenen Dienst ausgelagert, der per Default auf "Manuell" steht:

Die beiden Dienste heißen:

  • DOT3SVC
    Automatische Konfiguration (verkabelt)
    Dieser Dienst führt eine IEEE 802.1X-Authentifizierung auf Ethernet-Schnittstellen aus.
  • WZCSVC
    Konfigurationsfreie drahtlose Verbindung
    Bietet automatische Konfiguration für 802.11-Adapter.

Die Dienste können natürlich über Gruppenrichtlinien auf "automatisch" gestellt werden.

Leider lassen sich weitere 802.1x Einstellungen nicht ��ber die Gruppenrichtlinien steuern. Selbst bei Windows Vista lassen sich nur drahtlose 802.1x-Parameter steuern. Hier ist also Luft für Zusatzprogramme, eigene VBScript und andere Einstellungen.

Auf der Webseite von Enterasys (http://www.enterasys.com/support/tools.html) gibt es ein Programm "XTweak", um verschiedene verborgene Parameter und Debugoptionen auf dem Client zu aktivieren. Leider kenne ich noch kein Programm, mit welchem ich die Authentifizierung neu starten kann. Hier hilft nur Abmelden, Netzwerkkarte deaktivieren und Cached Credentials in der Registry zu löschen (HKEY_CuRRENT_User\Software\Microsoft\Eapol\UserEapInfo).

Auf einem VISTA-System können Sie in den Netzwerkverbindungen dann kurz den Status "Authentifizierungsversuch" sehen:

802.1x und GPO

Gruppenrichtlinien sind wirklich eine elegante Möglichkeit, Einstellungen auf viele Clients zu bringen. für Firmen ist es um so interessanter, den Mitarbeitern die Arbeit zu erleichtern, indem die WLAN-Konfiguration einfach "vorgegeben" wird. Unter Windows XP ist noch etwas Vorarbeit erforderlich aber unter Vista und Windows 7 sind die Einstellungen einfach vorzunehmen, da die GPO-Verwaltung die passenden Vorlagen schon bereit hält.

Sie finden Sie recht einfach bei Windows 2008 unter den Computerrichtlinien - Policies - Windows Settings - Security Settings - Wireless Network (IEEE 802.11) Policies.

Bei der Neuanlage werden Sie gefragt, ob die Richtlinie für Windows XP oder Windows Vista und neuer ist. Hier exemplarisch die Dialoge für Windows Vista

Wenn Sie auf "General" die Netzwerke addieren, dann legen Sie ein Profil an, in der die verschiedenen SSIDs hinterlegt sind. Zu jeder SSID können Sie dann die Authentifizierung genauer spezifizieren.

Wenn sie die SSID des WiFi-Netzwerks eingeben, dann achten Sie darauf, dass zwischen Groß und Kleinschreibung unterschieden wird !

802.1x auf "fremden Clients"

Nun gibt es natürlich mehr und mehr Clients, die auch WiFi nutzen möchten und natürlich 802.1x unterstützen. Die Eingabe von Domain\Benutzername und Kennwort ist noch relativ einfach. Aber damit haben Sie als Administrator natürlich keine Kontrolle über die verwendeten Clients. Hier spielen Zertifikate ihre Stärke aus. Eigentlich benötigen Sie nur ein Computerzertifikat für den Client und ein passendes AD-Konto, damit der ISA/NPS die Zugriffsrechte prüfen kann. Allerdings sind ein paar Handgriffe zusätzlich erforderlich

Schritt Beschreibung Status

CA vorbereiten

Bei einem Windows Computer in der Domäne sollte per GPO, Autoenrollment etc. alles alleine passieren. Aber die haben ja dann auch schon ein Computerkonto. Anders sieht es aus, wenn fremde Clients eingebunden werden. Da müssen Sie zuerst mal in der CA dafür sorgen, dass ein passendes Template erstellt und verbunden wird:

  • Windows Enterprise CA (erforderlich für eigene Templates)
  • Neues Template anlegen(z.B. 8021xCert)
    Sie sollten dazu einfach das "Computer"-Template duplizieren.
    Optional: Gültigkeit auf z.B. 5 Jahre ausdehnen.

  • Private Key Export zulassen.
    Sonst können Sie das auf einem Hilfssystem angeforderte Zertifikat ja nicht auf das Fremdsystem übertragen

    Optional Schlüssellänge auf 2048 oder mehr
  • Daten nicht aus dem AD übernehmen, sondern "erfassen" lassen
  • CA: Ausstellen von SAN-Zertifikaten konfigurieren.
  • Template berechtigen
    Nicht jeder Anwender soll exportierbare Computerzertifikate ausstellen können !

 

Computerkonto anlegen

Legen Sie mit Active Directory Benutzer und Computer in einer passenden Ou ein neues Computerkonto an. Als Computername bietet sich z.B. der Hostname des Endgeräts an oder etwas, was das Endgerät anderweitig später identifizierbar macht.

Genau genommen sollten Sie das Kennwort dieses "neu" angelegten Computerkontos noch ändern, z.B. durch einen PowerShell-Einzeiler:

([adsi]"LDAP://cn=ipad-frank,ou=8021xmou=msxfaq,dc=fabrikam,dc=com").SetPassword("ganzgeheim")

 

SPN setzen

Bei der Anmeldung per Radius sendet der Client einen Kontennamen. Der Radius/IAS/NPS-Server sucht dann über den ServicePrincipalName (SPN) im Active Directory nach dem Host. Pflegen Sie hier also den Eintrag über ADSIEDIT oder über AD Benutzer und Computer unter Windows 2008 mit aktivierter erweiterter Ansicht:

Es ist nicht erforderlich, das Feld "dnsHostName" zu pflegen oder den Public Key zu addieren.

 

Konto in Radiusgruppe aufnehmen

Wenn Sie den Zugriff per 802.1x und WiFi über eine Computergruppe steuern, dann müssen Sie das Computerkonto natürlich noch aufnehmen. Eine Gruppe bietet sich schon daher an, weil diese gleich mehrfach genutzt werden kann:

  • Steuerung der Zugriffe auf dem Radius/IAS/NPS-Server
  • Vergabe der Berechtigungen auf das "richtige" Zertifikattemplate
    Zumindest wenn der Client ein Autoenrollment unterstützt.
  • Zuweisung einer GPO
    um das Autoenrollment für die Domainclients zu steuern und optional das WiFi-Profil gleich mit anzulegen.

 

Zertifikat erstellen.

Wenn das Endgerät nicht selbst von der Windows CA das Zertifikat anfordern oder einen Request zur Einreichung anfordern kann, dann muss eine vertrauenswürdige und auf dem Template berechtigte Person dies z.B. auf einem Windows Desktop machen. Mit dem richtigen Template muss bei der Erstellung der Antragsteller und der DNS-Name als "Alternativer Antragsteller) addiert werden.

Hinweis: Es soll Endgeräte geben, die über "Simple Certificate Enrollment Protocol (SCEP)" ein Zertifikat erhalten können. Diesen Weg betrachte ich hier nicht. Könnte aber interessant sein.

 

Zertifikat exportieren

Das lokal erstellte Zertifikat kann dann in eine PFX-Datei exportiert werden. für diverse Systeme müssen sie eventuell mittels OpenSSL das Format konvertieren (PFX->PEM). Sie sollten natürlich auch eine CER-Datei mit dem Stammzertifikat der CA zur Hand haben.

Hinweis:
Wenn Sie das Zertifikat über eine PFX-Datei auf das Mobilgerät übertragen, dann sollten Sie eine "gesicherte Umgebung" nutzen. die PFX ist zwar mit Kennwort geschützt aber das Zertifikat liegt auf der Quelle exportierbar vor und die PFX kann problemlos mehrfach importiert werden und beim Import muss sicher gestellt sein, dass das Zertifikat nicht mehr exportierbar ist. Ansonsten könnte jemand das Zertifikat auch auf ein andere Gerät übertragen und damit "mitspielen".
Das ist auch das wichtigste Argument für jedes Endgerät ein eigenes Zertifikat und Computerkonto zu verwenden.

 

Import auf dem Client

Nun nehmen Sie das exportierte Zertifikat samt privatem Schlüssel und das Stammzertifikat und importieren dies auf dem Client. Der Weg ist je nach Client unterschiedlich.

 

Für einige Clients habe ich in der folgenden Tabelle Werte hinterlegt.

System Import

IPad

Ein IPad kann einfach CER und PFX-Dateien importieren, wenn man Sie denn erst mal auf das IPAD bekommt. Über USB stellt ein IPad zwar einen Massenspeicher dar, ist aber "Readonly". In der Regel wird man auf dem iPAD z.B. die Exchange-Verbindung über GSM einrichten und sich die Dateien zusenden. Aus der Mail lassen sich diese einfach extrahieren und importieren.

Mit dem iPhone Configuration utility 3.4 für Windows (http://support.apple.com/kb/DL1466) können Sie ein Konfigurationsprofil hinterlegen und hierüber auch Zertifikate auf das Endgerät senden. Auch hier muss aber Mail schon funktionieren.

Es ist ja durchaus auch möglich, ein WiFi mit Authentifizierung über Benutzername/Kennwort für die Ersteinrichtung vorzuhalten, um intern die Zertifikate bereit zu stellen.

Die Einrichtung unter WiFi ist dann wieder fast selbsterklärend. Wobei hier im Gegensatz zu einem Windows PC auch ein "Kontenname" eingegeben werden kann.

Bild fehlt noch

Hier ist der FQDN des IPAD zu hinterlegen. Anscheinend geht aber auch "DOMäNE\BENuTZERNAME".  prüfen Sie einfach im Radius-Eventlog, wie die Anmeldung ankommt.

Rim Playbook

Die RIM-Playbooks können auch 802.1x, wobei hier die Einrichtung über USB den einfachsten Weg darstellen dürfte. Nachdem Sie schon das Zertifikat mit private Key als PFX-Datei und die CER-Datei mit der StammCA vorliegen haben, müssen Sie diese auf das Playbook kopieren. Das geht wohl nur über einen Weg

  1. Playbook per USB anschließen
  2. Blackberry Device Manager installieren (wen noch nicht installiert)
  3. Device Manager zeigt die "IP-Adresse" des Playbook an
    Scheinbar wird die USB-Verbindung wie ein kleines LAN angesehen
  4. UNC Zugriff auf \\playbookIP\certs
  5. CER und PFX-Datei auf die Freigabe kopieren
  6. Auf Gerät über Einstellungen -Sicherheit das Zertifikat importieren
    Hinweis: Nach dem Import ist der Inhalt von "Certs" wieder gelöscht.
  7. Konfiguration in den WiFi-Einstellungen
    Besonderheit hier: Als "Kontoname" tragen Sie am besten "host/name.domain.tld" ein, damit der Request von Radius verstanden wird.

Bild fehlt noch

Android Tableds

Ich habe zu Android einige Anleitungen per Google finden können, wie diese in Hochschulnetzen (eduroam) angebunden werden. Hier wird allerdings 802.1x immer nur mit "Benutzername/Kennwort" eingesetzt.

MAC

In Ermangelung eines eigenen MAC kann ich hier nur ein paar Links liefern. Ich denke aber auch hier, dass der wichtigste Punkt wieder der Import der Root-Zertifkate ist, welche die Client und das Radius-Server Zertifikat ausstellt und dass das Client-Zertifikat die richtigen Strings im Antragsteller und Alternativen Namen (DNS) hat.

Linux

Leider nutze ich Linux aktuell nur in VMs und habe daher noch keinen Bedarf gehabt, diese per WiFi an meinem AP anzubinden

Es gibt sicher noch andere Clients, die 802.1x unterstützen. Da Radius nur eingeschränkt verschlüsselt ist, können Sie mit NETMON oder anderen Schnüfflern eigentlich ganz gut die Anfragen der Clients über den Accesspoint an den Radius-Server mitschneiden und sehen die Anfrage und die Antworten. Zudem ist der Windows Radius-Server relativ gesprächig im Eventlog, wenn Authentifizierungen erfolgen.

802.1x und VoIP

Auf einen ganz eigenen Bereich hat mit Herr Götz Weinmann (Avaya) aufmerksam gemacht, welche ich hier leicht ergänzt wiedergeben möchte:

Dann kommt das "Problem" der VoIP-Phones:
Die allermeisten Hersteller unterstützen als Authentifizierungsverfahren lediglich EAP-MD5. Damit in AD aber MD5 Passworthashes gespeichert werden, muss die Richtlinie "Kennwörter mit reversibler Verschlüsselung abspeichern" aktiviert werden. Es werden also auch LM-Hashes abgelegt. Was das für Konsequenzen hat muss ich wohl nicht erläutern.

Das nächste Problem ist, dass die "User" ein abgelaufenes Kennwort des IP-Phones nicht ändern können, weil das IP Phone die Funktionalität nicht hergibt. Also muss die Kennwortrichtlinie für die IP-Phones so konfiguriert werden, dass Kennwörter nie ablaufen - Wohl dem der eine Native 2008 Domain hat, in der diese pro OU definiert werden können. Außerdem ist es meist recht kompliziert über eine Telefontastatur ein "komplexes" Kennwort einzugeben.

Die meisten großen Kunden entscheiden sich daher für eine separate AD-Infrastruktur (manchmal auch als Child Domain). Alternativ ist auch eine neue Domain für die MD5-Clients und die bestehende für die TLS Clients eine Lösung (Alles in einer separaten Domain zu machen birgt wieder ein Problem, wenn die Computer sich per EAP-MSChapv2 anmelden sollen). Die Unterscheidung wer sich in welcher Domain anmeldet findet dann auf IAS Seite statt.

Zudem sind die meisten VoIP Phones mit einem Eigenen kleinen Switch ausgestattet. Aus Kostengründen (Verkabelung) werden die Apparate zwischen Dose und PC geklemmt. Sollte also 802.1x zum Einsatz kommen, so müssen die Phones und Switche einen "Multi-Supplicant-Mode" unterstützen, bei dem mehrere Endgeräte auf einem Port das Login machen dürfen.

Beim Einsatz von eigenen VoIP-Endgeräten sind also weitere Dinge zu beachten. Dies gilt nur bedingt für VoIP-Software, die auf einem PC mitläuft wie z.B. den OCS Communicator)

Windows 2003 Radius /IAS

Windows enthält schon einen Radius-Server, welcher auch für handelsübliche Switche problemlos aus Authentifizierungsdienst arbeiten kann. Über die Systemsteuerung ist der Dienst recht schnell installieren und über die RAS-Richtlinien können Sie dann als Quelle z.B. "Ethernet" nehmen und z.B. über den optionalen Parameter.

Windows 2003 Radius und > 50 Switches
Wenn sie mehr als 50 Switches betreiben wollen, dann ist ein Windows Enterprise Server als RADIUS-Server erforderlich. (Angeblich soll dieses Limit bei Win2008 nicht mehr da sein.

Folgende Schritte beschreiben kurz die Installation.

  • Radius installieren
    Installieren Sie den Radius-Server einfach über Systemsteuerung - Software
  • Radius im Active Directory registrieren
    Sie sollten unbedingt den Radius-Server im AD aktivieren:

    Der Radius-Server bekommt damit die Rechte auf das Active Directory, um die RAS-Berechtigungen der Benutzer zu lesen. Allerdings wird er über den Weg auch erst Mitglied in der Gruppe "RAS und IAS-Server", welche Voraussetzung für den nächsten Schritt ist. Warten Sie nach dem Schritt ein paar Minuten und starten Sie dann den Server durch, damit die neue Gruppenmitgliedschaft auch greift.
  • Zertifikat einspielen
    Alle IAS und RAS-Server landen normalerweise in der Windows Gruppe "IAS und RAS-Server" und bekommen damit auch das Recht, ein Zertifikat automatisch anzufordern. Das funktioniert aber nur mit einer Windows Enterprise CA (Siehe auch CA installieren). Zudem muss der Computer die Rechte auf das IAS-RAS-Zertifikat hat, welches er über den vorigen Schritt (Im AD registrieren) über die Gruppenmitgliedschaft erhält.

Hinweis:
Wenn der RADIUS auf einem DC läuft, kann funktioniert PEAP auch mit einer Standard CA, da das ausgestellte Domain Controller Zertifikat ebenfalls für IAS tauglich ist. Sie müssen dann kein separates Zertifikat für IAS anfordern.

  • Radius-Konfiguration übertragen
    Wenn sie aus Redundanzgründen einen zweiten Radius-Server installieren wollen, dann können Sie die Konfiguration von einem bestehenden Server einfach übernehmen. Die Befehle sind auch als Backup des Radius-Servers nutzbar:
Rem Export der Konfiguration auf dem aktiven Radius Server
netsh aaaa show config > c:\radius.txt

Rem Import der Konfiguration
netsh exec c:\radius.txt
  • Radius Clients konfigurieren
    Sofern die Konfiguration nicht von einem anderen Server übernommen wurde, müssen Sie nun alle Switches als Radius-Clients einrichten
  • Radius Zugriffsrichtlinien
    Zudem müssen Sie über RAS-Richtlinien einstellen, nach welchen Kriterien die Clients letztlich authentifiziert werden. Hier hilft ihnen schon der Assistent eine erste Regel zu erstellen:

    Allerdings sollten Sie diese noch um die für den Switch spezifischen Parameter (z.B. VLAN-Nummer) erweitern, die dann greifen sollen.

Zwar schreibt der Radius-Server auch ein Log nach C:\Windows\System32\logfiles\in*.log aber hilfreicher für die Fehlersuche ist auf jeden Fall das System-Eventlog, welches erfolgreiche und fehlerhafte Anmeldungen sehr genau protokolliert.

Radius mit Windows 2008

Mit Windows 2008 ist der RADIUS-Dienst in die Rolle "Network Policy Server" gerutscht, welche einfach installiert werden muss. Nach der Installation ist aber auch hier eine Konfiguration erforderlich. Ein Assistent erleichtert die Konfiguration, wenn Sie gleich als Szenario 802.1x auswählen:

Danach werden sie direkt gefragt, ob sie den Zugang für WIFI oder drahtgebundene Verbindungen absichern möchten. Das sollten Sie aber nicht tun, wenn Sie mit Smartcards und EAP arbeiten wollen. Dann müssen Sie zuerst ein Computerzertifikat anfordern. Und dazu muss der Computer zuerst in die Gruppe "RAS- und ISA Server" Aufgenommen werden. Hierzu sollten Sie den Radius Assistenten nutzen -> "Server im Active Directory registrieren.

Achtung
Der Server muss nach der AD-Replikation der Gruppenmitgliedschaft neu gestartet werden, damit die Berechtigungen für den nächsten Schritt gesetzt sind

Wer mit EAP und Smartcards arbeitet, muss ein Zertifikat im Radius hinterlegen.

Kleiner Tipp: Wenn Sie eine Windows Enterprise CA haben, dann sollten Sie das Template kopieren und ein eigenes Template mit einer längeren Gültigkeit von vielleicht 5 Jahren erstellen. Dann müssen sie nicht jedes Jahr eine Verlängerung durchführen. Beachten Sie aber, dass der IAS-Server Zertifikate mit leerem Antragsteller nicht verwenden kann.

Im folgenden Fenster sind die Clients, d.h. die Switches und Accesspoints einzutragen:

Nach Eingabe der Clients ist das Authentifizierungsverfahren festzulegen. Interessant ist in Verbindung mit einer Windows Enterprise CA und entsprechenden Zertifikaten natürlich die Anmeldung mit diesen. Dazu benötigt der Radius-Server natürlich selbst ein Zertifikat, welche Sie vorher schon installiert haben müssen.

In den folgenden Fenstern müssen Sie noch die Benutzer oder Personen eintragen, die den Zugang verwenden dürfen, z.B. einfach die Domänenbenutzer

Bei Bedarf können danach noch RADIUS-Parameter wie z.B.: VLAN-IDs eingestellt werden, d.h. in welche VLAN z.B. der Port nach erfolgter Anmeldung geschaltet wird. Am Ende steht dann die Abschlussmeldung mit einer Zusammenfassung. In den meisten Fällen funktioniert dann schon alles, wenn Sie auf dem AccessPoint nun den RADIUS-Server eintragen. Jede weitergehende Konfiguration würde aber den Rahmen der MSXFAQ sprengen.

Unterstützung durch Net at Work:
Wir haben mehrere Projekte mit 802.1x bereits umgesetzt. Rufen Sie einfach unter 0800-MSXFAQ (0800-638 28 96) an.

Zertifikate und CRL

Beachten Sie bitte, dass bei der Anmeldung per Smartcard auch die CRL des übermittelten Zertifikats vom Radius-Server geprüft wird. "Passt" diese nicht, dann scheitert die Anmeldung und im Sicherheitseventlog gibt es einen Eintrag wie der Folgende

Protokollname: Security
Quelle:        Microsoft-Windows-Security-Auditing
Ereignis-ID:   6273
Aufgabenkategorie:Netzwerkrichtlinienserver
Ebene:         Informationen
Schlüsselwörter:Überwachung gescheitert
Benutzer:      Nicht zutreffend
Computer:      srv01.msxfaq.local
Beschreibung:
Der Netzwerkrichtlinienserver verweigerte einem Benutzer den Zugriff.

Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten.

Benutzer:
        Sicherheits-ID:                         MSXFAQ\carius
        Kontoname:                              carius@msxfaq.local
        Kontodomäne:                            MSXFAQ
        Vollqualifizierter Kontoname:           MSXFAQ\carius

Clientcomputer:
        Sicherheits-ID:                         NuLL SID
        Kontoname:                              -
        Vollqualifizierter Kontoname:           -
        Betriebssystemversion:                  -
        Empfänger-ID:                           000B86617FA8
        Anrufer-ID:                             001F3CAB7621

NAS:
        NAS-IPv4-Adresse:                       10.1.1.201
        NAS-IPv6-Adresse:                       -
        NAS-ID:                                 10.1.1.202
        NAS-Porttyp:                            Drahtlos - IEEE 802.11
        NAS-Port:                               1

RADIUS-Client:
        Clientanzeigenname:                     WifiAP
        Client-IP-Adresse:                      10.1.1..3

Authentifizierungsdetails:
        Name der Verbindungsanforderungsrichtlinie: Sichere Drahtlosverbindungen
        Netzwerkrichtlinienname:                    Sichere Drahtlosverbindungen
        Authentifizierungsanbieter:                 Windows
        Authentifizierungsserver:                   dc1.msxfaq.local
        Authentifizierungstyp:                      EAP
        EAP-Typ:                        Microsoft: Smartcard- oder anderes Zertifikat
        Kontositzungs-ID:               -
        Protokollierungsergebnisse:     Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben. Ursachencode:259 
        Ursache:                        Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

Die Funktion der CRL darf also nicht unterschätzt werden. Die CRL Prüfung kann abgeschaltet werden

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rasman\ppp\eap\13]
"IgnoreRevocationOffline"=dword:00000001

Damit nimmt der Server dann an, dass die Zertifikate gültig sein, wenn er die CRL nicht erreichen kann

802.1x im NETMON

Die Pakete zwischen Switch bzw. Access Point und dem Radius-Server sind nicht besonders verschlüsselt. Zur Authentifizierung dient die IP-Adresse des Clients und ein vereinbartes. Damit werden aber nicht die Anfragen bzw. Antworten verschlüsselt, so dass Sie sehr einfach auf diesem Weg den Handshake einsehen können. Hier ein Auszug aus dem Netzwerk Monitor.

Sie sehen am Anfang bei Zeile 7 den ersten Request, dann den Austausch von Zertifikaten und letztlich die Anmeldung per PEAP mit der Erfolgsmeldung in Zeile 25. Der Client ist angemeldet.

Grenzen von 802.1x

802.1x schützt die Verbindung des Servers gegen "nicht autorisierte" Clients, aber es schützt nicht gegen Systeme, die sich autorisiert haben und dann sich daneben benehmen. Lesen Sie hierzu auch den Artikel auf

Der mit einem guten Vergleich zwischen 802.1x und IPSec schließt.

Weitere Links

Quelle: http://h40060.www4.hp.com/procurve/uk/en/pdfs/application-notes/AN-S9_ProCurve-802.1x-configuration-final-091608.pdf

Seite 3. 1.1 Network Access Control methods MAC authentication is the default method für devices that do not support web authentication or 802.1X; these devices are authenticated by their MAC address. für more details about this method and its implementation on ProCurve switches, please refer to Application Note AN-S2, How to configure MAC authentication on a ProCurve switch.