Intune WiFi-Profil Server-Vertrauensstellung: Zertifikat-Servernamen und Stamm-CA-Checkliste für Entra ID

Um die Vertrauensstellung des Intune WiFi-Profilservers mit der Microsoft Entra ID-Integration herzustellen, müssen Ihre Zertifikatsservernamen mit Ihrem RADIUS-Serverzertifikat übereinstimmen. Die Bereitstellung dieses IEEE 802.1X-Standards an über 80.000 Standorten erfordert die Verknüpfung eines vertrauenswürdigen Zertifikatsprofils, das die Stamm-CA enthält, mit derselben Entra ID-Gruppe, um Fehler beim Authentifizierungs-Handshake zu vermeiden.

Was genau bewirkt die Servervalidierung in einem Intune WiFi-Profil?

Ein Enterprise-WiFi-Profil in Intune besteht aus zwei Teilen. Die Client-Hälfte beweist die Identität des Geräts. Die Server-Hälfte beweist, dass das Netzwerk Ihnen gehört. Die meisten ins Stocken geratenen Implementierungen scheitern an der Server-Hälfte, weshalb sich diese Anleitung ausschließlich mit diesem Teil befasst.

Zunächst einige Definitionen. IEEE 802.1X ist der Standard für die portbasierte Zugriffskontrolle. Er hält ein Gerät so lange vom Netzwerk fern, bis ein RADIUS-Server (Remote Authentication Dial-In User Service) es freigibt. EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security, RFC 5216) authentifiziert beide Seiten mit Zertifikaten. PEAP (Protected EAP) verpackt einen Kennwortaustausch in einen TLS-Tunnel.

Bei beiden Methoden legt der RADIUS-Server sein Zertifikat zuerst vor. Das Gerät entscheidet, ob es diesem vertraut, bevor es ein Zertifikat oder ein Kennwort sendet.

Prüfungen und Entscheidungen

Das Gerät führt zwei Prüfungen des RADIUS-Serverzertifikats durch:

• Vertrauenskette. Lässt sich das Zertifikat auf eine Stammzertifizierungsstelle (Root CA) zurückführen, die im Profil angegeben ist? In Intune gelangt diese Root-CA als vertrauenswürdiges Zertifikatsprofil auf das Gerät.
• Identität. Stimmt der Name auf dem Zertifikat mit dem Feld für die Zertifikatsservernamen überein? Unter Windows, iOS und macOS trägt das Feld diesen Namen. Unter Android Enterprise ist es das Feld für den Namen des Radius-Servers.

Beide Prüfungen müssen erfolgreich sein. Ein Zertifikat einer vertrauenswürdigen CA mit dem falschen Namen schlägt fehl. Der richtige Name einer nicht aufgeführten CA schlägt ebenfalls fehl. Diese Kopplung blockiert einen betrügerischen Access Point, der ein gültiges Zertifikat für die Domäne eines anderen Anbieters vorlegt. Dieser Angriff greift PEAP-Anmeldedaten von Geräten ab, die die Validierung überspringen.

Warum Fehler unsichtbar bleiben

Intune meldet, ob ein Profil das Gerät erreicht hat. Es meldet nicht, ob das Gerät Ihren RADIUS-Server akzeptiert. Ein Profil kann als erfolgreich angezeigt werden, während jeder Handshake am Access Point fehlschlägt. Sie bemerken das Problem erst, wenn Mitarbeiter melden, dass keine Verbindung zum Netzwerk hergestellt werden kann.

Was benötigen Sie, bevor Sie beginnen?

Halten Sie diese Informationen bereit, bevor Sie Intune öffnen:

