Einrichtung von Enterprise WiFi auf Android-Geräten mit EAP-TLS

Einrichten von Enterprise WiFi auf Android-Geräten mit EAP-TLS Ein Purple Technical Briefing - Ca. 10 Minuten --- EINFÜHRUNG UND KONTEXT - ca. 1 Minute Willkommen zur Purple Technical Briefing Reihe. Ich bin Ihr Moderator, und heute befassen wir uns mit den Besonderheiten der Bereitstellung von 802.1X EAP-TLS-Authentifizierung auf Android-Geräten - unabhängig davon, ob Sie ein Hotelgelände, eine Einzelhandelskette, ein Stadion oder einen Campus im öffentlichen Sektor verwalten. Wenn Sie für ein Netzwerk verantwortlich sind, das geschäftliche oder BYOD-Android-Geräte authentifizieren muss, ohne sich auf gemeinsam genutzte Passwörter zu verlassen, ist diese Folge genau das Richtige für Sie. EAP-TLS ist der Goldstandard für die Sicherheit von Enterprise WiFi - es nutzt eine gegenseitige zertifikatsbasierte Authentifizierung. Das bedeutet, dass keine Anmeldedaten gefischt werden können, keine Passwörter rotiert werden müssen und eine Compliance-Richtlinie erreicht wird, die PCI-DSS, ISO 27001 und die meisten Sicherheitsrahmenwerke des öffentlichen Sektors erfüllt. Am Ende dieses Briefings werden Sie genau verstehen, wie EAP-TLS auf Android funktioniert, welche Bereitstellungsoptionen Sie haben und welches die drei häufigsten Fehler sind, die zu fehlgeschlagenen Rollouts führen. Legen wir los. --- TECHNISCHER DEEP-DIVE - ca. 5 Minuten Beginnen wir mit der Architektur. 802.1X ist der IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle. Wenn sich ein Android-Gerät mit einem Enterprise WiFi-Netzwerk verbindet - einem Netzwerk, das als WPA2-Enterprise oder WPA3-Enterprise konfiguriert ist - fungiert der Access Point als sogenannter Authentifikator. Er trifft die Authentifizierungsentscheidung nicht selbst, sondern leitet die Kommunikation zwischen dem Gerät und einem RADIUS-Server weiter, der der eigentliche Authentifizierungsserver ist. EAP-TLS - Extensible Authentication Protocol mit Transport Layer Security - ist die Authentifizierungsmethode, die innerhalb dieses 802.1X-Rahmenwerks läuft. Der Unterschied zu EAP-PEAP oder EAP-TTLS, die Benutzername und Passwort innerhalb eines TLS-Tunnels verwenden, besteht darin, dass EAP-TLS auf beiden Seiten X.509-Zertifikate nutzt. Der RADIUS-Server präsentiert dem Gerät ein Serverzertifikat, und das Gerät präsentiert dem RADIUS-Server wiederum ein Clientzertifikat. Beide Parteien validieren sich gegenseitig. Das ist eine gegenseitige Authentifizierung, und genau das macht EAP-TLS zur sichersten verfügbaren Option. Speziell bei Android gibt es jedoch einige Dinge, die Sie beachten müssen. Android 11 und neuere Versionen haben strengere Anforderungen an die Zertifikatsvalidierung eingeführt. Wenn Sie die Bereitstellung auf Android 11 oder höher durchführen - was zu diesem Zeitpunkt die weite Mehrheit Ihrer Geräte betrifft - verweigert das Gerät die Verbindung, es sei denn, dem RADIUS-Serverzertifikat wird explizit vertraut. Sie können sich nicht allein auf den Vertrauensspeicher des Systems verlassen; Sie müssen entweder das Root-CA-Zertifikat auf das Gerät übertragen oder das WiFi-Profil so konfigurieren, dass es explizit darauf verweist. Sprechen wir über die Zertifikatskette. Sie benötigen drei Komponenten, bevor sich ein einziges Android Gerät über EAP-TLS authentifizieren kann. Erstens eine Zertifizierungsstelle (Certificate Authority, CA) - entweder Ihre interne PKI, Microsoft Active Directory Certificate Services oder eine Cloud PKI wie SCEP über Intune. Zweitens ein Serverzertifikat, das für Ihren RADIUS Server ausgestellt und von dieser CA signiert wurde. Drittens ein eindeutiges Clientzertifikat, das für jedes Gerät oder jeden Benutzer ausgestellt und ebenfalls von derselben CA signiert wurde. Das Gerät präsentiert sein Clientzertifikat während des TLS-Handshakes, und der RADIUS Server validiert es anhand der Zertifikatssperrliste der CA (CRL) oder über das OCSP (Online Certificate Status Protocol). Bei Android werden das Clientzertifikat und der private Schlüssel normalerweise als PKCS12-Datei verpackt - das ist eine .P12- oder .PFX-Datei - die sowohl das Zertifikat als auch den verschlüsselten privaten Schlüssel enthält. Auf einem manuell konfigurierten Gerät importiert der Benutzer diese Datei über die Einstellungen, dann Sicherheit, dann Zertifikat installieren. Auf einem per MDM verwalteten Gerät wird das Zertifikat unbemerkt auf den verwalteten Keystore des Geräts übertragen - es ist keine Benutzerinteraktion erforderlich. Sprechen wir nun über das WiFi Profil selbst. Wenn Sie eine Enterprise WiFi Verbindung auf Android konfigurieren, müssen Sie Folgendes angeben: die SSID, den Sicherheitstyp - WPA2-Enterprise oder WPA3-Enterprise - die EAP-Methode - also TLS - das CA-Zertifikat für die Servervalidierung, das Clientzertifikat für die Geräteauthentifizierung und den Identitäts-String, bei dem es sich in der Regel um den Common Name des Geräts oder den UPN des Benutzers handelt. Auf Android 11 und höher müssen Sie außerdem die Domänensuffix-Übereinstimmung oder den Betreff des Serverzertifikats angeben, um Man-in-the-Middle-Angriffe zu verhindern. Bei MDM-Bereitstellungen - und hier kommt die tatsächliche Skalierbarkeit ins Spiel - übertragen Sie all dies als strukturiertes Konfigurationsprofil. In Microsoft Intune erstellen Sie ein SCEP-Zertifikatsprofil, das automatisch ein eindeutiges Clientzertifikat anfordert und auf jedem registrierten Android Gerät installiert. Anschließend erstellen Sie ein WiFi Konfigurationsprofil, das auf dieses Zertifikatsprofil verweist. Wenn sich das Gerät meldet, erhält es sowohl das Zertifikat als auch das WiFi Profil und verbindet sich automatisch mit Ihrem 802.1X Netzwerk. Keine Benutzerinteraktion, keine Supportanrufe. Wenn Sie dafür Intune verwenden, führt Sie unser begleitender Leitfaden zur Verwendung von Microsoft Intune zur Übertragung von WiFi Zertifikaten auf Geräte durch die genauen Konfigurationsschritte - ich empfehle, diesen parallel zu diesem Briefing zu lesen. Bei VMware Workspace ONE und Jamf Connect ist der Prozess architektonisch identisch - ein SCEP- oder PKCS-Zertifikatsprofil, gefolgt von einem WiFi Profil, das darauf verweist. Die spezifische Benutzeroberfläche unterscheidet sich, aber die Anforderungen an die Zertifikatskette und die RADIUS Konfiguration sind dieselben. Eine Sache, die auf der RADIUS Seite beachtet werden sollte: Wenn Sie FreeRADIUS, Microsoft NPS oder Cisco ISE verwenden, stellen Sie sicher, dass Ihr Serverzertifikat die korrekten Extended Key Usage Attribute enthält - speziell Server Authentication, OID 1.3.6.1.5.5.7.3.1. Android ist hier sehr streng. Ein Zertifikat, das mit Windows Clients problemlos funktioniert, kann unter Android fehlschlagen, wenn das EKU fehlt oder falsch konfiguriert ist. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE - ca. 2 Minuten Lassen Sie uns nun darüber sprechen, was in der Praxis tatsächlich schiefgeht, denn hier treten bei den meisten Implementierungen die Probleme auf. Der erste und häufigste Fehler ist das Vertrauen in Zertifikate. Android 11 und höher stellen keine Verbindung her, wenn die Zertifikatskette des RADIUS Servers nicht validiert werden kann. Die Lösung ist einfach: Verteilen Sie Ihr Root-CA-Zertifikat über ein MDM an den Zertifikatsspeicher des Benutzers auf dem Gerät und verweisen Sie im Feld für das CA-Zertifikat des WiFi Profils explizit darauf. Stellen Sie dies nicht auf "Nicht validieren" ein - das ist eine Sicherheitslücke und wird auf einigen Android Versionen ohnehin fehlschlagen. Der zweite Stolperstein ist der Ablauf von Zertifikaten. Client-Zertifikate haben in der Regel eine Gültigkeitsdauer von ein bis zwei Jahren. Wenn Sie keine automatische Verlängerung über SCEP oder NDES eingerichtet haben, werden Sie eines Morgens aufwachen und feststellen, dass die Hälfte Ihrer Geräte gleichzeitig den WiFi Zugriff verloren hat. Integrieren Sie die Automatisierung der Zertifikatsverlängerung vom ersten Tag an in Ihren MDM-Workflow und nicht erst im Nachhinein. Das dritte Problem ist die Kapazität des RADIUS Servers. EAP-TLS Handshakes sind aufgrund des vollständigen gegenseitigen Zertifikatsaustauschs rechenintensiver als PEAP Handshakes. In einem Stadion oder Konferenzzentrum mit Tausenden von gleichzeitigen Authentifizierungen wird ein unterdimensionierter RADIUS Server zum Nadelöhr. Dimensionieren Sie Ihre RADIUS Infrastruktur für Spitzenwerte bei gleichzeitigen Authentifizierungen, nicht für die durchschnittliche Last. Schließlich sollten Sie auf der Android Seite beachten, dass verschiedene Hersteller - wie Samsung, Google oder Xiaomi - die API für die WiFi Konfiguration leicht unterschiedlich implementieren. Testen Sie Ihre per MDM verteilten Profile auf repräsentativen Geräten der einzelnen Hersteller in Ihrem Bestand, bevor Sie das Rollout im großen Stil durchführen. Insbesondere Samsung-Geräte erforderten in der Vergangenheit eine explizite Angabe des Identitätsfeldes, selbst wenn dieses aus dem Zertifikat abgeleitet werden konnte. --- SCHNELLE FRAGEN UND ANTWORTEN - ca. 1 Minute Ein paar kurze Fragen, die mir regelmäßig gestellt werden. Kann ich EAP-TLS für BYOD-Geräte nutzen? Ja, aber dazu muss der Benutzer ein Client-Zertifikat auf seinem persönlichen Gerät installieren. Für BYOD im großen Stil sollten Sie abwägen, ob EAP-TTLS mit PAP oder PEAP-MSCHAPv2 ein praktischerer Kompromiss ist und EAP-TLS für firmeneigene Geräte reserviert bleibt. Funktioniert EAP-TLS mit WPA3-Enterprise? Ja, und WPA3-Enterprise im 192-Bit-Modus schreibt EAP-TLS sogar zwingend vor. Wenn Sie WPA3-Enterprise in Hochsicherheitsumgebungen bereitstellen, ist EAP-TLS Ihre einzige konforme Option. Was ist die Mindest-Android-Version, die ich anvisieren sollte? Android 8 und höher unterstützt EAP-TLS nativ. Erzwingen Sie für Android 11 und höher eine explizite CA-Zertifikatsvalidierung. Für Android 13 und höher können Sie die verbesserten APIs zur Zertifikatsverwaltung für eine präzisere Steuerung nutzen. Kann die Plattform von Purple in EAP-TLS-Netzwerke integriert werden? Die Plattform für Gast-WiFi und Analytics von Purple läuft auf einer separaten SSID von Ihrem 802.1X-Unternehmensnetzwerk. Ihre Unternehmensgeräte authentifizieren sich über EAP-TLS auf der sicheren SSID, während Gastgeräte das Captive Portal von Purple auf der Gast-SSID nutzen. Beide koexistieren auf derselben Access-Point-Infrastruktur, wobei die VLAN-Trennung die Sicherheitsgrenze bildet. - ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE - ca. 1 Minute Zusammenfassend lässt sich sagen: EAP-TLS auf Android ist die sicherste verfügbare Methode zur WiFi-Authentifizierung in Unternehmen, und mit modernen MDM-Tools lässt sie sich absolut praxisnah in großem Maßstab bereitstellen. Die drei wichtigsten Punkte dabei sind: eine ordnungsgemäß konfigurierte PKI mit automatischer Zertifikatsverlängerung, explizites Vertrauen in CA-Zertifikate auf Android 11 und höher sowie eine auf Spitzenlasten ausgelegte RADIUS-Infrastruktur. Wenn Sie die Lösung an einem Standort mit gemischtem Unternehmens- und Gastdatenverkehr bereitstellen, bietet Ihnen die Plattform von Purple die Analyse- und Interaktionsebene im Gastnetzwerk, während Ihre EAP-TLS-Infrastruktur die Unternehmensseite sichert. Beide ergänzen sich hervorragend. Für Ihre nächsten Schritte: Überprüfen Sie unser Architekturdiagramm im vollständigen Leitfaden, arbeiten Sie die Anleitung zur Bereitstellung mit Intune durch und führen Sie ein Pilotprojekt auf einer Untergruppe von Geräten durch, bevor Sie die Lösung für Ihren gesamten Bestand ausrollen. Beginnen Sie mit einer kontrollierten Gruppe von fünfzig Geräten, validieren Sie die Zertifikatsbereitstellung sowie die WiFi-Konnektivität und skalieren Sie dann mit Zuversicht. Vielen Dank für Ihr Interesse am Purple Technical Briefing. Den vollständigen schriftlichen Leitfaden, Diagramme und Konfigurationsreferenzen finden Sie unter purple.ai. Bis zum nächsten Mal.