Was ist ein 802.1X Supplicant? Client-Typen und Gerätekonfiguration

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und konversationellen Ton - wie ein leitender Netzwerksicherheitsberater, der einen Kunden brieft. Gemäßigtes Tempo, klare Diktion, professionell, aber nicht steif. Gelegentliche natürliche Pausen zur Betonung: Willkommen zur technischen Briefing-Reihe von Purple. Heute behandeln wir ein Thema, das im Mittelpunkt der WiFi-Sicherheit von Unternehmen steht - den 802.1X-Supplicant. Wenn Sie sich jemals gefragt haben, warum sich einige Geräte ohne Passwortabfrage mit Ihrem Unternehmensnetzwerk verbinden, während andere Zertifikatsfehler und Helpdesk-Tickets verursachen, ist dies die richtige Episode für Sie. [medium pause] Beginnen wir mit den Grundlagen. Der 802.1X-Supplicant ist die Softwarekomponente auf einem Client-Gerät - einem Laptop, einem Smartphone, einem Tablet - die den Authentifizierungs-Handshake abwickelt, wenn dieses Gerät versucht, sich mit einem durch IEEE 802.1X geschützten Netzwerk zu verbinden. Stellen Sie sich ihn als den Ausweisprüfer des Geräts vor. Das Netzwerk lässt nicht einfach jeden hinein. Es verlangt nach Anmeldedaten. Der Supplicant ist derjenige, der vortritt und sagt: Hier ist, wer ich bin, hier ist mein Zertifikat, lass mich rein. Der Standard selbst - IEEE 802.1X - definiert die portbasierte Netzwerkzugriffskontrolle. Bevor die Authentifizierung erfolgreich ist, lässt der Access Point oder Switch nur eine sehr begrenzte Art von Datenverkehr zu: EAPOL-Frames, was für Extensible Authentication Protocol over LAN steht. Alles andere wird blockiert. Sobald der Supplicant seine Identität gegenüber dem RADIUS-Server über den Authenticator nachweist, öffnet sich der Port und der normale Datenverkehr fließt. [medium pause] Es gibt drei Akteure in diesem Spiel. Erstens, der Supplicant - das Client-Gerät. Zweitens, der Authenticator - Ihr Access Point oder Switch, also Hardware wie Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist. Drittens, der Authentifizierungsserver - fast immer ein RADIUS-Server, der die Anmeldedaten mit einem Verzeichnis wie Microsoft Entra ID oder Okta abgleicht. Der Supplicant initiiert den Prozess, indem er eine EAPOL-Start-Nachricht sendet. Der Authenticator antwortet mit einer EAP-Anforderung zur Identität. Der Supplicant antwortet mit seiner Identität. Diese Identität wird an den RADIUS-Server weitergeleitet, der den Supplicant dann mit der vereinbarten EAP-Methode herausfordert. Wenn alles stimmt, sendet der RADIUS-Server ein Access-Accept, der Port öffnet sich und das Gerät wird im richtigen VLAN platziert. [medium pause] Lassen Sie uns über EAP-Methoden sprechen, denn hier werden die meisten Bereitstellungsentscheidungen getroffen. EAP-TLS - also Extensible Authentication Protocol mit Transport Layer Security - ist der Goldstandard. Hierbei müssen sowohl der Client als auch der Server Zertifikate vorlegen. Gegenseitige Authentifizierung. Keine Passwörter. Das Client-Zertifikat belegt die Identität des Geräts; das Server-Zertifikat belegt, dass das Netzwerk legitim ist, was vor Evil-Twin-Angriffen schützt, bei denen ein betrügerischer Access Point versucht, Anmeldedaten abzugreifen. EAP-TLS wird in zwölf Schritten abgeschlossen und nutzt durchgängig die Kryptografie mit öffentlichen und privaten Schlüsseln. Es ist die für WPA3-Enterprise im höchsten Sicherheitsmodus erforderliche Methode und entspricht den NIST SP 800-171-Anforderungen zur Verifizierung der Geräteidentität. PEAP - Protected EAP - ist der gängigere Ausgangspunkt für Unternehmen, die noch keine vollständige PKI implementiert haben. PEAP verpackt eine passwortbasierte interne Methode, in der Regel MSCHAPv2, in einen TLS-Tunnel. Der Server legt ein Zertifikat vor; der Client nicht. Das bedeutet, dass die Bereitstellung einfacher ist - Sie müssen keine Client-Zertifikate verteilen -, aber sie ist weniger sicher. MSCHAPv2 verwendet MD4-Hashing, das seit 1995 als kompromittiert gilt. Wenn sich ein Benutzer mit einem betrügerischen Access Point verbindet, der ein vertrauenswürdig aussehendes Zertifikat vorlegt, können seine Anmeldedaten abgefangen werden. Die clientseitige Validierung des Server-Zertifikats ist daher bei der Ausführung von PEAP unverzichtbar. [medium pause] Kommen wir nun zum Supplicant selbst - insbesondere zur Wahl zwischen nativen OS-Supplicants und Client-Software von Drittanbietern. Jedes gängige Betriebssystem wird mit einem integrierten 802.1X-Supplicant ausgeliefert. Windows unterstützt dies seit XP nativ über die Dienste für die automatische WLAN-Konfiguration und die automatische Verkabelungskonfiguration. macOS und iOS verarbeiten 802.1X über ihre Netzwerkkonfigurationsprofile. Android unterstützt dies über das WiFi-Einstellungsmenü. Diese nativen Supplicants decken EAP-TLS und PEAP-MSCHAPv2 auf allen aktuellen Plattformen ab. Der Vorteil nativer Supplicants liegt auf der Hand: keine zusätzliche Software zu installieren, keine Lizenzkosten, automatische OS-Sicherheitsupdates und eine enge Integration in den Zertifikatsspeicher des Betriebssystems. Für verwaltete Geräteflotten - z. B. Windows-Geräte, die in Microsoft Intune registriert sind, oder Macs, die über Jamf verwaltet werden - können Sie 802.1X-Konfigurationsprofile geräuschlos über MDM verteilen, und die Benutzer sehen nie eine Aufforderung. Das Gerät authentifiziert sich jedes Mal automatisch, wenn es in Reichweite kommt. Supplicants von Drittanbietern kommen in bestimmten Szenarien ins Spiel. Wenn Sie eine Cisco-Infrastruktur betreiben und EAP-FAST - das proprietäre EAP-Verfahren von Cisco - nutzen möchten, benötigen Sie die Client-Software von Cisco, in der Vergangenheit der Secure Services Client oder AnyConnect Network Access Manager. Wenn Sie ein einheitliches Konfigurationsmanagement über eine heterogene OS-Landschaft hinweg benötigen und die Supplicant-Einstellungen sperren möchten, damit Benutzer sie nicht versehentlich falsch konfigurieren, bietet Ihnen ein Drittanbieter-Client diese Kontrolle. Tools wie die JoinNow-Suite von SecureW2 fungieren auch als Onboarding-Agenten - sie konfigurieren den nativen Supplicant, anstatt ihn zu ersetzen, und führen die Benutzer durch die Zertifikatsregistrierung und Profilinstallation. [medium pause] Lassen Sie mich Sie durch zwei reale Szenarien führen, um dies zu verdeutlichen. Erstens, ein Hotel mit 400 Zimmern. Das Hotel betreibt heute ein Mitarbeiternetzwerk auf Basis von WPA2-Enterprise mit PEAP-MSCHAPv2. Das IT-Team möchte auf EAP-TLS migrieren, um die passwortbasierte Authentifizierung abzuschaffen und das Risiko von Anmeldedaten-Diebstahl zu verringern. Die Herausforderung: Die Geräte der Mitarbeiter sind eine Mischung aus Windows-Laptops, die über Intune verwaltet werden, persönlichen Android-Telefonen, die für die Hotelmanagement-Software genutzt werden, und einer Handvoll veralteter Windows 7-Geräte im Backoffice. Der Ansatz hier ist phasenweise. Beginnen Sie mit der verwalteten Windows-Flotte. Übertragen Sie ein Intune-Konfigurationsprofil, das das Root-CA-Zertifikat des RADIUS-Servers installiert, das WiFi-Profil für EAP-TLS konfiguriert und die SCEP-basierte Zertifikatsregistrierung von der internen PKI auslöst. Diese Geräte authentifizieren sich ab dem ersten Tag automatisch. Für Android-BYOD-Geräte stellen Sie ein Self-Service-Onboarding-Portal bereit - Benutzer rufen eine URL auf, laden ein Konfigurationsprofil herunter, und der Supplicant wird für sie konfiguriert. Die veralteten Windows 7-Geräte verbleiben auf PEAP mit strenger Serverzertifikatsvalidierung, isoliert in einem separaten VLAN mit eingeschränktem Zugriff, bis sie außer Betrieb genommen werden. [medium pause] Zweites Szenario: eine große Einzelhandelskette mit 200 Filialen. Jede Filiale verfügt über eine Mischung aus Point-of-Sale-Terminals, Mitarbeiter-Tablets und einem Gäste-WiFi-Netzwerk. PCI-DSS erfordert, dass Karteninhaber-Datenumgebungen von anderen Netzwerksegmenten isoliert sind. Der Einzelhändler nutzt 802.1X in den Mitarbeiter- und POS-Netzwerken, wobei die VLAN-Zuweisung durch Zertifikatsattribute gesteuert wird. Ein POS-Terminal legt ein Gerätezertifikat mit der Organisationseinheit "POS" vor - die RADIUS-Richtlinie weist es dem PCI-VLAN zu. Ein Mitarbeiter-Tablet legt ein Zertifikat mit "Staff" vor - es landet im Mitarbeiter-VLAN. Gäste-Geräte verbinden sich mit einer völlig separaten SSID, die über eine Captive Portal-Lösung verwaltet wird. Die Supplicant-Konfiguration auf den POS-Terminals ist über ein MDM gesperrt. Es ist keine Benutzerinteraktion erforderlich. Die Terminals authentifizieren sich geräuschlos beim Booten. Die Zertifikatsverlängerung ist über SCEP automatisiert, sodass kein manueller Eingriff erforderlich ist, wenn Zertifikate ablaufen. [medium pause] Nun zu den Fallstricken bei der Implementierung. Lassen Sie mich Ihnen die vier häufigsten nennen. Nummer eins: Fehlende Validierung des Serverzertifikats bei PEAP - Implementierungen. Wenn Sie den Supplicant nicht so konfigurieren, dass er das Zertifikat des RADIUS - Servers validiert und den Servernamen überprüft, sind Benutzer anfällig für Verbindungen mit einem Rogue Access Point. Geben Sie im Supplicant-Profil immer die vertrauenswürdige Stamm-CA und den Servernamen an. Nummer zwei: Zertifikatsablauf, der zu Massenauthentifizierungsfehlern führt. Client-Zertifikate haben eine Gültigkeitsdauer. Wenn Sie keine automatische Verlängerung über SCEP oder NDES eingerichtet haben, stehen Sie vor einem kritischen Punkt, an dem Hunderte von Geräten gleichzeitig die Authentifizierung einstellen. Richten Sie eine Verlängerungsautomatisierung ein, bevor Sie live gehen. Nummer drei: BYOD-Geräte mit inkonsistentem Supplicant-Verhalten. Insbesondere Android weist bei verschiedenen Herstellern eine fragmentierte 802.1X - Unterstützung auf. Einige Versionen erfordern, dass der Benutzer das CA-Zertifikat manuell installiert, bevor das WiFi - Profil es akzeptiert. Ein Onboarding-Portal, das diesen Schritt übernimmt, reduziert das Aufkommen beim Helpdesk erheblich. Nummer vier: Funktionsupdates von Windows 11, die die Supplicant-Konfiguration beeinträchtigen. Microsoft hat das Verhalten von 802.1X in mehreren Windows 11 - Updates geändert. Insbesondere das 24H2-Update führte Änderungen bei der Handhabung des EAP-TLS - Fallbacks durch den nativen Supplicant ein. Testen Sie Ihre Supplicant-Profile mit neuen Betriebssystemversionen, bevor Sie sie in der Produktionsumgebung bereitstellen. [medium pause] Jetzt zu den Schnellfeuerfragen. Können IoT-Geräte 802.1X unterstützen? Die meisten können es nicht. IoT-Geräten fehlt in der Regel ein Supplicant vollständig. Die Alternative ist MAC Authentication Bypass (MAB), bei dem der RADIUS - Server das Gerät anhand seiner MAC-Adresse authentifiziert. MAC-Adressen können gefälscht werden, daher sollten MAB-Geräte immer in einem isolierten IoT-VLAN mit strengen Firewall-Regeln platziert werden. Benötige ich eine PKI, um 802.1X zu betreiben? Für PEAP nicht - Sie benötigen lediglich ein Serverzertifikat auf dem RADIUS - Server. Für EAP-TLS ja - Sie benötigen eine PKI, um Client-Zertifikate auszustellen. Cloudbasierte PKI-Dienste reduzieren den Aufwand für die Infrastruktur erheblich. Wie interagiert 802.1X mit der Netzwerkzugriffsplattform von Purple? Purple fungiert als Cloud-Overlay auf Ihrer bestehenden Hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und andere. In WiFi - Netzwerken für Mitarbeiter lässt sich das SecurePass - Add-on von Purple in Ihren Identitätsanbieter - Microsoft Entra ID, Okta oder Google Workspace - integrieren, um eine 802.1X - Authentifizierung zu erzwingen und VLAN - Richtlinien pro Benutzer anzuwenden, ohne dass eine lokale RADIUS - Infrastruktur erforderlich ist. [medium pause] Zusammenfassend lässt sich sagen: Der 802.1X - Supplicant ist der geräteseitige Client, der die portbasierte Netzwerkzugriffskontrolle ermöglicht. Ihre Wahl der EAP-Methode - EAP-TLS für maximale Sicherheit, PEAP als Übergangsoption - bestimmt Ihre PKI-Anforderungen und Ihren Ansatz für die Supplicant-Konfiguration. Native Supplicants des Betriebssystems decken die Mehrheit der Szenarien für verwaltete Geräte ab, wenn sie über MDM bereitgestellt werden. Drittanbieter-Clients bieten in bestimmten Fällen einen Mehrwert: proprietäre EAP-Methoden, gemischte Betriebssystemumgebungen, die eine konsistente Konfiguration erfordern, oder das Self-Service-Onboarding für BYOD. Die drei wichtigsten Erkenntnisse: Validieren Sie Ihr RADIUS-Serverzertifikat auf jedem Supplicant-Profil, automatisieren Sie die Zertifikatsverlängerung, bevor Sie EAP-TLS im großen Stil bereitstellen, und isolieren Sie Geräte, die 802.1X nicht unterstützen können - IoT, ältere Hardware - auf dedizierten VLANs mit MAC Authentication Bypass als Fallback. Weitere Informationen darüber, wie Purple sich in Ihre Netzwerkzugriffsarchitektur integriert, finden Sie unter purple.ai. Vielen Dank fürs Zuhören.