Microsoft Cloud PKI für WiFi: EAP-TLS Zertifikats-Deployment mit Intune und Microsoft Entra ID

Ja. Microsoft Cloud PKI, die gehostete Zertifizierungsstelle in der Intune Suite, stellt EAP-TLS WiFi-Zertifikate für von Intune verwaltete Geräte aus. Ein SCEP-Zertifikatprofil fordert diese direkt an, sodass Sie keinen NDES-Server, Zertifikat-Connector oder eine On-Premises-CA benötigen. Ihr RADIUS-Server vertraut der importierten Cloud PKI-Root und prüft jedes Zertifikat gegen die von dem Dienst veröffentlichte CRL.

Was macht Microsoft Cloud PKI für die WiFi-Authentifizierung?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) ist die 802.1X-Methode, bei der beide Seiten ihre Identität mit Zertifikaten nachweisen. IEEE 802.1X ist der portbasierte Zugriffssteuerungsstandard hinter WPA2-Enterprise und WPA3-Enterprise. Der Access Point leitet jeden Verbindungsversuch an einen RADIUS-Server weiter - den Authentifizierungsserver, der das Gerät akzeptiert oder ablehnt. Bei EAP-TLS gibt es kein Passwort für Phishing-Angriffe und keinen gemeinsamen Schlüssel, der durchsickern könnte. Jedes Gerät besitzt seinen eigenen privaten Schlüssel und sein eigenes Zertifikat.

Der schwierige Teil war schon immer die dahinterstehende PKI (Public Key Infrastructure). Das Bereitstellen von Zertifikaten auf Intune-verwalteten Geräten erforderte gewöhnlich vier Dinge:

• eine Ausstellungs-CA der Active Directory-Zertifikatdienste (AD CS)
• einen NDES-Server (Netzwerkgeräte-Registrierungsdienst)
• den Intune Certificate Connector
• einen Reverse-Proxy oder Microsoft Entra-Anwendungsproxy, um NDES im Internet zu veröffentlichen

Jede dieser Komponenten erfordert Patching, Backups und Überwachung.

Microsoft Cloud PKI ersetzt diesen Stack durch eine Zertifizierungsstelle, die in Ihrem Intune-Tenant gehostet wird. Geräte fordern Zertifikate über SCEP (Simple Certificate Enrollment Protocol) an, und Cloud PKI beantwortet diese Anfragen selbst. Es validiert jede Anfrage anhand von Intune, signiert das Zertifikat und gibt es zurück. Das Gerät generiert seinen privaten Schlüssel lokal, und der Schlüssel verlässt das Gerät zu keinem Zeitpunkt.

Für Entra ID-gebundene Geräteflotten entfernt dies die letzte On-Premises-Abhängigkeit in der Zertifikatskette. Geräte, die noch nie einen Domänencontroller gesehen haben, können weiterhin ein WiFi-Zertifikat erhalten.

Wie die Cloud PKI CA-Hierarchie funktioniert

Cloud PKI verwendet eine zweistufige Hierarchie. Eine Root-CA signiert eine oder mehrere Ausstellungs-CAs, und die Ausstellungs-CA signiert die Gerätezertifikate. Microsoft verwahrt die CA-Signaturschlüssel in Hardware-Sicherheitsmodulen (HSMs), sodass Sie niemals Schlüsselmaterial selbst verwalten müssen.

Sie wählen einen von zwei Ankern:

• Cloud PKI-Root. Microsoft hostet sowohl die Root- als auch die Ausstellungs-CA in Ihrem Tenant. Dies ist die einfachste Option für eine neu aufgebauten Entra ID-Umgebung.
• Bring Your Own CA (BYOCA). Sie erstellen eine Cloud PKI-Ausstellungs-CA, laden deren Zertifikatsignierungsanfrage (CSR) herunter und signieren sie mit Ihrer bestehenden privaten Root, beispielsweise einer AD CS-Root. Alles, was dieser Root bereits vertraut, vertraut dann auch der Kette der neuen Ausstellungs-CA.

