Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Resumo Executivo

Para ambientes corporativos — seja um setor dinâmico de Hospitalidade , uma operação de Varejo com várias unidades ou um campus corporativo moderno —, depender de chaves pré-compartilhadas ou de Captive Portals básicos para o WiFi da equipe é uma vulnerabilidade de segurança e um gargalo operacional. A arquitetura de rede moderna exige autenticação 802.1X usando EAP-TLS, garantindo que cada dispositivo seja verificado criptograficamente antes de acessar a rede.

No entanto, o desafio está na distribuição: como implantar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar sua equipe de suporte? O Microsoft Intune resolve isso por meio do gerenciamento automatizado do ciclo de vida dos certificados. Ao aproveitar os perfis de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), as equipes de TI podem enviar certificados raiz e de cliente confiáveis de forma silenciosa para os endpoints gerenciados.

Este guia fornece um modelo de arquitetura definitivo e uma estratégia de implementação passo a passo para a implantação de certificados WiFi do Intune. Exploraremos as diferenças críticas entre SCEP e PKCS, detalharemos a sequência exata de implantação necessária para o sucesso e descreveremos estratégias reais de mitigação de riscos para garantir que o seu Guest WiFi e as redes corporativas permaneçam seguros e eficientes.

Ouça o podcast complementar informativo:

Análise Técnica Detalhada: SCEP vs. PKCS

Ao projetar sua estratégia de implantação de certificados WiFi do Intune, a primeira decisão de arquitetura é selecionar o mecanismo de entrega de certificados. O Intune oferece suporte tanto para SCEP quanto para PKCS, mas eles operam de maneiras fundamentalmente diferentes.

SCEP (Simple Certificate Enrollment Protocol)

O SCEP é o padrão do setor para registro de dispositivos corporativos. Em um fluxo de trabalho SCEP, o serviço do Intune instrui o endpoint a gerar seu próprio par de chaves privada/pública. O dispositivo então cria uma Solicitação de Assinatura de Certificado (CSR) e a envia por meio de um servidor NDES (Network Device Enrollment Service) para a sua Autoridade Certificadora (CA). A CA assina a solicitação e retorna o certificado público para o dispositivo.

A vantagem crítica de segurança do SCEP é que a chave privada nunca sai do dispositivo. Ela é gerada localmente, armazenada no enclave seguro do dispositivo (como o TPM no Windows ou o Secure Enclave no iOS) e nunca é transmitida pela rede. Isso torna o SCEP a abordagem altamente recomendada para autenticação 802.1X.

PKCS (Public Key Cryptography Standards)

Por outro lado, com o PKCS, a Autoridade Certificadora gera as chaves pública e privada de forma centralizada. O Microsoft Intune Certificate Connector então exporta esse par de chaves com segurança e o envia para o dispositivo de destino.

Embora o PKCS elimine a necessidade de implantar e manter um servidor NDES — simplificando a infraestrutura —, ele introduz um risco teórico de segurança porque a chave privada é transmitida pela rede. O PKCS geralmente é mais adequado para casos de uso em que a custódia de chaves é necessária, como a criptografia de e-mail S/MIME, em vez de autenticação de rede.

Guia de Implementação: A Sequência de Implantação

A configuração bem-sucedida de um perfil de WiFi do Intune para 802.1X exige a adesão estrita a uma sequência de implantação específica. As dependências de perfil do Intune determinam que a relação de confiança deve ser estabelecida antes que a autenticação possa ser configurada.

Passo 1: Implantar o Perfil de Certificado Raiz Confiável

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora.

1. Exporte o certificado da sua CA Raiz (e quaisquer certificados de CA Intermediária) como arquivos .cer.
2. No centro de administração do Microsoft Endpoint Manager, navegue até Dispositivos > Perfis de configuração > Criar perfil.
3. Selecione a plataforma de destino (por exemplo, Windows 10 e posterior) e escolha o tipo de perfil Certificado confiável.
4. Faça o upload do arquivo .cer e implante este perfil nos seus grupos de dispositivos de destino.

Regra de Ouro: Sempre direcione para os mesmos grupos (sejam Usuários ou Dispositivos) em todos os perfis relacionados para evitar incompatibilidades de implantação.

Passo 2: Configurar o Perfil de Certificado SCEP

Assim que a relação de confiança for estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter seu certificado de cliente.

1. Crie um novo perfil de configuração e selecione Certificado SCEP.
2. Configure o Formato do nome do assunto. Para autenticação baseada em usuário, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo, use CN={{AAD_Device_ID}}.
3. Defina o Uso da chave como Assinatura digital e Criptografia de chave.
4. Em Uso estendido da chave, especifique Autenticação do Cliente (OID: 1.3.6.1.5.5.7.3.2).
5. Vincule este perfil ao perfil de certificado Raiz Confiável criado no Passo 1.
6. Forneça a URL externa do seu servidor NDES.