• Das aktive RADIUS-Serverzertifikat. Notieren Sie den Subject Common Name (CN), jeden DNS-Eintrag des Subject Alternative Name (SAN), das Ablaufdatum, die ausstellende Zwischen-CA und die Root-CA.
• Das Zertifikat jedes RADIUS-Servers. Primäre und sekundäre Server verfügen oft über unterschiedliche Zertifikate. Geräte müssen beide validieren.
• Die Zertifikatsdatei der Root-CA. Exportieren Sie diese als .cer-Datei. Sie laden diese in ein vertrauenswürdiges Zertifikatsprofil hoch.- Client-Zertifikatsinfrastruktur für EAP-TLS. Sie benötigen ein SCEP- (Simple Certificate Enrollment Protocol) oder PKCS-Zertifikatsprofil und die ausstellende CA. Intune erfordert zudem ein vertrauenswürdiges Zertifikatsprofil für diese CA.
• Entra ID-Gruppendesign. Entscheiden Sie, ob jede Plattform auf Benutzergruppen oder Gerätegruppen ausgerichtet ist. Halten Sie diese Wahl für jedes verknüpfte Profil identisch.
• Für WPA2-Enterprise oder WPA3-Enterprise konfigurierte Access Points. Die SSID muss auf Ihren RADIUS-Server verweisen. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet unterstützen alle 802.1X.
• Eine Pilotgruppe. Fügen Sie mindestens ein Windows-, ein Apple- und ein Android-Gerät hinzu.

Ein wichtiger Unterschied besteht, wenn Ihre Access Points RADIUS über RadSec (RADIUS über TLS, RFC 6614) erreichen. Der Access Point führt auf diesem Abschnitt eine eigene Zertifikatsnamen-Überprüfung durch. Die Juniper Mist-Konfiguration von Purple für SecurePass legt einen Wildcard-RadSec-Servernamen unter der Domain von Purple fest. Zudem wird ein RadSec-Zertifikat auf Organisationsebene geladen. Diese Überprüfung findet zwischen dem Access Point und dem Server statt. Intune ist daran nicht beteiligt. Halten Sie diese beiden Ebenen bei der Fehlersuche getrennt.

Wie richten Sie Servernamen für Zertifikate und die Root-CA in Intune ein?

Die Dokumentation zu Microsoft Intune enthält die genauen Klickschritte. Die folgenden Entscheidungen bestimmen jedoch, ob diese Schritte erfolgreich sind.

Schritt 1: Lesen Sie die Namen aus dem vom Server präsentierten Zertifikat aus

Lesen Sie das Zertifikat aus, das Ihr RADIUS-Server aktuell präsentiert. Verlassen Sie sich nicht auf die Zertifikatsanforderung oder Notizen von Kollegen. Ein Load Balancer, ein neuer Node oder eine kürzliche Erneuerung können die Daten ändern, die Geräte empfangen.

Im Idealfall sind der CN und der erste SAN-DNS-Eintrag identisch, zum Beispiel radius.contoso.com. Wenn Sie zwei Server betreiben, wählen Sie zwischen folgenden Mustern:

• Geben Sie jedem Server einen eigenen Namen und listen Sie beide Namen im Profil auf.
• Vergeben Sie für beide Server Namen unter einem gemeinsamen Suffix, wie radius1.contoso.com und radius2.contoso.com.

Schritt 2: Erstellen Sie ein vertrauenswürdiges Zertifikatsprofil für das Root-Zertifikat des Servers

Erstellen Sie ein vertrauenswürdiges Zertifikatsprofil pro Plattform: Windows, iOS und iPadOS, macOS und Android Enterprise. Jedes Profil enthält die Root-CA, die das RADIUS-Serverzertifikat ausgestellt hat.

Häufige Fehler an dieser Stelle:

• Fälschliches Hochladen der Client-ausstellenden CA. Wenn Ihre SCEP-Zertifikate von einer anderen CA stammen als das RADIUS-Zertifikat, benötigen Sie separate vertrauenswürdige Zertifikatsprofile. Das Feld für die Servervalidierung muss sich auf das Root-Zertifikat des Servers beziehen.
• Hochladen des Intermediate- statt des Root-Zertifikats. Laden Sie das Root-Zertifikat hoch. Konfigurieren Sie den RADIUS-Server so, dass er seine Intermediate-Zertifikate während des TLS-Handshakes sendet, damit Geräte die vollständige Kette aufbauen können.

Schritt 3: Füllen Sie die Servervalidierungsfelder pro Plattform aus

