> 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). # Problembehandlung ## Verbindungsprobleme ### Client-Ansicht #### Falsches XML {% hint style="warning" %} Keine Verbindung möglich, weil Sie ein Zertifikat zum Anmelden benötigen. Wenden Sie sich an Ihre IT-Support-Person. {% endhint %} ![](/files/9db5d247a271705f47edc015f188acf3e4423fcc) Prüfen Sie, ob Ihr Client über ein Zertifikat zur Authentifizierung verfügt und ob 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 Stammzertifizierungsstellen {% hint style="warning" %} Verbindung zu diesem Netzwerk nicht möglich. {% endhint %} ![](/files/73b9153e5aecb30bc7cdde1924bedb107c6362b9) Prüfen Sie, ob Sie Folgendes getan haben: * Ihrem RADIUS-Server mitgeteilt haben, welche Zertifikate eine Verbindung herstellen dürfen, wie [hier](/de/admin-portal/settings/trusted-roots.md#add) * das aktive RADIUS-Serverzertifikat als vertrauenswürdige Stammzertifizierungsstelle auf Ihrem Client importiert haben, wie [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 ausführliche Beschreibung des Fehlers. Vielleicht ist es [dieses](/de/andere/troubleshooting.md#fatal-decrypt-error) Problem. #### Mit der Verbindung fortfahren? {% hint style="warning" %} Mit der Verbindung fortfahren? \ Wenn Sie an diesem Ort Corporate WiFi erwarten, fahren Sie fort und verbinden Sie sich. Andernfalls handelt es sich möglicherweise um ein anderes Netzwerk mit demselben Namen. Zertifikatsdetails anzeigen. {% endhint %} Wenn Ihre Clients die Verbindung beim ersten Verbindungsaufbau überprüfen müssen und Sie diesen Dialog sehen: ![](/files/08076386a9c87805f8d9a3ebe9a8a8cb70d72eac) Stellen Sie sicher, dass Sie in Ihrem WLAN-Profil auf das RADIUS-Serverzertifikat verweisen und das SAN-Attribut (FQDN) sowie den Common Name (CN) des Serverzertifikats angegeben haben:

Anzeige des SAN-Attributs (FQDN) und des Common Name (CN) des Serverzertifikats

