Pular para o conteúdo principal

Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Este guia fornece uma referência técnica passo a passo para implantar certificados de autenticação WiFi via Microsoft Intune usando SCEP e PKCS. Ele foi projetado para gerentes de TI e arquitetos de rede que implementam WiFi 802.1X sem senha para garantir uma conectividade contínua e segura em ambientes corporativos.

By Iain JewittPublished
📖 6 min de leitura1,231 palavras2 exemplos práticos3 questões práticas8 definições principais

Parte da nossa série principal: 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

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.

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

Definições principais

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo que permite que os dispositivos solicitem certificados digitais de uma Autoridade Certificadora, onde a chave privada é gerada e armazenada de forma segura no próprio dispositivo.

O método recomendado para implantar certificados de autenticação WiFi devido à sua alta segurança e escalabilidade.

PKCS (Public Key Cryptography Standards)

Um conjunto de padrões onde as chaves pública e privada são geradas pela Autoridade Certificadora e, em seguida, entregues com segurança ao dispositivo final.

Frequentemente usado para criptografia de e-mail S/MIME, mas menos ideal para WiFi devido à transmissão da chave privada pela rede.

NDES (Network Device Enrollment Service)

Uma função do Microsoft Windows Server que atua como uma ponte, permitindo que dispositivos sem credenciais de domínio obtenham certificados via SCEP.

Um componente de infraestrutura obrigatório ao implementar a implantação de certificados SCEP com o Microsoft Intune.

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

O método de autenticação 802.1X mais seguro, que exige que tanto o servidor quanto o cliente apresentem certificados digitais válidos.

O protocolo de autenticação de destino que os perfis de WiFi e de certificado do Intune foram projetados para habilitar.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade Certificadora contendo os números de série dos certificados que foram revogados antes da sua data de expiração.

Crítico para a segurança; os servidores RADIUS devem verificar a CRL para garantir que funcionários desligados não consigam acessar o WiFi usando um certificado que, de outra forma, seria válido.

Intune Certificate Connector

Um agente de software instalado em um Windows Server local que intermedia as solicitações entre o Microsoft Intune e a Autoridade Certificadora interna.

Necessário para implantações SCEP (para validar solicitações) e PKCS (para exportar chaves).

Subject Alternative Name (SAN)

Uma extensão para um certificado digital que permite que múltiplos valores (como UPN, e-mail ou endereço MAC) sejam associados ao certificado.

Configurado no perfil SCEP do Intune para garantir que o servidor RADIUS possa identificar com precisão o usuário ou dispositivo.

Azure AD Application Proxy

Um recurso que fornece acesso remoto seguro a aplicativos web locais sem a necessidade de uma VPN ou de abrir portas de entrada no firewall.

O método de melhor prática para publicar com segurança a URL do servidor NDES interno na internet para registro de dispositivos remotos.

Exemplos práticos

Uma rede nacional de varejo com 500 locais está migrando de WPA2-Personal (Pre-Shared Key) para WPA3-Enterprise em seus tablets de associados de loja (Android Enterprise Dedicated Devices). Eles usam o Intune para MDM. Como eles devem arquitetar a implantação de certificados?

  1. Implante um servidor NDES publicado via Azure AD App Proxy.
  2. Crie um perfil de certificado SCEP baseado em dispositivo no Intune, pois estes são dispositivos dedicados (quiosque) não vinculados a um usuário específico. Use CN={{AAD_Device_ID}} para o Subject Name.
  3. Implante o perfil de CA Raiz para o Grupo de Dispositivos do Azure AD 'All Store Tablets'.
  4. Implante o perfil SCEP para o mesmo grupo 'All Store Tablets'.
  5. Crie um perfil de WiFi configurado para WPA3-Enterprise, EAP-TLS, referenciando o perfil SCEP, e implante-o no mesmo grupo.
  6. Configure os servidores RADIUS centrais para autenticar os certificados de dispositivo em relação aos objetos de computador do Active Directory.
Comentário do examinador: Esta abordagem identifica corretamente que dispositivos dedicados exigem certificados baseados em dispositivo (não baseados em usuário). Ao direcionar os Grupos de Dispositivos de forma consistente em todos os três perfis, o arquiteto evita a falha de implantação mais comum do Intune. O uso do Azure AD App Proxy para NDES garante que os tablets possam renovar certificados de forma segura sem a necessidade de VPNs.

