Dieser Artikel wurde automatisch übersetzt. Die Übersetzung kann Ungenauigkeiten enthalten.
Zur englischen Originalversion wechseln.
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Fehlerbehebung

Verbindungsprobleme

Client-Ansicht

Falsches XML

Keine Verbindung möglich, da Sie zum Anmelden ein Zertifikat benötigen. Wenden Sie sich an Ihren IT-Support.

Prüfen Sie, ob Ihr Client über ein Zertifikat zur Authentifizierung verfügt und dass Sie das richtige WLAN-Konfigurationsprofil oder XML.

Probleme mit vertrauenswürdigen Stammzertifikaten

Mit diesem Netzwerk kann keine Verbindung hergestellt werden.

Stellen Sie sicher, dass Sie Folgendes getan haben:

  • Teilen Sie Ihrem RADIUS-Server mit, welche Zertifikate eine Verbindung herstellen dürfen, wie beschrieben hier

  • Das aktuelle RADIUS-Serverzertifikat wie beschrieben als vertrauenswürdiges Stammzertifikat auf Ihren Client importiert hier

  • Prüfen Sie Ihre Protokolle. Es gibt eine detaillierte Beschreibung des Fehlers. Vielleicht ist es dieses Problem.

Verbindung fortsetzen?

Verbindung fortsetzen? Wenn Sie an diesem Ort Corporate-WLAN erwarten, fahren Sie fort und verbinden Sie sich. Andernfalls könnte es sich um ein anderes Netzwerk mit demselben Namen handeln.

Zertifikatsdetails anzeigen.

Wenn Ihre Clients bei der ersten Verbindung eine Überprüfung durchführen müssen und dieses Dialogfeld angezeigt wird:

Stellen Sie sicher, dass Sie im WLAN-Profil auf das RADIUS-Serverzertifikat verwiesen und das SAN-Attribut (FQDN) sowie den allgemeinen Namen (CN) des Serverzertifikats angegeben haben:

Anzeige des SAN-Attributs (FQDN) und des allgemeinen Namens (CN) des Serverzertifikats

Server-Ansicht

Unbekannte CA

Wenn Ihre Protokolle Fehlernachrichten enthalten, die den unten gezeigten ähneln

Dies kann die folgenden Ursachen haben:

  • Client gibt Fehler aus TLS-Alarm read:fatal:unbekannte CA

    • Ihr Client kennt das Serverzertifikat und lehnt die Verbindung ab. Stellen Sie sicher, dass Sie Ihr Serverzertifikat wie beschrieben hinzugefügt haben hier.

    • Sie haben ein neues Serverzertifikat und Ihr XML-Profil auf dem Client verwendet das alte. In diesem Fall überprüfen Sie bitte noch einmal, ob Sie entweder Ihr WLAN-/Kabelprofil aktualisiert oder Ihr XML nach dem Hinzufügen der Zertifikate neu generiert und an Ihre Clients verteilt haben.

  • Server gibt Fehler aus TLS-Alarm write:fatal:unbekannte CA

    • Ihr RADIUS-Server kennt den Aussteller des für die Authentifizierung verwendeten Zertifikats nicht. Fügen Sie Ihre CA wie beschrieben hinzu hier.

Zertifikat unbekannt

Wenn Sie macOS (und möglicherweise andere Apple-Plattformen) verwenden und wenn Ihre Protokolle Fehlernachrichten enthalten, die der unten gezeigten ähneln

Dies kann die folgenden Ursachen haben:

Entschlüsselungsfehler | Zugriff verweigert

Wenn Ihre Protokolle Fehlernachrichten enthalten, die den unten gezeigten ähneln

... dann handelt es sich wahrscheinlich um einen Fehler der TPM-Software auf Ihren Windows-Maschinen. Weitere Informationen dazu finden Sie in der SCEPman-Dokumentation.

Wenn Sie so etwas in Ihrem Protokolle