• Windows: Fügen Sie jeden RADIUS-Servernamen unter Zertifikatsservernamen hinzu. Wählen Sie das vertrauenswürdige Zertifikatsprofil unter Stammzertifikaten für die Servervalidierung aus. Windows akzeptiert mehr als ein Stammprofil.
• iOS, iPadOS und macOS: Geben Sie den Namen unter Zertifikatsservernamen ein. Die Konfigurationsprofil-Referenz von Apple dokumentiert dieses Feld als eine Liste von akzeptierten Common Names für Serverzertifikate, wobei Platzhalter wie *.contoso.com zulässig sind. Wählen Sie das vertrauenswürdige Zertifikatsprofil als Stamm für die Servervalidierung aus.
• Android Enterprise: Geben Sie den DNS-Namen oder das Suffix unter Radius-Servername ein. Die Richtlinien von Microsoft empfehlen, nur das gemeinsame Suffix einzugeben, wenn mehrere Server dieses teilen. Wählen Sie das Stammzertifikat für die Servervalidierung aus.

Schritt 4: Jedes verknüpfte Profil derselben Gruppe zuweisen

Weisen Sie das vertrauenswürdige Zertifikatsprofil, das SCEP- oder PKCS-Profil und das WiFi-Profil derselben Microsoft Entra ID-Gruppe zu. Senden Sie nicht ein Profil an eine Benutzergruppe und ein anderes an eine Gerätegruppe. Wenn das vertrauenswürdige Zertifikatsprofil ein Gerät niemals erreicht, schlägt das abhängige WiFi-Profil fehl oder wird nicht installiert.

Für die Identitätsseite eines Microsoft Entra ID-Rollouts siehe Aktivieren von Single Sign-On.

Wie die einzelnen Plattformen das Feld anwenden

Verhalten	Windows 10 und 11	iOS, iPadOS und macOS	Android Enterprise
Intune-Feldname	Zertifikatsservernamen	Zertifikatsservernamen	Radius-Servername
Womit es abgeglichen wird	DNS-Name auf dem Serverzertifikat	Common Name des Serverzertifikats	DNS-Name oder Suffix auf dem Serverzertifikat
Musterunterstützung	Geben Sie jeden vollständigen Servernamen ein	Platzhalter, zum Beispiel *.contoso.com	Suffix, zum Beispiel contoso.com
Stamm-Einstellung	Vertrauenswürdige Zertifikatsprofile	Ein vertrauenswürdiges Zertifikatsprofil	Ein vertrauenswürdiges Zertifikatsprofil
Wenn das Namensfeld leer gelassen wird	Windows fordert die Mitarbeiter möglicherweise auf, dem Server zu vertrauen	Das Gerät fordert die Mitarbeiter möglicherweise auf, dem Server zu vertrauen	Android 11 und neuer entfernen die Option, die Validierung zu überspringen
Was Mitarbeiter bei einer Abweichung sehen	Die Verbindung schlägt ohne Aufforderung fehl	Meldung "Verbindung nicht möglich" oder eine Vertrauensaufforderung	Authentifizierungsproblem wird beim Netzwerkeintrag angezeigt
Wo Sie den Fehler lesen	WLAN-AutoConfig-Betriebsprotokoll	macOS-Konsole, eapolclient-Prozess	adb logcat, Supplicant-TLS-Zeilen

Wie überprüfen Sie, ob die Servervalidierung funktioniert?

Führen Sie diese Prüfungen auf jedem Pilotgerät durch, bevor Sie die Zuweisung ausweiten:

1. Profilstatus. Bestätigen Sie in Intune, dass das vertrauenswürdige Zertifikat, das Clientzertifikat und die WiFi-Profile alle einen Erfolg auf dem Gerät melden.
2. Live-Verbindung. Verbinden Sie sich mit der SSID. Unter Windows bestätigt netsh wlan show interfaces die Verbindung und die Authentifizierungsmethode.
3. Serverseitige Annahme. Suchen Sie im RADIUS-Protokoll nach einem Access-Accept für dieses Gerät oder dieses Konto.
4. Negativtest. Verweisen Sie eine Test-SSID auf einen RADIUS-Server, dessen Zertifikat einen anderen Namen trägt. Das Gerät muss die Verbindung verweigern. Dies beweist, dass die Validierung erzwungen und nicht durch eine Vertrauensabfrage umgangen wird.
5. Ablaufdatum festhalten. Notieren Sie das Ablaufdatum des RADIUS-Zertifikats und dessen Root-Zertifikat. Planen Sie die Erneuerung rechtzeitig im Voraus ein.

