Fehlerbehebung bei Android 802.1X und EAP-TLS: Eine Checkliste für die Bereitstellung mit Intune und Microsoft Entra ID

Verwaltete Android-Telefone scheitern bei EAP-TLS in der Regel aus einem von vier Gründen: Dem WiFi-Profil fehlt ein CA-Zertifikat oder eine Domain, sodass Android den RADIUS-Server ablehnt. Das Client-Zertifikat befindet sich in einem anderen Profil. Das Feld für die RADIUS-Servernamen stimmt nicht mit dem Server-Zertifikat überein. Oder das vertrauenswürdige Stammprofil hat das Gerät nie erreicht.

Wie sieht ein EAP-TLS-Fehler auf Android aus?

EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security) authentifiziert ein Gerät mit einem Zertifikat anstelle eines Passworts. Es läuft innerhalb von IEEE 802.1X, dem portbasierten Standard für die Zugriffskontrolle. 802.1X übergibt die Authentifizierung an einen RADIUS- (Remote Authentication Dial-In User Service) Server.

Wenn dies auf Android fehlschlägt, treten in der Regel folgende Symptome auf:

• Das Netzwerk erscheint in der Liste, kommt aber nie über "Verbindung wird hergestellt" hinaus und fällt dann auf "Gespeichert" zurück.
• Das Gerät zeigt einen allgemeinen Authentifizierungsfehler an. Die genaue Formulierung variiert je nach Hersteller.
• Das Netzwerk funktioniert auf Samsung-Geräten, aber nicht auf Google Pixel - oder umgekehrt.
• Das Netzwerk funktioniert auf unternehmenseigenen Telefonen, scheitert jedoch auf persönlichen Geräten, die mit einem Arbeitsprofil registriert sind.
• In Ihren RADIUS-Protokollen wird überhaupt nichts angezeigt.

Dieses letzte Symptom ist am wichtigsten. Ein Gerät, das RADIUS gar nicht erst erreicht, hat ein Profilproblem und kein Authentifizierungsproblem.

Was sind die häufigsten Ursachen für EAP-TLS-Fehler bei Android?

Strengere Server-Validierung in neueren Android-Versionen

Neuere Android-Versionen haben die Option "Nicht validieren" für neue Unternehmensnetzwerke entfernt. Android benötigt nun zwei Dinge, bevor es sein Zertifikat sendet: ein vertrauenswürdiges CA-Zertifikat und eine passende Domain.

Ohne diese beiden Angaben weigert sich das Gerät, den TLS-Handshake abzuschließen. Profile, die auf älteren Versionen jahrelang funktionierten, können nach einem Update des Betriebssystems fehlschlagen.

Zertifikat im Arbeitsprofil, Netzwerkbeitritt über den privaten Bereich

Android Enterprise trennt das Arbeitsprofil vom privaten Bereich, und beide haben ihren eigenen Zertifikatsspeicher. Intune installiert das Client-Zertifikat und den vertrauenswürdigen Stamm im Arbeitsprofil. Ein Mitarbeiter, der die SSID manuell über die persönlichen Einstellungen hinzufügt, kann nicht auf diese Zertifikate zugreifen, weshalb die Authentifizierung fehlschlägt.

Das Feld für RADIUS-Servernamen

Das Intune Android Enterprise WiFi-Profil enthält ein Feld für RADIUS-Servernamen. Die Microsoft-Dokumentation verlangt hier den DNS-Namen, der im Zertifikat Ihres RADIUS-Servers angegeben ist. Android trägt diesen Wert in sein Domain-Feld ein und vergleicht ihn mit dem Server-Zertifikat. Wenn das Feld leer ist, Tippfehler enthält oder eine IP-Adresse enthält, schlägt die Validierung fehl.

Das vertrauenswürdige Stammprofil

Das WiFi-Profil verweist auf ein separates vertrauenswürdiges Intune-Zertifikatsprofil. Dieses Profil muss die Root-CA enthalten, die das Zertifikat des RADIUS-Servers ausgestellt hat. Ein häufiger Fehler besteht darin, die Root-CA hinter Ihren Client-Zertifikaten bereitzustellen, obwohl eine andere CA das Server-Zertifikat signiert hat. Zudem müssen beide Profile auf dieselben Gruppen und denselben Android Enterprise-Registrierungstyp ausgerichtet sein.### Herstellerunterschiede

Samsung, Google Pixel und die Builds anderer Hersteller benennen und ordnen die Enterprise WiFi Einstellungen unterschiedlich an. Einige zeigen zusätzliche Optionen an, wie z. B. Online-Zertifikatsstatusprüfungen. Verwenden Sie die Geräte Ihrer eigenen Flotte als Referenz, nicht Screenshots einer anderen Marke.