Um grande centro de conferências usa a Purple para seu [WiFi Analytics](/products/wifi-analytics) e Guest WiFi, mas precisa proteger sua rede interna de funcionários. A equipe usa uma mistura de laptops Windows de propriedade da empresa e dispositivos iOS BYOD. Como eles lidam com a implantação do Intune para os dispositivos BYOD?

  1. Exija que os usuários de BYOD registrem seus dispositivos iOS via Intune User Enrollment (criando uma partição de trabalho segura).
  2. Crie um perfil de certificado SCEP baseado em usuário usando CN={{UserPrincipalName}}.
  3. Implante os perfis de CA Raiz, SCEP e WiFi para um Grupo de Usuários do Azure AD (por exemplo, 'All Staff').
  4. Quando o usuário registra seu dispositivo pessoal, o Intune envia os perfis especificamente para a partição de trabalho gerenciada.
  5. O dispositivo se conecta ao SSID da equipe usando a identidade do usuário, permitindo que o servidor RADIUS aplique o controle de acesso baseado em função (atribuição de VLAN) com base em sua associação ao grupo do AD.
Comentário do examinador: Esta solução aplica corretamente o User Enrollment para o gerenciamento de BYOD que preserva a privacidade. Ao direcionar Grupos de Usuários, os certificados acompanham o funcionário independentemente de qual dispositivo ele registre. A integração do controle de acesso baseado em função via RADIUS demonstra um design de rede avançado.

Questões práticas

Q1. Você implantou os perfis de Root CA, SCEP e WiFi em seus dispositivos Windows 10. Os certificados são instalados com sucesso, mas o perfil de WiFi falha ao ser aplicado, exibindo 'Erro' no console do Intune. Qual é a causa mais provável?

Dica: Verifique como os perfis estão atribuídos aos grupos do Azure AD.

Ver resposta modelo

A causa mais provável é uma incompatibilidade no direcionamento de grupo. Se o perfil SCEP foi atribuído a um Grupo de Usuários, mas o perfil de WiFi foi atribuído a um Grupo de Dispositivos, o Intune não consegue resolver a dependência entre eles. Todos os três perfis (Root, SCEP, WiFi) devem ser direcionados exatamente ao mesmo tipo de grupo.

Q2. Sua equipe de segurança exige que as chaves privadas nunca sejam transmitidas pela rede, mesmo que criptografadas. Qual método de implantação de certificado você deve usar no Intune e qual servidor de infraestrutura adicional é necessário?

Dica: Pense em onde o par de chaves é gerado.

Ver resposta modelo

Você deve usar SCEP (Simple Certificate Enrollment Protocol). Como o SCEP instrui o dispositivo final a gerar a chave privada localmente, ela nunca trafega pela rede. Essa implantação requer um servidor Network Device Enrollment Service (NDES) para atuar como uma ponte para a Autoridade de Certificação.

Q3. Um funcionário remoto provisiona um novo laptop em casa via Windows Autopilot. Os perfis do Intune são implantados com sucesso, mas o dispositivo falha ao obter o certificado SCEP. Qual configuração de infraestrutura provavelmente está faltando?

Dica: Como o dispositivo alcança a CA interna a partir da internet?

Ver resposta modelo

O servidor NDES provavelmente não foi publicado para a internet. Para que dispositivos remotos solicitem certificados antes de chegarem ao escritório corporativo, a URL do NDES deve estar acessível externamente, idealmente publicada de forma segura via Azure AD Application Proxy.

Continue a ler esta série

Sophos Firewall e guest WiFi: configuração do Captive Portal com Purple

Como o guest WiFi em nuvem da Purple funciona com o Sophos Firewall e seus pontos de acesso por meio de um Captive Portal externo padrão e RADIUS, e onde verificar o suporte e encontrar as etapas.

Ler o guia →

Aruba Central e Purple WiFi: Integração Gerenciada em Nuvem

Um guia de referência técnica abrangente para integrar o Aruba Central com a plataforma de inteligência de WiFi de visitantes hospedada em nuvem da Purple. Este guia cobre arquitetura, configuração passo a passo de Captive Portals externos e RADIUS, e estratégias de implantação multi-site para equipes de TI empresariais.

Ler o guia →

Azure AD and Entra ID WiFi Authentication: Integration and Configuration Guide

Este guia de referência técnica fornece a gerentes de TI, arquitetos de rede e diretores de operações de locais um roteiro prático para integrar o Microsoft Entra ID (Azure AD) com redes WiFi corporativas usando RADIUS e 802.1X. Ele aborda a decisão arquitetônica entre o Windows NPS local e o RADIUS nativo em nuvem, a implantação de autenticação EAP-TLS baseada em certificado via Microsoft Intune e as melhores práticas operacionais para proteger o acesso sem fio em ambientes de hotelaria, varejo e setor público. Para organizações que já investem no ecossistema Microsoft 365 e Entra ID, este guia preenche a lacuna entre o gerenciamento de identidade em nuvem e a segurança da rede física.

Ler o guia →

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.