Der Negativtest ist der Schritt, den Teams am häufigsten überspringen. Ohne ihn können Sie ein Profil, das korrekt validiert, nicht von einem unterscheiden, das einfach jedem Zertifikat vertraut.

Was kann schiefgehen und wie behebt man es?

Typische Fehlermuster

• Der falsche Name im Feld. Teams geben oft eine IP-Adresse, einen kurzen Hostnamen oder den Namen des Load-Balancers ein. Tragen Sie stattdessen den Namen ein, der auf dem Zertifikat selbst aufgedruckt ist.
• Das falsche Root-Zertifikat. Das Profil verweist auf die Client-ausstellende CA oder eine Zwischenzertifizierungsstelle (Intermediate CA). Verweisen Sie auf das Root-Zertifikat, das die Kette des Serverzertifikats signiert hat.
• Fehlerhafte Zuweisung. Das WiFi-Profil ist auf Benutzergruppen ausgerichtet, während das Profil für das vertrauenswürdige Zertifikat auf Gerätegruppen abzielt. Richten Sie diese einheitlich aus.
• Ein fehlendes Intermediate-Zertifikat. Der RADIUS-Server sendet nur sein Leaf-Zertifikat. Die Geräte können die Kette nicht aufbauen und weisen sie ab. Installieren Sie das Intermediate-Zertifikat auf dem Server.
• Ein CN, der vom SAN abweicht. Apple gleicht den Common Name (CN) ab. Ein Zertifikat mit dem richtigen SAN und einem anderen CN kann unter Android funktionieren, schlägt jedoch auf dem iPhone fehl. Halten Sie beide identisch.

Wie ein erneuertes RADIUS-Zertifikat unbemerkt Verbindungen trennt

Eine Erneuerung, die dasselbe Root-Zertifikat und dieselben Namen beibehält, ändert auf den Geräten nichts. Die Verbindungen laufen normal weiter.

Eine Erneuerung unterbricht die Verbindungen, wenn sich eines der folgenden Elemente ändert:

• Die Root-CA. Ihr Anbieter stellt das neue Zertifikat von einer anderen Root-CA aus. Jedes Gerät verweist weiterhin auf das alte Root-Zertifikat.
• Die Intermediate-Kette. Die neue Kette benötigt ein Intermediate-Zertifikat, das der Server nicht mitsendet.
• Der Name. Das Zertifikat wird unter einem neuen Hostnamen neu ausgestellt oder das alte SAN wird weggelassen.
• Ein Server in einem Multi-Server-Setup. Nur der sekundäre Server ändert sich, wodurch die Fehler zufällig und unregelmäßig erscheinen.

Der Fehler tritt unbemerkt auf, da sich in Intune nichts ändert. Das Profil wird weiterhin als erfolgreich angezeigt und die Geräte behalten das alte Root-Zertifikat.

Erneuerungen werden in Zukunft noch häufiger erforderlich sein. Der Beschluss SC-081 des CA/Browser Forums verkürzt die maximale Lebensdauer öffentlich vertrauenswürdiger TLS-Zertifikate. Das Limit sinkt in den kommenden Jahren erheblich. Ein RADIUS-Server mit einem öffentlichen CA-Zertifikat muss sich dann mehrmals im Jahr erneuern.

Bestimmte Maßnahmen eliminieren den Großteil des Risikos:

• Stellen Sie das RADIUS-Zertifikat über eine private CA aus, die Sie kontrollieren. Deren Root-Zertifikat kann viele Serverzertifikate überdauern. Erneuerungen unter demselben Root-Zertifikat sind für die Geräte unsichtbar.
• Bereiten Sie jeden Root-Wechsel vor der Erneuerung vor. Verteilung Sie das neue Root-Zertifikat zunächst als zusätzliches vertrauenswürdiges Zertifikatsprofil. Windows-Profile können während der Übergangsphase auf beide Root-Zertifikate verweisen. Tauschen Sie das Serverzertifikat erst aus, wenn die Geräte das neue Profil erfolgreich melden.

Fehlermeldungen auf den einzelnen Plattformen richtig interpretieren

