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 erfordert – entweder weil Ihr Compliance-Team darauf hingewiesen hat, Ihr Versicherer danach gefragt hat oder Sie einfach 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 der 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 übertragen darf. Dies ist keine Option für Organisationen, die Zahlungskartendaten gemäß PCI DSS verarbeiten, es ist keine Option für das Gesundheitswesen unter GDPR und den NHS-Datensicherheitsstandards, und ehrlich gesagt ist es für jede Organisation mit mehr als einer Handvoll Access Points die einzig 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. [TECHNISCHER DEEP-DIVE — ca. 5 Minuten] Gut, das 802.1X-Framework besteht also aus drei Komponenten. Da ist zum einen der Supplicant – das ist das Client-Gerät, der Laptop, das Telefon, der IoT-Sensor. Dann haben wir den Authenticator – das ist Ihr Access Point oder Ihr Netzwerkschalter, manchmal auch NAS (Network Access Server) genannt. Und schließlich gibt es den Authentifizierungsserver – in Unternehmensumgebungen 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) durchlä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 Identity-Backend ab – und sendet entweder ein Access-Accept oder ein Access-Reject zurück. Nur 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 Unternehmensumgebungen 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. Dies 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 (Public Key Infrastructure) benötigen, um Client-Zertifikate auszustellen und zu verwalten. Das bedeutet eine Zertifizierungsstelle, ein Zertifikats-Lebenszyklusmanagement und einen Mechanismus, um Zertifikate auf jedes Gerät zu übertragen. 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 baut einen TLS-Tunnel auf, der nur ein serverseitiges Zertifikat verwendet, und überträgt dann Benutzername 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 Nachteil ist, dass sie anfällig für Angriffe zum Abgreifen von Anmeldedaten ist, wenn Benutzer dazu verleitet werden, sich mit einem gefälschten 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 flexibler bei der internen Authentifizierungsmethode. Sie 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 Schwachstellen von LEAP entwickelt. Es verwendet Protected Access Credentials anstelle von Zertifikaten. Dies ist in erster Linie relevant, wenn Sie in einer stark von Cisco geprägten Umgebung arbeiten 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 – wie OpenRoaming oder Passpoint –, bei denen die Authentifizierung an eine SIM-Karte oder USIM gebunden ist. Diese gewinnen zunehmend an Bedeutung für das WiFi an öffentlichen Orten, an denen Sie ein nahtloses, sicheres Onboarding ohne ein Captive Portal wünschen. Lassen Sie uns nun über die RADIUS-Konfiguration sprechen. Unabhängig davon, ob Sie Microsoft NPS, FreeRADIUS, Cisco ISE oder Aruba ClearPass bereitstellen, sind die grundlegenden Konfigurationsschritte dieselben. Zuerst 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 zur Authentifizierung der RADIUS-Nachrichten zwischen dem AP und dem Server verwendet. Verwenden Sie mindestens 22 zufällig generierte Zeichen, die für jedes NAS-Gerät eindeutig sind. Zweitens konfigurieren Sie Ihre Netzwerkrichtlinie. Hier legen Sie fest, wer worauf Zugriff erhält. Im Fall von NPS erstellen Sie eine Netzwerkrichtlinie, die Bedingungen abgleicht – Gruppenmitgliedschaft im Active Directory, Gerätetyp, Tageszeit – und Attribute zuweist – VLAN-ID, Sitzungs-Timeout, Bandbreitenbeschränkungen. Das RADIUS-Attribut, das Sie am häufigsten verwenden werden, ist die VLAN-Zuweisung, speziell 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-Anfragen umzugehen ist – 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 diesen Root-Zertifikaten bereits von allen gängigen Betriebssystemen vertraut wird. Wenn Sie eine interne CA verwenden, müssen Sie das Root-Zertifikat über Gruppenrichtlinien oder Ihre MDM-Plattform auf alle Client-Geräte übertragen. 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 übertragen. Für BYOD-Geräte würden Sie Ihr MDM – Intune, Jamf, VMware Workspace ONE – nutzen, um sowohl das Zertifikat als auch das WiFi-Profil zu übertragen. Auf der Seite des Access Points 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 ein, 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 – verfügen hierfür über eine grafische Benutzeroberfläche, die in etwa zehn Minuten eingerichtet ist, sobald Ihr RADIUS-Server bereit ist. [EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND FALLSTRICKE — ca. 2 Minuten] Gut, sprechen wir darüber, wo Bereitstellungen schiefgehen können, denn hier verdiene ich meine Beraterhonorare. Der häufigste Fehlerpunkt ist die Zertifikatsvalidierung. Ich habe erlebt, dass Organisationen PEAP-MSCHAPv2 auf der Serverseite korrekt bereitstellen, die Client-Supplicant-Profile jedoch so konfiguriert lassen, dass sie jedes Zertifikat akzeptieren. Das untergräbt das Sicherheitsmodell vollständig. Jedes Supplicant-Profil – ob über Gruppenrichtlinien oder MDM übertragen – 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 Secret. 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 festen Zeitplan. Drittens: VLAN-Fehlkonfiguration. Die dynamische VLAN-Zuweisung ist mächtig – sie ermöglicht es Ihnen, Mitarbeitergeräte im Unternehmens-VLAN, Auftragnehmer in einem eingeschränkten VLAN und IoT-Geräte in einem isolierten VLAN zu platzieren, 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 nun ein kritischer Teil der Infrastruktur. Wenn er ausfällt, kann sich niemand mehr verbinden. Sie benötigen mindestens einen primären und einen sekundären RADIUS-Server, die auf jedem AP konfiguriert sind. Erwägen Sie bei großen Bereitstellungen RADIUS-Proxy-Cluster mit Zustandsüberwachung. Fünftens, und das betrifft speziell das Gastgewerbe und den Einzelhandel: die Trennung von Gast- und Unternehmensnetzwerk. Ihre 802.1X-Unternehmens-SSID und Ihre Gast-WiFi-SSID sollten vollständig getrennt sein – unterschiedliche VLANs, unterschiedliche Firewall-Richtlinien, unterschiedliches DNS. Eine Plattform wie Purple kümmert sich um die Gastseite mit einem eigenen Captive Portal und einer 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 cloudbasierten AP-Plattform ausführen? Ja – Meraki, Aruba Central und Ruckus Cloud unterstützen dies alle. Sie konfigurieren die RADIUS-Server-Details im Cloud-Dashboard, und die APs übernehmen das EAP-Proxying. Benötige ich Active Directory? Nein. FreeRADIUS kann sich gegenüber LDAP, SQL-Datenbanken, Flatfiles oder sogar REST-APIs authentifizieren. Die AD-Integration über NPS ist jedoch der bei weitem am häufigsten genutzte 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 zwar 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 es zusammenzufassen: 802.1X ist kein „Nice-to-have“. Für jede Organisation, die mit sensiblen Daten arbeitet, Zahlungen abwickelt oder in einer regulierten Umgebung tätig ist, ist es die Baseline für die WiFi-Sicherheit im Unternehmen. 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 höchste Sicherheitsniveau benötigen. Konfigurieren Sie Ihren RADIUS-Server redundant, bevor Sie auch nur einen einzigen AP anfassen. Übertragen Sie Ihre Supplicant-Profile über Gruppenrichtlinien oder MDM, bevor Sie live gehen. Und halten Sie Ihr Gast-WiFi völlig getrennt – nutzen Sie eine speziell für diesen Zweck entwickelte Plattform für diese Ebene. 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 liegt in einem zentralisierten RADIUS mit standortlokaler Redundanz und einem konsistenten, per MDM übertragenen Supplicant-Profil auf all Ihren Geräten. Vielen Dank fürs Zuhören. Der vollständige schriftliche Leitfaden, Architekturdiagramme und Konfigurations-Checklisten sind unter 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.