Microsoft Intune WiFi Certificate Deployment via SCEP and PKCS

Resumo Executivo

Para espaços empresariais — quer se trate de um ambiente dinâmico de Hospitality , de uma operação de Retail com vários locais ou de um campus corporativo moderno — depender de chaves pré-partilhadas ou de Captive Portals básicos para o WiFi dos colaboradores é uma vulnerabilidade de segurança e um estrangulamento operacional. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS, garantindo que cada dispositivo é verificado criptograficamente antes de aceder à rede.

No entanto, o desafio reside na distribuição: como implementar certificados de cliente únicos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar a sua equipa de suporte com pedidos de assistência? O Microsoft Intune resolve isto através da gestão automatizada do ciclo de vida dos certificados. Ao tirar partido de perfis de certificado SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards), as equipas de TI podem enviar certificados raiz e de cliente fidedignos de forma silenciosa para os endpoints geridos.

Este guia fornece um modelo arquitetónico definitivo e uma estratégia de implementação passo a passo para a implementação de certificados WiFi no Intune. Iremos explorar as diferenças críticas entre SCEP e PKCS, detalhar a sequência exata de implementação necessária para o sucesso e delinear estratégias reais de mitigação de riscos para garantir que o seu Guest WiFi e as redes corporativas permanecem seguros e com elevado desempenho.

Ouça o podcast complementar informativo:

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

Ao desenhar a sua estratégia de implementação de certificados WiFi no Intune, a primeira decisão arquitetónica é selecionar o mecanismo de entrega de certificados. O Intune suporta tanto SCEP como PKCS, mas estes funcionam de forma fundamentalmente diferente.

SCEP (Simple Certificate Enrollment Protocol)

O SCEP é o padrão da indústria para o registo de dispositivos empresariais. Num fluxo de trabalho SCEP, o serviço Intune instrui o endpoint a gerar o seu próprio par de chaves privada/pública. O dispositivo cria então um Pedido de Assinatura de Certificado (CSR) e envia-o através de um servidor NDES (Network Device Enrollment Service) para a sua Autoridade de Certificação (CA). A CA assina o pedido e devolve o certificado público ao dispositivo.

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

PKCS (Public Key Cryptography Standards)

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

Embora o PKCS elimine a necessidade de implementar e manter um servidor NDES — simplificando a infraestrutura —, introduz um risco teórico de segurança porque a chave privada é transmitida através da rede. O PKCS é geralmente mais adequado para casos de utilização onde a custódia de chaves (key escrow) é necessária, como a encriptação de e-mail S/MIME, em vez de autenticação de rede.

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

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

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

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, deve confiar na Autoridade de Certificação emissora.

1. Exporte o seu certificado de CA Raiz (e quaisquer certificados de CA Intermédia) como ficheiros .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. Carregue o ficheiro .cer e implemente este perfil nos seus grupos de dispositivos de destino.

Regra de Ouro: Direcione sempre os mesmos grupos (Utilizadores ou Dispositivos) em todos os perfis relacionados para evitar falhas de correspondência na implementação.

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.

1. Crie um novo perfil de configuração e selecione Certificado SCEP.
2. Configure o Formato do nome do requerente. Para autenticação baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos, utilize CN={{AAD_Device_ID}}.
3. Defina a Utilização da chave para Assinatura digital e Cifragem de chaves.
4. Em Utilização de chave estendida, especifique Autenticação de Cliente (OID: 1.3.6.1.5.5.7.3.2).
5. Associe este perfil ao perfil de certificado de Raiz Confiável criado no Passo 1.
6. Forneça o URL externo do seu servidor NDES.

Passo 3: Implementar o Perfil WiFi 802.1X

O passo final é enviar a configuração WiFi que associa os certificados ao SSID da rede.

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

Melhores Práticas e Padrões do Setor

Ao implementar a implementação de certificados WiFi do Intune, adira às seguintes melhores práticas independentes de fornecedor para garantir a conformidade e a fiabilidade.

Posicionamento e Segurança do Servidor NDES

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

Recomendação: Publique o URL do NDES utilizando o 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.

Verificação de RADIUS e CRL

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

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

Para obter mais informações sobre o design de rede seguro, considere rever Os Principais Benefícios do SD WAN para Empresas Modernas .

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

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

Problema: Falha na Aplicação do Perfil WiFi

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

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

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

Problema: Erros NDES 403 Forbidden

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

Causa Raiz: A conta de serviço do Intune Certificate Connector não tem as permissões necessárias no modelo de certificado, ou a filtragem de URL na sua firewall está a bloquear os parâmetros específicos da query string utilizados pelo SCEP. Mitigação: Verifique se a conta do conector tem permissões de 'Leitura' e 'Inscrição' no modelo de CA. Verifique os registos da firewall para garantir que os URLs que contêm ?operation=GetCACaps não estão a ser bloqueados.

ROI e Impacto no Negócio

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

1. 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, erros de digitação). A autenticação baseada em certificados é invisível para o utilizador, reduzindo normalmente o volume de suporte relacionado com WiFi em 70-80%.
2. Melhoria da Postura de Segurança: O EAP-TLS elimina o risco de recolha de credenciais e de ataques Man-in-the-Middle (MitM). Isto é fundamental para a conformidade com estruturas como o PCI DSS e o GDPR, particularmente em ambientes de Saúde e retalho.
3. Integração Sem Falhas: Para organizações que gerem grandes frotas de dispositivos Apple juntamente com Windows, a integração do Intune com os fluxos de trabalho de MDM existentes (consulte o nosso guia sobre Jamf e RADIUS: Autenticação WiFi Baseada em Certificados para Frotas de Dispositivos Apple ) garante uma experiência de aprovisionamento unificada e sem intervenção desde o primeiro dia.