跳至主要內容

透過 SCEP 與 PKCS 進行 Microsoft Intune WiFi 憑證部署

本指南提供逐步技術參考,說明如何透過 Microsoft Intune 使用 SCEP 和 PKCS 部署 WiFi 驗證憑證。它專為實作無密碼 802.1X WiFi 的 IT 經理和網路架構師所設計,以確保跨企業環境的無縫、安全連線。

By Iain JewittPublished
📖 6 分鐘閱讀1,231 字數2 範例3 練習題8 關鍵定義

核心系列的一部分:Enterprise WiFi Security Guide

透過 SCEP 與 PKCS 進行 Microsoft Intune WiFi 憑證部署

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.

透過 SCEP 與 PKCS 進行 Microsoft Intune WiFi 憑證部署 - 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.

透過 SCEP 與 PKCS 進行 Microsoft Intune WiFi 憑證部署 - architecture overview

對於您的特定設置有任何疑問嗎?

我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。

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).

關鍵定義

SCEP (Simple Certificate Enrollment Protocol)

一種通訊協定,允許裝置向憑證授權單位要求數位憑證,其中私密金鑰在裝置本身上安全地產生並儲存。

由於其高安全性和可擴展性,用於部署 WiFi 驗證憑證的建議方法。

PKCS (Public Key Cryptography Standards)

一套標準,其中公開和私密金鑰由憑證授權單位產生,然後安全地傳遞至端點。

通常用於 S/MIME 電子郵件加密,但由於私密金鑰需要透過網路傳輸,因此對於 WiFi 來說較不理想。

NDES (Network Device Enrollment Service)

一個 Microsoft Windows Server 角色,可作為橋樑,允許沒有網域認證的裝置透過 SCEP 取得憑證。

使用 Microsoft Intune 實作 SCEP 憑證部署時所需的基礎架構元件。

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

最安全的 802.1X 驗證方法,需要伺服器和用戶端都出示有效的數位憑證。

Intune WiFi 和憑證設定檔旨在啟用的目標驗證通訊協定。

CRL (Certificate Revocation List)

由憑證授權單位發佈的清單,包含在到期日前已被撤銷的憑證序號。

對安全性至關重要;RADIUS 伺服器必須檢查 CRL,以確保已離職的員工無法使用原本有效的憑證存取 WiFi。

Intune Certificate Connector

一個安裝在內部部署 Windows Server 上的軟體代理程式,可作為 Microsoft Intune 與內部憑證授權單位之間的要求中介。

SCEP (用於驗證要求) 和 PKCS (用於匯出金鑰) 部署都所需的。

Subject Alternative Name (SAN)

數位憑證的一項擴充功能,允許將多個值 (例如 UPN、電子郵件或 MAC 位址) 與該憑證相關聯。

在 Intune SCEP 設定檔中設定,以確保 RADIUS 伺服器能夠準確識別使用者或裝置。

Azure AD Application Proxy

一項功能,可提供對內部部署 Web 應用程式的安全遠端存取,而無需 VPN 或開啟入埠防火牆連接埠。

用於將內部 NDES 伺服器 URL 安全地發佈到網際網路以供遠端裝置註冊的最佳做法方法。

範例

一家擁有 500 個據點的全國性零售連鎖店,正在將其店員平板電腦(Android Enterprise 專用裝置)從 WPA2-Personal(預先共用金鑰)遷移至 WPA3-Enterprise。他們使用 Intune 進行 MDM。他們應如何架構憑證部署?

  1. 部署透過 Azure AD App Proxy 發佈的 NDES 伺服器。
  2. 在 Intune 中建立基於裝置的 SCEP 憑證設定檔,因為這些是專用(資訊站)裝置,不與特定使用者繫結。使用 CN={{AAD_Device_ID}} 作為主體名稱。
  3. 將根 CA 設定檔部署至「所有店鋪平板電腦」Azure AD 裝置群組。
  4. 將 SCEP 設定檔部署至相同的「所有店鋪平板電腦」群組。
  5. 建立設定為 WPA3-EnterpriseEAP-TLS 的 WiFi 設定檔,參照 SCEP 設定檔,並將其部署至相同的群組。
  6. 設定中央 RADIUS 伺服器,以根據 Active Directory 電腦物件來驗證裝置憑證。
考官評語: 此方法正確地識別出專用裝置需要基於裝置(而非使用者)的憑證。透過在所有三個設定檔中一致地鎖定裝置群組,架構師避免了最常見的 Intune 部署失敗。對 NDES 使用 Azure AD App Proxy 可確保平板電腦能夠安全地更新憑證,無需 VPN。

一家大型會議中心使用 Purple 進行其 WiFi Analytics 和 Guest WiFi,但需要保護其內部員工網路。員工使用公司擁有的 Windows 筆記型電腦和 BYOD iOS 裝置的混合組合。他們如何處理 BYOD 裝置的 Intune 部署?

  1. 要求 BYOD 使用者透過 Intune 使用者註冊(建立安全的工作分割區)來註冊其 iOS 裝置。
  2. 使用 CN={{UserPrincipalName}} 建立基於使用者的 SCEP 憑證設定檔。
  3. 將根 CA、SCEP 和 WiFi 設定檔部署至 Azure AD 使用者群組(例如「全體員工」)。
  4. 當使用者註冊其個人裝置時,Intune 會專門將設定檔推送至受管理的工作分割區。
  5. 裝置使用使用者的身分連線至員工 SSID,從而允許 RADIUS 伺服器根據其 AD 群組成員資格套用基於角色的存取控制(VLAN 指派)。
考官評語: 此解決方案正確地套用了使用者註冊,以實現保護隱私的 BYOD 管理。透過鎖定使用者群組,憑證會跟隨員工,無論他們註冊哪個裝置。透過 RADIUS 整合基於角色的存取控制,展示了進階的網路設計。

練習題

Q1. 您已將根 CA、SCEP 和 WiFi 設定檔部署至您的 Windows 10 裝置。憑證安裝成功,但 WiFi 設定檔無法套用,在 Intune 主控台中顯示「錯誤」。最可能的原因是什麼?

提示:檢查設定檔如何指派給 Azure AD 群組。

查看標準答案

最可能的原因是群組目標不符。如果 SCEP 設定檔指派給使用者群組,但 WiFi 設定檔指派給裝置群組,Intune 就無法解析它們之間的相依性。三個設定檔 (根、SCEP、WiFi) 都必須鎖定完全相同的群組類型。

Q2. 您的安全團隊強制要求私密金鑰絕不能在網路上傳輸,即使是加密的也不行。您必須在 Intune 中使用哪種憑證部署方法,以及需要什麼額外的基礎架構伺服器?

提示:思考金鑰對是在哪裡產生的。

查看標準答案

您必須使用 SCEP (Simple Certificate Enrollment Protocol)。因為 SCEP 指示端點裝置在本地產生私密金鑰,因此它永遠不會在網路上傳輸。此部署需要網路裝置註冊服務 (NDES) 伺服器作為通往憑證授權單位的橋樑。

Q3. 一名遠端員工在家透過 Windows Autopilot 佈建了一台新筆記型電腦。Intune 設定檔成功部署,但裝置無法取得 SCEP 憑證。可能缺少哪項基礎架構設定?

提示:裝置如何從網際網路連線到內部 CA?

查看標準答案

NDES 伺服器很可能尚未發佈至網際網路。為了讓遠端裝置在抵達公司辦公室之前要求憑證,NDES URL 必須可從外部存取,理想情況下是透過 Azure AD Application Proxy 安全地發佈。

對於您的特定設置有任何疑問嗎?

我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。