• Windows: Öffnen Sie das Betriebsprotokoll von Microsoft-Windows-WLAN-AutoConfig in der Ereignisanzeige. Verbindungsfehler werden dort mit einem Grund aufgeführt. netsh wlan show wlanreport erstellt einen HTML-Bericht über die letzten Sitzungen.
• macOS: Filtern Sie die Konsole nach dem eapolclient-Prozess. TLS-Vertrauensfehler benennen das Zertifikat, das abgelehnt wurde.
• iOS und iPadOS: Das Gerät zeigt die Meldung "Verbindung nicht möglich" oder eine Vertrauensaufforderung an. Überprüfen Sie die Profilinhalte in Intune und reproduzieren Sie den Fehler auf einem Mac mit demselben Profil, um die Protokolle zu lesen.
• Android: Der Netzwerkeintrag zeigt ein Authentifizierungsproblem an. Auf einem Testgerät zeigt adb logcat Supplicant-Zeilen, die den Fehler bei der Zertifikatsüberprüfung benennen.
• RADIUS-Server: Ein EAP-Austausch, der beginnt und dann ohne Antwort des Clients stoppt, bedeutet in der Regel, dass das Gerät Ihr Zertifikat abgelehnt hat.

Praxisbeispiele

Szenario 1: Eine Einzelhandelskette verlängert mit einem neuen Root-Zertifikat. Eine Einzelhandelskette betrieb PEAP für die Handhelds der Mitarbeiter und Windows-Kassen. Ihre öffentliche CA erneuerte das RADIUS-Zertifikat von einem neueren Root-Zertifikat aus. Jedes Gerät verwies immer noch auf das alte Root-Zertifikat, sodass am nächsten Morgen keine Filiale eine Verbindung herstellen konnte. Das Team stellte ein vertrauenswürdiges Zertifikatsprofil für das neue Root-Zertifikat für dieselbe Gerätegruppe bereit. Anschließend erzwang es eine Synchronisierung über Intune. Die Filialen stellten innerhalb eines Intune-Abfragezyklus wieder eine Verbindung her, und das Team verlagerte die RADIUS-Zertifikate auf eine private CA. Spätere Erneuerungen führten zu keinen Verbindungsfehlern mehr. Einzelhandels- Umgebungen mit Handhelds und Kassen teilen dieses Risiko.

Szenario 2: Ein Hotel und der Apple Common Name. Ein Hotel stattete das Housekeeping mit iPads und Android-Tablets auf einer gemeinsamen EAP-TLS-SSID aus. Das neu ausgestellte RADIUS-Zertifikat behielt den richtigen SAN bei, aber sein CN fiel auf den kurzen Hostnamen des Servers zurück. Die Android-Tablets stimmten mit dem DNS-Suffix überein und stellten eine Verbindung her. Die iPads verweigerten die Verbindung. Die erneute Ausstellung des Zertifikats mit identischem CN und SAN stellte die Verbindung für jedes iPad wieder her, ohne dass Intune angepasst werden musste. Hotels mit gemischten Geräteflotten sollten CN und SAN standardmäßig aufeinander abstimmen.

Szenario 3: Ein Konferenzzentrum mit geteilten Zuweisungen. Ein Konferenzzentrum des öffentlichen Sektors stellte EAP-TLS auf Windows-Laptops für das Event-Personal bereit. Das WiFi-Profil war an eine Benutzergruppe gerichtet, während das vertrauenswürdige Zertifikat und die SCEP-Profile an eine Gerätegruppe gerichtet waren. Einige Laptops erhielten das WiFi-Profil nie. Die Neuausrichtung der Profile auf eine einzige Gerätegruppe behob die Bereitstellung. Die Laptops stellten bei ihrer nächsten Überprüfung eine Verbindung her.

Sobald die Validierung erfolgreich ist, sind verbleibende Verbindungsabbrüche meist auf Funk- oder Roaming-Probleme zurückzuführen. Siehe Behebung von Roaming-Problemen in Unternehmens-WLANs. Für Kanalwechsel an stark frequentierten Veranstaltungsorten siehe DFS-Radarereignisse auf Cisco Meraki, HPE Aruba und Ruckus: Eine Diagnose-Checkliste für Kanalwechsel.

Checkliste für in Microsoft Entra ID eingebundene Geräteflotten