... dafür kann es zwei Gründe geben. Einer ist, dass Ihr WLAN-Profil auf das falsche Stammzertifikat für die Servervalidierung verweist. Stellen Sie sicher, dass Ihr Profil korrekt eingerichtet ist. Wenn das der Fall ist und das Problem weiterhin besteht, versuchen Sie, Ihren KSP auf Software KSP.

Die Einstellung Key Storage Provider (KSP) bestimmt den Speicherort des privaten Schlüssels für die Endbenutzerzertifikate. Die Speicherung im TPM ist sicherer als die softwarebasierte Speicherung, da das TPM eine zusätzliche Sicherheitsebene bietet, um Schlüsseldiebstahl zu verhindern. Allerdings gibt es einen Fehler in einigen älteren TPM-Firmwareversionen der einige mit einem TPM-gestützten privaten Schlüssel erstellte Signaturen ungültig macht. In solchen Fällen kann das Zertifikat nicht für die EAP-Authentifizierung verwendet werden, wie sie bei WLAN- und VPN-Verbindungen üblich ist. Betroffene TPM-Firmwareversionen umfassen:

  • STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100

  • Intel: 11.8.50.3399, 2.0.0.2060

  • Infineon: 7.63.3353.0

  • IFX: Version 3.19 / Spezifikation 1.2

Wenn Sie TPM mit dieser Firmware verwenden, aktualisieren Sie Ihre Firmware entweder auf eine neuere Version oder wählen Sie "Software KSP" als Key-Storage-Provider.

Fortfahren nicht möglich, da sich der Peer fehlerhaft verhält

Wenn Ihre Protokolle Ablehnungen mit dem Fehler enthalten "Fortfahren nicht möglich, da sich der Peer fehlerhaft verhält" dies weist darauf hin, dass der Client die Kommunikation mit dem RADIUS-Dienst eingestellt hat, meist weil die Vertrauenseinstellungen falsch sind. Überprüfen Sie in diesem Fall bitte die Zertifikate auf den betroffenen Geräten.

Falsches gemeinsames RADIUS-Geheimnis

Wenn Ihr (Proxy) Protokolle Fehlernachrichten enthalten, die den unten gezeigten ähneln

dann verwendet eines Ihrer Access Points oder Switches, das bzw. der versucht, eine Verbindung zu Ihrer RADIUSaaS-Instanz über einen RADIUS Proxy ein nicht übereinstimmendes Shared Secret.

Um den betroffenen Access Point oder Switch zu identifizieren, ermitteln Sie zunächst den RADIUS-Proxy, indem Sie die Fehlermeldung aufklappen und nach der proxyip Eigenschaft suchen. Da Sie nun den Proxy kennen, nutzen Sie Ihr Inventar und Ihr Wissen über spezifische Standorte oder Gruppen von Geräten, die keine Verbindung zu Ihrem Netzwerk herstellen können, um das falsch konfigurierte Netzwerkgerät zu identifizieren. Aktualisieren Sie schließlich das Shared Secret so, dass es dem in Ihrer RADIUSaaS-Instanz für diesen Proxy konfigurierten Wert entspricht.

Problembehandlung bei Verbindungsproblemen mit CAPI2-Protokollen

Windows-Clients verwenden den Cryptographic API (CAPI2) Subsystem, um Zertifikatsoperationen während der EAP-TLS-Authentifizierung zu verarbeiten. Wenn eine Verbindung fehlschlägt und weder die Client-Oberfläche noch die RADIUSaaS-Serverprotokolle einen klaren Hinweis auf die Ursache liefern, kann das Aktivieren der CAPI2-Protokollierung auf dem betroffenen Gerät Fehler bei der Zertifikatsvalidierung, Fehler beim Erstellen der Zertifikatskette oder Probleme beim Zugriff auf den privaten Schlüssel aufdecken, die sonst unsichtbar wären.

Schritt 1: CAPI2-Protokollierung aktivieren

