如何配置 SCEP 以实现自动化企业级 WiFi 证书注册
本指南详细介绍了如何配置 SCEP（简单证书注册协议）以实现自动化企业级 WiFi 证书注册，涵盖了从 PKI 和 NDES 到 MDM 配置文件部署以及 RADIUS 验证的完整架构。本指南面向酒店、零售连锁、体育场馆、会议中心和公共部门组织的 IT 经理、网络架构师和 CTO，旨在帮助他们摆脱预共享密钥，实施可扩展的、基于身份的 802.1X EAP-TLS 认证。Purple 的硬件无关型云覆盖平台可与该架构直接集成，为您提供与证书认证的员工网络并行的访客和 BYOD WiFi 层。
收听本指南
查看播客转录
Resumo executivo
Para espaços empresariais - quer se trate de um hotel de 200 quartos, de uma cadeia de retalho com 50 localizações ou de um grande centro de conferências - depender de chaves pré-partilhadas para o WiFi dos funcionários é um risco de segurança e um estrangulamento operacional. Uma única palavra-passe divulgada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova a sua identidade de forma criptográfica antes de o ponto de acesso lhe conceder acesso à rede.
O desafio reside na distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve este problema. Automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos geridos através da sua plataforma MDM - sem qualquer interação do utilizador.
Este guia abrange toda a arquitetura: o que o SCEP faz, como se integra com o Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implementação que a maioria das equipas erra e as armadilhas operacionais que causam interrupções de serviço. Também abordamos dois cenários reais de implementação em hotelaria e retalho, e explicamos onde a plataforma de Guest WiFi da Purple se enquadra ao lado da sua rede de funcionários autenticada por certificado.
Ouça o podcast informativo complementar:
Análise técnica detalhada: SCEP, PKI e 802.1X
O que o SCEP realmente faz
O SCEP não substitui a sua Public Key Infrastructure (PKI). É a camada de registo automatizada que se posiciona sobre ela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificados.
No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente como o servidor RADIUS apresentem certificados X.509 válidos. Nenhuma das partes confia na outra sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.
Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre WiFi Certificate Authentication: Secure Network Access .
O fluxo de registo SCEP, passo a passo
A cadeia de registo completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.
O dispositivo gera o seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo cria então um Certificate Signing Request (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.
A partir desse momento, quando o dispositivo se liga ao seu SSID de WiFi, apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à sua cadeia de confiança da CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.
SCEP vs. PKCS: qual utilizar para WiFi
As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetónica é significativa.
Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.
O PKCS é adequado para casos de utilização em que a custódia de chaves é necessária, como a encriptação de e-mail S/MIME. Para a autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.
| Propriedade | SCEP | PKCS |
|---|---|---|
| Geração de chave privada | No dispositivo (TPM/Secure Enclave) | Centralizada (CA) |
| Transmissão de chave privada | Nunca | Através da rede |
| Servidor NDES necessário | Sim (ou gateway na nuvem) | Não |
| Recomendado para WiFi | Sim | Não |
| Recomendado para S/MIME | Não | Sim |
Compatibilidade de hardware
O SCEP e o EAP-TLS são normas independentes de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - quer seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.
A atribuição dinâmica de VLAN é a forma como segmenta a rede através da identidade do dispositivo. Um dispositivo de um funcionário recebe a VLAN 10 com acesso a sistemas internos. O dispositivo de um prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isto é gerido por atributos de certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo.
Para saber mais sobre como o WiFi Analytics se integra com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.
Guia de implementação: a sequência de implementação
A configuração bem-sucedida do SCEP para WiFi empresarial exige a adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faça referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação desta sequência é a causa mais comum de falhas na implementação.
A sequência é: primeiro a Raiz de Confiança (Trusted Root), segundo o perfil SCEP, terceiro o perfil WiFi. Esta ordem não é negociável.
Passo 1: implementar o perfil de Certificado de Raiz de Confiança (Trusted Root)
Antes de qualquer dispositivo poder solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado de CA Raiz - e quaisquer certificados de CA Intermédia - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança, carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.
Se tiver uma hierarquia PKI de dois níveis (recomendado), precisa de implementar tanto o certificado da CA raiz como o da CA emissora como perfis de Certificado de Confiança separados, ou como uma cadeia num único perfil, dependendo da sua plataforma MDM.
Passo 2: configurar o perfil de Certificado SCEP
Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o seu certificado de cliente.
Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do Nome do Requerente (Subject name). Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos partilhados, IoT, terminais POS), utilize CN={{AAD_Device_ID}}. Defina a Utilização da chave (Key usage) para Assinatura digital e Cifragem de chave. Defina a Utilização de Chave Alargada (Extended Key Usage) para Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado de Raiz de Confiança criado no Passo 1. Forneça o URL externo do seu servidor NDES.Para o Microsoft Intune especificamente, o servidor NDES deve ser publicado através do Azure AD Application Proxy para permitir que os dispositivos remotos se registem antes de chegarem ao local. Não exponha o NDES diretamente à internet.
Passo 3: implementar o perfil de WiFi 802.1X
O passo final é enviar a configuração de WiFi que associa os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Introduza o Nome da rede (SSID) exatamente como é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP para EAP-TLS. Nas definições de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado Trusted Root para validação do servidor - isto garante que o dispositivo apenas se liga ao seu servidor RADIUS legítimo e não a um ponto de acesso não autorizado.
Integração do fornecedor de identidade
Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM remove o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-partilhadas não conseguem igualar.
Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access , incluindo caminhos de migração PEAP-MSCHAPv2, consulte o nosso guia dedicado.
Boas práticas e padrões da indústria
Posicionamento do servidor NDES
O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de firewall de entrada e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Nunca exponha o NDES diretamente à internet.
Para redes com mais de 500 dispositivos geridos, considere um gateway SCEP na nuvem em vez de um NDES local. Os gateways na nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na nuvem.
Disponibilidade da CRL
O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está em baixo ou o URL mudou - a autenticação falha para todos os dispositivos na rede em simultâneo. Configure o seu servidor NPS ou RADIUS para impor uma verificação rigorosa da CRL e torne os seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.
O Requisito 8.6 do PCI DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retail e Hospitality .
Compatibilidade com WPA3
O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suite de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se está a implementar em ambientes de Saúde ou Transportes com requisitos de conformidade rigorosos, o WPA3-Enterprise com EAP-TLS é a arquitetura-alvo correta.
BYOD e WiFi de convidados
O SCEP requer a inscrição no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não geridos ou convidados. Para esses casos de utilização, necessita de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.
Resolução de problemas e mitigação de riscos
Falha na aplicação do perfil de WiFi
Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi é apresentado como Erro ou Não Aplicável no MDM.
Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP se destinar a um grupo de Utilizadores e o perfil de WiFi se destinar a um grupo de Dispositivos, o MDM não consegue resolver a dependência.
Solução: Audite as suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi se destinam todos exatamente ao mesmo grupo de diretório.
Erros NDES 403 Forbidden
Sintoma: Os dispositivos não conseguem obter o certificado SCEP. Os registos do IIS do NDES mostram erros HTTP 403.
Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, ou a filtragem de URLs da firewall está a bloquear os parâmetros de query string do SCEP.
Solução: Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo da CA. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão bloqueados.
Falha de autenticação em massa após expiração da CRL
Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo.
Causa raiz: A CRL expirou ou o URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha por omissão (fails closed).
Solução: Configure a monitorização e alertas de CRL. Publique as CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento.
Expiração de certificado a causar falhas silenciosas
Sintoma: Dispositivos individuais falham a ligação de forma intermitente, sem um padrão claro.
Causa raiz: Os certificados de cliente expiraram e o MDM não os renovou com sucesso.
Solução: Configure a renovação do certificado para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de estado de inscrição do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos.
ROI e impacto empresarial
A transição para a autenticação por certificado 802.1X baseada em SCEP proporciona retornos mensuráveis em termos de segurança, operações e conformidade.
Redução de pedidos de suporte: O WiFi baseado em palavra-passe gera um volume significativo de pedidos de suporte - expiração de palavras-passe, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o utilizador. As organizações registam tipicamente uma redução de 70-80% no volume de suporte relacionado com WiFi após a migração.
Postura de segurança: O EAP-TLS elimina a recolha de credenciais e os ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI DSS 4.0 para redes de retalho e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.
Revogação automatizada: Quando um colaborador sai da empresa, a desativação da sua conta no Microsoft Entra ID aciona a revogação automática do certificado e a desassociação do MDM. O acesso ao WiFi é cortado sem qualquer intervenção manual por parte da equipa de rede.
Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede aplicada de forma criptográfica. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou na filtragem de endereços MAC - ambas facilmente contornáveis.
A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A nossa sobreposição de nuvem agnóstica em termos de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet - para que a sua rede de colaboradores autenticada por certificado e a nossa camada de WiFi de convidados funcionem a partir da mesma infraestrutura.
Para saber mais sobre como a análise comportamental ( Behavioral Analytics: Insights for WiFi Networks ) pode complementar a sua implementação de rede segura, consulte o nosso guia de análise.
Referências
[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council
关键定义
SCEP (Simple Certificate Enrollment Protocol)
RFC 8894 中规范化的一种协议，允许托管设备通过 HTTP 自动向证书颁发机构请求并接收 X.509 数字证书，并使用共享质询密码进行初始身份验证。私钥在设备上生成，绝不进行传输。
Microsoft Intune 和 Jamf 等 MDM 平台用于大规模向托管终端部署 WiFi 身份验证证书的标准机制。
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
最安全的 802.1X 身份验证方法，要求客户端设备和 RADIUS 服务器均出示有效的 X.509 证书。双向身份验证意味着在没有密码学证明的情况下，双方互不信任。
企业级 WiFi 的目标身份验证协议。PCI DSS 4.0、WPA3-Enterprise 192-bit (Suite B) 以及 HIPAA 针对处理敏感数据的无线网络强制要求或强烈推荐该协议。
NDES (Network Device Enrollment Service)
一个 Microsoft Windows Server 角色，在支持 SCEP 的设备与证书颁发机构之间充当注册机构 (RA)。它负责验证质询密码，并代表缺乏域凭据的设备向证书颁发机构转发 CSR。
使用 Microsoft Intune 进行 SCEP 部署所需的必要基础设施。应通过 Azure AD Application Proxy 发布，而不是直接暴露给互联网。
PKI (Public Key Infrastructure)
用于颁发、管理和吊销数字证书的证书颁发机构、策略和流程的层级结构。双层 PKI 由一个离线根证书颁发机构（主信任锚点）和一个在线发证证书颁发机构（处理日常证书颁发）组成。
部署 EAP-TLS 和 SCEP 的不可逾越的前提条件。根证书颁发机构应保持物理隔离（air-gapped）；其私钥是您整个证书信任链的基石。
CSR (Certificate Signing Request)
由设备生成的包含其公钥和身份信息的消息，发送给证书颁发机构以请求签名的数字证书。在 SCEP 中，CSR 在设备端生成，并在传输前封装在 PKCS 包中。
在 SCEP 注册流程中由设备自动生成。用于对 CSR 进行签名的私钥绝不会离开设备。
CRL (Certificate Revocation List)
由证书颁发机构发布的列表，其中包含在过期前已被吊销的证书的序列号。RADIUS 服务器在每次身份验证尝试时都会检查 CRL，以确保被吊销的证书无法访问网络。
CRL 分发点 (CDP) 的可用性至关重要。如果 RADIUS 服务器无法访问 CRL，它将采取“故障关闭”策略并拒绝所有身份验证，从而导致全网中断。
RADIUS (Remote Authentication Dial-In User Service)
一种网络协议，为网络访问提供集中式的认证、授权和计费 (AAA)。在 802.1X WiFi 中，RADIUS 服务器验证客户端证书，检查 CRL，并向接入点返回 Access-Accept 或 Access-Reject 消息。
802.1X 申请者-验证者-服务器模型中的身份验证服务器。常见实现包括 Windows NPS、FreeRADIUS 和云 RADIUS 服务。
Dynamic VLAN assignment
一种 RADIUS 功能，可根据证书属性或目录组数员身份将已验证的设备分配到特定的 VLAN，而不是依赖 SSID 选择或 MAC 地址过滤。通过设备身份强制执行网络细分。
允许单个 SSID 为具有不同网络访问权限的多种设备类型提供服务。员工设备分配到 VLAN 10（内部访问）；承包商设备分配到 VLAN 20（仅限互联网）；POS 终端分配到 VLAN 30（仅限支付系统）。
MDM (Mobile Device Management)
IT 团队用于注册、配置、保护和管理智能手机、平板电脑和笔记本电脑的软件。Microsoft Intune 和 Jamf 等 MDM 平台使用 SCEP 配置文件，在无需用户交互的情况下向托管设备推送证书注册指令。
基于 SCEP 的证书部署的前提条件。设备必须先在 MDM 中注册，然后才能接收 SCEP 和 WiFi 配置文件。未托管的 BYOD 设备需要采用单独的接入引导方案。
应用实例
一家拥有 200 间客房的 Premier Inn 酒店需要为其用于销售点（POS）平板电脑和客房部智能手机的员工 WiFi 提供安全保障。他们目前使用的是已泄露给承包商的预共享密钥（PSK）。他们通过 Microsoft Intune 管理设备，且设备混合了 iOS 和 Android 系统。该酒店使用的是 HPE Aruba 接入点。
- 部署内部 Microsoft AD CS 双层 PKI。在专用 Windows Server 上配置 NDES，并通过 Azure AD Application Proxy 将其发布。
- 在 Intune 中，创建一个包含根 CA 和颁发 CA 证书的“受信任的根证书”配置文件。部署到“Property Staff Devices” Azure AD 组。
- 在 Intune 中创建一个指向 NDES 外部 URL 的 SCEP 证书配置文件。由于这些是共享设备，将“使用者名称”格式设置为 CN={{AAD_Device_ID}}。将“密钥用法”设置为“数字签名”和“密钥加密”，将“扩展密钥用法”设置为“客户端身份验证”。部署到“Property Staff Devices”。
- 为员工 SSID 创建一个 Wi-Fi 配置文件，配置 WPA2-Enterprise 和 EAP-TLS。选择 SCEP 配置文件进行客户端身份验证，并选择根 CA 进行服务器验证。部署到“Property Staff Devices”。
- 配置 HPE Aruba RADIUS 设置以指向 Windows NPS。在 NPS 上，配置一个要求 EAP-TLS 并为员工设备分配 VLAN 10 的网络策略。
- 一旦设备接收到配置文件并成功连接，在旧的 SSID 上轮换 PSK 并安排其停用。
一家拥有 50 个门店的零售连锁店希望在所有站点为其企业笔记本电脑部署 802.1X。他们使用 Cisco Meraki 接入点和 Microsoft Intune。他们不想在每个门店或其数据中心部署和维护本地 NDES 服务器或 AD CS 基础设施。
- 实施基于云的 PKI 和 SCEP 网关服务，该服务通过 SCEP 协议与 Intune 集成。云 CA 负责颁发证书；云 SCEP 网关负责处理 CSR 验证。
- 在 Cisco Meraki 控制面板的“无线 > 访问控制”下，针对企业 SSID 配置云 RADIUS 服务（由 PKI 供应商提供）。将安全性设置为 WPA2-Enterprise，并将 RADIUS 指向该云服务。
- 在 Intune 中，创建一个包含云 CA 根证书的“受信任的根证书”配置文件。部署到“Corporate Laptops”设备组。
- 创建一个指向云 SCEP 网关 URL 的 SCEP 证书配置文件。将“使用者名称”设置为 CN={{UserPrincipalName}} 以进行基于用户的身份验证。部署到“Corporate Laptops”。
- 为企业 SSID 创建一个带有 EAP-TLS 的 Wi-Fi 配置文件，引用 SCEP 配置文件和云 CA 根证书。部署到“Corporate Laptops”。
- 当笔记本电脑注册到 Intune 时，它们会自动通过云 SCEP 网关向云 CA 请求证书。这 50 个门店中的任何一个都不需要本地基础设施。
练习题
Q1. 您的组织正在从 PEAP-MSCHAPv2 迁移到 EAP-TLS。您已成功将 Trusted Root 和 SCEP 配置文件部署到 Intune 中的“Corporate Users” Azure AD 组。您将 WiFi 配置文件部署到“All Corporate Devices”。用户报告他们无法连接，且 WiFi 配置文件显示为“不适用”。
提示：检查配置文件依赖关系和组目标规则。Intune 会根据分配的组来解析配置文件依赖关系。
查看标准答案
问题在于组目标不匹配。WiFi 配置文件依赖于 SCEP 配置文件，而后者针对的是用户组（“Corporate Users”）。WiFi 配置文件针对的是设备组（“All Corporate Devices”）。Intune 无法跨组类型解析依赖关系。解决方法是将所有这三个配置文件分配（Trusted Root、SCEP 和 WiFi）更改为针对同一个组。根据您的身份验证模型（基于用户还是基于设备）决定是使用用户组还是设备组，并在所有三个配置文件中一致地应用该组。
Q2. 安全审计发现，当员工离职且其 Microsoft Entra ID 账户被禁用时，其公司智能手机在离职后长达一周的时间内仍能连接到员工 WiFi 网络。
提示：考虑 RADIUS 服务器在账户被禁用后如何确定证书是否仍然有效。传达吊销状态的机制是什么？
查看标准答案
RADIUS 服务器未执行严格的证书吊销列表（CRL）检查，或者 CRL 的发布频率较低。当员工离职时，MDM 应该注销设备，且 CA 应该吊销证书。但是，如果 RADIUS 服务器在每次身份验证尝试时不检查 CRL，或者如果 CRL 仅每周发布一次，则被吊销的证书将继续被接受。解决方法包括三个步骤：配置 RADIUS 服务器在每次身份验证时强制执行严格的 CRL 检查；配置 CA 以更短的间隔（每天或更频繁）发布 CRL；并确保 MDM 配置为在设备注销时触发证书吊销。
Q3. 您需要为无法运行 MDM 代理且无法显示 Captive Portal 的无头 IoT 设备（智能温控器、数字标牌播放器）提供安全的 WiFi 访问。您能对这些设备使用 SCEP 吗？如果不能，推荐的替代方案是什么？
提示：考虑 SCEP 注册的前提条件，以及对于无法进行 MDM 注册或无法与浏览器交互的设备存在哪些替代方案。
查看标准答案
这些设备无法使用 SCEP。SCEP 需要 MDM 代理来接收注册 URL 和质询密码、生成密钥对并安装生成的证书。无法运行 MDM 代理的无头 IoT 设备无法参与 SCEP 注册流程。推荐的替代方案是：（1）MAC 身份验证绕过（MAB）结合严格的 VLAN 隔离——RADIUS 服务器根据设备的 MAC 地址允许其接入，并将其置于无法访问公司系统的隔离 IoT VLAN 中；（2）如果设备支持，EST（基于安全传输的注册，RFC 7030）可以为支持 HTTPS 但不支持 MDM 的设备配置证书；（3）对于具有管理界面的设备，一些厂商支持直接通过设备固件进行 SCEP 注册，而无需 MDM 代理。在所有情况下，无论使用何种身份验证方法，IoT 设备都应隔离在专用的 VLAN 上。
继续阅读本系列
如何安全隔离员工和访客 WiFi 网络
本权威技术指南为 IT 负责人提供了使用 VLAN 和 802.1X 安全隔离员工、访客和 IoT WiFi 网络的实用策略。它详细介绍了如何保护企业基础设施、维持 PCI DSS 合规性，以及利用 captive portals 收集第一方数据。
最佳 DNS filtering：面向企业用户的全面指南
本技术参考指南阐述了企业级 DNS filtering 如何通过在解析层（即在建立连接之前）拦截恶意域名来保障公共网络的安全。它为 IT 总监、网络架构师和场所运营团队提供了在酒店、零售和公共部门环境中保护宾客 WiFi 所需的部署架构、防火墙配置以及合规性背景信息。Purple Shield 在 DNS 级别为超过 80,000 个实时场所拦截恶意软件、僵尸网络和不当内容。
SCEP 企业指南：部署简单证书注册协议以实现自动化校园 WiFi 安全
本技术参考指南为使用 SCEP 进行企业 WiFi 证书部署提供了权威的架构蓝图和逐步实施策略。它涵盖了 SCEP 与 PKCS 之间的关键区别、成功部署所需的精确顺序，以及 IT 领导者的实际风险缓解策略。