Sie legen erweiterte Schlüsselverwendungen (EKUs) fest, wenn Sie die jeweilige CA erstellen. WiFi-Clientzertifikate benötigen die EKU "Clientauthentifizierung", fügen Sie diese also auf beiden Ebenen hinzu. Planen Sie dies sorgfältig, da die EKUs bei der Erstellung der CA festgelegt werden.

Eine Grenze ist für das Design wichtig. Cloud PKI stellt Zertifikate für von Intune verwaltete Geräte über SCEP aus. Es ist nicht dafür ausgelegt, das eigene Zertifikat Ihres RADIUS-Servers auszustellen. Daher stammt dieses Zertifikat normalerweise von einer öffentlichen CA oder Ihrer bestehenden PKI.

Cloud PKI im Vergleich zu SCEP mit NDES und PKCS

	Cloud PKI (SCEP)	SCEP mit NDES	PKCS
CA-Hosting	Von Microsoft gehostet in Ihrem Intune-Tenant	Ihre AD CS oder Drittanbieter-CA	Ihre AD CS oder Drittanbieter-CA
On-Premises-Server	Keine	Ausstellende CA, NDES-Server, Connector-Host	Ausstellende CA, Connector-Host
Im Internet veröffentlichte Komponente	Keine	NDES, über Reverse Proxy oder Anwendungsproxy	Keine
Wo der private Schlüssel generiert wird	Auf dem Gerät	Auf dem Gerät	Auf der CA-Seite, als PFX an das Gerät geliefert
Geeignet für reine Microsoft Entra ID-Flotten	Nativ	Funktioniert, behält aber On-Premises-Abhängigkeiten bei	Funktioniert, behält aber On-Premises-Abhängigkeiten bei
Sperrung	Sperren im Intune Admin Center, veröffentlicht über CRL	Über den Connector und die CRL Ihrer CA	Über den Connector und die CRL Ihrer CA
Lizenzmodell	Intune Suite oder Cloud PKI Add-on, pro Benutzerplatz	Windows Server-Lizenzen plus Intune	Windows Server-Lizenzen plus Intune
Für wen es sich eignet	Cloud-First-Umgebungen, die ihre On-Premises-PKI ablösen	Umgebungen mit einem erfahrenen AD CS-Team und einer langfristigen CA-Roadmap	Fälle, die denselben Schlüssel auf mehr als einer Plattform benötigen, wie z. B. S/MIME

Unser separater Leitfaden zur Intune-Zertifikatsbereitstellung mit SCEP und PKCS behandelt die beiden On-Premises-Pfade im Detail.

Was benötigen Sie, bevor Sie Cloud PKI für EAP-TLS bereitstellen?

Überprüfen Sie diese sechs Punkte, bevor Sie etwas erstellen. Jeder Punkt entspricht einer Fehlerquelle im folgenden Abschnitt zur Fehlerbehebung.

• Lizenzierung. Ein Intune Plan 1-Abonnement plus entweder die Microsoft Intune Suite oder das eigenständige Cloud PKI Add-on.
• Berechtigungen. Die Rolle "Intune-Administrator" oder eine benutzerdefinierte Rolle mit den Cloud PKI-Berechtigungen.
• Registrierte Geräte. Windows, macOS, iOS/iPadOS oder Android-Geräte, die in Intune registriert und in Microsoft Entra ID-Sicherheitsgruppen organisiert sind.
• Ein EAP-TLS-fähiger RADIUS-Server. Er muss den Import von CA-Zertifikaten ermöglichen, die Cloud PKI CRL über HTTP erreichen und Zertifikatsidentitäten Entra ID-Objekten zuordnen können. Microsoft NPS (Network Policy Server) sucht Konten im lokalen Active Directory gesucht, weshalb reine Cloud-Geräte dort fehlschlagen.
• Ein RADIUS-Serverzertifikat. Sie benötigen auch das Root-Zertifikat und alle Zwischenzertifikate, die es ausgestellt haben, da die Geräte den Server validieren müssen.
• 802.1X-fähige Access Points. Diese müssen eine WPA2-Enterprise oder WPA3-Enterprise SSID ausstrahlen, die auf Ihren RADIUS-Server verweist.

Auf der Access-Point-Seite unterstützt jede große Plattform 802.1X. Dazu gehören Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Eine herstellerspezifische Anleitung finden Sie unter Konfiguration von 802.1X auf Juniper Mist mit Cloud RADIUS.