Die CAPI2-Protokollierung ist standardmäßig deaktiviert. So aktivieren Sie sie:

  1. Öffnen Sie Ereignisanzeige: drücken Sie Win + R, geben Sie eventvwr.exe, und drücken Sie Enter.

  2. Erweitern Sie im Baum links Anwendungs- und Dienstprotokolle.

  3. Erweitern Sie Microsoft → Windows → CAPI2.

  4. Klicken Sie mit der rechten Maustaste auf Operational und wählen Sie Protokoll aktivieren.

Sobald die Protokollierung aktiviert ist, zeichnet Windows alle CAPI2-Ereignisse auf. Stellen Sie den Verbindungsfehler erneut her. Versuchen Sie nun, eine Verbindung zum Wi-Fi- oder kabelgebundenen Netzwerk herzustellen, und fahren Sie dann mit dem nächsten Schritt fort.

Tipp: Deaktivieren Sie das Protokoll nach dem Sammeln der Daten wieder (klicken Sie mit der rechten Maustaste auf Operational → Protokoll deaktivieren), um unnötigen Speicherplatzverbrauch zu vermeiden.

Schritt 2: Die relevanten Ereignisse finden

Nachdem Sie das Problem reproduziert haben, suchen Sie in den folgenden Protokollquellen nach Ereignissen:

Protokollquelle
Pfad in der Ereignisanzeige

CAPI2

Anwendungs- und Dienstprotokolle → Microsoft → Windows → CAPI2 → Operational

WLAN AutoConfig

Anwendungs- und Dienstprotokolle → Microsoft → Windows → WLAN-AutoConfig → Operational

Konzentrieren Sie sich auf Ereignisse, die aufgezeichnet wurden zum Zeitpunkt des fehlgeschlagenen Verbindungsversuchs. Nützliche Hinweise sind:

  • CAPI2 — Fehler im Zusammenhang mit dem Erstellen der Zertifikatskette, Widerrufsprüfungen oder dem Zugriff auf den privaten Schlüssel (z. B. Ereignis-IDs 11, 70, 90).

  • WLAN-AutoConfig — Ereignisse, die das Ergebnis der 802.1X-Aushandlung beschreiben (z. B. Ereignis-IDs 8001, 8002, 12013).

Schritt 3: Die Protokolle exportieren und senden

Um uns die Protokolle zur Prüfung zu senden:

  1. Klicken Sie in der Ereignisanzeige mit der rechten Maustaste auf das Operational Protokoll unter CAPI2 und wählen Sie Alle Ereignisse speichern unter…

  2. Speichern Sie die Datei als Ereignisprotokoll (*.evtx) Datei und geben Sie ihr einen aussagekräftigen Namen, z. B. CAPI2_<device-name>_<date>.evtx.

  3. Wiederholen Sie dieselben Schritte für das WLAN-AutoConfig → Operational Protokoll.

  4. Senden Sie beide .evtx Dateien an unser Support-Team unter https://www.radius-as-a-service.com/help/ zusammen mit einer kurzen Beschreibung des betroffenen Geräts, der OS-Version und des Auftretens des Problems.

Zertifikatsprobleme

Zertifikatskette konnte nicht überprüft werden

Wenn Sie Ihr eigenes Serverzertifikat verwenden möchten, benötigt Ihr RADIUS-Server die vollständige Zertifikatskette, damit andere Teilnehmer (Proxy, RadSec-Clients, Endpunkte, die versuchen, eine Verbindung herzustellen) die Identität des Servers überprüfen können. Wenn Sie diese Meldung sehen, kopieren Sie entweder das CA-Zertifikat unterhalb des Serverzertifikats in das Textfeld und fügen Sie es ein, oder erstellen Sie ein PCKS8-Zertifikatsbündel, das alle Zertifikate vom Blatt bis zur Wurzel enthält.

Probleme mit dem Admin-Portal

Anmeldung

