Pular para o conteúdo principal

Implantando SCEP para Autenticação WiFi e BYOD Segura no Ensino Superior

Este guia técnico oferece aos arquitetos de rede e gerentes de TI um modelo neutro de fornecedor para implantar o registro de certificados baseado em SCEP para proteger o WiFi no ensino superior. Ele detalha a transição da vulnerável autenticação baseada em senha para o EAP-TLS, concentrando-se na integração escalável de BYOD e MDM.

Publicado Atualizado
📖 5 min de leitura1,454 palavras2 exemplos práticos3 questões práticas8 definições principais

Video overview

Ouça este guia

Ver transcrição do podcast
Bem-vindo ao Informativo Técnico da Purple. Eu sou o seu apresentador e hoje vamos abordar algo que surge constantemente no setor de TI do ensino superior: a implantação do SCEP para BYOD e autenticação WiFi seguras. Se você utiliza PEAP-MSCHAPv2 na rede do seu campus, este informativo é diretamente relevante para você. E se você já está planejando a transição para a autenticação baseada em certificados, apresentaremos a arquitetura, as armadilhas e a sequência de implementação para chegar lá. Vamos começar com o problema. As universidades são, por definição, ambientes abertos. Os estudantes chegam em setembro com dois, três ou às vezes cinco dispositivos pessoais. Eles esperam se conectar imediatamente, de forma segura e sem precisar ligar para a central de atendimento. A realidade para a maioria das instituições é uma fila de suporte que chega a dois mil chamados nas primeiras quarenta e oito horas do início do período letivo. Isso não é um problema de pessoal. É um problema de arquitetura. A causa raiz é quase sempre a mesma: autenticação WiFi baseada em senhas. Quando você executa WPA2-Enterprise com PEAP e MSCHAPv2, você está pedindo aos estudantes para configurarem manualmente as definições de 802.1X em cada dispositivo. Uma única configuração incorreta e eles ficam vulneráveis a um ataque de man-in-the-middle. Pior ainda, quando a universidade força uma redefinição de senha a cada noventa dias, todos os dispositivos no campus perdem o acesso ao WiFi simultaneamente. Isso é um desastre previsível e evitável. A resposta é a autenticação baseada em certificados usando EAP-TLS, e o mecanismo que torna isso escalável é o SCEP: o Simple Certificate Enrolment Protocol. O SCEP foi formalizado pelo IETF na RFC 8894 em 2020, embora esteja em uso desde o início dos anos 2000. Ele automatiza o processo de solicitação e instalação de certificados digitais X.509 nos dispositivos, sem exigir qualquer intervenção manual da equipe de TI em cada aparelho. Veja como funciona em alto nível. A sua plataforma de MDM, seja ela Microsoft Intune ou Jamf, envia um payload SCEP para cada dispositivo registrado. Esse payload contém duas coisas: a URL do gateway SCEP e uma senha de desafio compartilhada. O dispositivo gera uma Solicitação de Assinatura de Certificado, envia para o gateway SCEP, que valida a senha de desafio e encaminha a solicitação para a sua Autoridade Certificadora. A AC assina o certificado e o devolve ao dispositivo. A partir desse momento, o dispositivo se autentica na sua rede WiFi usando EAP-TLS: o certificado comprova a identidade do dispositivo para o servidor RADIUS, e o certificado do servidor RADIUS comprova a identidade da rede para o dispositivo. Autenticação mútua. Sem troca de senhas pelo ar. Essa etapa de autenticação mútua é essencial. Com o PEAP, um estudante que se conecta a um ponto de acesso falso que transmite o seu SSID entregará alegremente as suas credenciais. Com o EAP-TLS, o dispositivo verifica o certificado do servidor RADIUS antes de prosseguir. Se ele não corresponder à AC confiável, a conexão falha silenciosamente. Você acaba de eliminar toda a classe de ataques do tipo evil twin. Agora vamos falar de arquitetura. Uma implantação de SCEP em produção para uma universidade possui seis componentes principais. Primeiro, seu provedor de identidade: Microsoft Entra ID, Okta ou Google Workspace. Segundo, sua plataforma de MDM: Intune para Windows e Android, Jamf para macOS e iOS. Terceiro, sua Autoridade Certificadora: ou o Microsoft Active Directory Certificate Services local, ou uma PKI em nuvem. Quarto, seu gateway SCEP: o endpoint HTTP que recebe as solicitações de certificado. Quinto, seu servidor RADIUS para autenticação. Sexto, sua camada de acesso: pontos de acesso Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist configurados para 802.1X. A cadeia de confiança funciona assim. A CA emite um certificado raiz. Esse raiz é distribuído para cada dispositivo via MDM, estabelecendo a confiança. A CA então emite certificados de cliente para os dispositivos via SCEP. Quando um dispositivo se conecta, ele apresenta seu certificado de cliente ao servidor RADIUS, e o servidor RADIUS apresenta seu certificado de servidor ao dispositivo. Ambos os lados realizam a verificação em relação ao raiz confiável. O acesso é concedido ou negado com base na validade do certificado, e não em uma senha. Deixe-me orientar você pela sequência de implementação. Esta é a ordem que funciona. Passo um: limpe seu repositório de identidades. Certifique-se de que seu Active Directory ou Entra ID tenha grupos bem definidos para alunos, funcionários e convidados. As políticas de certificado e as atribuições de VLAN serão vinculadas a esses grupos. Passo dois: implante sua Autoridade Certificadora. Se estiver usando o Microsoft ADCS, configure uma hierarquia de duas camadas: uma CA raiz offline e uma CA emissora online. A CA raiz deve ser isolada fisicamente (air-gapped) após a configuração inicial. Passo três: configure seu gateway SCEP. Este é o endpoint HTTP para o qual seu MDM apontará os dispositivos. Certifique-se de que ele esteja acessível a partir do segmento de rede onde os dispositivos realizam o registro inicial, normalmente seu SSID de onboarding. Passo quatro: configure seu servidor RADIUS. Importe o certificado da CA emissora como uma CA confiável. Configure o EAP-TLS como seu método de autenticação. Defina os atributos de retorno de VLAN para que o RADIUS possa atribuir dinamicamente os alunos ao segmento de rede correto. Passo quinto: configure seus perfis de MDM. No Intune, crie primeiro um perfil de Certificado Confiável, depois um perfil de Certificado SCEP e, por fim, um perfil de WiFi que faça referência ao certificado SCEP. Implante-os exatamente nessa ordem. Cada um depende da existência do anterior. Passo seis: configure seus pontos de acesso. No Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, configure seu SSID seguro para WPA2-Enterprise ou WPA3-Enterprise. Defina o timeout do RADIUS para pelo menos cinco segundos para acomodar a latência de validação de certificados durante os períodos de pico de onboarding. Agora, as armadilhas. Já vi isso descarrilar implantações repetidamente. A primeira é implantar perfis de MDM na ordem errada. Se o perfil de WiFi chegar ao dispositivo antes do perfil de certificado SCEP, o dispositivo não terá nenhum certificado para se autenticar. A conexão falha e o usuário liga para o suporte técnico. O segundo erro é esquecer os dispositivos BYOD. O Intune e o Jamf gerenciam a frota de propriedade da sua instituição. Mas os dispositivos pessoais dos alunos não estão registrados no seu MDM. Para esses, você precisa de um portal de integração self-service. O aluno se autentica via Single Sign-On usando suas credenciais universitárias, e o portal usa SCEP para provisionar o certificado. A plataforma da Purple integra esse fluxo de integração diretamente na experiência do captive portal, para que os alunos concluam o registro em menos de dois minutos sem qualquer envolvimento da TI. O terceiro erro são as falhas de timeout do RADIUS durante o pico de integração. Faça testes de carga em sua infraestrutura RADIUS antes de setembro, não durante. Implemente o balanceamento de carga em pelo menos dois nós RADIUS. O quarto erro é a revogação de certificados. Quando um aluno sai, ou um dispositivo é perdido ou roubado, você precisa revogar o certificado imediatamente. Certifique-se de que sua CA publique uma Lista de Revogação de Certificados e que seu servidor RADIUS a verifique a cada autenticação. Agora, uma rodada rápida de perguntas e respostas sobre as dúvidas que ouvimos com mais frequência. O SCEP pode funcionar sem um MDM? Tecnicamente sim, mas na prática não. Sem um MDM para enviar o payload do SCEP e o perfil de WiFi, você volta à configuração manual do dispositivo. Qual deve ser o tempo de validade do certificado? Para dispositivos de alunos, o padrão é de um a dois anos. Longo o suficiente para durar o ano letivo sem o atrito da renovação, curto o suficiente para limitar a exposição se um certificado for comprometido. E quanto aos dispositivos IoT que não suportam 802.1X? Use o MAC Authentication Bypass com um portal self-service de registro de dispositivos. Os alunos registram o endereço MAC de seu console de videogame ou smart TV, e seu sistema NAC o coloca na VLAN correta. Isso funciona com o eduroam? Sim. O EAP-TLS é totalmente suportado pela federação eduroam. Certificados emitidos pela CA do seu campus podem autenticar alunos no eduroam em qualquer instituição participante em todo o mundo. Para encerrar, aqui estão as três decisões que definem uma implantação SCEP bem-sucedida. Primeiro: escolha a arquitetura da sua CA antes de qualquer outra coisa. O ADCS local oferece controle total. A PKI em nuvem oferece simplicidade operacional. A escolha errada aqui custará meses de retrabalho. Segundo: automatize a integração de BYOD desde o primeiro dia. Não presuma que os alunos configurarão seus dispositivos pessoais manualmente. Eles não farão isso. Crie o portal self-service antes do início do período letivo. Terceiro: teste a capacidade do seu RADIUS sob carga antes de setembro. Uma interrupção do RADIUS no primeiro dia de aula é totalmente evitável. A plataforma da Purple suporta todas essas três frentes: integração de PKI em nuvem overlay, integração BYOD self-service através do nosso captive portal e infraestrutura RADIUS testada em mais de oitenta mil locais ativos com noventa e nove vírgula nove nove nove por cento de uptime. Obrigado por participar do Purple Technical Briefing. Para obter mais orientações, acesse purple.ai.