Wie finden Sie heraus, welche Ursache vorliegt?

Beginnen Sie auf dem Gerät und überprüfen Sie dies anschließend in den RADIUS-Logs. Das Muster in den Logs deutet in der Regel auf die Ursache hin.

Symptom	Was RADIUS anzeigt	Wahrscheinliche Ursache	Erste Fehlerbehebung
Kein Versuch erreicht RADIUS	Keine Anfrage vom Gerät	WiFi-Profil nicht angewendet oder SSID-Name stimmt nicht überein	Überprüfen Sie den Status des gerätespezifischen Profils in Intune
Handshake stoppt, nachdem der Server sein Zertifikat gesendet hat	TLS-Warnung vom Client, wie z. B. "unknown CA"	Falscher oder fehlender vertrauenswürdiger Root-Eintrag oder Domänenkonflikt	Stellen Sie die Root-CA des Servers und die korrekten RADIUS-Servernamen bereit
Handshake wird serverseitig abgeschlossen, schlägt dann aber fehl	Kein Client-Zertifikat vorgelegt	SCEP- oder PKCS-Zertifikat fehlt oder befindet sich im falschen Profil	Bestätigen Sie, dass das Zertifikatsprofil für dieses Gerät erfolgreich war
Zertifikat akzeptiert, dann abgelehnt	Access-Reject nach der Zertifikatsvalidierung	Identitätszuordnung, Sperrung oder Richtlinienregel	Überprüfen Sie den Zertifikatsantragsteller oder SAN mit dem Identitätsanbieter
Schlägt nur auf persönlichen Geräten fehl	Keine Anfrage oder kein Client-Zertifikat	Beitritt zur SSID über den persönlichen Bereich	Stellen Sie das Profil für das Arbeitsprofil bereit und unterbinden Sie manuelle Beitritte

Fehler auf dem Gerät auslesen

Öffnen Sie im Microsoft Intune Admin Center das Gerät und überprüfen Sie den Status jedes Konfigurationsprofils. Ein WiFi-Profil, das als ausstehend oder fehlerhaft angezeigt wird, hat das Gerät nie erreicht. Ein fehlerhaftes Zertifikatsprofil bedeutet, dass die SCEP- (Simple Certificate Enrollment Protocol) oder PKCS- (Public Key Cryptography Standards) Ausstellung fehlgeschlagen ist. Beheben Sie dies, bevor Sie Änderungen am Netzwerk vornehmen.

Auf Testgeräten zeigen die Android Debug Bridge Logs des WiFi-Supplicants die genaue TLS-Warnung an. Nutzen Sie dies für ein Testgerät, nicht für eine Produktionsflotte.

RADIUS-Logs auslesen

FreeRADIUS, Microsoft Network Policy Server und Cloud-RADIUS-Plattformen protokollieren alle, wo der EAP-Austausch gestoppt wurde. Suchen Sie nach der MAC-Adresse des Geräts oder der Zertifikatsidentität. Eine vom Client gesendete TLS-Warnung bedeutet, dass das Telefon Ihren Server abgelehnt hat. Ein Access-Reject nach einem gültigen Zertifikat bedeutet, dass Ihr Server das Telefon abgelehnt hat.

Wenn sich Geräte authentifizieren und dann die Verbindung trennen, sobald Mitarbeiter zwischen den Etagen wechseln, liegt eine andere Ursache vor. Lesen Sie Resolving Roaming Issues in Corporate WLANs. Verbindungsabbrüche, die mit Kanalwechseln zusammenfallen, deuten stattdessen auf Radarereignisse hin. Siehe DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Wie beheben Sie das Problem in Intune und auf dem jeweiligen Android-Build?

In Intune

1. Öffnen Sie das Android Enterprise WiFi Profil, das dem Registrierungstyp entspricht. Für vollständig verwaltete, dedizierte und unternehmenseigene Arbeitsprofilgeräte wird ein Profiltyp verwendet. Für persönlich genutzte Arbeitsprofilgeräte ein anderer.
2. Stellen Sie den EAP-Typ auf EAP-TLS ein.
3. Geben Sie den DNS-Namen des RADIUS-Serverzertifikats unter RADIUS-Servernamen ein. Der genaue Name aus dem Zertifikat ist der sicherste Wert. Geben Sie niemals eine IP-Adresse ein.
4. Wählen Sie das vertrauenswürdige Zertifikatsprofil aus, das die Root-CA des Servers enthält.
5. Wählen Sie das SCEP- oder PKCS-Profil für die Client-Authentifizierung aus.
6. Weisen Sie alle drei Profile derselben Gruppe zu.

Auf Samsung-, Pixel- und anderen Builds

