So richten Sie Enterprise WiFi auf Android Geräten mit EAP-TLS ein

Einrichtung 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 Gastgeber, und heute befassen wir uns mit den Besonderheiten der Bereitstellung von 802.1X EAP-TLS-Authentifizierung auf Android-Geräten - ganz gleich, ob Sie ein Hotelportfolio, eine Einzelhandelskette, ein Stadion oder einen Campus im öffentlichen Sektor verwalten. Wenn Sie für ein Netzwerk verantwortlich sind, das firmeneigene oder BYOD-Android-Geräte authentifizieren muss, ohne sich auf gemeinsam genutzte Passwörter zu verlassen, ist diese Episode 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: keine Anmeldedaten, die per Phishing abgefangen werden können, keine Passwörter, die regelmäßig geändert werden müssen, und ein Compliance-Status, der PCI-DSS, ISO 27001 und die meisten Sicherheitsframeworks 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 - konfiguriert als WPA2-Enterprise oder WPA3-Enterprise - 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 den eigentlichen Authentifizierungsserver darstellt. EAP-TLS - das steht für Extensible Authentication Protocol mit Transport Layer Security - ist die Authentifizierungsmethode, die innerhalb dieses 802.1X-Frameworks 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 sendet ein Clientzertifikat an den RADIUS-Server zurück. Beide Parteien validieren sich gegenseitig. Das ist eine gegenseitige Authentifizierung und macht EAP-TLS zur sichersten verfügbaren Option. Speziell bei Android müssen Sie einige Dinge beachten. Mit Android 11 und neueren Versionen wurden strengere Anforderungen an die Zertifikatsvalidierung eingeführt. Wenn Sie die Bereitstellung auf Android 11 oder höher durchführen - was mittlerweile den Großteil 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 einzelnes Android-Gerät über EAP-TLS authentifizieren kann. Erstens eine Zertifizierungsstelle (Certificate Authority) - 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 Client-Zertifikat, das für jedes Gerät oder jeden Benutzer ausgestellt und ebenfalls von derselben CA signiert wurde. Das Gerät legt sein Client-Zertifikat während des TLS-Handshakes vor, und der RADIUS-Server validiert es anhand der Zertifikatssperrliste (CRL) der CA oder über OCSP (Online Certificate Status Protocol). Bei Android werden das Client-Zertifikat und der private Schlüssel normalerweise als PKCS12-Datei verpackt - also 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 und schließlich Zertifikat installieren. Auf einem per MDM verwalteten Gerät wird das Zertifikat im Hintergrund an den verwalteten Keystore des Geräts übertragen - es ist keine Interaktion des Benutzers erforderlich. Sprechen wir nun über das WiFi-Profil selbst. Wenn Sie eine WiFi-Verbindung für Unternehmen 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 Client-Zertifikat 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. Ab Android 11 müssen Sie außerdem den übereinstimmenden Domänensuffix 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 Client-Zertifikat auf jedem registrierten Android-Gerät anfordert und installiert. Anschließend erstellen Sie ein WiFi-Konfigurationsprofil, das sich auf dieses Zertifikatsprofil bezieht. Wenn sich das Gerät anmeldet, empfängt es sowohl das Zertifikat als auch das WiFi-Profil und verbindet sich automatisch mit Ihrem 802.1X-Netzwerk. Keine Benutzerinteraktion, keine Support-Anrufe. Wenn Sie hierfür Intune verwenden, führt Sie unser begleitender Leitfaden zur Verteilung von WiFi-Zertifikaten an Geräte mit Microsoft Intune durch die genauen Konfigurationsschritte - ich empfehle Ihnen, diesen parallel zu diesem Briefing zu lesen. Bei VMware Workspace ONE und Jamf Connect ist der Prozess architektonisch identisch - SCEP- oder PKCS-Zertifikatsprofil, gefolgt von einem WiFi-Profil, das sich darauf bezieht. Die Benutzeroberfläche unterscheidet sich im Detail, aber die Anforderungen an die Zertifikatskette und die RADIUS-Konfiguration sind dieselben. Ein wichtiger Punkt auf der RADIUS-Seite: Wenn Sie FreeRADIUS, Microsoft NPS oder Cisco ISE verwenden, stellen Sie sicher, dass Ihr Serverzertifikat die korrekten Attribute für die erweiterte Schlüsselverwendung (Extended Key Usage - EKU) enthält - insbesondere Server-Authentifizierung, OID 1.3.6.1.5.5.7.3.1. Android ist hier sehr streng. Ein Zertifikat, das mit Windows-Clients einwandfrei funktioniert, kann unter Android fehlschlagen, wenn die EKU fehlt oder falsch konfiguriert ist. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE - ca. 2 Minuten Lassen Sie uns darüber sprechen, was in der Praxis tatsächlich schiefgeht, denn hier stoßen die meisten Bereitstellungen auf Probleme. 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 in den Benutzer-Zertifikatsspeicher des Geräts 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 feststellen, dass die Hälfte Ihres Gerätebestands gleichzeitig den WiFi-Zugriff verloren hat. Integrieren Sie die Automatisierung der Zertifikatsverlängerung vom ersten Tag an in Ihren MDM-Workflow, 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 zu klein dimensionierter RADIUS-Server zum Engpass. Dimensionieren Sie Ihre RADIUS-Infrastruktur für Spitzenzeiten bei gleichzeitigen Authentifizierungen, nicht für die durchschnittliche Last. Schließlich sollten Sie auf der Android-Seite beachten, dass verschiedene Hersteller - Samsung, Google, Xiaomi - leicht unterschiedliche Implementierungen der WiFi-Konfigurations-API haben. Testen Sie Ihre über MDM verteilten Profile auf repräsentativen Geräten der einzelnen Hersteller in Ihrem Bestand, bevor Sie sie im großen Stil einführen. Insbesondere bei Samsung-Geräten war es in der Vergangenheit erforderlich, das Identitätsfeld explizit festzulegen, selbst wenn es aus dem Zertifikat abgeleitet werden kann. --- 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 verwenden? Ja, aber dazu muss der Benutzer ein Client-Zertifikat auf seinem persönlichen Gerät installieren. Bei BYOD im großen Stil sollten Sie abwägen, ob EAP-TTLS mit PAP oder PEAP-MSCHAPv2 ein praktischerer Kompromiss ist, während 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 einsetzen, ist EAP-TLS Ihre einzige konforme Option. Was ist die Mindestversion von Android, 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? Das Gäste-WiFi und die Analyseplattform von Purple laufen auf einer separaten SSID von Ihrem 802.1X-Unternehmensnetzwerk. Ihre Unternehmensgeräte authentifizieren sich über EAP-TLS auf der sicheren SSID, während Gäste-Geräte das Captive Portal von Purple auf der Gäste-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 ist die Bereitstellung in großem Maßstab absolut praktikabel. Die drei Dinge, die Sie richtig machen müssen, sind: eine ordnungsgemäß konfigurierte PKI mit automatischer Zertifikatsverlängerung, explizites CA-Zertifikatsvertrauen auf Android 11 und höher sowie eine auf Spitzenlast ausgelegte RADIUS-Infrastruktur. Wenn Sie die Lösung an einem Standort mit gemischtem Unternehmens- und Gästeverkehr bereitstellen, bietet Ihnen die Plattform von Purple die Analyse- und Interaktionsebene im Gästenetzwerk, während Ihre EAP-TLS-Infrastruktur die Unternehmensseite sichert. Beide ergänzen sich hervorragend. Für Ihre nächsten Schritte: Sehen Sie sich unser Architekturdiagramm im vollständigen Leitfaden an, arbeiten Sie sich durch die Intune-Bereitstellungsanleitung und führen Sie ein Pilotprojekt auf einer Teilmenge von Geräten durch, bevor Sie die Lösung für Ihren gesamten Bestand bereitstellen. 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, dass Sie sich das Purple Technical Briefing angehört haben. Den vollständigen schriftlichen Leitfaden, Diagramme und Konfigurationsreferenzen finden Sie unter purple.ai. Bis zum nächsten Mal.