Vai al contenuto principale

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Questa guida fornisce un riferimento tecnico dettagliato per la distribuzione di certificati di autenticazione WiFi tramite Microsoft Intune utilizzando SCEP e PKCS. È progettata per IT manager e architetti di rete che implementano il WiFi 802.1X senza password per garantire una connettività fluida e sicura negli ambienti aziendali.

By Iain JewittPublished
📖 6 minuti di lettura1,231 parole2 esempi pratici3 domande di esercitazione8 definizioni chiave

Parte della nostra serie principale: Enterprise WiFi Security Guide

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Executive Summary

Für Unternehmensstandorte – ob eine geschäftige Gastgewerbe -Umgebung, ein Einzelhandel -Betrieb mit mehreren Standorten oder ein moderner Campus – ist die Nutzung 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. Dies stellt sicher, dass jedes Gerät kryptografisch verifiziert wird, bevor es auf das Netzwerk zugreift.

Die Herausforderung liegt jedoch in der Verteilung: Wie stellen Sie eindeutige Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten bereit, ohne Ihren Helpdesk mit Support-Tickets zu überlasten? Microsoft Intune löst dies durch ein automatisiertes Zertifikats-Lebenszyklusmanagement. Durch die Nutzung von SCEP- (Simple Certificate Enrollment Protocol) oder PKCS-Zertifikatsprofilen (Public Key Cryptography Standards) können IT-Teams vertrauenswürdige Root- und Client-Zertifikate geräuschlos auf verwaltete Endpunkte übertragen.