Parte da nossa série principal: Enterprise WiFi Security Guide

Implantando SCEP para Autenticação WiFi e BYOD Segura no Ensino Superior

Resumo Executivo

Para as equipes de TI do ensino superior, o início do ano letivo traz um teste de estresse imediato. Milhares de estudantes chegam ao campus com múltiplos dispositivos não gerenciados, esperando conectividade instantânea e segura. Quando as universidades dependem de autenticação baseada em senha como PEAP-MSCHAPv2, essa entrada previsivelmente resulta em filas enormes no suporte, erros de configuração e vulnerabilidades graves de roubo de credenciais via access points do tipo "evil twin".

A solução arquitetônica para esse desafio de escala e segurança é a autenticação baseada em certificado usando EAP-TLS. Para tornar a implantação de certificados viável em dezenas de milhares de endpoints, as universidades devem implementar o Simple Certificate Enrollment Protocol (SCEP). O SCEP automatiza o provisionamento de certificados digitais para dispositivos gerenciados via MDM e para dispositivos não gerenciados de estudantes por meio de portais de autoatendimento. Este guia detalha os requisitos técnicos para implantar o SCEP em um ambiente de ensino superior, fornecendo etapas práticas para eliminar chamados de suporte relacionados a senhas e proteger o perímetro do campus.