### Server-Ansicht #### Unbekannte CA Wenn Ihre [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlermeldungen ähnlich den unten gezeigten enthalten ``` ERROR: (14872) eap_tls: ERROR: SSL says error 20 : unable to get local issuer certificate ERROR: (14872) eap_tls: ERROR: TLS Alert write:fatal:unknown CA Error: tls: TLS_accept: Error in error Auth: (14872) Login incorrect (eap_tls: SSL says error 20 : unable to get local issuer certificate): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5) ``` Es kann die folgenden Ursachen haben: * Client gibt Fehler aus `TLS Alert read:fatal:unknown CA` * Ihr Client kennt das **Serverzertifikat** nicht und lehnt die Verbindung ab. Prüfen Sie, ob Sie Ihr **Serverzertifikat** wie beschrieben [hier](/de/profilbereitstellung/microsoft-intune/trusted-root.md#adding-a-trusted-root-profile-for-your-clients). * Sie haben ein neues **Serverzertifikat** geändert/hinzugefügt und Ihr XML-Profil auf dem Client verwendet noch das alte. Bitte prüfen Sie in diesem Fall sorgfältig, ob Sie entweder Ihr Wi-Fi-/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 Alert write:fatal:unknown 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 Ihre [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlermeldungen ähnlich der unten gezeigten enthalten ``` eap_tls: (TLS) TLS - Alert read:fatal:certificate unknown ``` Es kann die folgenden Ursachen haben: * Es befindet sich irgendwo ein Leerzeichen in der **Zertifikatsservername** in Ihrem [WiFi](/de/profilbereitstellung/microsoft-intune/wifi-profile/apple-devices.md) oder [Kabel](/de/profilbereitstellung/microsoft-intune/wired-profile/mac.md) Konfigurationsprofil. #### Entschlüsselungsfehler | Zugriff verweigert Wenn Ihre [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlermeldungen ähnlich den unten gezeigten enthalten ``` Auth: (312) Login incorrect (eap_tls: TLS Alert write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/] (from client contoso port 1 cli 84-FD-D1-8C-0E-33) ERROR: (320) eap_tls: ERROR: TLS Alert write:fatal:decrypt error Error: tls: TLS_accept: Error in error ``` ... dann handelt es sich wahrscheinlich um einen Fehler in 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 etwas wie dies in Ihren [Protokolle](/de/admin-portal/insights/log.md#logs) ``` ERROR: (95878) eap_tls: ERROR: (TLS) Alert read:fatal:access denied Auth: (95878) Login incorrect (eap_tls: (TLS) Alert read:fatal:access denied): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12] ERROR: (95717) eap_tls: ERROR: (TLS) Alert read:fatal:access denied ``` ... dafür kann es zwei Gründe geben. Einer ist, dass Ihr WLAN-Profil auf das falsche Stammzertifikat für die Servervalidierung verweist. Bitte stellen Sie sicher, dass Ihr Profil korrekt eingerichtet ist. Falls ja und Sie weiterhin auf dieses Problem stoßen, 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 Speicherung in Software, da das TPM eine zusätzliche Sicherheitsebene bietet, um den Diebstahl von Schlüsseln 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 Wi-Fi- 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 entweder Ihre Firmware auf eine neuere Version oder wählen Sie „Software KSP“ als Speicheranbieter für den Schlüssel. {% endhint %} #### Fortfahren nicht möglich, da sich die Gegenstelle fehlerhaft verhält Wenn Ihre Protokolle Zurückweisungen mit dem Fehler enthalten *„Fortfahren nicht möglich, da sich die Gegenstelle fehlerhaft verhält“* weist dies 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 Ihre (Proxy) [Protokolle](/de/admin-portal/insights/log.md#logs) Fehlermeldungen ähnlich den unten gezeigten enthalten ``` - Nachrichten-Authenticator, falscher Wert - buf2radmsg: Nachrichtenauthentifizierung fehlgeschlagen - radsrv: Anfrage von default (8.222.246.231) ignoriert, Validierung fehlgeschlagen ``` dann verwendet einer Ihrer Access Points oder Switches, der versucht, über einen [RADIUS-Proxy](/de/admin-portal/settings/settings-proxy.md) eine nicht passende [Shared Secret](/de/admin-portal/settings/settings-server.md#properties-1). Um den betroffenen Access Point oder Switch zu identifizieren, bestimmen Sie zunächst den RADIUS-Proxy, indem Sie die Fehlermeldung aufklappen und nach der `proxyip` Eigenschaft suchen. Wenn Sie den Proxy nun kennen, verwenden Sie Ihr Inventar und Ihr Wissen über bestimmte Standorte oder Gerätegruppen, 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 mit dem in Ihrer RADIUSaaS-Instanz für diesen Proxy konfigurierten Wert übereinstimmt. ### Fehlerbehebung bei Verbindungsproblemen mit CAPI2-Protokollen Windows-Clients verwenden das **Cryptographic API (CAPI2)** Subsystem zur Verarbeitung von Zertifikatsoperationen während der EAP-TLS-Authentifizierung. Wenn eine Verbindung fehlschlägt und weder die Client-UI noch die Protokolle des RADIUSaaS-Servers einen klaren Hinweis auf die Ursache liefern, kann das Aktivieren der CAPI2-Protokollierung auf dem betroffenen Gerät Zertifikatsvalidierungsfehler, Fehler beim Aufbau der Zertifikatskette oder Probleme beim Zugriff auf private 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`ein und drücken Sie **Enter**. 2. Erweitern Sie im linken Baum **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 Funktion aktiviert ist, beginnt Windows mit der Aufzeichnung aller CAPI2-Ereignisse. 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 erneut (**Operational per Rechtsklick → Protokoll deaktivieren**), um unnötigen Speicherplatzverbrauch zu vermeiden. *** #### **Schritt 2: Relevante 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 Aufbau der Zertifikatskette, Widerrufsprüfungen oder dem Zugriff auf private 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: 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 zusammen mit einer kurzen Beschreibung des betroffenen Geräts, der Betriebssystemversion und des Auftretens des Problems an unser Support-Team unter sowie einer kurzen Beschreibung des betroffenen Geräts, der Betriebssystemversion und wann das Problem auftritt. ## Zertifikatsprobleme ### Die Zertifikatskette konnte nicht verifiziert 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 eine Verbindung herstellen wollen) die Identität des Servers überprüfen können. \ Wenn Sie diese Meldung sehen, kopieren Sie entweder das CA-Zertifikat unterhalb des Serverzertifikats im Textfeld per Copy & Paste ein oder erstellen Sie ein PCKS8-Zertifikatsbundle, das alle Zertifikate von der Zwischenzertifizierungsstelle bis zur Stammzertifizierungsstelle enthält. ## Probleme mit dem Admin-Portal ### Anmeldung Um sich im RADIUSaaS-Webportal („RADIUSaas Admin Portal“) anzumelden, müssen die folgenden Anforderungen erfüllt sein: * Die UPN-/E-Mail-Adresse, die Sie als technischen Administrator angegeben haben, muss gegenüber **einem** Microsoft Entra ID (Azure AD) authentifizierbar sein (es muss sich nicht um eine Identität aus dem Tenant handeln, dessen Benutzer RADIUSaaS für die Netzwerkauthentifizierung nutzen werden). * Die UPN-/E-Mail-Adresse, die Sie als technischen Administrator angegeben haben, muss in Ihrer RADIUSaaS-Instanz wie beschrieben registriert worden sein [hier](/de/admin-portal/settings/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 Basis-Benutzerprofil * **Verwalten** den Zugriff auf Daten beibehalten, auf die Sie ihm Zugriff gewährt haben (Anforderung eines Aktualisierungstokens zulassen)\ ![](/files/ec93f0d065f4a60bb5dda5a6671af7d0d23237da) * Falls Ihr Microsoft Entra ID (Azure AD)-Benutzer nicht berechtigt ist, die erforderlichen Berechtigungen zu erteilen, wird keine entsprechende **Enterprise Application** in Ihrer Microsoft Entra ID (Azure AD) automatisch 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 können als „Ausstehend“ angezeigt werden oder es gibt gar keinen Status. Bitte verwenden Sie die **gleiche Gruppe oder „Alle Geräte“ bzw. „Alle Benutzer“** für **alle verknüpften Profile**. Sie können das SCEP-Stammzertifikatsprofil sowohl „Allen Benutzern“ als auch „Allen Geräten“ zuweisen, wenn Sie ein Gerät (zugewiesen an „Alle Geräte“) und ein Benutzerzertifikat (zugewiesen an „Alle Benutzer“) verwenden. ### SCEP-Zertifikat #### Android Android scheint in neueren Versionen einen UPN im Subject Alternative Name zu benötigen (selbst 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 Wichtige Punkte sind: * wählen Sie das **Root-CA-Zertifikat** für **Servervalidierung** (wichtig: laden Sie nicht das Serverzertifikat von RADIUSaaS hoch)\ \&#xNAN;**- und -** * definieren Sie einen **RADIUS-Servernamen** * Hinweis: Für dieses Feld scheint es eine Zeichenbegrenzung zu geben. Um mögliche Probleme zu beheben, können Sie einfach den Domänenanteil ohne Subdomäne verwenden, z. B. „radius-as-a-service.com“ (anstelle von „contoso.radius-as-a-service.com“). * [Android-Entwickler](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) geben an: „\[...] muss konfigurieren **sowohl ein Root-CA-Zertifikat**, und entweder einen **Domänensuffix-Abgleich** oder einen alternativen Subject-Abgleich“. So kann das MDM nach dem Hinzufügen eines Stammzertifikats zur Wi-Fi-Konfiguration „setAltSubjectMatch“ oder „setDomainSuffixMatch“ verwenden. Intune scheint „setDomainSuffixMatch“ zu verwenden, da lediglich „radius-as-a-service.com“ ausreicht. * manchmal **Identitätsprivacy** erforderlich ist (z. B. auf Android-Kioskgeräten / dedizierten Android-Enterprise-Geräten zu sehen) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.radiusaas.com/de/andere/troubleshooting.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.