Bitten Sie Ihre Mitarbeiter bei keiner Marke, die Enterprise-Einstellungen manuell zu bearbeiten. Manuelle Änderungen umgehen Intune und landen auf der falschen Seite des Arbeitsprofils. Wenn ein Hersteller fehlerhaft ist und ein anderer funktioniert, vergleichen Sie zuerst den Profilstatus. Testen Sie dann den Domänenwert mit diesem Build in Ihrer Testumgebung.

Auf der RADIUS-Seite

Bestätigen Sie, dass das Serverzertifikat den DNS-Namen trägt, den Sie in Intune eingegeben haben. Bestätigen Sie, dass seine Kette zu der von Ihnen bereitgestellten Root-CA führt. Wenn Sie Purple Staff WiFi nutzen, stellt Purple den Cloud-RADIUS-Service bereit und verbindet sich über RadSec - RADIUS innerhalb von TLS - mit Ihren Access Points. Die Schritte zur Einrichtung des Herstellers finden Sie in den Support-Artikeln von Purple, zum Beispiel Staff WiFi - Ubiquiti UniFi. Überprüfen Sie die Anforderungen an die Access Points unter Security and Hardware Compatibility.

Praxisszenarien

Ein 200-Zimmer-Hotel nach einem Android-Update

Stellen Sie sich ein Hotel mit 200 Zimmern und 60 firmeneigenen Mobilgeräten für Housekeeping und Haustechnik vor. Nach einem monatlichen Update konnten sich 40 Mobilgeräte nicht mehr mit der Mitarbeiter-SSID verbinden. Die RADIUS-Protokolle zeigten vom Client gesendete TLS-Warnungen.

Das WiFi Profil enthielt keinen Wert für RADIUS-Servernamen, was von älteren Builds toleriert worden war. Das IT-Team fügte den DNS-Namen des Serverzertifikats hinzu und stellte das Profil neu bereit. Alle 60 Mobilgeräte bauten nach dem nächsten Intune-Check-In eine Verbindung auf, ganz ohne Zurücksetzen auf Werkseinstellungen. Hotelbetreiber finden weitere Informationen zur Konnektivität für Mitarbeiter auf unserer Seite für Hotels.

Eine Einzelhandelskette mit 120 Filialen und privaten Geräten

Stellen Sie sich eine Einzelhandelskette mit 120 Filialen vor, bei der die Filialleiter persönliche Mobiltelefone nutzen, die mit einem Arbeitsprofil registriert sind. Helpdesk-Tickets zeigten, dass Telefone in vielen Filialen den RADIUS-Server nie erreichten.

Die Filialleiter hatten die Filial-SSID über die persönlichen Einstellungen hinzugefügt, wo kein Zertifikat existiert. Das Team wies das WiFi Profil für persönlich genutzte Arbeitsprofile zu und wies die Manager an, manuelle Einträge zu entfernen. Die Verbindungsfehler hörten auf, sobald jedes Telefon das verwaltete Profil erhielt.

Ein Bahnbetreiber erneuert sein Serverzertifikat

Denken Sie an einen Zugbetreiber, der Mitarbeiter-WiFi an Bord und in Depots betreibt (Trains). Der Betreiber erneuerte sein RADIUS-Serverzertifikat von einer neuen ausstellenden CA. Jedes Android-Gerät fiel über Nacht mit der Meldung "unbekannte CA" aus. Das Hochladen des neuen Root-Zertifikats in das vertrauenswürdige Zertifikatsprofil vor der Umstellung hätte den Ausfall verhindert. Der Betreiber bereitet Root-Zertifikatsänderungen nun zwei Wochen im Voraus vor.

Wie verhindern Sie, dass so etwas noch einmal passiert?

Rollout-Checkliste für Android-Flotten in Intune und Entra ID

• Identitäten zuordnen. Entscheiden Sie, ob Zertifikate die Geräte-ID oder den UPN des Mitarbeiters, also seinen Entra ID-Anmeldenamen, tragen. Konfigurieren Sie RADIUS so, dass es mit diesem Feld übereinstimmt.
• Nach Registrierungstyp trennen. Erstellen Sie ein Profilset für firmeneigene Geräte und eines für persönliche Geräte mit Arbeitsprofil.
• Profile koppeln. Das vertrauenswürdige Root-Zertifikat, das Client-Zertifikat und die WiFi-Profile müssen dieselbe Zuweisungsgruppe teilen.
• Das richtige Root-Zertifikat verwenden. Stellen Sie die CA bereit, die das RADIUS-Serverzertifikat signiert hat.
• RADIUS-Servernamen ausfüllen. Verwenden Sie den DNS-Namen aus dem Serverzertifikat, niemals eine IP-Adresse.
• Herstellerübergreifender Pilotversuch. Testen Sie mindestens ein Samsung- und ein Pixel-Gerät sowie alle anderen Marken in Ihrer Flotte.
• Manuelle Verbindungen verbieten. Weisen Sie die Mitarbeiter an, die SSID niemals manuell hinzuzufügen.
• Zertifikatsverlängerungen staffeln. Verteilung neuer Root-Zertifikate, bevor sich das Serverzertifikat ändert.
• Beide Seiten überwachen. Überprüfen Sie während des Rollouts wöchentlich den Intune-Profilstatus und die RADIUS-Ablehnungen.