A Arquitetura do Registro de Certificados SCEP

A transição para o WiFi baseado em certificado exige uma mudança fundamental da validação do conhecimento do usuário (uma senha) para a validação da identidade do dispositivo (um certificado). O protocolo SCEP atua como a ponte entre a camada de gerenciamento de dispositivos e a sua Infraestrutura de Chaves Públicas (PKI).

Implantando SCEP para Autenticação WiFi e BYOD Segura no Ensino Superior - scep architecture diagram

Componentes de Infraestrutura Essenciais

Uma implantação do SCEP pronta para produção requer seis componentes integrados trabalhando em sequência:

  1. Provedor de Identidade (IdP): O diretório autoritativo (Microsoft Entra ID, Okta ou Google Workspace) que verifica a identidade do usuário antes da emissão do certificado.
  2. Gerenciamento de Dispositivos Móveis (MDM): Plataformas como Microsoft Intune ou Jamf que enviam a carga de dados do SCEP para dispositivos de propriedade da instituição.
  3. Autoridade Certificadora (CA): O mecanismo de PKI que assina e emite os certificados. Isso pode ser uma implantação local do Microsoft ADCS ou uma sobreposição de PKI nativa em nuvem.
  4. Gateway SCEP: O endpoint HTTP que recebe as solicitações de assinatura de certificado (CSRs) dos dispositivos, valida a senha de desafio e encaminha a solicitação para a CA.
  5. Servidor RADIUS: O servidor de autenticação que avalia o certificado de cliente apresentado em relação às políticas de acesso à rede durante a troca de mensagens 802.1X EAP-TLS.
  6. Rede de Acesso Sem Fio: Os access points físicos (Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist) configurados para aplicar a autenticação 802.1X.

