802.1x - Zugang zum Netzwerk steuern

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:

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 kennen 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.

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.

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:

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:

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.

802.1x Probleme mit IP-Change / VLAN-Switch

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 kennen meist auch die dort verwendeten IP-Adressen und natürlich 802.1x Anmeldedaten.

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:

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.

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 Clients

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:

Die beiden Dienste heißen:

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 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 Authentifizierungsvrfahren 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.

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.

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

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:

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-NETATWORK (0800-638 28 96) an.

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.

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 for devices that do not support web authentication or 802.1X; these devices are authenticated by their MAC address. For 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.

Keywords: IPSec WiFi 802.1x Security Sicherheit Isolation