Wie richtet man Cloud-PKI-Zertifikate für WiFi ein?

Die folgende Sequenz fasst den Aufbau zusammen. Verwenden Sie die Cloud-PKI-Dokumentation von Microsoft auf Microsoft Learn für die aktuellen Bildschirme und Schritte Feld für Feld, da sich das Layout des Admin Centers zwischen den Versionen ändert.

Schritt 1: Erstellen Sie die Root-CA oder bringen Sie Ihre eigene mit

Erstellen Sie im Intune Admin Center eine Root-CA unter Mandantenverwaltung. Wählen Sie die Schlüssellänge, die Gültigkeitsdauer und die EKUs, einschließlich Client-Authentifizierung.

Für BYOCA überspringen Sie die Root-CA. Erstellen Sie die ausstellende CA als BYOCA-Typ und exportieren Sie deren Zertifikatssignierungsanfrage (CSR). Signieren Sie die Anfrage auf Ihrer privaten CA mithilfe einer Vorlage, die die Client-Authentifizierung enthält, und laden Sie dann das signierte Zertifikat und seine Kette hoch.

Schritt 2: Erstellen Sie die ausstellende CA

Erstellen Sie eine ausstellende CA, die an der Root-CA aus Schritt 1 verankert ist. Ihre EKUs müssen die Client-Authentifizierung enthalten. Nach der Erstellung werden auf der Eigenschaftenseite drei Dinge angezeigt, die Sie später benötigen:

• die SCEP-URI
• der Download des CA-Zertifikats
• der CRL-Verteilungspunkt

Schritt 3: Bereitstellen von Profilen für vertrauenswürdige Zertifikate

Laden Sie die Zertifikate der Root-CA und der ausstellenden CA herunter. Erstellen Sie pro Plattform ein Profil für vertrauenswürdige Zertifikate für jedes dieser Zertifikate. Weisen Sie sie denselben Gruppen zu, die auch die SCEP- und WiFi-Profile erhalten.

Geräte benötigen diese Kette, bevor das SCEP-Profil erfolgreich sein kann. Erstellen Sie ein weiteres Profil für vertrauenswürdige Zertifikate für die CA, die Ihr RADIUS-Serverzertifikat ausgestellt hat, falls die Geräte diesem noch nicht vertrauen.

Schritt 4: Erstellen Sie das SCEP-Zertifikatsprofil

Erstellen Sie ein SCEP-Zertifikatsprofil pro Plattform und richten Sie es auf die Cloud-PKI aus. Dies sind die wichtigsten Entscheidungen:

• SCEP-Server-URL. Fügen Sie die SCEP-URI der ausstellenden CA genau wie angegeben ein. Belassen Sie den Platzhaltertext unverändert, da Intune ihn bei der Ausstellung auflöst.
• Stammzertifikat. Wählen Sie das Profil für vertrauenswürdige Zertifikate für die Cloud-PKI-Root-CA aus, nicht die ausstellende CA.
• Zertifikatstyp. Wählen Sie Gerätezertifikate für gemeinsam genutzte Geräte wie Tablets an der Rezeption oder Handhelds in Filialen. Wählen Sie personengebundene Zertifikate, wenn die Mitarbeiter ihren eigenen Laptop tragen und Sie die Richtlinie an die Einzelperson binden möchten.
• Betreff und alternativer Anrufername (SAN). Fügen Sie eine Kennung hinzu, die Ihr RADIUS-Server Microsoft Entra ID zuordnen kann. Beispiele sind die Entra-Geräte-ID-Variable {{AAD_Device_ID}} oder die UPN-Variable {{UserPrincipalName}}.
• Schlüsselverwendung und EKU. Stellen Sie Digitale Signatur und Schlüsselverschlüsselung mit Client-Authentifizierung ein.
• Schlüsselspeicherung auf Windows. Melden Sie sich beim TPM-Schlüsselspeicheranbieter (Trusted Platform Module) an, damit der private Schlüssel hardwaregebunden und nicht exportierbar ist.
• Erneuerungsschwellenwert. Legen Sie den Prozentsatz der verbleibenden Lebensdauer fest, bei dem Intune erneuert, damit Zertifikate nie unbemerkt ablaufen.