1. Lesen Sie den CN und jeden SAN-DNS-Eintrag aus dem Zertifikat ab, das der jeweilige RADIUS-Server präsentiert.
2. Stellen Sie sicher, dass der CN identisch mit dem primären SAN-DNS-Namen ist.
3. Bestätigen Sie, dass jeder RADIUS-Server seine Zwischenzertifikate im TLS-Handshake sendet.
4. Exportieren Sie die Root-CA, die das Serverzertifikat ausgestellt hat, nicht das Zwischenzertifikat.
5. Erstellen Sie ein vertrauenswürdiges Zertifikatsprofil für diese Root-CA auf jeder von Ihnen verwalteten Plattform.
6. Halten Sie die Client-ausstellende CA in ihrem eigenen, separaten Profil für vertrauenswürdige Zertifikate.
7. Tragen Sie genaue Servernamen auf Windows, einen Platzhalter (Wildcard) auf Apple und das DNS-Suffix auf Android ein.
8. Weisen Sie das vertrauenswürdige Zertifikat, SCEP oder PKCS sowie die WiFi-Profile einer einzigen Entra ID-Gruppe zu.
9. Verwenden Sie denselben Gruppentyp (Benutzer oder Gerät) für jedes verknüpfte Profil auf einer Plattform.
10. Führen Sie den Negativtest mit einem nicht übereinstimmenden Serverzertifikat auf jeder Plattform durch.
11. Erfassen Sie das Ablaufdatum und die Root-CA jedes RADIUS-Zertifikats und überprüfen Sie diese weit vor dem geplanten Termin.
12. Bereiten Sie jede neue Root-CA als zusätzliches vertrauenswürdiges Zertifikatsprofil vor, bevor Sie das Serverzertifikat austauschen.

Was kostet es und was erhalten Sie dafür zurück?

Intune ist in Microsoft 365 E3, E5 und Business Premium enthalten. Die meisten mit Entra ID verknüpften Geräteflotten besitzen bereits die Lizenz. Eine private CA kann auf den Active Directory-Zertifikatsdiensten in Windows Server ausgeführt werden. Microsoft Cloud PKI ist als separat lizensiertes Intune-Add-on erhältlich.

Der Hauptkostenfaktor ist die Arbeitszeit der Mitarbeiter. Jede fehlgeschlagene Verlängerung zieht eine Welle von Support-Tickets an allen Standorten gleichzeitig nach sich. Die obige Checkliste erfordert nur wenige Stunden pro Plattform und verhindert diese wiederkehrende Welle.

Der Nutzen ist ein Netzwerk ohne gemeinsamen Schlüssel, der kompromittiert werden könnte. Sie entziehen den Zugriff, indem Sie das Konto deaktivieren oder das Zertifikat sperren. EAP-TLS unterstützt zudem die Anforderung 4.2.1.2 des Standards PCI-DSS v4.0, die eine starke Kryptografie für drahtlose Netzwerke fordert, die mit der Karteninhaber-Datenumgebung verbunden sind. Standorte im Gesundheitswesen und Betreiber von Zügen, die Mitarbeitergeräte nutzen, profitieren von derselben Kontrolle.

Purple Staff WiFi bringt identitätsbasierte Netzwerke und Cloud-RADIUS in dieses Modell. Es lässt sich in Microsoft Entra ID, Okta und Google Workspace integrieren, sodass Neueinstellungen, Abteilungswechsel und Austritte den Netzwerkzugriff automatisch aktualisieren. Es ist hardwareunabhängig und funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Purple wird an über 80.000 Live-Standorten betrieben und ist nach ISO 27001 und Cyber Essentials zertifiziert.

Häufig gestellte Fragen

Funktioniert die Intune WiFi-Zertifikatsauthentifizierung mit den Access Points, die wir bereits besitzen?

Ja. Die Servervalidierung erfolgt direkt zwischen dem Gerät und dem RADIUS-Server, sodass der Access Point lediglich WPA2-Enterprise oder WPA3-Enterprise unterstützen muss. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet unterstützen alle 802.1X. Purple Staff WiFi ist hardwareunabhängig und läuft als Cloud-Overlay auf dieser bestehenden Infrastruktur. Sie müssen keine Hardware austauschen, um Ihre Mitarbeiter auf die zertifikatsbasierte Authentifizierung umzustellen.

Benötigen wir zusätzliche Microsoft-Lizenzen, um Intune WiFi-Profile bereitzustellen?