O Fluxo de Registro SCEP

O processo de registro é executado sem intervenção do usuário em dispositivos gerenciados. A plataforma MDM envia um perfil de configuração contendo a URL do gateway SCEP e uma senha de desafio gerada dinamicamente. O dispositivo gera uma chave privada localmente e constrói uma CSR. Em seguida, ele transmite essa CSR para o gateway SCEP via HTTP.

O gateway intercepta a solicitação e valida a senha de desafio junto à API do MDM para confirmar que o dispositivo está autorizado. Uma vez verificado, o gateway encaminha a CSR para a CA. A CA assina o certificado e o retorna ao dispositivo através do gateway. A chave privada nunca sai do endpoint, garantindo a integridade criptográfica.

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.

Guia de Implementação: Uma Estratégia de Implantação em Fases

A implantação do SCEP exige um sequenciamento preciso. Devido às dependências de perfil, executar essas etapas fora de ordem resultará em falhas de autenticação.

Passo 1: Sincronização de Diretório e Política de Grupo

Antes de mexer nos certificados, garanta que seu repositório de identidade esteja limpo. Crie grupos de segurança distintos para alunos, funcionários e professores no Entra ID ou Active Directory. Seu servidor RADIUS usará essas associações de grupo, incorporadas como Subject Alternative Names (SAN) nos certificados, para atribuir dispositivos às VLANs corretas de forma dinâmica.

Passo 2: Configuração de PKI e Gateway SCEP

Estabeleça sua hierarquia de CA. Se estiver construindo localmente, implante uma CA raiz offline e uma CA emissora online. Para ambientes de ensino superior que buscam reduzir a infraestrutura física, as soluções de PKI em nuvem oferecem simplicidade operacional. Configure o gateway SCEP para se comunicar com sua CA e exponha o endpoint de registro para o segmento de rede onde os dispositivos se conectarão inicialmente.

Passo 3: Integração do Servidor RADIUS

Importe o certificado da CA emissora para o repositório de certificados confiáveis do seu servidor RADIUS. Configure o protocolo de autenticação estritamente para EAP-TLS. Defina políticas de rede que mapeiem atributos de certificado (como o User Principal Name) para atributos de retorno de VLAN específicos, permitindo a microsegmentação em todo o campus.

Passo 4: Sequenciamento de Perfis de MDM

Para dispositivos pertencentes à instituição gerenciados pelo Intune ou Jamf, a ordem de implantação do perfil é crítica. Você deve implantar os perfis exatamente nesta sequência:

  1. Perfil de Certificado Confiável: Distribui o certificado da CA raiz para estabelecer a confiança.
  2. Perfil de Certificado SCEP: Direciona o dispositivo ao gateway para obter seu certificado de cliente.
  3. Perfil de WiFi: Configura o SSID para usar WPA3-Enterprise com EAP-TLS, referenciando explicitamente o certificado adquirido na etapa anterior.

Passo 5: Integração de BYOD via Autoatendimento