Schritt 5: Richten Sie das Vertrauen des RADIUS-Servers in die Cloud PKI ein

Importieren Sie sowohl das Cloud PKI Root- als auch das ausstellende CA-Zertifikat in den Speicher für vertrauenswürdige CAs Ihres RADIUS-Servers. Das Importieren nur der Root-CA ist die häufigste Ursache für Ablehnungen aufgrund einer "unbekannten CA".

Aktivieren Sie die CRL-Prüfung und erlauben Sie dem RADIUS-Server ausgehenden HTTP-Zugriff auf den in jedem Zertifikat aufgeführten CRL-Verteilungspunkt. Bei BYOCA vertraut der RADIUS-Server Ihrer Root-CA möglicherweise bereits, sodass Sie nur das neue ausstellende CA-Zertifikat hinzufügen.

Wenn der Cloud-RADIUS von Purple Ihr Mitarbeiter-WiFi authentifiziert, bestätigt Ihr Purple-Account-Team, wie die Cloud PKI-Kette für Ihren Mandanten geladen wird.

Schritt 6: Erstellen Sie das WiFi-Profil

Erstellen Sie ein Intune-WiFi-Profil mit Enterprise-Sicherheit und EAP-TLS als EAP-Typ. Legen Sie drei Felder fest:

• Zertifikat für Client-Authentifizierung. Wählen Sie das SCEP-Profil aus Schritt 4.
• Stammzertifikate für Servervalidierung. Wählen Sie das vertrauenswürdige Zertifikatsprofil für die ausstellende Root-CA Ihres RADIUS-Servers.
• Zertifikatserver-Namen. Geben Sie Namen ein, die exakt mit dem RADIUS-Serverzertifikat übereinstimmen.

Weisen Sie das Profil denselben Gruppen zu wie die SCEP- und vertrauenswürdigen Zertifikatsprofile.

Wie funktioniert der Widerruf mit Cloud PKI?

Sie widerrufen Cloud PKI-Zertifikate von der ausstellenden CA im Intune Admin Center. Öffnen Sie die Liste der ausgetellten Zertifikate, wählen Sie das Zertifikat des Geräts aus und widerrufen Sie es. Cloud PKI veröffentlicht die Änderung dann in seiner CRL (Zertifikatwiderrufsliste), die sich am HTTP-Verteilungspunkt befindet, der in jedem von ihr ausgetellten Zertifikat eingebettet ist.

Ihr RADIUS-Server setzt den Widerruf durch, nicht Intune. Er lädt die CRL herunter und lehnt jedes Zertifikat ab, dessen Seriennummer darauf steht.

Die meisten RADIUS-Server zwischenspeichern eine CRL bis zu deren nächstem Aktualisierungszeitpunkt. Ein widerrufenes Gerät kann sich daher weiterhin verbinden, bis der RADIUS-Server eine neue Liste abruft. Schließen Sie dieses Fenster auf drei Arten:

1. Explizit widerrufen. Verlassen Sie sich nicht darauf, eine Profilzuweisung zu entfernen oder einen Gerätedatensatz zu löschen. Widerrufen Sie das Zertifikat selbst im Rahmen Ihres JML-Prozesses (Joiners, Movers, Leavers).
2. Widerruf mit Identitätsprüfungen koppeln. Wenn Ihr RADIUS-Dienst bei jeder Authentifizierung den Microsoft Entra ID-Konto- oder Gerätestatus überprüft, sperrt das Deaktivieren des Kontos den Zugriff, bevor die CRL aktualisiert wird.
3. CRL-Abruf überwachen. Richten Sie Benachrichtigungen für fehlgeschlagene CRL-Downloads ein. Ein RADIUS-Server, der eine veraltete CRL enthält, gewährt widerrufenen Geräten weiterhin Zugriff oder lehnt jedes Gerät ab, je nach seinen Ausfallrichtlinien.

Wie überprüfen Sie, ob die Cloud PKI WiFi-Authentifizierung funktioniert?

Führen Sie einen Pilotversuch mit einer Testgruppe von fünf bis 10 Geräten auf allen von Ihnen unterstützten Plattformen durch. Bestätigen Sie fünf Dinge:

1. Profilstatus. Das vertrauenswürdige Zertifikat, SCEP- und WiFi-Profil melden alle einen Erfolg in den Intune-Gerätekonfigurationsberichten.
2. Zertifikat auf dem Gerät. Unter Windows erscheint das Zertifikat im persönlichen Speicher mit dem erwarteten Betreff, SAN und Client-Authentifizierung-EKU. Seine Kette sollte sich bis zur Cloud PKI-Root aufbauen.
3. Ausstellungseintrag. Das Zertifikat erscheint in der Liste der ausgestellten Zertifikate der ausstellenden Zertifizierungsstelle im Intune Admin Center.
4. RADIUS-Protokolle. Das Authentifizierungsprotokoll zeigt den Erfolg von EAP-TLS, die erwartete Identität und eine gültige Kette.
5. Sperrprüfung. Sperren Sie ein Testzertifikat. Sobald der RADIUS-Server die neue CRL erfasst hat, bestätigen Sie, dass das Gerät abgelehnt wird.

Führen Sie den Sperrtest durch, bevor Sie live gehen. Es ist die einzige Prüfung, die beweist, dass Ihr RADIUS-Server die CRL erreichen kann.

Was läuft bei Cloud PKI EAP-TLS schief, und wie beheben Sie es?

Symptom	Wahrscheinliche Ursache	Lösung
SCEP-Profil bleibt im Fehler oder ausstehend stecken	Vertrauenswürdige Zertifikatprofile sind nicht derselben Gruppe zugewiesen, oder das SCEP-Profil verweist auf die ausstellende CA statt auf die Root	Weisen Sie Root- und ausstellende vertrauenswürdige Profile denselben Gruppen zu und wählen Sie die Root im SCEP-Profil aus
Zertifikat ausgestellt, RADIUS lehnt mit "unbekannte CA" ab	Nur die Root wurde in RADIUS importiert	Importieren Sie auch das Zertifikat der ausstellenden CA
Jedes Gerät wird nach dem Go-Live abgelehnt	RADIUS kann den CRL-Verteilungspunkt nicht erreichen und bricht sicherheitshalber ab (fails closed)	Erlauben Sie ausgehenden HTTP-Verkehr vom RADIUS-Server zum CRL-Host
Android-Geräte verweigern die Verbindung	Keine Servervalidierung eingestellt; Android 11 und neuer erfordern diese	Bereitstellen der Root des RADIUS-Servers als vertrauenswürdiges Profil und Festlegen der Zertifikat-Servernamen
Windows fordert Mitarbeiter auf, dem Server zu vertrauen	Servernamen im WiFi-Profil stimmen nicht mit dem RADIUS-Zertifikat überein	Korrigieren Sie die Servernamen, sodass sie exakt mit dem Zertifikat übereinstimmen
NPS lehnt mit Microsoft Entra ID verbundene Geräte ab	NPS sucht nach einem lokalen Active Directory-Konto, das nicht existiert	Verwenden Sie einen RADIUS-Dienst, der Zertifikate Microsoft Entra ID-Objekten zuordnet
Gesperrtes Gerät verbindet sich weiterhin	RADIUS speichert eine zwischengespeicherte CRL	Verknüpfen Sie die Sperrung mit der Deaktivierung eines Microsoft Entra ID-Kontos oder -Geräts und überprüfen Sie das CRL-Caching
Dem Zertifikat fehlt die Client-Authentifizierung	Ausstellende CA wurde ohne diese EKU erstellt	Erstellen Sie eine neue ausstellende CA mit Client-Authentifizierung und weisen Sie das SCEP-Profil neu zu

Wenn sich Fehler in bestimmten Räumen oder Etagen häufen, während dieselben Geräte andernorts authentifiziert werden, liegt der Fehler an der Funkabdeckung, nicht an der PKI. EAP-TLS tauscht mehr Pakete aus als ein Pre-Shared-Key-Handshake, sodass sich schwache Signale als Zeitüberschreitungen bemerkbar machen. WiFi Site Surveys: A Practical Planning Guide erklärt, wie Sie diese Lücken finden.

Cloud PKI oder SCEP mit NDES: Was sollten Sie wählen?