Nein, wenn Sie bereits Microsoft 365 E3, E5 oder Business Premium besitzen. Diese Suites enthalten Intune, was WiFi, vertrauenswürdige Zertifikate sowie SCEP- oder PKCS-Profile abdeckt. Eventuell zahlen Sie separat für eine Zertifizierungsstelle. Active Directory Certificate Services läuft auf Windows Server. Microsoft Cloud PKI ist ein separat lizenziertes Intune Add-on. Ihr RADIUS-Server stellt einen separaten Kostenfaktor dar, unabhängig davon, ob Sie den Network Policy Server oder einen Cloud-RADIUS-Service nutzen.

Sollte das RADIUS-Serverzertifikat von einer öffentlichen oder einer privaten Zertifizierungsstelle stammen?

Eine private Zertifizierungsstelle ist für die meisten Geräteflotten die sicherere Wahl. Sie kontrollieren deren Root, sodass Verlängerungen unter diesem Root niemals das Vertrauen der Geräte beeinträchtigen. Die Gültigkeit von öffentlichen Zertifikaten verkürzt sich gemäß dem CA/Browser Forum Ballot SC-081 immer weiter. Jede öffentliche Verlängerung birgt das Risiko einer Änderung der Root- oder Zwischenzertifizierungsstelle, die von den Geräten abgelehnt wird, bis Sie das Vertrauensprofil neu bereitstellen.

Können wir von PEAP-Passwörtern zu EAP-TLS migrieren, ohne die Mitarbeiter zu stören?

Ja. Stellen Sie das SCEP- oder PKCS-Zertifikatsprofil und das neue EAP-TLS WiFi-Profil parallel zum bestehenden PEAP-Profil bereit. Führen Sie ein Pilotprojekt mit einer Gruppe pro Plattform durch und bestätigen Sie die Verbindungen in Ihren RADIUS-Protokollen. Entfernen Sie das PEAP-Profil, sobald sich jede Gruppe zuverlässig verbindet. Die Einstellungen für die Servervalidierung - Namen und Root - können bei beiden Methoden gleich bleiben. Dadurch wird die risikoreichste Variable aus der Migration eliminiert.

Was passiert mit Intune WiFi-Profilen, wenn das RADIUS-Zertifikat erneuert wird?

Nichts, vorausgesetzt, das erneuerte Zertifikat behält dieselbe Root-Zertifizierungsstelle und dieselben Namen bei. Die Geräte verbinden sich weiterhin. Wenn sich die Root, die Zwischenzertifikatskette, der CN oder der SAN ändern, lehnen die Geräte den Server ab, selbst wenn Intune das Profil weiterhin als erfolgreich meldet. Stellen Sie eine neue Root zuerst als zusätzliches vertrauenswürdiges Zertifikatsprofil bereit. Bestätigen Sie, dass die Geräte es erhalten haben, und installieren Sie dann das erneuerte Zertifikat auf dem RADIUS-Server.

Hilft zertifikatsbasiertes WiFi für Mitarbeiter bei PCI DSS und GDPR?

Ja. Die PCI DSS v4.0-Anforderung 4.2.1.2 verlangt eine starke Kryptographie für drahtlose Netzwerke, die mit der Karteninhaber-Datenumgebung verbunden sind. EAP-TLS mit Servervalidierung erfüllt diese Anforderung ohne einen gemeinsam genutzten Schlüssel. Für die GDPR verknüpft die Zertifikatsauthentifizierung jede Sitzung mit einer bekannten Identität, was die Protokollierung von Zugriffen und den schnellen Widerruf unterstützt. Purple besitzt die Zertifizierungen nach ISO 27001 und Cyber Essentials, und die Plattform ist GDPR-konform.

Wie lange dauert es, bis Profiländerungen die Geräte erreichen?

Die meisten registrierten Geräte erhalten Änderungen bei ihrem nächsten Intune Check-in. Für Windows, iOS und Android-Geräte wird dieser Check-in regelmäßig über den Tag verteilt ausgeführt. Sie können eine sofortige Synchronisierung über Intune oder direkt vom Gerät aus erzwingen. Planen Sie Root-Änderungen mindestens einen vollen Check-in-Zyklus vor dem Austausch des RADIUS-Zertifikats ein. Ausgeschaltete Geräte rufen das Update bei ihrem nächsten Check-in ab.