Enterprise SCEP Setup Guide: Certificate-Based Wi-Fi Authentication for Higher Education and Large Networks

Enterprise SCEP Setup Guide: Certificate-Based WiFi Authentication for Higher Education and Large Networks A Purple Technical Briefing - Podcast Script (approximately 10 minutes) --- INTRODUCTION AND CONTEXT - approximately 1 minute Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network - whether that is a university campus, a multi-site hotel group, or a large public sector estate? We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them. This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map. Let us get into it. --- TECHNICAL DEEP-DIVE - approximately 5 minutes So, first principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalised by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine. In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks - where an attacker spins up a rogue access point to harvest credentials. Eis como funciona a cadeia completa. Um dispositivo gerido - um portátil de um estudante, um telemóvel de um funcionário, um terminal de ponto de venda de um hotel - precisa de se ligar à rede sem fios corporativa. A sua plataforma MDM, que pode ser o Microsoft Intune ou o Jamf, envia um payload SCEP para esse dispositivo. O payload contém duas coisas: o URL do SCEP, que aponta para o seu servidor NDES ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado. O dispositivo gera localmente o seu próprio par de chaves pública e privada. Isto é crítico. A chave privada nunca sai do dispositivo. É gerada no dispositivo, armazenada no secure enclave ou TPM, e nunca é transmitida através da rede. O dispositivo cria então um Pedido de Assinatura de Certificado - um CSR - e envia-o para o gateway SCEP. O gateway valida o 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 à cadeia de confiança da sua CA, verifica a Lista de Revogação de Certificados para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem de aceitação para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador. Agora, falemos sobre onde o SCEP se posiciona em relação à alternativa, que é o PKCS. O PKCS - Public Key Cryptography Standards - é o outro método de entrega de certificados suportado por plataformas como o Intune. Com o PKCS, a CA gera tanto a chave pública como a privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo. Isso significa que a chave privada viaja pela rede, o que introduz uma superfície de ataque teórica. O PKCS é adequado para casos de uso como a encriptação de e-mail S/MIME, onde a custódia de chaves é realmente desejável. Para a autenticação de WiFi, o SCEP é a escolha certa. A chave privada permanece no dispositivo, sem exceções. Agora, a camada de hardware. O SCEP e o EAP-TLS são normas neutras em termos de fornecedor, o que significa que 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 o Windows NPS, o FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e, fundamentalmente, onde configura a atribuição dinâmica de VLANs. As VLANs dinâmicas são a forma de segmentar a rede por identidade. O dispositivo de um estudante obtém a VLAN 20 - apenas acesso à internet. O dispositivo de um docente obtém a VLAN 10 - acesso a sistemas de investigação internos. Um dispositivo de gestão de instalações obtém a VLAN 30 - acesso a sistemas de gestão de edifícios. Tudo isto é impulsionado pelos atributos do certificado e pela política RADIUS, sem qualquer intervenção manual por dispositivo. Para a integração com fornecedores de identidade, os atributos de certificado SCEP - especificamente o Subject Alternative Name - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica, o que significa que, quando desativa uma conta no Entra ID e o MDM remove o dispositivo, o certificado é revogado e o acesso WiFi é cortado automaticamente. Essa é a história de revogação que as chaves pré-partilhadas simplesmente não conseguem contar. --- RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - aproximadamente 2 minutos Muito bem, vamos falar sobre a sequência de implementação, porque é aqui que a maioria das equipas tropeça. A sequência não é negociável: primeiro o certificado Trusted Root, segundo o perfil de certificado SCEP e terceiro o perfil WiFi. O Intune e o Jamf impõem dependências de perfil. Se o seu perfil WiFi fizer referência a um certificado SCEP que ainda não foi implementado no dispositivo, o perfil WiFi falhará com um erro enigmático que parece uma configuração incorreta, mas que na verdade é apenas um problema de temporização. O segundo erro comum é a segmentação de grupos. Todos os três perfis - Trusted Root, SCEP e WiFi - devem ser implementados no exato mesmo grupo de Azure AD ou Jamf. Se o perfil SCEP for direcionado a um grupo de utilizadores e o perfil WiFi a um grupo de dispositivos, o Intune não conseguirá resolver a dependência e o perfil WiFi será apresentado como Não Aplicável. Isto apanha as equipas de surpresa constantemente. Terceiro: acessibilidade do servidor NDES. O seu servidor NDES precisa de ser acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. A forma correta de fazer isto é através do Azure AD Application Proxy, e não abrindo uma porta na sua firewall. O App Proxy oferece acesso remoto seguro sem portas de entrada e permite aplicar políticas de Acesso Condicional ao fluxo de registo. Quarto: disponibilidade de CRL. O seu servidor RADIUS verifica a Lista de Revogação de Certificados sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição CRL 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. Trata-se de uma interrupção em todo o campus. Torne os seus endpoints de CRL altamente disponíveis e teste a revogação antes de entrar em produção. Para redes de grande dimensão - qualquer coisa acima de 500 dispositivos - 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, removendo mais uma dependência de infraestrutura. --- PERGUNTAS E RESPOSTAS RÁPIDAS - aproximadamente 1 minuto O SCEP pode gerir dispositivos BYOD que não estão registados num MDM? Não diretamente. O SCEP requer o registo num MDM para enviar o payload do certificado. Para BYOD não geridos, necessita de uma abordagem diferente - ou um portal de integração self-service ou um SSID separado que utilize um Captive Portal com verificação de identidade. A plataforma da Purple trata dessa camada de convidados e BYOD de forma limpa, coexistindo com a sua rede de colaboradores autenticada por certificado. E em relação ao iOS e Android? Ambas as plataformas suportam SCEP nativamente. O iOS suporta SCEP desde o iOS 4. O Android Enterprise suporta SCEP através do Intune e de outros MDMs. A configuração é ligeiramente diferente por plataforma, mas o protocolo subjacente é idêntico. O EAP-TLS funciona com WPA3? Sim. O WPA3-Enterprise exige o modo de segurança de 192 bits para ambientes sensíveis, e o EAP-TLS é totalmente compatível. Na verdade, o WPA3-Enterprise com EAP-TLS é a combinação recomendada pela Wi-Fi Alliance para redes governamentais e financeiras. --- RESUMO E PRÓXIMOS PASSOS - aproximadamente 1 minuto Para resumir. A autenticação WiFi por certificado SCEP é a arquitetura certa para qualquer rede com mais de 50 dispositivos geridos. Elimina as credenciais partilhadas, fornece identidade por dispositivo, permite a segmentação dinâmica de VLAN e integra-se diretamente com o seu fornecedor de identidade para revogação automatizada. A sequência de implementação - Trusted Root, depois perfil SCEP, depois perfil WiFi - é fixa. O direcionamento de grupos deve ser consistente. A disponibilização de CRL não é opcional. Especificamente para o ensino superior, a combinação de SCEP para dispositivos de funcionários e docentes, juntamente com uma camada separada de WiFi para convidados para os estudantes nos seus dispositivos pessoais, oferece segurança e uma excelente experiência de utilizador sem cedências. Se quiser aprofundar este tema, o guia da Purple sobre autenticação WiFi empresarial sem Active Directory ou um servidor local aborda o caminho cloud-native. E se está a pensar no que acontece quando um colaborador se demite, o nosso guia sobre revogação de acesso a WiFi detalha todo o fluxo de trabalho de revogação. Obrigado por nos ouvir. Sou da equipa técnica da Purple, e encontramo-nos no próximo briefing. --- FIM DO SCRIPT