> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/de/andere/troubleshooting.md). # Fehlerbehebung ## Verbindungsprobleme ### Client-Ansicht #### Falsches XML {% hint style="warning" %} Keine Verbindung möglich, da Sie zum Anmelden ein Zertifikat benötigen. Wenden Sie sich an Ihren IT-Support. {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/k8FhkMHpqVOne7UXpLzC/image.png) Prüfen Sie, ob Ihr Client über ein Zertifikat zur Authentifizierung verfügt und dass Sie das richtige [WLAN-Konfigurationsprofil](/de/profilbereitstellung/microsoft-intune/wifi-profile.md) oder [XML](/de/admin-portal/settings/trusted-roots.md#xml). #### Probleme mit vertrauenswürdigen Stammzertifikaten {% hint style="warning" %} Mit diesem Netzwerk kann keine Verbindung hergestellt werden. {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/g3XbpcPNSLDJPrr96nYr/image.png) Stellen Sie sicher, dass Sie Folgendes getan haben: * Teilen Sie Ihrem RADIUS-Server mit, welche Zertifikate eine Verbindung herstellen dürfen, wie beschrieben [hier](/de/admin-portal/settings/trusted-roots.md#add) * Das aktuelle RADIUS-Serverzertifikat wie beschrieben als vertrauenswürdiges Stammzertifikat auf Ihren Client importiert [hier](/de/profilbereitstellung/microsoft-intune/trusted-root.md#to-add-a-trusted-root-profile-for-your-clients) * Prüfen Sie Ihre [Protokolle](/de/admin-portal/insights/log.md#logs). Es gibt eine detaillierte Beschreibung des Fehlers. Vielleicht ist es [dieses](/de/andere/troubleshooting.md#fatal-decrypt-error) Problem. #### Verbindung fortsetzen? {% hint style="warning" %} 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. {% endhint %} Wenn Ihre Clients bei der ersten Verbindung eine Überprüfung durchführen müssen und dieses Dialogfeld angezeigt wird: ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/8uYG1oXtvKS2IJkLbQyL/image.png) 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](/de/admin-portal/insights/log.md#logs) Fehlernachrichten enthalten, die den unten gezeigten ähneln ``` FEHLER: (14872) eap_tls: FEHLER: SSL meldet Fehler 20: Lokales Ausstellerzertifikat kann nicht abgerufen werden FEHLER: (14872) eap_tls: FEHLER: TLS-Alarm write:fatal:unbekannte CA Fehler: tls: TLS_accept: Fehler in error Auth: (14872) Anmeldung falsch (eap_tls: SSL meldet Fehler 20: Lokales Ausstellerzertifikat kann nicht abgerufen werden): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5) ``` 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](/de/profilbereitstellung/microsoft-intune/trusted-root.md#adding-a-trusted-root-profile-for-your-clients). * 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](/de/admin-portal/settings/trusted-roots.md#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](/de/admin-portal/settings/trusted-roots.md#add). #### Zertifikat unbekannt Wenn Sie macOS (und möglicherweise andere Apple-Plattformen) verwenden und wenn Ihre [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlernachrichten enthalten, die der unten gezeigten ähneln ``` eap_tls: (TLS) TLS - Alarm read:fatal:Zertifikat unbekannt ``` Dies kann die folgenden Ursachen haben: * Irgendwo im **Zertifikats-Servernamen** in Ihrem [WLAN](/de/profilbereitstellung/microsoft-intune/wifi-profile/apple-devices.md) oder [kabelgebundenen Netzwerk](/de/profilbereitstellung/microsoft-intune/wired-profile/mac.md) Konfigurationsprofil. #### Entschlüsselungsfehler | Zugriff verweigert Wenn Ihre [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlernachrichten enthalten, die den unten gezeigten ähneln ``` Auth: (312) Anmeldung falsch (eap_tls: TLS-Alarm write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/] (from client contoso port 1 cli 84-FD-D1-8C-0E-33) FEHLER: (320) eap_tls: FEHLER: TLS-Alarm write:fatal:Entschlüsselungsfehler Fehler: tls: TLS_accept: Fehler in error ``` ... dann handelt es sich wahrscheinlich um einen Fehler der TPM-Software auf Ihren Windows-Maschinen. Weitere Informationen dazu finden Sie in der [SCEPman-Dokumentation](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). Wenn Sie so etwas in Ihrem [Protokolle](/de/admin-portal/insights/log.md#logs) ``` FEHLER: (95878) eap_tls: FEHLER: (TLS) Alarm read:fatal:Zugriff verweigert Auth: (95878) Anmeldung falsch (eap_tls: (TLS) Alarm read:fatal:Zugriff verweigert): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12] FEHLER: (95717) eap_tls: FEHLER: (TLS) Alarm read:fatal:Zugriff verweigert ``` ... 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**](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). {% hint style="warning" %} 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. {% endhint %} #### 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](/de/admin-portal/insights/log.md#logs) Fehlernachrichten enthalten, die den unten gezeigten ähneln ``` - Message Authenticator, falscher Wert - buf2radmsg: Nachrichtenauthentifizierung fehlgeschlagen - radsrv: Anfrage von default (8.222.246.231) wird ignoriert, Validierung fehlgeschlagen ``` dann verwendet eines Ihrer Access Points oder Switches, das bzw. der versucht, eine Verbindung zu Ihrer RADIUSaaS-Instanz über einen [RADIUS Proxy](/de/admin-portal/settings/settings-proxy.md) ein nicht übereinstimmendes [Shared Secret](/de/admin-portal/settings/settings-server.md#properties-1). 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__.evtx`. 3. Wiederholen Sie dieselben Schritte für das **WLAN-AutoConfig → Operational** Protokoll. 4. Senden Sie beide `.evtx` Dateien an unser Support-Team unter 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](/de/admin-portal/zugriff-and-regeln/permissions.md). Falls es sich um den ersten Administrator handelt, bitte [kontaktieren Sie uns](https://www.radius-as-a-service.com/help/) 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)\ ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/zBRh87CJ75R1N8hz7mZF/Screenshot_2022-04-11_at_09_31_26.png) * 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](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) 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) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/de/andere/troubleshooting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.