Microsoft Intune WiFi Zertifikatsbereitstellung via SCEP und PKCS
Dieser Leitfaden bietet eine schrittweise technische Referenz für die Bereitstellung von WiFi-Authentifizierungszertifikaten über Microsoft Intune mittels SCEP und PKCS. Er richtet sich an IT-Manager und Netzwerkarchitekten, die passwortloses 802.1X WiFi implementieren, um eine nahtlose und sichere Konnektivität in Unternehmensumgebungen zu gewährleisten.
Executive Summary
Für Unternehmensstandorte – ob in einem belebten Gastgewerbe -Umfeld, einem Einzelhandelsbetrieb mit mehreren Standorten oder einem modernen Unternehmenscampus – ist die Abhängigkeit von Pre-Shared Keys oder einfachen Captive Portals für das Mitarbeiter-WiFi ein Sicherheitsrisiko und ein betrieblicher Engpass. Moderne Netzwerkarchitekturen erfordern eine 802.1X-Authentifizierung mittels EAP-TLS, um sicherzustellen, dass jedes Gerät kryptografisch verifiziert wird, bevor es auf das Netzwerk zugreift.
Die Herausforderung liegt jedoch in der Verteilung: Wie stellen Sie Tausenden von Windows-, iOS- und Android-Geräten eindeutige Client-Zertifikate bereit, ohne Ihren Helpdesk mit Support-Tickets zu überlasten? Microsoft Intune löst dies durch automatisiertes Zertifikats-Lifecycle-Management. Durch die Nutzung von SCEP (Simple Certificate Enrollment Protocol) oder PKCS (Public Key Cryptography Standards) Zertifikatsprofilen können IT-Teams vertrauenswürdige Root- und Client-Zertifikate geräuschlos auf verwaltete Endpunkte übertragen.
Dieser Leitfaden bietet einen definitiven architektonischen Blueprint und eine schrittweise Implementierungsstrategie für die Intune WiFi Zertifikatsbereitstellung. Wir werden die entscheidenden Unterschiede zwischen SCEP und PKCS untersuchen, die genaue Bereitstellungssequenz für den Erfolg detailliert beschreiben und Strategien zur Risikominderung in der Praxis skizzieren, um sicherzustellen, dass Ihr Guest WiFi und Ihre Unternehmensnetzwerke sicher und leistungsstark bleiben.
Hören Sie sich das begleitende Podcast-Briefing an:
Technischer Deep-Dive: SCEP vs. PKCS
Bei der Planung Ihrer Intune WiFi Zertifikatsbereitstellungsstrategie ist die erste architektonische Entscheidung die Wahl des Zertifikatsübermittlungsmechanismus. Intune unterstützt sowohl SCEP als auch PKCS, aber sie funktionieren grundlegend unterschiedlich.
SCEP (Simple Certificate Enrollment Protocol)
SCEP ist der Branchenstandard für die Registrierung von Unternehmensgeräten. In einem SCEP-Workflow weist der Intune-Dienst den Endpunkt an, sein eigenes privates/öffentliches Schlüsselpaar zu generieren. Das Gerät erstellt dann einen Certificate Signing Request (CSR) und sendet diesen über einen Network Device Enrollment Service (NDES) Server an Ihre Zertifizierungsstelle (CA). Die CA signiert die Anfrage und gibt das öffentliche Zertifikat an das Gerät zurück.
Der entscheidende Sicherheitsvorteil von SCEP besteht darin, dass der private Schlüssel das Gerät niemals verlässt. Er wird lokal generiert, in der Secure Enclave des Geräts gespeichert (z. B. im TPM unter Windows oder der Secure Enclave unter iOS) und niemals über das Netzwerk übertragen. Dies macht SCEP zum dringend empfohlenen Ansatz für die 802.1X-Authentifizierung.
PKCS (Public Key Cryptography Standards)
Im Gegensatz dazu generiert die Zertifizierungsstelle bei PKCS sowohl den öffentlichen als auch den privaten Schlüssel zentral. Der Microsoft Intune Certificate Connector exportiert dieses Schlüsselpaar dann sicher und überträgt es auf das Zielgerät.
Während PKCS die Notwendigkeit der Bereitstellung und Wartung eines NDES-Servers eliminiert – was den Infrastruktur-Footprint vereinfacht –, führt es ein theoretisches Sicherheitsrisiko ein, da der private Schlüssel über das Netzwerk übertragen wird. PKCS eignet sich im Allgemeinen besser für Anwendungsfälle, in denen ein Key Escrow erforderlich ist, wie z. B. die S/MIME-E-Mail-Verschlüsselung, als für die Netzwerkauthentifizierung.
Implementierungsleitfaden: Die Bereitstellungssequenz
Die erfolgreiche Konfiguration eines Intune WiFi Profils für 802.1X erfordert die strikte Einhaltung einer spezifischen Bereitstellungssequenz. Abhängigkeiten von Intune-Profilen schreiben vor, dass Vertrauen etabliert sein muss, bevor die Authentifizierung konfiguriert werden kann.
Schritt 1: Bereitstellung des vertrauenswürdigen Root-Zertifikatsprofils
Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle vertrauen.
- Exportieren Sie Ihr Root-CA-Zertifikat (und alle Intermediate-CA-Zertifikate) als
.cer-Dateien. - Navigieren Sie im Microsoft Endpoint Manager Admin Center zu Geräte > Konfigurationsprofile > Profil erstellen.
- Wählen Sie die Zielplattform (z. B. Windows 10 und höher) und den Profiltyp Vertrauenswürdiges Zertifikat.
- Laden Sie die
.cer-Datei hoch und stellen Sie dieses Profil für Ihre Zielgerätegruppen bereit.
Faustregel: Adressieren Sie immer dieselben Gruppen (entweder Benutzer oder Geräte) über alle zugehörigen Profile hinweg, um Bereitstellungsfehler zu vermeiden.
Schritt 2: Konfiguration des SCEP-Zertifikatsprofils
Sobald das Vertrauen etabliert ist, konfigurieren Sie das SCEP-Profil, um Geräte anzuweisen, wie sie ihr Client-Zertifikat erhalten.
- Erstellen Sie ein neues Konfigurationsprofil und wählen Sie SCEP-Zertifikat.
- Konfigurieren Sie das Format des Antragstellernamens. Für die benutzergesteuerte Authentifizierung ist
CN={{UserPrincipalName}}Standard. Verwenden Sie für die GeräteauthentifizierungCN={{AAD_Device_ID}}. - Stellen Sie die Schlüsselverwendung auf
Digitale SignaturundSchlüsselverschlüsselungein. - Geben Sie unter Erweiterte Schlüsselverwendung
Clientauthentifizierung(OID: 1.3.6.1.5.5.7.3.2) an. - Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten vertrauenswürdigen Root-Zertifikatsprofil.
- Geben Sie die externe URL Ihres NDES-Servers an.
Schritt 3: Bereitstellung des 802.1X WiFi Profils
Der letzte Schritt ist das Übertragen der WiFi-Konfiguration, die die Zertifikate mit der Netzwerk-SSID verknüpft.
- Erstellen Sie ein Wi-Fi-Konfigurationsprofil.
- Geben Sie den Netzwerknamen (SSID) exakt so ein, wie er von Ihren Wireless Access Points ausgestrahlt wird.
- Wählen Sie WPA2-Enterprise oder WPA3-Enterprise als Sicherheitstyp.
- Stellen Sie den EAP-Typ auf EAP-TLS ein.
- Wählen Sie in den Authentifizierungseinstellungen das in Schritt 2 erstellte SCEP-Zertifikatsprofil aus. als Client-Authentifizierungszertifikat.
- Geben Sie das Trusted Root-Zertifikat für die Servervalidierung an, um sicherzustellen, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server verbindet.
Best Practices & Branchenstandards
Bei der Implementierung der Intune WiFi-Zertifikatsbereitstellung sollten Sie die folgenden herstellerneutralen Best Practices einhalten, um Compliance und Zuverlässigkeit zu gewährleisten.
NDES-Serverplatzierung und Sicherheit
Der NDES-Server muss über das Internet erreichbar sein, damit Remote-Geräte Zertifikate bereitstellen können, bevor sie vor Ort eintreffen. Die direkte Freigabe eines internen Servers im Internet stellt jedoch ein erhebliches Sicherheitsrisiko dar.
Empfehlung: Veröffentlichen Sie die NDES-URL über den Azure AD-Anwendungsproxy. Dies bietet sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und ermöglicht die Anwendung von Richtlinien für bedingten Zugriff auf den Registrierungsflow.
RADIUS und CRL-Prüfung
Die Zertifikatsbereitstellung ist nur die halbe Miete für die Sicherheit; der Widerruf ist ebenso wichtig. Wenn ein Mitarbeiter ausscheidet, widerruft die Deaktivierung seines Active Directory-Kontos möglicherweise nicht sofort seinen WiFi-Zugang, wenn sein Client-Zertifikat gültig bleibt und der RADIUS-Server die Zertifikatssperrliste (CRL) nicht strikt prüft.
Empfehlung: Konfigurieren Sie Ihren Network Policy Server (NPS) oder RADIUS-Server so, dass eine strikte CRL-Prüfung erzwungen wird. Stellen Sie sicher, dass Ihre CRL-Verteilungspunkte (CDPs) hochverfügbar sind; wenn der RADIUS-Server die CRL nicht erreichen kann, schlägt die Authentifizierung fehl, was zu einem weitreichenden Ausfall führt.
Weitere Einblicke in sicheres Netzwerkdesign finden Sie unter Die wichtigsten SD-WAN-Vorteile für moderne Unternehmen .
Fehlerbehebung & Risikominderung
Selbst bei sorgfältiger Planung können bei der Zertifikatsbereitstellung Probleme auftreten. Hier sind häufige Fehlermodi und Minderungsstrategien.
Problem: WiFi-Profil kann nicht angewendet werden
Symptom: Das Gerät erhält die Trusted Root- und SCEP-Zertifikate, aber das WiFi-Profil wird in Intune als 'Fehler' oder 'Nicht anwendbar' angezeigt.
Ursache: Dies wird fast immer durch eine Diskrepanz beim Gruppen-Targeting verursacht. Wenn das SCEP-Profil einer Benutzergruppe zugewiesen ist, das WiFi-Profil jedoch einer Gerätegruppe, kann Intune die Abhängigkeit nicht auflösen.
Lösung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die Trusted Root-, SCEP- und WiFi-Profile alle derselben Azure AD-Gruppe zugewiesen sind.
Problem: NDES 403 Forbidden-Fehler
Symptom: Geräte können das SCEP-Zertifikat nicht abrufen, und die NDES-IIS-Protokolle zeigen HTTP 403-Fehler.
Ursache: Dem Dienstkonto des Intune Certificate Connector fehlen die erforderlichen Berechtigungen für die Zertifikatsvorlage, oder die URL-Filterung Ihrer Firewall blockiert die spezifischen Abfragezeichenfolgen-Parameter, die von SCEP verwendet werden.
Lösung: Überprüfen Sie, ob das Connector-Konto über die Berechtigungen 'Lesen' und 'Registrieren' für die CA-Vorlage verfügt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.
ROI & geschäftliche Auswirkungen
Der Übergang zur Microsoft Intune 802.1X-Zertifikatsbereitstellung liefert messbare Erträge in den Bereichen Sicherheit und Betrieb.
- Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi erzeugt ein erhebliches Volumen an Support-Tickets (Passwortablauf, Sperrungen, Tippfehler). Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar und reduziert das WiFi-bezogene Helpdesk-Volumen in der Regel um 70-80 %.
- Verbesserte Sicherheitslage: EAP-TLS eliminiert das Risiko von Credential Harvesting und Man-in-the-Middle (MitM)-Angriffen. Dies ist entscheidend für die Einhaltung von Frameworks wie PCI DSS und GDPR, insbesondere im Gesundheitswesen und im Einzelhandel.
- Nahtloses Onboarding: Für Unternehmen, die neben Windows auch große Flotten von Apple-Geräten verwalten, gewährleistet die Integration von Intune in bestehende MDM-Workflows (siehe unseren Leitfaden zu Jamf und RADIUS: Zertifikatsbasierte WiFi-Authentifizierung für Apple-Geräteflotten ) eine einheitliche Zero-Touch-Bereitstellung vom ersten Tag an.
Schlüsselbegriffe & Definitionen
SCEP (Simple Certificate Enrollment Protocol)
A protocol that allows devices to request digital certificates from a Certificate Authority, where the private key is generated and stored securely on the device itself.
The recommended method for deploying WiFi authentication certificates due to its high security and scalability.
PKCS (Public Key Cryptography Standards)
A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.
Often used for S/MIME email encryption, but less ideal for WiFi due to the network transmission of the private key.
NDES (Network Device Enrollment Service)
A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates via SCEP.
A required infrastructure component when implementing SCEP certificate deployment with Microsoft Intune.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
The most secure 802.1X authentication method, requiring both the server and the client to present valid digital certificates.
The target authentication protocol that the Intune WiFi and certificate profiles are designed to enable.
CRL (Certificate Revocation List)
A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date.
Critical for security; RADIUS servers must check the CRL to ensure terminated employees cannot access the WiFi using an otherwise valid certificate.
Intune Certificate Connector
A software agent installed on an on-premises Windows Server that brokers requests between Microsoft Intune and the internal Certificate Authority.
Required for both SCEP (to validate requests) and PKCS (to export keys) deployments.
Subject Alternative Name (SAN)
An extension to a digital certificate that allows multiple values (like UPN, email, or MAC address) to be associated with the certificate.
Configured in the Intune SCEP profile to ensure the RADIUS server can accurately identify the user or device.
Azure AD Application Proxy
A feature that provides secure remote access to on-premises web applications without requiring a VPN or opening inbound firewall ports.
The best practice method for securely publishing the internal NDES server URL to the internet for remote device enrollment.
Fallstudien
A national retail chain with 500 locations is migrating from WPA2-Personal (Pre-Shared Key) to WPA3-Enterprise for their store associate tablets (Android Enterprise Dedicated Devices). They use Intune for MDM. How should they architect the certificate deployment?
- Deploy an NDES server published via Azure AD App Proxy.
- Create a Device-based SCEP certificate profile in Intune, as these are dedicated (kiosk) devices not tied to a specific user. Use
CN={{AAD_Device_ID}}for the Subject Name. - Deploy the Root CA profile to the 'All Store Tablets' Azure AD Device Group.
- Deploy the SCEP profile to the same 'All Store Tablets' group.
- Create a Wi-Fi profile configured for WPA3-Enterprise, EAP-TLS, referencing the SCEP profile, and deploy it to the same group.
- Configure the central RADIUS servers to authenticate the device certificates against the Active Directory computer objects.
A large conference centre uses Purple for their [WiFi Analytics](/products/wifi-analytics) and Guest WiFi, but needs to secure their internal staff network. Staff use a mix of corporate-owned Windows laptops and BYOD iOS devices. How do they handle the Intune deployment for the BYOD devices?
- Require BYOD users to enroll their iOS devices via Intune User Enrollment (creating a secure work partition).
- Create a User-based SCEP certificate profile using
CN={{UserPrincipalName}}. - Deploy the Root CA, SCEP, and Wi-Fi profiles to an Azure AD User Group (e.g., 'All Staff').
- When the user enrolls their personal device, Intune pushes the profiles specifically to the managed work partition.
- The device connects to the staff SSID using the user's identity, allowing the RADIUS server to apply role-based access control (VLAN assignment) based on their AD group membership.
Szenarioanalyse
Q1. You have deployed the Root CA, SCEP, and Wi-Fi profiles to your Windows 10 devices. The certificates install successfully, but the Wi-Fi profile fails to apply, showing 'Error' in the Intune console. What is the most likely cause?
💡 Hinweis:Check how the profiles are assigned to Azure AD groups.
Empfohlenen Ansatz anzeigen
The most likely cause is a mismatch in group targeting. If the SCEP profile was assigned to a User Group, but the Wi-Fi profile was assigned to a Device Group, Intune cannot resolve the dependency between them. All three profiles (Root, SCEP, Wi-Fi) must be targeted to the exact same group type.
Q2. Your security team mandates that private keys must never be transmitted across the network, even if encrypted. Which certificate deployment method must you use in Intune, and what additional infrastructure server is required?
💡 Hinweis:Think about where the key pair is generated.
Empfohlenen Ansatz anzeigen
You must use SCEP (Simple Certificate Enrollment Protocol). Because SCEP instructs the endpoint device to generate the private key locally, it never traverses the network. This deployment requires a Network Device Enrollment Service (NDES) server to act as a bridge to the Certificate Authority.
Q3. A remote employee provisions a new laptop at home via Windows Autopilot. The Intune profiles deploy successfully, but the device fails to obtain the SCEP certificate. What infrastructure configuration is likely missing?
💡 Hinweis:How does the device reach the internal CA from the internet?
Empfohlenen Ansatz anzeigen
The NDES server has likely not been published to the internet. For remote devices to request certificates before arriving at the corporate office, the NDES URL must be externally accessible, ideally published securely via Azure AD Application Proxy.
Wichtigste Erkenntnisse
- ✓802.1X EAP-TLS is the standard for secure enterprise WiFi, requiring client certificates on all devices.
- ✓Microsoft Intune automates certificate deployment at scale using SCEP or PKCS profiles.
- ✓SCEP is highly recommended for WiFi as the private key is generated locally and never leaves the device.
- ✓Deployment requires a strict sequence: 1) Trusted Root, 2) SCEP Profile, 3) Wi-Fi Profile.
- ✓Group targeting (User vs. Device) must be identical across all three profiles to prevent dependency failures.
- ✓NDES servers should be published via Azure AD App Proxy to allow secure, remote certificate provisioning.
- ✓Strict CRL checking on the RADIUS server is mandatory to ensure revoked certificates cannot access the network.