Informationen zur Integration von Identitätsanbietern finden Sie unter How to Enable Single Sign On.

Häufig gestellte Fragen

Funktioniert Purple Staff WiFi mit in Intune verwalteten Android-Geräten?

Ja. Purple Staff WiFi authentifiziert verwaltete Android-Geräte mit zertifikatsbasiertem 802.1X gegen den Cloud-RADIUS von Purple. Sie nutzen weiterhin Intune für die Bereitstellung von Zertifikaten und WiFi-Profilen. Purple stellt für die Identität eine Verbindung zu Microsoft Entra ID, Okta und Google Workspace her. Ihre Intune-Profile verweisen auf das Purple RADIUS-Serverzertifikat anstelle eines On-Premises-Servers. Die in diesem Leitfaden beschriebenen Regeln auf der Android-Seite gelten weiterhin: Ein vertrauenswürdiges Root-Zertifikat und eine passende Domain sind erforderlich.

Benötige ich neue Access Points, um EAP-TLS mit Purple auszuführen?

Nein. Purple ist hardwareunabhängig und funktioniert als Cloud-Overlay auf den Access Points, die Sie bereits betreiben. Zu den unterstützten Herstellern gehören Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Jeder Hersteller benötigt eine RADIUS-Konfiguration, die auf Purple verweist. Die Einrichtungsschritte finden Sie in den Support-Artikeln von Purple. Prüfen Sie vor dem Start die Anforderungen auf Modellebene im Artikel zur Sicherheits- und Hardwarekompatibilität.

Kann ich von On-Premises NPS zu Cloud-RADIUS wechseln, ohne Android-Geräte neu zu registrieren?

Ja, in den meisten Fällen ist dies möglich. Geräte behalten ihre bestehenden Client-Zertifikate, wenn der neue RADIUS-Service Ihrer ausstellenden CA vertraut. Sie aktualisieren das Profil für vertrauenswürdige Stammzertifikate und die RADIUS-Servernamen in Intune, damit sie mit dem neuen Serverzertifikat übereinstimmen. Bereiten Sie diese Profiländerungen vor, bevor Sie das RADIUS-Ziel der SSID wechseln. Das verhindert die in diesem Leitfaden beschriebenen nächtlichen Fehler durch eine "unbekannte CA".

Ist EAP-TLS besser als PEAP oder iPSK für Mitarbeitergeräte?

Ja, für verwaltete Geräteflotten. EAP-TLS verwendet ein Zertifikat pro Gerät oder Identität, sodass keine gemeinsam genutzten Passwörter durchsickern können. PEAP (Protected EAP) basiert auf einem Benutzernamen und einem Passwort in einem TLS-Tunnel. iPSK (identity pre-shared key) weist jedem Gerät oder jeder Gruppe einen eigenen Schlüssel zu. iPSK eignet sich für nicht verwaltete Geräte, die keine Zertifikate speichern können. EAP-TLS eignet sich für Telefone, die Sie über Intune verwalten.

Welche Compliance-Standards erfüllt Purple für die Authentifizierungsdaten von Mitarbeitern?

Purple ist nach ISO 27001 und Cyber Essentials zertifiziert und entspricht der GDPR und der CCPA. Zertifikatsbasiertes 802.1X unterstützt die strengen Zugriffskontrollen, die PCI-DSS für Netzwerke in der Nähe von Karteninhaberdaten vorschreibt. Purple besitzt außerdem die B Corp-Zertifizierung. Fragen Sie Ihr Account-Team nach den aktuellen Zertifikaten, falls Ihr Beschaffungsprozess Kopien erfordert.

Wie lange dauert ein Android EAP-TLS-Rollout?

Der Großteil des Aufwands fließt in der Regel in die PKI und Intune, nicht in die Access Points. Die Ausrichtung einer SSID auf den RADIUS von Purple folgt einer kurzen Checkliste des Anbieters im Support-Center. Das Erstellen von SCEP- oder PKCS-Profilen, Profilen für vertrauenswürdige Stammzertifikate und WiFi-Profilen für jeden Registrierungstyp nimmt mehr Zeit in Anspruch. Planen Sie vor der umfassenden Bereitstellung Zeit für ein Pilotprojekt ein, das jeden Hersteller in Ihrer Flotte abdeckt.