Os estudantes não instalarão certificados manualmente em seus dispositivos pessoais. Você deve fornecer um caminho de integração automatizado. Implante um SSID aberto que restrinja o tráfego exclusivamente ao captive portal e ao gateway SCEP. Quando um estudante se conecta, o portal solicita que ele se autentique via Single Sign-On usando suas credenciais universitárias. Após a autenticação bem-sucedida, o portal provisiona o payload SCEP para o dispositivo. O Purple integra esse fluxo de integração diretamente na experiência do captive portal, permitindo que os estudantes concluam a inscrição em menos de dois minutos sem a intervenção da TI.

Melhores Práticas e Mitigação de Riscos

A transição para o EAP-TLS elimina o roubo de credenciais, mas introduz novas considerações operacionais. Os arquitetos de rede devem antecipar eventos de escala e de ciclo de vida.

Implantando SCEP para Autenticação WiFi e BYOD Segura no Ensino Superior - scep vs password comparison

Planejamento de Capacidade RADIUS

O custo computacional da validação de certificados EAP-TLS é significativamente maior do que a verificação de senha PEAP. Durante a primeira semana de aulas, milhares de dispositivos tentarão se autenticar simultaneamente. Um único nó RADIUS provavelmente esgotará seus recursos e descartará solicitações, levando a falhas generalizadas de conexão. Você deve implementar o balanceamento de carga em vários nós RADIUS e aumentar o limite de tempo limite de autenticação em seus pontos de acesso para pelo menos cinco segundos para acomodar o pico de latência.

Gerenciamento do Ciclo de Vida dos Certificados

Os certificados para dispositivos de estudantes geralmente devem ter um período de validade de um a dois anos. Essa duração cobre o ciclo acadêmico enquanto limita a exposição caso um dispositivo seja comprometido. Fundamentalmente, você deve implementar um mecanismo robusto de revogação. Quando um estudante se forma ou relata a perda de um dispositivo, o certificado deve ser revogado imediatamente. Certifique-se de que sua autoridade certificadora publique uma Lista de Revogação de Certificados (CRL) ou opere um respondente do Protocolo de Status de Certificados Online (OCSP), e configure seu servidor RADIUS para verificar o status de revogação a cada tentativa de autenticação.

Como Lidar com Dispositivos IoT sem Interface Gráfica

Smart TVs, consoles de videogame e impressoras sem fio em residências estudantis não possuem os suplicantes 802.1X nativos necessários para a inscrição SCEP. Para esses dispositivos, implemente o MAC Authentication Bypass (MAB). Forneça um portal de autoatendimento para registro de dispositivos, onde os estudantes possam registrar os endereços MAC de seus hardwares IoT. O sistema de Controle de Acesso à Rede (NAC) então autentica esses endereços registrados e os coloca na VLAN de estudantes apropriada.

Ouça o Briefing Técnico

Para um aprofundamento na arquitetura e nos cenários reais de implantação, ouça nosso podcast de briefing técnico de 10 minutos.

ROI e Impacto no Negócio

O caso de negócio para a implantação do SCEP no ensino superior baseia-se em dois pilares: postura de segurança e eficiência operacional.

Do ponto de vista da segurança, o EAP-TLS fornece autenticação mútua. O dispositivo verifica o certificado do servidor RADIUS antes de transmitir qualquer dado, mitigando inteiramente o risco de pontos de acesso clones capturarem credenciais. Essa arquitetura alinha-se com os princípios de zero-trust, garantindo que apenas dispositivos criptograficamente verificados acessem a rede do campus.

Operacionalmente, dissociar a autenticação WiFi das senhas de diretório gera retornos financeiros imediatos. Quando uma universidade força uma redefinição de senha a cada 90 dias, os alunos que usam PEAP devem atualizar suas credenciais em todos os dispositivos. Inevitavelmente, muitos falham, resultando em um surto de chamados no helpdesk. Com SCEP e EAP-TLS, o certificado permanece válido independentemente das alterações de senha. As universidades que implantam o registro automatizado de certificados relatam consistentemente uma redução de até 70% nos chamados de suporte relacionados a WiFi durante os períodos de pico, permitindo que a equipe de TI se concentre em iniciativas estratégicas em vez de solucionar problemas básicos de conectividade.