Dieser Leitfaden bietet einen definitiven Architektur-Entwurf und eine schrittweise Implementierungsstrategie für die Intune WiFi-Zertifikatsbereitstellung. Wir untersuchen die entscheidenden Unterschiede zwischen SCEP und PKCS, beschreiben die genaue Bereitstellungsreihenfolge für den Erfolg und skizzieren praxisnahe Strategien zur Risikominderung. So stellen Sie sicher, dass Ihr Gäste-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 Wahl des Zertifikatsbereitstellungsmechanismus die erste Architekturentscheidung. Intune unterstützt sowohl SCEP als auch PKCS, diese funktionieren jedoch 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 eine Zertifikatsignierungsanforderung (Certificate Signing Request, CSR) und sendet diese über einen NDES-Server (Network Device Enrollment Service) an Ihre Zertifizierungsstelle (Certificate Authority, CA). Die CA signiert die Anforderung 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 sicheren Enklave des Geräts gespeichert (wie dem 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 anschließend sicher und überträgt es auf das Zielgerät.

Obwohl PKCS die Bereitstellung und Wartung eines NDES-Servers überflüssig macht – was den Infrastruktur-Aufwand vereinfacht –, birgt es ein theoretisches Sicherheitsrisiko, da der private Schlüssel über das Netzwerk übertragen wird. PKCS eignet sich im Allgemeinen besser für Anwendungsfälle, in denen eine Schlüsselhinterlegung (Key Escrow) erforderlich ist, wie z. B. bei der S/MIME-E-Mail-Verschlüsselung, als für die Netzwerkauthentifizierung.

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS - scep vs pkcs comparison

Implementierungsleitfaden: Die Bereitstellungsreihenfolge

Die erfolgreiche Konfiguration eines Intune WiFi-Profils für 802.1X erfordert die strikte Einhaltung einer bestimmten Bereitstellungsreihenfolge. Die Abhängigkeiten der Intune-Profile schreiben vor, dass Vertrauen etabliert werden 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.

  1. Exportieren Sie Ihr Root-CA-Zertifikat (und alle Intermediate-CA-Zertifikate) als .cer-Dateien.
  2. Navigieren Sie im Microsoft Endpoint Manager Admin Center zu Geräte > Konfigurationsprofile > Profil erstellen.
  3. Wählen Sie die Zielplattform (z. B. Windows 10 und neuer) und den Profiltyp Vertrauenswürdiges Zertifikat.
  4. Laden Sie die .cer-Datei hoch und stellen Sie dieses Profil für Ihre Zielgerätegruppen bereit.

Faustregel: Weisen Sie alle zusammengehörigen Profile immer denselben Gruppen zu (entweder Benutzern oder Geräten), um Bereitstellungsfehler zu vermeiden.

Schritt 2: Konfigurieren des SCEP-Zertifikatsprofils

Sobald das Vertrauen etabliert ist, konfigurieren Sie das SCEP-Profil, um Geräten mitzuteilen, wie sie ihr Client-Zertifikat abrufen können.

  1. Erstellen Sie ein neues Konfigurationsprofil und wählen Sie SCEP-Zertifikat.
  2. Konfigurieren Sie das Format des Antragstellernamens (Subject name format). Für die benutzergesteuerte Authentifizierung ist CN={{UserPrincipalName}} Standard. Für die Geräteauthentifizierung verwenden Sie CN={{AAD_Device_ID}}.
  3. Legen Sie die Schlüsselverwendung (Key usage) auf Digitale Signatur und Schlüsselverschlüsselung fest.
  4. Geben Sie unter Erweiterte Schlüsselverwendung (Extended key usage) Clientauthentifizierung (OID: 1.3.6.1.5.5.7.3.2) an.
  5. Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten vertrauenswürdigen Root-Zertifikatsprofil.
  6. Geben Sie die externe URL Ihres NDES-Servers an.

Schritt 3: Bereitstellung des 802.1X WiFi-Profils

Der letzte Schritt besteht darin, die WiFi-Konfiguration bereitzustellen, die die Zertifikate mit der Netzwerk-SSID verknüpft.

  1. Erstellen Sie ein WiFi-Konfigurationsprofil.
  2. Geben Sie den Netzwerknamen (SSID) exakt so ein, wie er von Ihren Wireless Access Points übertragen wird.
  3. Wählen Sie WPA2-Enterprise oder WPA3-Enterprise as security type.
  4. Stellen Sie den EAP-Typ auf EAP-TLS ein.
  5. Wählen Sie in den Authentifizierungseinstellungen das in Schritt 2 erstellte SCEP-Zertifikatsprofil als Client-Authentifizierungszertifikat aus.
  6. Geben Sie das vertrauenswürdige Root-Zertifikat für die Servervalidierung an, um sicherzustellen, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server verbindet.

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS - architecture overview

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

Best Practices & Branchenstandards

Halten Sie sich bei der Implementierung der Intune WiFi-Zertifikatsbereitstellung an die folgenden herstellerneutralen Best Practices, um Compliance und Zuverlässigkeit zu gewährleisten.

Platzierung und Sicherheit des NDES-Servers

Der NDES-Server muss aus dem 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 Application Proxy. Dies ermöglicht einen sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und erlaubt es Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungs-Flow anzuwenden.

RADIUS- und CRL-Prüfung

Die Zertifikatsbereitstellung ist nur die halbe Miete; der Widerruf ist ebenso wichtig. Wenn ein Mitarbeiter das Unternehmen verlässt, entzieht das Deaktivieren seines Active Directory-Kontos möglicherweise nicht sofort den WiFi-Zugriff, wenn sein Client-Zertifikat gültig bleibt und der RADIUS-Server die Zertifikatsperrliste (Certificate Revocation List, 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 typische Fehlerbilder und Strategien zu deren Behebung.

Problem: WiFi-Profil kann nicht angewendet werden

Symptom: Das Gerät empfängt die vertrauenswürdigen Root- und SCEP-Zertifikate, aber das WiFi-Profil wird in Intune als 'Fehler' oder 'Nicht anwendbar' angezeigt.

Ursache: Dies wird fast immer durch eine fehlerhafte Gruppenzuweisung verursacht. Wenn das SCEP-Profil einer Benutzergruppe, das WiFi-Profil jedoch einer Gerätegruppe zugewiesen ist, kann Intune die Abhängigkeit nicht auflösen.

Behebung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die vertrauenswürdigen Root-, SCEP- und WiFi-Profile alle für dieselbe Azure AD-Gruppe bereitgestellt werden.

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 Connectors fehlen die erforderlichen Berechtigungen für die Zertifikatvorlage, oder die URL-Filterung auf Ihrer Firewall blockiert die spezifischen von SCEP verwendeten Abfragezeichenfolgen-Parameter.

Behebung: Überprüfen Sie, ob das Connector-Konto die Berechtigungen 'Lesen' und 'Registrieren' für die CA-Vorlage besitzt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.

ROI & geschäftliche Auswirkungen

Der Übergang zur 802.1X-Zertifikatsbereitstellung mit Microsoft Intune liefert messbare Vorteile für Sicherheit und Betrieb.

  1. Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi verursacht ein erhebliches Aufkommen an Support-Tickets (abgelaufene Passwörter, Sperren, Tippfehler). Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar und reduziert das WiFi-bezogene Helpdesk-Volumen in der Regel um 70–80 %.
  2. Verbesserte Sicherheitslage: EAP-TLS eliminiert das Risiko von Credential Harvesting und Man-in-the-Middle-Angriffen (MitM). Dies ist entscheidend für die Einhaltung von Frameworks wie PCI-DSS und GDPR, insbesondere im Gesundheitswesen und im Einzelhandel.
  3. Nahtloses Onboarding: Für Unternehmen, die neben Windows auch große Flotten von Apple-Geräten verwalten, sorgt die Integration von Intune in bestehende MDM-Workflows (siehe unseren Leitfaden zu Jamf und RADIUS: Zertifikatsbasierte WiFi-Authentifizierung für Apple-Geräteflotten ) vom ersten Tag an für eine einheitliche, berührungslose Bereitstellung (Zero-Touch-Provisioning).

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

Un protocollo che consente ai dispositivi di richiedere certificati digitali a una Certificate Authority, in cui la chiave privata viene generata e memorizzata in modo sicuro sul dispositivo stesso.

Il metodo consigliato per distribuire i certificati di autenticazione WiFi grazie alla sua elevata sicurezza e scalabilità.

PKCS (Public Key Cryptography Standards)

Un insieme di standard in cui sia la chiave pubblica che quella privata vengono generate dalla Certificate Authority e poi consegnate in modo sicuro all'endpoint.

Spesso utilizzato per la crittografia delle e-mail S/MIME, ma meno ideale per il WiFi a causa della trasmissione in rete della chiave privata.

NDES (Network Device Enrollment Service)

Un ruolo di Microsoft Windows Server che funge da ponte, consentendo ai dispositivi privi di credenziali di dominio di ottenere certificati tramite SCEP.

Un componente infrastrutturale richiesto quando si implementa la distribuzione dei certificati SCEP con Microsoft Intune.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Il metodo di autenticazione 802.1X più sicuro, che richiede sia al server che al client di presentare certificati digitali validi.

Il protocollo di autenticazione di destinazione che i profili WiFi e dei certificati di Intune sono progettati per abilitare.

CRL (Certificate Revocation List)

Un elenco pubblicato dalla Certificate Authority contenente i numeri di serie dei certificati che sono stati revocati prima della loro data di scadenza.

Critico per la sicurezza; i server RADIUS devono controllare la CRL per garantire che i dipendenti licenziati non possano accedere al WiFi utilizzando un certificato altrimenti valido.

Intune Certificate Connector

Un agente software installato su un Windows Server locale che gestisce le richieste tra Microsoft Intune e la Certificate Authority interna.

Richiesto sia per le distribuzioni SCEP (per convalidare le richieste) che PKCS (per esportare le chiavi).

Subject Alternative Name (SAN)

Un'estensione di un certificato digitale che consente di associare al certificato più valori (come UPN, e-mail o indirizzo MAC).

Configurato nel profilo SCEP di Intune per garantire che il server RADIUS possa identificare accuratamente l'utente o il dispositivo.

Azure AD Application Proxy

Una funzionalità che fornisce un accesso remoto sicuro alle applicazioni web locali senza richiedere una VPN o l'apertura di porte in entrata nel firewall.

Il metodo basato sulle migliori pratiche per pubblicare in modo sicuro l'URL del server NDES interno su Internet per la registrazione dei dispositivi remoti.

Esempi pratici

Una catena di vendita al dettaglio nazionale con 500 punti vendita sta migrando da WPA2-Personal (Pre-Shared Key) a WPA3-Enterprise per i tablet dei dipendenti del negozio (Android Enterprise Dedicated Devices). Utilizzano Intune come MDM. Come dovrebbero progettare la distribuzione dei certificati?

  1. Distribuire un server NDES pubblicato tramite Azure AD App Proxy.
  2. Creare un profilo di certificato SCEP basato su dispositivo in Intune, poiché si tratta di dispositivi dedicati (kiosk) non associati a un utente specifico. Utilizzare CN={{AAD_Device_ID}} per il Subject Name.
  3. Distribuire il profilo Root CA al gruppo di dispositivi Azure AD 'All Store Tablets'.
  4. Distribuire il profilo SCEP allo stesso gruppo 'All Store Tablets'.
  5. Creare un profilo WiFi configurato per WPA3-Enterprise, EAP-TLS, facendo riferimento al profilo SCEP, e distribuirlo allo stesso gruppo.
  6. Configurare i server RADIUS centrali per autenticare i certificati dei dispositivi rispetto agli oggetti computer di Active Directory.
Commento dell'esaminatore: Questo approccio identifica correttamente che i dispositivi dedicati richiedono certificati basati su dispositivo (e non su utente). Indirizzando i gruppi di dispositivi in modo coerente in tutti e tre i profili, l'architetto evita il fallimento di distribuzione più comune in Intune. L'uso di Azure AD App Proxy per NDES garantisce che i tablet possano rinnovare i certificati in modo sicuro senza VPN.

Un grande centro congressi utilizza Purple per i propri [WiFi Analytics](/products/wifi-analytics) e Guest WiFi, ma deve proteggere la rete interna del personale. Il personale utilizza un mix di laptop Windows aziendali e dispositivi iOS BYOD. Come gestiscono la distribuzione di Intune per i dispositivi BYOD?

  1. Richiedere agli utenti BYOD di registrare i propri dispositivi iOS tramite Intune User Enrollment (creando una partizione di lavoro sicura).
  2. Creare un profilo di certificato SCEP basato su utente utilizzando CN={{UserPrincipalName}}.
  3. Distribuire i profili Root CA, SCEP e WiFi a un gruppo di utenti Azure AD (ad esempio, 'All Staff').
  4. Quando l'utente registra il proprio dispositivo personale, Intune invia i profili specificamente alla partizione di lavoro gestita.
  5. Il dispositivo si connette all'SSID del personale utilizzando l'identità dell'utente, consentendo al server RADIUS di applicare il controllo degli accessi basato sui ruoli (assegnazione VLAN) in base alla loro appartenenza al gruppo AD.
Commento dell'esaminatore: Questa soluzione applica correttamente la registrazione dell'utente (User Enrollment) per una gestione BYOD che tutela la privacy. Indirizzando i gruppi di utenti, i certificati seguono il dipendente indipendentemente dal dispositivo registrato. L'integrazione del controllo degli accessi basato sui ruoli tramite RADIUS dimostra una progettazione di rete avanzata.

Domande di esercitazione

Q1. Hai distribuito i profili Root CA, SCEP e WiFi sui tuoi dispositivi Windows 10. I certificati vengono installati correttamente, ma l'applicazione del profilo WiFi non va a buon fine, mostrando "Errore" nella console Intune. Qual è la causa più probabile?

Suggerimento: Verifica come i profili sono assegnati ai gruppi Azure AD.

Visualizza risposta modello

La causa più probabile è una discrepanza nel targeting dei gruppi. Se il profilo SCEP è stato assegnato a un Gruppo Utenti, ma il profilo WiFi è stato assegnato a un Gruppo Dispositivi, Intune non può risolvere la dipendenza tra di essi. Tutti e tre i profili (Root, SCEP, WiFi) devono essere indirizzati esattamente allo stesso tipo di gruppo.

Q2. Il tuo team di sicurezza impone che le chiavi private non vengano mai trasmesse sulla rete, anche se crittografate. Quale metodo di distribuzione dei certificati devi utilizzare in Intune e quale server di infrastruttura aggiuntivo è richiesto?

Suggerimento: Pensa a dove viene generata la coppia di chiavi.

Visualizza risposta modello

È necessario utilizzare SCEP (Simple Certificate Enrollment Protocol). Poiché SCEP indica al dispositivo endpoint di generare la chiave privata localmente, questa non attraversa mai la rete. Questa distribuzione richiede un server NDES (Network Device Enrollment Service) che funga da ponte verso la Certificate Authority.

Q3. Un dipendente da remoto configura un nuovo laptop da casa tramite Windows Autopilot. I profili Intune vengono distribuiti correttamente, ma il dispositivo non riesce a ottenere il certificato SCEP. Quale configurazione dell'infrastruttura è probabilmente mancante?

Suggerimento: In che modo il dispositivo raggiunge la CA interna da Internet?

Visualizza risposta modello

Il server NDES probabilmente non è stato pubblicato su Internet. Affinché i dispositivi remoti possano richiedere i certificati prima di arrivare in ufficio, l'URL NDES deve essere accessibile dall'esterno, idealmente pubblicato in modo sicuro tramite Azure AD Application Proxy.

Continua a leggere questa serie

Sophos Firewall e guest WiFi: configurazione del Captive Portal con Purple

Come il cloud guest WiFi di Purple funziona con Sophos Firewall e i suoi access point attraverso un Captive Portal esterno standard e RADIUS, e dove verificare il supporto e trovare i passaggi.

Leggi la guida →

Aruba Central and Purple WiFi: Cloud-Managed Integration

Una guida di riferimento tecnico completa per integrare Aruba Central con la piattaforma cloud-hosted di guest WiFi intelligence di Purple. Questa guida copre l'architettura, la configurazione passo-passo di Captive Portal esterni e RADIUS, e le strategie di implementazione multi-sito per i team IT aziendali.

Leggi la guida →

Autenticazione WiFi con Azure AD ed Entra ID: Guida all'Integrazione e alla Configurazione

Questa guida di riferimento tecnico fornisce a IT manager, architetti di rete e direttori operativi delle sedi una roadmap pratica per integrare Microsoft Entra ID (Azure AD) con le reti WiFi aziendali utilizzando RADIUS e 802.1X. Copre la decisione architetturale tra Windows NPS on-premise e RADIUS cloud-native, l'implementazione dell'autenticazione EAP-TLS basata su certificati tramite Microsoft Intune e le migliori pratiche operative per proteggere l'accesso wireless nei settori dell'ospitalità, del retail e pubblico. Per le organizzazioni che hanno già investito nell'ecosistema Microsoft 365 ed Entra ID, questa guida colma il divario tra la gestione delle identità in cloud e la sicurezza della rete fisica.

Leggi la guida →

Hai domande sulla tua configurazione specifica?

Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS | Purple