Machen Sie die Entscheidung davon abhängig, was Sie bereits betreiben und was Sie außer Betrieb nehmen möchten.

Ihre Situation	Empfehlung	Warum
Mit Microsoft Entra ID verbundene Flotte, kein AD CS	Cloud PKI mit einer Cloud PKI-Root	Keine lokale PKI aufzubauen oder zu betreiben
AD CS vorhanden, NDES-Server vor Betriebssystem-Aktualisierung	Cloud PKI mit BYOCA	Behält Ihr bestehendes Root-Vertrauen bei und ersetzt NDES sowie den Connector
AD CS-Team mit langfristiger CA-Roadmap und weiteren Zertifikatvorlagen	SCEP mit NDES, Überprüfung bei der nächsten Server-Aktualisierung	Bisherige Investition deckt bereits Anwendungsfälle außerhalb von WiFi ab
Dasselbe Schlüsselpaar wird auf mehreren Geräten benötigt, z. B. S/MIME	PKCS für diesen Anwendungsfall, Cloud PKI für WiFi	PKCS liefert exportierbare Schlüssel; WiFi-Zertifikate sollten gerätegebunden bleiben
Hybrid eingebundene Geräte derzeit auf NPS, Wechsel zu Microsoft Entra ID Join	Cloud PKI plus ein Cloud-RADIUS-Dienst	NPS-Abfragen schlagen fehl, sobald Geräte Active Directory verlassen

Regulierte Umgebungen im Gesundheitswesen behalten AD CS oft für andere Workloads bei. Für sie ist BYOCA meist die passende Lösung, da dadurch eine einzige Vertrauensstellung (Root of Trust) im gesamten Unternehmen erhalten bleibt. Bahnunternehmen, die Zertifikate an Tablets des Zugpersonals in Zügen ausstellen, nutzen in der Regel den Cloud PKI Root-Weg. Diese Geräte werden vom ersten Tag an über die Cloud verwaltet.

Was kostet Cloud PKI und was erhalten Sie im Gegenzug?

Microsoft lizenziert Cloud PKI pro Benutzer und Monat. Es ist entweder in der Intune Suite enthalten oder als eigenständiges Add-on zusätzlich zu Intune Plan 1 erhältlich. Prüfen Sie die aktuelle Preisliste von Microsoft, da sich Paketangebote ändern können.

Wägen Sie dies gegen die Kosten der On-Premises-Variante ab:

• Windows Server-Lizenzen und virtuelle Maschinen für die ausstellende CA, NDES und Connector-Hosts
• Der Reverse Proxy oder Application Proxy, der NDES veröffentlicht
• CA-Datenbanksicherungen
• Patching und Verwaltung von Zertifikatvorlagen

Der Ertrag sind weniger Server, kein im Internet veröffentlichter NDES-Endpunkt und gerätegebundene Schlüssel auf jeder von Ihnen verwalteten Plattform.

Praxisbeispiel: Eine Hotelgruppe mit 30 Standorten

Ausgangslage. Eine Gruppe von 30 Hotels betrieb 900 in Microsoft Entra ID eingebundene Laptops und Rezeptionstablets in einem Mitarbeiter-SSID, das mit einem einzigen gemeinsam genutzten Pre-Shared Key gesichert war. Das quartalsweise Ändern dieses Schlüssels bedeutete, jedes Gerät an jedem Standort manuell anzupassen. Ein verlorenes Tablet setzte den Schlüssel bis zur nächsten Änderung einem Sicherheitsrisiko aus.

Umsetzung. Die IT-Abteilung erstellte eine Cloud PKI Root- und Ausstellungs-CA und stellte anschließend TPM-gestützte Gerätezertifikate über SCEP aus. Ein Cloud-RADIUS-Dienst validierte die Kette und prüfte die CRL. Die Gruppe betrieb für die Testphase ein EAP-TLS-SSID parallel zum alten Netzwerk, stellte die Standorte schrittweise um und schaltete das Netzwerk mit dem Pre-Shared Key anschließend ab.

Ergebnis. Die Bilanz dieses Szenarios ist eindeutig:

• Gemeinsam genutzte Zugangsdaten im Mitarbeiternetzwerk sinken von eins auf null.
• Die quartalsweise Schlüsseländerung über 30 Standorte hinweg entfällt vollständig.
• Ein verlorenes Tablet führt zu einer einzigen Zertifikatssperrung statt zur Neukonfiguration von 900 Geräten.
• Es wird keine On-Premises-CA, kein NDES-Server und kein Connector benötigt.

Praxisbeispiel: Eine Einzelhandelskette mit 250 Filialen

Ausgangssituation. Eine Einzelhandelskette stellte WiFi-Zertifikate für 4.000 Handhelds und Laptops in den Filialen über AD CS und zwei NDES-Server aus. Der Intune Certificate Connector lief auf einem dritten Server. Alle drei Server standen zur Erneuerung des Betriebssystems an, und NDES wurde über einen Anwendungsproxy bereitgestellt.

Durchführung. Das Team erstellte eine Cloud PKI Issuing CA als BYOCA und signierte sie mit der bestehenden AD CS Root. Der RADIUS-Server vertraute dieser Root bereits, sodass nur das neue Issuing-CA-Zertifikat importiert werden musste. SCEP-Profile wurden Filialgruppe für Filialgruppe auf die Cloud PKI übertragen. Bestehende Zertifikate blieben bis zur Verlängerung gültig, was eine einfache Rückrollung ermöglichte.

Ergebnis. Die Kette konnte drei Server stilllegen: zwei NDES-Server und einen Connector-Host. Zudem wurde der im Internet veröffentlichte NDES-Endpunkt entfernt. Es war keine erneute Vertrauensstellung für die Root auf dem RADIUS-Server oder den Geräten erforderlich. Die AD CS Root blieb für andere Workloads erhalten.

Wo Purple ins Spiel kommt

Purple Staff WiFi nutzt identitätsbasierte Netzwerke mit Cloud-RADIUS, angebunden an Microsoft Entra ID, Okta oder Google Workspace. Purple ist herstellerunabhängig und kompatibel mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Der Artikel Warum Ihr nächstes WiFi-Upgrade keine neue Hardware erfordert erklärt, warum der Umstieg auf zertifikatsbasierten Mitarbeiterzugang selten den Austausch von Access Points bedeutet.

Purple wird an über 80.000 aktiven Standorten betrieben (Purple-Daten) mit einer Verfügbarkeit von 99,999 % und ist nach ISO 27001 zertifiziert. Trennen Sie Mitarbeiter und Besucher zuverlässig in separate Netzwerke: zertifikatsbasiertes Staff WiFi für von Ihnen verwaltete Geräte und Guest WiFi für alle anderen.

Häufig gestellte Fragen (FAQ)

Kann Microsoft Cloud PKI WiFi-Zertifikate ausstellen?

Ja. Cloud PKI stellt Client-Authentifizierungszertifikate für von Intune verwaltete Windows-, macOS-, iOS/iPadOS- und Android-Geräte über ein SCEP-Zertifikatsprofil aus. Diese Zertifikate authentifizieren Geräte an WPA2-Enterprise- oder WPA3-Enterprise-Netzwerken mittels EAP-TLS. Ihre ausstellende CA muss die EKU für Client-Authentifizierung enthalten, und Ihr RADIUS-Server muss der Cloud PKI Root sowie der ausstellenden CA vertrauen. Cloud PKI stellt im Normalfall nicht das eigene Zertifikat des RADIUS-Servers aus. Dieses Zertifikat stammt von einer öffentlichen CA oder Ihrer bestehenden PKI.

Benötige ich mit Cloud PKI weiterhin NDES?

Nein. Cloud PKI verarbeitet SCEP-Anfragen selbstständig. Sie benötigen keinen NDES-Server, keinen Intune Certificate Connector und keinen Reverse-Proxy mehr, der NDES im Internet bereitstellt. Das SCEP-Profil in Intune verweist direkt auf die SCEP-URI, die auf Ihrer Cloud PKI Issuing CA angezeigt wird. Wenn Sie die Bring-Your-Own-CA-Option nutzen, signiert Ihre private Root die Cloud PKI Issuing CA einmalig. Danach erfolgt die Geräteregistrierung vollständig ohne Zugriff auf Ihre On-Premises-Server.