Definições principais

SCEP (Simple Certificate Enrollment Protocol)

Um protocolo que automatiza a solicitação e a emissão de certificados digitais para dispositivos de rede sem intervenção manual.

Essencial para escalar implantações EAP-TLS, pois permite que MDMs e portais de onboarding provisionem certificados para dezenas de milhares de dispositivos de alunos de forma integrada.

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

O método de autenticação 802.1X mais seguro, que exige um certificado tanto do lado do servidor quanto do lado do cliente para autenticação mútua.

Substitui protocolos vulneráveis baseados em senha, como PEAP, eliminando o risco de roubo de credenciais por meio de pontos de acesso clones maliciosos (evil twin).

MDM (Mobile Device Management)

Plataformas de software como Microsoft Intune ou Jamf usadas para administrar e proteger dispositivos de propriedade da instituição.

Usado para enviar payloads SCEP e perfis de WiFi silenciosamente para dispositivos gerenciados, garantindo que estejam configurados para acesso à rede antes da implantação.

CSR (Certificate Signing Request)

Um bloco de texto codificado gerado pelo dispositivo cliente contendo a chave pública e informações de identidade, enviado à CA para solicitar um certificado.

Em um fluxo de trabalho SCEP, o dispositivo gera a chave privada localmente e envia apenas a CSR para o gateway, garantindo que a chave privada permaneça segura no endpoint.

RADIUS (Remote Authentication Dial-In User Service)

O protocolo de rede que fornece gerenciamento centralizado de autenticação, autorização e bilhetagem.

O servidor que avalia o certificado do cliente apresentado pelo dispositivo durante a troca 802.1X e determina a atribuição de VLAN.

Evil Twin Attack

Uma exploração de segurança onde um invasor configura um ponto de acesso não autorizado com o mesmo SSID da rede legítima para interceptar credenciais de usuários.

O EAP-TLS previne isso porque o dispositivo cliente verifica o certificado do servidor RADIUS antes de transmitir qualquer dado; se o invasor não possuir o certificado de servidor confiável, a conexão cai.

MAB (MAC Authentication Bypass)

Um método de autenticação alternativo que utiliza o endereço MAC de um dispositivo como sua credencial.

Necessário para a integração de dispositivos IoT sem interface direta (como consoles de jogos) em residências estudantis que não suportam 802.1X ou SCEP.

CRL (Certificate Revocation List)

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

Crucial para a segurança da rede; o servidor RADIUS deve verificar a CRL para garantir que dispositivos roubados ou alunos formados tenham o acesso negado imediatamente.

Exemplos práticos

Uma universidade com 20.000 alunos está migrando de PEAP-MSCHAPv2 para EAP-TLS. Eles usam o Microsoft Intune para 3.000 laptops Windows de propriedade da universidade, mas os 45.000 dispositivos restantes são BYOD de estudantes (telefones, tablets, laptops pessoais). Como eles devem projetar a arquitetura de implantação de certificados para garantir que todos os dispositivos possam se autenticar no primeiro dia de aula?

A universidade deve implementar uma estratégia de registro bifurcada. Para os 3.000 laptops gerenciados pelo Intune, a equipe de TI configura um perfil de Certificado SCEP dentro do Intune, enviando a URL do gateway e a senha de desafio silenciosamente para os dispositivos. Para os 45.000 dispositivos BYOD, eles implantam um SSID de 'Onboarding' aberto que restringe o tráfego a um Captive Portal de autoatendimento e ao gateway SCEP. Os alunos se conectam ao SSID de Onboarding, autenticam-se via SAML SSO no Entra ID e baixam um payload de configuração que aciona o registro SCEP. Assim que o certificado é instalado, o dispositivo se associa automaticamente ao SSID 'eduroam' seguro usando EAP-TLS.

Comentário do examinador: Esta abordagem identifica corretamente que o MDM sozinho não pode resolver o desafio do BYOD. Ao utilizar um Captive Portal para dispositivos não gerenciados, a universidade obtém 100% de cobertura de certificados sem exigir que os alunos configurem manualmente as definições de 802.1X, evitando assim uma avalanche de chamados no suporte técnico.