Um sich beim RADIUSaaS-Webportal ("RADIUSaas Admin Portal") anzumelden, müssen die folgenden Voraussetzungen erfüllt sein:

  • Die von Ihnen als technischer Administrator angegebene UPN-/E-Mail-Adresse muss authentifizierbar sein gegen einen beliebigen Microsoft Entra ID (Azure AD) (es muss sich nicht um eine Identität aus dem Tenant handeln, dessen Benutzer RADIUSaaS für die Netzwerkauthentifizierung nutzen werden).

  • Die von Ihnen als technischer Administrator angegebene UPN-/E-Mail-Adresse muss auf Ihrer RADIUSaaS-Instanz wie beschrieben registriert worden sein hier. Falls es sich um den ersten Administrator handelt, bitte kontaktieren Sie uns wenn Sie glauben, dass wir den falschen Benutzer registriert haben.

  • Das Microsoft Entra ID (Azure AD)-Benutzerobjekt hinter der UPN-/E-Mail-Adresse muss berechtigt sein, der RADIUSaaS Enterprise Application die folgenden Berechtigungen zu erteilen (siehe Screenshot unten):

    • Lesen das grundlegende Benutzerprofil

    • Verwalten Zugriff auf Daten beibehalten, für die Sie Zugriff gewährt haben (Anforderung eines Aktualisierungstokens zulassen)

  • Falls Ihr Microsoft Entra ID (Azure AD)-Benutzer keine Rechte zum Erteilen der erforderlichen Berechtigungen hat, wird keine entsprechende Enterprise Application automatisch in Ihrem Microsoft Entra ID (Azure AD) erstellt. Um dies zu umgehen, bitten Sie Ihre IT-Abteilung, Ihrem Benutzer die erforderlichen Berechtigungen zu erteilen.

Probleme mit der Intune-Konfiguration

Profilzuweisung

Die Wi-Fi-Konfiguration wird nicht bereitgestellt, wenn Wi-Fi-, SCEP- und vertrauenswürdige Zertifikatsprofile verschiedenen Gruppen zugewiesen sind. Sie werden möglicherweise als "Ausstehend" angezeigt, oder es gibt überhaupt keinen Status. Bitte verwenden Sie das dieselbe Gruppe oder "Alle Geräte" bzw. "Alle Benutzer" für alle verknüpften Profile.

Sie können das SCEP-Stammzertifikatsprofil sowohl "Alle Benutzer" als auch "Alle Geräte" zuweisen, wenn Sie ein Gerätezertifikat (zugewiesen zu "Alle Geräte") und ein Benutzerzertifikat (zugewiesen zu "Alle Benutzer") verwenden.

SCEP-Zertifikat

Android

Android scheint in neueren Versionen einen UPN im Subject Alternative Name zu benötigen (sogar für Gerätezertifikate). Bitte fügen Sie dies in Ihrem SCEP-Profil hinzu (z. B. {{DeviceId}}@contoso.com):

Wi-Fi-Profil

Android

Häufige Fehlercodes: 0xc7d24fc5 oder -942518331

Die wichtigsten Punkte sind:

  • wählen Sie das Root-CA-Zertifikat für Servervalidierung (wichtig: Laden Sie nicht das Serverzertifikat von RADIUSaaS hoch) - und -

  • definieren Sie einen RADIUS-Servernamen

    • Hinweis: Für dieses Feld scheint es eine Zeichenbegrenzung zu geben. Um mögliche Probleme zu lösen, können Sie einfach den Domain-Teil ohne Subdomain verwenden, z. B. "radius-as-a-service.com" (statt "contoso.radius-as-a-service.com").

    • Android-Entwickler schreibt: "[...] muss konfigurieren sowohl ein Root-CA-Zertifikat, und entweder eine Übereinstimmung des Domänensuffixes oder eine alternative Subject-Übereinstimmung". Das MDM kann also "setAltSubjectMatch" oder "setDomainSuffixMatch" verwenden, nachdem der WLAN-Konfiguration ein Root-Zertifikat hinzugefügt wurde. Intune scheint "setDomainSuffixMatch" zu verwenden, da einfach "radius-as-a-service.com" ausreicht.

  • manchmal Identitätsprivatsphäre erforderlich ist (z. B. zu sehen auf Android-Kioskgeräten / Android Enterprise Dedicated)

Zuletzt aktualisiert

War das hilfreich?