Fehlerbehebung
Verbindungsprobleme
Client-Ansicht
Falsches XML
Verbindung nicht möglich, da Sie ein Zertifikat zum Anmelden benötigen. Wenden Sie sich an Ihre IT-Unterstützung.
Überprüfen Sie, dass Ihr Client ein Zertifikat zur Authentifizierung besitzt und dass Sie das richtige WiFi-Konfigurationsprofil oder XML.
Probleme mit vertrauenswürdigen Stammzertifikaten
Verbindung zu diesem Netzwerk nicht möglich.
Überprüfen Sie, ob Sie Folgendes getan haben:
Ihrem RADIUS-Server mitgeteilt haben, welche Zertifikate wie beschrieben eine Verbindung herstellen dürfen hier
das aktive RADIUS-Serverzertifikat wie beschrieben als vertrauenswürdiges Stammzertifikat auf Ihrem Client importiert haben hier
Überprüfen Sie Ihre Protokolle. Dort gibt es eine detaillierte Beschreibung des Fehlers. Vielleicht handelt es sich um dieses Problem.
Weiter verbinden?
Weiter verbinden? Wenn Sie an diesem Standort ein Unternehmens-WiFi erwarten, können Sie fortfahren und verbinden. Andernfalls könnte es ein anderes Netzwerk mit demselben Namen sein.
Zertifikatsdetails anzeigen.
Wenn Ihre Clients die Verbindung beim ersten Mal verifizieren müssen und Sie diesen Dialog sehen:
Stellen Sie sicher, dass Sie das RADIUS-Serverzertifikat in Ihrem WiFi-Profil referenziert und das SAN-Attribut (FQDN) sowie den allgemeinen Namen (CN) des Serverzertifikats angegeben haben:
Server-Ansicht
Unbekannte CA
Wenn Ihre Protokolle Fehlermeldungen ähnlich den unten gezeigten enthalten
kann dies folgende Ursachen haben:
Client wirft Fehler
TLS Alert read:fatal:unknown CAIhr Client kennt das Serverzertifikat nicht und lehnt die Verbindung ab. Prüfen Sie, ob Sie Ihr Serverzertifikat wie beschrieben hier.
Sie haben ein neues geändert/ hinzugefügt Serverzertifikat und Ihr XML-Profil auf dem Client verwendet das alte. In diesem Fall überprüfen Sie bitte, ob Sie entweder Ihr WiFi/Wired-Profil aktualisiert oder Ihr XML nach dem Hinzufügen der Zertifikate neu generiert und an Ihre Clients verteilt haben.
Server wirft Fehler
TLS Alert write:fatal:unknown CAIhr 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 Fehlermeldungen ähnlich der unten gezeigten enthalten
kann dies folgende Ursachen haben:
Irgendwo in dem Zertifikatsservernamen in Ihrem WiFi oder Kabelgebunden Konfigurationsprofil ein Leerzeichen vorhanden ist.
Entschlüsselungsfehler | Zugriff verweigert
Wenn Ihre Protokolle Fehlermeldungen ähnlich den unten gezeigten enthalten
... dann ist es wahrscheinlich ein Fehler der TPM-Software auf Ihren Windows-Rechnern. Weitere Informationen dazu finden Sie in der SCEPman-Dokumentation.
Wenn Sie so etwas in Ihren Protokolle
... kann es zwei Gründe geben. Einer ist, dass Ihr WiFi-Profil auf das falsche Stammzertifikat zur Servervalidierung verweist. Bitte stellen Sie sicher, dass Ihr Profil korrekt eingerichtet ist. Sollte dies der Fall sein und Sie das Problem weiterhin haben, 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 Software-Speicherung, da das TPM eine zusätzliche Sicherheitsschicht bietet, um Diebstahl des Schlüssels zu verhindern. Allerdings gibt es einen Fehler in einigen älteren TPM-Firmware-Versionen der einige mit einem TPM-gestützten privaten Schlüssel erzeugte Signaturen ungültig macht. In solchen Fällen kann das Zertifikat nicht für EAP-Authentifizierung verwendet werden, wie es üblich für WLAN- und VPN-Verbindungen ist. Betroffene TPM-Firmware-Versionen 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 Key Storage Provider.
Kann nicht fortfahren, da das Gegenüber sich fehlerhaft verhält
Wenn Ihre Protokolle Ablehnungen mit dem Fehler enthalten "Kann nicht fortfahren, da das Gegenüber sich fehlerhaft verhält" dann zeigt dies an, dass der Client die Kommunikation mit dem RADIUS-Dienst eingestellt hat, meist weil die Vertrauenseinstellungen falsch sind. In diesem Fall überprüfen Sie bitte die Zertifikate auf den betroffenen Geräten.
Falsches geteiltes RADIUS-Geheimnis
Wenn Ihre (Proxy) Protokolle Fehlermeldungen ähnlich den unten gezeigten enthalten
dann verwendet einer Ihrer Access Points oder Switches, der versucht, sich über einen RADIUS-Proxy mit Ihrer RADIUSaaS-Instanz zu verbinden, ein nicht übereinstimmendes Shared Secret.
Um den betroffenen Access Point oder Switch zu identifizieren, bestimmen Sie zuerst den RADIUS-Proxy, indem Sie die Fehlermeldung erweitern und nach der proxyip Eigenschaft suchen. Sobald Sie den Proxy kennen, nutzen Sie Ihr Inventar und Wissen über bestimmte Standorte oder Gerätegruppen, die keine Verbindung herstellen können, um das falsch konfigurierte Netzwerkgerät zu identifizieren. Aktualisieren Sie schließlich das Shared Secret, damit es dem in Ihrer RADIUSaaS-Instanz für diesen Proxy konfigurierten Wert entspricht.
Zertifikatsprobleme
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 sich zu verbinden versuchen) die Identität des Servers verifizieren können. Wenn Sie diese Meldung sehen, kopieren Sie entweder das CA-Zertifikat unter das Serverzertifikat im Textfeld oder erstellen Sie ein PKCS#8-Zertifikatsbundle, das alle Zertifikate vom ausstellenden bis zum Root-Zertifikat enthält.
Admin-Portal-Probleme
Anmeldung
Um sich beim RADIUSaaS-Webportal ("RADIUSaaS Admin Portal") anzumelden, müssen die folgenden Voraussetzungen 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 keine Identität aus dem Mandanten sein, dessen Benutzer RADIUSaaS für die Netzwerk-Authentifizierung nutzen werden).
Die von Ihnen als technischer Administrator angegebene UPN/E-Mail-Adresse muss wie beschrieben in Ihrer RADIUSaaS-Instanz registriert worden sein hier. Falls es sich um den initialen 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-Anwendung die folgenden Berechtigungen zu gewähren (siehe Screenshot unten):
Lesen das grundlegende Benutzerprofil
Pflegen Zugriff auf Daten, für die Sie ihm Zugriff gewährt haben (Anforderung eines Refresh-Tokens erlauben)
Falls Ihr Microsoft Entra ID (Azure AD)-Benutzer nicht die Rechte hat, die erforderlichen Berechtigungen zu gewähren, wird keine entsprechende Enterprise-Anwendung in Ihrer Microsoft Entra ID (Azure AD) automatisch erstellt. Um dies zu umgehen, bitten Sie Ihre IT-Abteilung, Ihrem Benutzer die benötigten Rechte zu gewähren.
Intune-Konfigurationsprobleme
Profilzuweisung
Die Wi-Fi-Konfiguration wird nicht bereitgestellt, wenn Wi-Fi-, SCEP- und Vertrauenszertifikatsprofile verschiedenen Gruppen zugewiesen sind. Sie können als "Ausstehend" angezeigt werden oder es gibt überhaupt 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-Stammzertifikat-Profil sowohl "Alle Benutzer" als auch "Alle Geräte" zuweisen, wenn Sie ein Gerät (zugewiesen zu "Alle Geräte") und ein Benutzerzertifikat (zugewiesen zu "Alle Benutzer") verwenden.
SCEP-Zertifikat
Android
Android scheint in neueren Versionen ein UPN im Subject Alternative Name zu verlangen (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 des 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 eventuell nur den Domain-Teil ohne Subdomain verwenden, z. B. "radius-as-a-service.com" (statt "contoso.radius-as-a-service.com").
Android-Entwickler geben an: "[...] müssen konfigurieren sowohl ein Root-CA-Zertifikat, als auch entweder ein Domain-Suffix-Match oder ein alternatives Subject-Match". Der MDM kann also "setAltSubjectMatch" oder "setDomainSuffixMatch" verwenden, nachdem ein Stammzertifikat zur Wi-Fi-Konfiguration hinzugefügt wurde. Intune scheint "setDomainSuffixMatch" zu verwenden, da bereits "radius-as-a-service.com" ausreicht.
manchmal Identitätsverschleierung ist erforderlich (z. B. bei Android-Kioskgeräten / Android Enterprise Dedicated)
Zuletzt aktualisiert
War das hilfreich?