Durante a primeira semana de aulas, o suporte técnico de uma universidade recebe relatórios de que os alunos conseguem se conectar ao WiFi com seus laptops, mas seus alto-falantes inteligentes e consoles de videogame nos dormitórios não conseguem se conectar à rede 802.1X. Como o arquiteto de rede deve resolver isso?

O arquiteto deve implementar o MAC Authentication Bypass (MAB) para dispositivos sem tela (headless). Como os alto-falantes inteligentes e consoles não possuem suplicantes 802.1X, eles não podem processar payloads SCEP ou apresentar certificados de cliente. A universidade deve implantar um portal de registro de dispositivos autoatendimento, onde os alunos fazem login com suas credenciais universitárias e inserem os endereços MAC de seus dispositivos IoT. O servidor RADIUS é configurado para aceitar esses endereços MAC registrados via MAB e atribuí-los à VLAN por quarto específica do aluno.

Comentário do examinador: Esta solução aborda a limitação técnica de dispositivos IoT sem tela, mantendo a segmentação de rede. Ao usar um portal de autoatendimento, a equipe de TI evita a inserção manual de endereços MAC, escalando a solução para acomodar milhares de dispositivos de consumo nos dormitórios.

Questões práticas

Q1. Sua universidade está implantando o EAP-TLS. Você configurou o gateway SCEP e os perfis de MDM. No entanto, quando os dispositivos de teste tentam se conectar ao SSID seguro, a conexão falha silenciosamente. Os logs do RADIUS mostram que o certificado do cliente é válido, mas o dispositivo está rejeitando o servidor. Qual é o erro de configuração mais provável?

Dica: Considere os requisitos para autenticação mútua e o que o dispositivo precisa para confiar no servidor.

Ver resposta modelo

O perfil de Certificado Confiável do MDM provavelmente está ausente ou configurado incorretamente. No EAP-TLS, a autenticação mútua exige que o dispositivo verifique o certificado do servidor RADIUS. Se o dispositivo não tiver o certificado da CA Raiz instalado em seu repositório confiável, ele não poderá validar o certificado do servidor e derrubará a conexão para evitar um potencial Evil Twin Attack.

Q2. Um estudante relata que seu notebook, que foi registrado com sucesso através do portal de BYOD e possui um certificado de cliente válido, não consegue mais acessar a rede após ele ter alterado a senha do diretório da universidade. Que falha de arquitetura isso indica?

Dica: A autenticação EAP-TLS depende inteiramente do certificado, não da senha.

Ver resposta modelo

Isso indica que a rede não está de fato utilizando EAP-TLS, mas provavelmente está recorrendo ao PEAP-MSCHAPv2 ou outro protocolo baseado em senha. Se o EAP-TLS verdadeiro estivesse configurado, o servidor RADIUS validaria a assinatura criptográfica do certificado, desvinculando completamente o acesso à rede da senha do diretório. O arquiteto de rede deve impor políticas rígidas de EAP-TLS no servidor RADIUS e desativar protocolos alternativos de fallback.

Q3. Durante a primeira semana de aulas, os servidores RADIUS estão apresentando alta utilização de CPU e erros intermitentes de timeout, causando falhas generalizadas de autenticação. Os servidores estão adequadamente dimensionados para o número total de sessões simultâneas. O que está causando os timeouts?

Dica: Considere a diferença na sobrecarga computacional entre verificar uma senha e validar uma cadeia de certificados durante a fase de conexão inicial.

Ver resposta modelo

Os timeouts são causados pela pesada sobrecarga computacional dos handshakes criptográficos do EAP-TLS durante a sobrecarga inicial de autenticação dos alunos que retornam. O arquiteto deve aumentar o valor de timeout do RADIUS nos pontos de acesso sem fio (como Cisco Meraki ou HPE Aruba) para pelo menos 5 segundos para acomodar a latência, e garantir que o balanceamento de carga esteja distribuindo uniformemente as solicitações iniciais de autenticação completa entre todos os nós do RADIUS.

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.