Wie vertraut der RADIUS-Server den Cloud PKI-Zertifikaten?

Sie importieren die Cloud-PKI-Root- und Ausstellungs-CA-Zertifikate in den Speicher für vertrauenswürdige CAs des RADIUS-Servers. Laden Sie beide aus dem Intune Admin Center herunter. Importieren Sie beide, da der Import nur der Root-CA zu "Unbekannte CA"-Ablehnungen führt. Der RADIUS-Server benötigt außerdem ausgehenden HTTP-Zugriff auf den CRL-Verteilungspunkt in jedem Zertifikat, damit er die Sperrung prüfen kann. Für Geräte mit Microsoft Entra ID-Meldung muss er Zertifikatsidentitäten zu Microsoft Entra ID statt zu einer lokalen Active Directory zuordnen.

Wie funktioniert die Sperrung mit Cloud PKI?

Sie widerrufen ein Zertifikat von der ausstellenden CA im Intune Admin Center, und Cloud PKI veröffentlicht die Änderung in seiner CRL. Ihr RADIUS-Server lädt diese CRL herunter und lehnt gesperrte Zertifikate ab. Da RADIUS-Server CRLs zwischenspeichern, kann sich ein gesperrtes Gerät bis zur nächsten Aktualisierung weiterhin verbinden. Schließen Sie diese Lücke, indem Sie auch das Microsoft Entra ID-Konto oder -Gerät deaktivieren, sofern Ihr RADIUS-Dienst den Identitätsstatus bei jeder Authentifizierung überprüft.

Sollte ich mich für Cloud PKI oder SCEP mit NDES entscheiden?

Wählen Sie Cloud PKI, wenn Sie eine reine Microsoft Entra ID-Flotte betreiben oder planen, lokale PKI-Server auszumustern. Es entfernt die ausstellende CA, NDES- und Connector-Hosts. Behalten Sie SCEP mit NDES bei, wenn Sie über ein gewachsenes AD CS-Team, eine langfristige CA-Roadmap und andere Zertifikatvorlagen verfügen. Wenn Ihre NDES-Server zur Erneuerung anstehen, bewahrt Cloud PKI mit BYOCA Ihr bestehendes Root-Vertrauen und löst NDES dennoch ab.

Wie wird Microsoft Cloud PKI lizenziert?

Cloud PKI wird pro Benutzer und Monat zusätzlich zu Intune Plan 1 lizenziert. Es ist entweder als Teil der Microsoft Intune Suite oder als eigenständiges Cloud PKI Add-on erhältlich. Prüfen Sie vor der Budgetierung die aktuelle Preisliste von Microsoft, da sich Pakete ändern können. Rechnen Sie die Lizenzkosten gegen die Windows Server-Lizenzen, virtuellen Maschinen, Proxy-Veröffentlichungen und den Patch-Aufwand auf, den ein AD CS-, NDES- und Connector-Stack erfordert.

Kann ich meine bestehende lokale Root-CA mit Cloud PKI behalten?

Ja, über die Bring-Your-Own-CA-Option. Sie erstellen eine Cloud PKI Ausstellungs-CA, exportieren deren Zertifikatssignierungsanforderung und signieren sie mit Ihrer bestehenden privaten Root-CA, wie z. B. AD CS. Alles, was dieser Root-CA bereits vertraut, einschließlich Ihres RADIUS-Servers und Ihrer Geräte, vertraut dann der neuen Kette. Sie fügen nur das Zertifikat der ausstellenden CA hinzu. Sie können SCEP-Profile Gruppe für Gruppe migrieren, während bestehende Zertifikate bis zur Erneuerung gültig bleiben.

Funktioniert Cloud PKI mit meinen vorhandenen Access Points?

Ja, solange Ihre Access Points 802.1X mit WPA2-Enterprise oder WPA3-Enterprise unterstützen. Cloud PKI betrifft nur die Zertifikate auf den Geräten und das Vertrauen auf Ihrem RADIUS-Server. Die Access Points leiten die Authentifizierung einfach an RADIUS weiter. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet unterstützen dies alle. Staff WiFi von Purple läuft über alle acht Anbieter hinweg als hardwareunabhängiges Cloud-Overlay.