Passo 3: Implantar o Perfil de WiFi 802.1X

A etapa final é enviar a configuração de WiFi que vincula os certificados ao SSID da rede.

1. Crie um perfil de configuração de Wi-Fi.
2. Insira o Nome da rede (SSID) exatamente como ele é transmitido pelos seus Pontos de Acesso Sem Fio .
3. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança.
4. Defina o Tipo de EAP como EAP-TLS.5. Nas configurações de autenticação, selecione o perfil de certificado SCEP criado na Etapa 2 como o certificado de autenticação do cliente.
5. Especifique o certificado Trusted Root para validação do servidor para garantir que o dispositivo se conecte apenas ao seu servidor RADIUS legítimo.

Melhores Práticas e Padrões do Setor

Ao implementar a implantação de certificado WiFi do Intune, siga as seguintes melhores práticas neutras de fornecedor para garantir a conformidade e a confiabilidade.

Implantação e Segurança do Servidor NDES

O servidor NDES deve estar acessível a partir da internet para permitir que dispositivos remotos provisionem certificados antes de chegarem ao local. No entanto, expor um servidor interno diretamente à internet é um risco de segurança significativo.

Recomendação: Publique a URL do NDES usando o Azure AD Application Proxy. Isso fornece acesso remoto seguro sem abrir portas de firewall de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registro.

Verificação de RADIUS e CRL

A implantação de certificados é apenas metade da equação de segurança; a revogação é igualmente crítica. Se um funcionário for desligado, desativar sua conta do Active Directory pode não revogar imediatamente seu acesso ao WiFi se o certificado do cliente continuar válido e o servidor RADIUS não estiver verificando rigorosamente a Lista de Revogação de Certificados (CRL).

Recomendação: Configure seu Network Policy Server (NPS) ou servidor RADIUS para impor uma verificação rigorosa de CRL. Garanta que seus Pontos de Distribuição de CRL (CDPs) estejam altamente disponíveis; se o servidor RADIUS não conseguir acessar a CRL, a autenticação falhará, causando uma interrupção generalizada.

Para obter mais informações sobre design de rede seguro, considere revisar The Core SD WAN Benefits for Modern Businesses .

Solução de Problemas e Mitigação de Riscos

Mesmo com um planejamento meticuloso, a implantação de certificados pode encontrar problemas. Aqui estão os modos de falha comuns e as estratégias de mitigação.

Problema: Falha ao Aplicar o Perfil de WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi aparece como 'Erro' ou 'Não Aplicável' no Intune.

Causa Raiz: Isso quase sempre é causado por uma incompatibilidade no direcionamento de grupos. Se o perfil SCEP for atribuído a um Grupo de Usuários, mas o perfil de WiFi for atribuído a um Grupo de Dispositivos, o Intune não conseguirá resolver a dependência.

Mitigação: Audite suas atribuições. Garanta que os perfis Trusted Root, SCEP e WiFi sejam todos implantados exatamente no mesmo grupo do Azure AD.

Problema: Erros NDES 403 Forbidden

Sintoma: Os dispositivos não conseguem recuperar o certificado SCEP e os logs do IIS do NDES mostram erros HTTP 403.

Causa Raiz: A conta de serviço do Intune Certificate Connector não possui as permissões necessárias no modelo de certificado, ou a filtragem de URL no seu firewall está bloqueando os parâmetros específicos da query string usados pelo SCEP.

Mitigação: Verifique se a conta do conector possui permissões de 'Leitura' e 'Inscrição' no modelo de CA. Verifique os logs do firewall para garantir que as URLs contendo ?operation=GetCACaps não estejam sendo bloqueadas.

ROI e Impacto nos Negócios

A transição para a implantação de certificados Microsoft Intune 802.1X oferece retornos mensuráveis em segurança e operações.

1. Redução de Chamados no Suporte: O WiFi baseado em senha gera um volume significativo de chamados de suporte (expiração de senhas, bloqueios, erros de digitação). A autenticação baseada em certificado é invisível para o usuário, reduzindo normalmente o volume de chamados relacionados ao WiFi em 70-80%.
2. Postura de Segurança Aprimorada: O EAP-TLS elimina o risco de roubo de credenciais e ataques Man-in-the-Middle (MitM). Isso é fundamental para a conformidade com frameworks como PCI DSS e GDPR, particularmente em ambientes de Saúde e varejo.
3. Integração Simplificada: Para organizações que gerenciam grandes frotas de dispositivos Apple junto com o Windows, a integração do Intune com os fluxos de trabalho de MDM existentes (consulte nosso guia sobre Jamf e RADIUS: Autenticação WiFi Baseada em Certificado para Frotas de Dispositivos Apple ) garante uma experiência de provisionamento unificada e sem toque desde o primeiro dia.