So konfigurieren Sie die 802.1X WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung

So konfigurieren Sie die 802.1X WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung Ein Purple Enterprise WiFi Intelligence Podcast [EINFÜHRUNG — ca. 1 Minute] Willkommen zurück. Ich spreche heute als Senior Solutions Architect zu Ihnen. Wenn Sie sich das hier anhören, stehen Sie wahrscheinlich vor einem Netzwerksicherheitsprojekt, das eine 802.1X-Authentifizierung beinhaltet – entweder weil Ihr Compliance-Team darauf hingewiesen hat, Ihr Versicherer danach gefragt hat oder Sie gerade ein Netzwerk übernommen haben, das mit einem gemeinsam genutzten PSK läuft, und Sie wissen, dass das nicht mehr ausreicht. Kommen wir also direkt zur Sache. 802.1X ist the IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle. Es ist das Rückgrat der Enterprise-WiFi-Sicherheit – der Mechanismus, der sicherstellt, dass jedes Gerät, das sich mit Ihrem Netzwerk verbindet, eindeutig identifiziert und autorisiert wurde, bevor es auch nur ein einziges Byte an Datenverkehr durchlässt. Dies ist für Organisationen, die Zahlungskartendaten gemäß PCI-DSS verarbeiten, nicht optional. Es ist für das Gesundheitswesen unter GDPR- und NHS-Datensicherheitsstandards nicht optional. Und ehrlich gesagt ist es für jede Organisation, die mehr als eine Handvoll Access Points betreibt, die richtige Architektur. In den nächsten zehn Minuten werde ich Sie durch die technische Architektur, die RADIUS-Konfiguration, die Zertifikatsbereitstellung und die realen Szenarien führen, in denen es kompliziert wird. Los geht's. [TECHNISCHE TIEFENANALYSE — ca. 5 Minuten] Richtig, das 802.1X-Framework besteht also aus drei Komponenten. Sie haben den Supplicant – das ist das Client-Gerät, der Laptop, das Telefon, der IoT-Sensor. Sie haben den Authenticator – das ist Ihr Access Point oder Ihr Netzwerk-Switch, manchmal auch NAS (Network Access Server) genannt. Und Sie haben den Authentication Server – in Enterprise-Bereitstellungen fast ausnahmslos ein RADIUS-Server. Und so funktioniert der Handshake. Wenn ein Gerät versucht, sich mit einer durch 802.1X geschützten SSID zu verbinden, lässt der Access Point es nicht einfach gewähren. Stattdessen öffnet er einen sogenannten kontrollierten Port – einen eingeschränkten Kanal, der nur EAP-Verkehr (Extensible Authentication Protocol) zulässt. Der AP sendet eine EAP-Request Identity an das Gerät. Das Gerät antwortet mit seiner Identität. Der AP leitet diese dann, verpackt in ein RADIUS-Access-Request-Paket, an den RADIUS-Server weiter. Der RADIUS-Server führt die Authentifizierung durch – er gleicht die Anmeldedaten mit dem Active Directory, einem Zertifikatsspeicher oder dem von Ihnen konfigurierten Identitäts-Backend ab – und sendet entweder ein Access-Accept oder ein Access-Reject zurück. Erst bei einem Accept öffnet der AP den vollständigen Datenport und weist das Gerät dem entsprechenden VLAN zu. Die EAP-Methode, die Sie hier wählen, ist von enormer Bedeutung. Es gibt fünf Methoden, auf die Sie in Enterprise-Bereitstellungen stoßen werden. EAP-TLS ist der Goldstandard. Sowohl der Client als auch der Server weisen X.509-Zertifikate vor. Es sind keine Passwörter im Spiel. Es ist die sicherste Option und wird für die höchsten PCI-DSS-Compliance-Stufen verlangt. Der Haken an der Sache ist, dass Sie eine vollständige PKI – eine Public-Key-Infrastruktur – benötigen, um Client-Zertifikate auszustellen und zu verwalten. Das bedeutet eine Zertifizierungsstelle, Zertifikats-Lebenszyklusmanagement und einen Mechanismus, um Zertifikate auf jedes Gerät zu pushen. Für Organisationen mit Microsoft Active Directory und Active Directory Certificate Services ist dies sehr gut machbar. Für Organisationen ohne diese Infrastruktur ist es eine erhebliche Investition. PEAP-MSCHAPv2 ist in der Praxis die am weitesten verbreitete Methode. Sie erstellt einen TLS-Tunnel nur mit einem serverseitigen Zertifikat und überträgt dann Benutzernamen und Passwort innerhalb dieses Tunnels. Sie ist standardmäßig mit praktisch jedem Gerät kompatibel, lässt sich über NPS auf Windows Server direkt in Active Directory integrieren und erfordert keine Client-Zertifikate. Der Kompromiss besteht darin, dass sie anfällig für Angriffe zum Abgreifen von Anmeldedaten ist, wenn Benutzer dazu verleitet werden, sich mit einem Rogue AP zu verbinden – da der Client das Serverzertifikat standardmäßig nicht validiert. Sie müssen die Validierung des Serverzertifikats in Ihren Supplicant-Profilen erzwingen. EAP-TTLS ähnelt PEAP, ist jedoch in der internen Authentifizierungsmethode flexibler. Es ist in Linux-Umgebungen üblich und dort, wo Sie ältere Authentifizierungs-Backends unterstützen müssen. EAP-FAST wurde von Cisco als Reaktion auf die Schwächen von LEAP entwickelt. Es verwendet Protected Access Credentials anstelle von Zertifikaten. Es ist in erster Linie relevant, wenn Sie sich in einer stark von Cisco geprägten Umgebung befinden oder mit älteren Geräten zu tun haben, die die anderen Methoden nicht unterstützen. EAP-SIM und EAP-AKA werden in Carrier-Grade-Bereitstellungen verwendet – denken Sie an OpenRoaming oder Passpoint –, bei denen die Authentifizierung an eine SIM-Karte oder USIM gebunden ist. Diese werden für das WiFi an öffentlichen Orten immer relevanter, wo Sie ein nahtloses, sicheres Onboarding ohne ein Captive Portal wünschen. Sprechen wir nun über die RADIUS-Konfiguration. Unabhängig davon, ob Sie Microsoft NPS, FreeRADIUS, Cisco ISE oder Aruba ClearPass bereitstellen, sind die grundlegenden Konfigurationsschritte dieselben. Erstens definieren Sie Ihre RADIUS-Clients – das sind Ihre Access Points oder Wireless LAN Controller. Jeder Client wird mit seiner IP-Adresse und einem Shared Secret registriert. Dieses Shared Secret wird verwendet, um die RADIUS-Nachrichten zwischen dem AP und dem Server zu authentifizieren. Verwenden Sie mindestens 22 Zeichen, zufällig generiert und eindeutig pro NAS-Gerät. Zweitens konfigurieren Sie Ihre Netzwerkrichtlinie. Hier definieren Sie, wer worauf Zugriff erhält. Im NPS-Kontext erstellen Sie eine Netzwerkrichtlinie, die Bedingungen abgleicht – Gruppenmitgliedschaft im Active Directory, Gerätetyp, Tageszeit – und Attribute zuweist – VLAN-ID, Sitzungs-Timeout, Bandbreitenbegrenzungen. Das am häufigsten verwendete RADIUS-Attribut ist die VLAN-Zuweisung, insbesondere Tunnel-Type auf VLAN, Tunnel-Medium-Type auf 802, und Tunnel-Private-Group-ID auf Ihre VLAN-Nummer gesetzt. Drittens konfigurieren Sie Ihre Verbindungsanforderungsrichtlinie. Diese teilt NPS mit, wie mit eingehenden RADIUS-Anforderungen verfahren werden soll – ob sie lokal authentifiziert oder an einen anderen RADIUS-Server weitergeleitet werden sollen. In einer verteilten Bereitstellung haben Sie möglicherweise einen zentralen RADIUS-Server mit NPS-Proxys an jedem Standort. Auf der Zertifikatsseite benötigt Ihr RADIUS-Server für PEAP und EAP-TLS ein Serverzertifikat, dem Ihre Clients vertrauen. Der einfachste Weg ist die Verwendung eines Zertifikats einer öffentlichen CA – DigiCert, Sectigo, Let's Encrypt –, da diese Root-Zertifikate bereits von allen gängigen Betriebssystemen als vertrauenswürdig eingestuft werden. Wenn Sie eine interne CA verwenden, müssen Sie das Root-Zertifikat über Gruppenrichtlinien oder Ihre MDM-Plattform auf alle Client-Geräte pushen. Speziell für EAP-TLS benötigen Sie auch Client-Zertifikate. In einer Active Directory-Umgebung würden Sie ADCS mit automatischer Registrierung über Gruppenrichtlinien verwenden, um Zertifikate auf domänenregistrierte Geräte zu pushen. Für BYOD-Geräte würden Sie Ihr MDM – Intune, Jamf, VMware Workspace ONE – verwenden, um sowohl das Zertifikat als auch das WiFi-Profil zu pushen. Auf der Access-Point-Seite ist die Konfiguration unkompliziert. Sie erstellen eine neue SSID, stellen die Sicherheit auf WPA2-Enterprise oder WPA3-Enterprise ein, verweisen den RADIUS-Authentifizierungsserver auf Ihre NPS-IP auf UDP-Port 1812, stellen den RADIUS-Accounting-Server auf UDP-Port 1813, geben das Shared Secret ein und aktivieren die dynamische VLAN-Zuweisung, falls Sie diese verwenden. Die meisten Enterprise-AP-Plattformen – Cisco Meraki, Aruba, Ruckus, Extreme Networks – verfügen über eine GUI dafür, was etwa zehn Minuten dauert, sobald Ihr RADIUS-Server bereit ist. [EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND FALLSTRICKE — ca. 2 Minuten] Richtig, sprechen wir darüber, wo Bereitstellungen schiefgehen, denn damit verdiene ich meine Beratungsgebühren. Der häufigste Fehlerpunkt ist die Zertifikatsvalidierung. Ich habe erlebt, dass Organisationen PEAP-MSCHAPv2 auf der Serverseite korrekt bereitgestellt haben, die Client-Supplicant-Profile jedoch so konfiguriert ließen, dass sie jedes Zertifikat akzeptieren. Das untergräbt das Sicherheitsmodell vollständig. Jedes Supplicant-Profil – ob über Gruppenrichtlinien oder MDM gepusht – muss die vertrauenswürdige Root-CA und den erwarteten Servernamen angeben. Ohne dies sind Sie anfällig für Evil-Twin-Angriffe. Das zweite häufige Problem ist die Verwaltung des RADIUS Shared Secrets. Ich habe Produktionsnetzwerke gesehen, bei denen das Shared Secret auf „radius“ oder den Standardwert des Herstellers eingestellt war. Diese Secrets sind die Schlüssel zu Ihrer Authentifizierungsinfrastruktur. Generieren Sie sie zufällig, speichern Sie sie in einem Secrets Manager und rotieren Sie sie nach einem Zeitplan. Drittens: VLAN-Fehlkonfiguration. Die dynamische VLAN-Zuweisung ist leistungsstark – sie ermöglicht es Ihnen, Mitarbeitergeräte in das Unternehmens-VLAN, Auftragnehmer in ein eingeschränktes VLAN und IoT-Geräte in ein isoliertes VLAN zu legen, und das alles über dieselbe SSID. Wenn jedoch die RADIUS-Attribute nicht korrekt konfiguriert sind oder die Switch-Trunk-Ports nicht die richtigen VLANs übertragen, schlägt die Verbindung der Geräte entweder fehl oder sie landen im falschen Segment. Testen Sie dies gründlich in einer Laborumgebung, bevor Sie es in der Produktion einführen. Viertens: Redundanz. Ihr RADIUS-Server ist jetzt ein kritischer Teil der Infrastruktur. Wenn er ausfällt, kann sich niemand verbinden. Sie benötigen mindestens einen primären und einen sekundären RADIUS-Server, die auf jedem AP konfiguriert sind. Ziehen Sie bei großen Bereitstellungen RADIUS-Proxy-Cluster mit Zustandsüberwachung in Betracht. Fünftens, und das betrifft speziell die Hotellerie und den Einzelhandel: die Trennung von Gäste- und Unternehmensnetzwerk. Ihre 802.1X-Unternehmens-SSID und Ihre Gäste-WiFi-SSID sollten vollständig getrennt sein – unterschiedliche VLANs, unterschiedliche Firewall-Richtlinien, unterschiedliches DNS. Eine Plattform wie Purple übernimmt die Gästeseite mit ihrem eigenen Captive Portal und ihrer eigenen Analyse-Ebene, während Ihre 802.1X-Infrastruktur die Unternehmensseite verwaltet. Dies sind komplementäre, keine konkurrierenden Systeme. [SCHNELLE FRAGERUNDE — ca. 1 Minute] Lassen Sie mich die Fragen durchgehen, die mir am häufigsten gestellt werden. Kann ich 802.1X auf einer Cloud-verwalteten AP-Plattform ausführen? Ja – Meraki, Aruba Central und Ruckus Cloud unterstützen dies alle. Sie konfigurieren die RADIUS-Serverdetails im Cloud-Dashboard, und die APs übernehmen das EAP-Proxying. Benötige ich Active Directory? Nein. FreeRADIUS kann sich gegen LDAP, SQL-Datenbanken, Flatfiles oder sogar REST-APIs authentifizieren. Aber die AD-Integration über NPS ist bei weitem der häufigste Weg in Unternehmen. Was ist mit IoT-Geräten, die kein 802.1X unterstützen? Verwenden Sie MAC Authentication Bypass – MAB – als Fallback. Die MAC-Adresse des Geräts wird als Benutzername und Passwort an RADIUS gesendet. Das ist nicht so sicher wie EAP, ermöglicht Ihnen aber das Onboarding von IoT-Geräten, während sie in einem eingeschränkten VLAN gehalten werden. Funktioniert 802.1X mit WPA3? Ja. WPA3-Enterprise ist im Wesentlichen WPA3 mit 802.1X-Authentifizierung. Es bietet eine stärkere Verschlüsselung – 192-Bit im Hochsicherheitsmodus – und ist der empfohlene Standard für neue Bereitstellungen. [ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE — ca. 1 Minute] Um das Ganze zusammenzufassen: 802.1X ist kein „Nice-to-have“. Für jede Organisation, die sensible Daten verarbeitet, Zahlungen abwickelt oder in einer regulierten Umgebung tätig ist, ist es die Baseline für die Enterprise-WiFi-Sicherheit. Die Architektur ist etabliert, die Tools sind ausgereift und der Bereitstellungsweg ist klar. Beginnen Sie mit der Auswahl Ihrer EAP-Methode – PEAP-MSCHAPv2, wenn Sie schnelle Erfolge und eine breite Kompatibilität benötigen, EAP-TLS, wenn Sie über die PKI-Infrastruktur verfügen und das stärkste Sicherheitsniveau benötigen. Konfigurieren Sie Ihren RADIUS-Server und stellen Sie Redundanz her, bevor Sie auch nur einen einzigen AP anfassen. Pushen Sie Ihre Supplicant-Profile über Gruppenrichtlinien oder MDM, bevor Sie live gehen. Und halten Sie Ihr Gäste-WiFi völlig getrennt – verwenden Sie eine speziell für diese Ebene entwickelte Plattform. Wenn Sie eine Umgebung mit mehreren Standorten betreiben – Hotels, Einzelhandelsketten, Stadien –, skaliert die Komplexität mit der Anzahl der Standorte, aber die Architektur ändert sich nicht. Der Schlüssel ist ein zentralisiertes RADIUS mit standortlokaler Redundanz und ein konsistentes, per MDM gepushtes Supplicant-Profil auf Ihrer gesamten Geräteflotte. Vielen Dank fürs Zuhören. Der vollständige schriftliche Leitfaden, Architekturdiagramme und Konfigurations-Checklisten sind auf purple.ai verfügbar. Wenn Sie eine 802.1X-Bereitstellung planen und die Besonderheiten Ihrer Umgebung besprechen möchten, wenden Sie sich direkt an das Purple-Team.