Saltar para o conteúdo principal
Português

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

Este guia técnico fornece aos arquitetos de rede e gestores de TI um plano neutro em termos de fornecedor para implementar a atribuição de certificados baseada em SCEP para proteger o WiFi no ensino superior. Detalha a transição de uma autenticação vulnerável baseada em palavras-passe para EAP-TLS, focando-se na integração escalável de BYOD e MDM.

📖 5 min de leitura📝 1,198 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 8 definições principais

Ouça este guia

Ver transcrição do podcast
Bem-vindo ao Purple Technical Briefing. Sou o seu anfitrião e hoje vamos abordar algo que surge constantemente no setor de TI do ensino superior: a implementação de SCEP para autenticação segura de BYOD e WiFi. Se tem vindo a executar PEAP-MSCHAPv2 na rede do seu campus, este briefing é diretamente relevante para si. E se já está a planear uma transição para a autenticação baseada em certificados, dar-lhe-emos a estrutura, as armadilhas e a sequência de implementação para lá chegar. Comecemos pelo problema. As universidades são, por conceção, ambientes abertos. Os estudantes chegam em setembro com dois, três, por vezes cinco dispositivos pessoais. Esperam ligar-se imediatamente, de forma segura e sem contactar o helpdesk. A realidade para a maioria das instituições é uma fila de helpdesk que atinge os dois mil tickets nas primeiras quarenta e oito horas do início do período letivo. Isto não é um problema de pessoal. É um problema de arquitetura. A causa raiz é quase sempre a mesma: autenticação WiFi baseada em palavra-passe. Quando executa WPA2-Enterprise com PEAP e MSCHAPv2, está a pedir aos estudantes que configurem manualmente as definições 802.1X em cada dispositivo. Uma definição incorreta e ficam vulneráveis a um ataque man-in-the-middle. Pior ainda, quando a universidade força a alteração de palavra-passe a cada noventa dias, todos os dispositivos no campus perdem o acesso WiFi em simultâneo. Trata-se de um desastre previsível e evitável. A resposta é a autenticação baseada em certificados através de EAP-TLS, e o mecanismo que a torna escalável é o SCEP: o Simple Certificate Enrollment Protocol. O SCEP foi formalizado pela IETF no RFC 8894 em 2020, embora seja utilizado desde o início dos anos 2000. Automatiza o processo de solicitação e instalação de certificados digitais X.509 nos dispositivos, sem necessidade de qualquer intervenção manual de TI por dispositivo. Eis como funciona a alto nível. A sua plataforma MDM, seja o Microsoft Intune ou o Jamf, envia um payload SCEP para cada dispositivo registado. Esse payload contém duas coisas: o URL do gateway SCEP e uma palavra-passe de desafio partilhada. O dispositivo gera um Certificate Signing Request, envia-o para o gateway SCEP, que valida a palavra-passe de desafio e encaminha o pedido para a sua Autoridade de Certificação (CA). A CA assina o certificado e devolve-o ao dispositivo. A partir desse momento, o dispositivo autentica-se na sua rede WiFi utilizando EAP-TLS: o certificado comprova a identidade do dispositivo perante o servidor RADIUS, e o certificado do servidor RADIUS comprova a identidade da rede perante o dispositivo. Autenticação mútua. Sem partilha de palavras-passe por via aérea. Este aspeto da autenticação mútua é fundamental. Com PEAP, um estudante que se ligue a um ponto de acesso falso que esteja a transmitir o seu SSID entregará alegremente as suas credenciais. Com EAP-TLS, o dispositivo verifica o certificado do servidor RADIUS antes de prosseguir. Se este não corresponder à CA fidedigna, a ligação falha silenciosamente. Acabou de eliminar toda a classe de ataques do tipo "evil twin". Agora vamos falar de arquitetura. Uma implementação SCEP de produção para uma universidade tem seis componentes principais. Primeiro, o seu fornecedor de identidade: Microsoft Entra ID, Okta ou Google Workspace. Segundo, a sua plataforma MDM: Intune para Windows e Android, Jamf para macOS e iOS. Terceiro, a sua Autoridade de Certificação (CA): quer o Microsoft Active Directory Certificate Services local (on-premises), quer uma PKI na nuvem. Quarto, o seu gateway SCEP: o endpoint HTTP que recebe os pedidos de certificado. Quinto, o seu servidor RADIUS para autenticação. Sexto, a 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 a cada dispositivo via MDM, estabelecendo a confiança. A CA emite então certificados de cliente para os dispositivos via SCEP. Quando um dispositivo se liga, apresenta o seu certificado de cliente ao servidor RADIUS, e o servidor RADIUS apresenta o seu certificado de servidor ao dispositivo. Ambos os lados verificam contra a raiz fidedigna. O acesso é concedido ou negado com base na validade do certificado, e não numa palavra-passe. Deixe-me guiar-lhe pela sequência de implementação. Esta é a ordem que funciona. Passo um: limpe o seu repositório de identidades. Garanta que o seu Active Directory ou Entra ID tem grupos bem definidos para estudantes, funcionários e convidados. As políticas de certificado e as atribuições de VLAN estarão associadas a estes grupos. Passo dois: implemente a sua Autoridade de Certificação. Se estiver a utilizar o Microsoft ADCS, configure uma hierarquia de dois níveis: uma CA raiz offline e uma CA de emissão online. A CA raiz deve ser isolada fisicamente (air-gapped) após a configuração inicial. Passo três: configure o seu gateway SCEP. Este é o endpoint HTTP para o qual o seu MDM irá direcionar os dispositivos. Certifique-se de que está acessível a partir do segmento de rede onde os dispositivos realizam o registo inicial, normalmente o seu SSID de integração. Passo quatro: configure o seu servidor RADIUS. Importe o certificado da CA de emissão como uma CA fidedigna. Configure o EAP-TLS como o seu método de autenticação. Configure os atributos de retorno de VLAN para que o RADIUS possa atribuir dinamicamente os estudantes ao segmento de rede correto. Passo cinco: configure os seus perfis de MDM. No Intune, crie primeiro um perfil de Certificado Fidedigno, depois um perfil de Certificado SCEP e, em seguida, um perfil de WiFi que faça referência ao certificado SCEP. Implemente-os exatamente nessa ordem. Cada um depende da existência do anterior. Passo seis: configure os seus pontos de acesso. No Cisco Meraki, HPE Aruba, Ruckus ou Juniper Mist, configure o seu SSID seguro para WPA2-Enterprise ou WPA3-Enterprise. Defina o limite de tempo do RADIUS para pelo menos cinco segundos para acomodar a latência de validação de certificados durante os picos de integração. Agora, as armadilhas. Tenho visto estas descarrilar implementações repetidamente. O primeiro erro é implementar perfis de MDM na ordem errada. Se o perfil de WiFi chegar ao dispositivo antes do perfil de certificado SCEP, o dispositivo não tem nenhum certificado com o qual se autenticar. A ligação falha e o utilizador liga para o suporte técnico. A segunda armadilha é esquecer os dispositivos BYOD. O Intune e o Jamf gerem a frota propriedade da sua instituição. Mas os dispositivos pessoais dos estudantes não estão registados no seu MDM. Para esses, precisa de um portal de onboarding self-service. O estudante autentica-se através de Single Sign-On utilizando as suas credenciais universitárias, e o portal utiliza SCEP para fornecer o certificado. A plataforma da Purple integra este fluxo de onboarding diretamente na experiência de Captive Portal, para que os estudantes concluam o registo em menos de dois minutos sem qualquer intervenção de TI. A terceira armadilha são as falhas de timeout do RADIUS durante os picos de onboarding. Faça testes de carga à sua infraestrutura RADIUS antes de setembro, não durante o mesmo. Implemente balanceamento de carga em pelo menos dois nós RADIUS. A quarta armadilha é a revogação de certificados. Quando um estudante sai, ou um dispositivo é perdido ou roubado, precisa de revogar o certificado imediatamente. Certifique-se de que a sua CA publica uma Lista de Revogação de Certificados e que o seu servidor RADIUS a verifica em cada autenticação. Passemos agora a uma sessão rápida de Perguntas e Respostas sobre as questões 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 SCEP e o perfil de WiFi, voltamos à configuração manual do dispositivo. Qual deve ser o período de validade do certificado? Para dispositivos de estudantes, o padrão é de um a dois anos. Suficientemente longo para durar o ano académico sem atrito de renovação, e suficientemente curto para limitar a exposição se um certificado for comprometido. E quanto aos dispositivos IoT que não suportam 802.1X? Utilize MAC Authentication Bypass com um portal de registo de dispositivos self-service. Os estudantes registam o endereço MAC da sua consola de jogos ou smart TV, e o seu sistema NAC coloca-o na VLAN correta. Isto funciona com o eduroam? Sim. O EAP-TLS é totalmente suportado pela federação eduroam. Os certificados emitidos pela CA do seu campus podem autenticar estudantes no eduroam em qualquer instituição participante no mundo. Para terminar, aqui estão as três decisões que definem uma implementação SCEP bem-sucedida. Primeiro: escolha a sua arquitetura de CA antes de tudo o resto. O ADCS on-premises dá-lhe controlo total. A PKI na nuvem dá-lhe simplicidade operacional. A escolha errada aqui custar-lhe-á meses de retrabalho. Segundo: automatize o onboarding de BYOD desde o primeiro dia. Não assuma que os estudantes irão configurar os seus dispositivos pessoais manualmente. Não o farão. Crie o portal self-service antes do início do ano letivo. Terceiro: teste a capacidade do seu RADIUS sob carga antes de setembro. Uma falha do RADIUS no primeiro dia de aulas é totalmente evitável. A plataforma da Purple suporta estas três vertentes: integração de PKI na nuvem, onboarding self-service de BYOD através do nosso Captive Portal, e uma infraestrutura RADIUS testada em oitenta mil locais ativos com noventa e nove vírgula nove nove nove por cento de uptime. Obrigado por se juntar ao Briefing Técnico da Purple. Para mais orientações, visite purple.ai.

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

header_image.png

Executive Summary

For higher education IT teams, the start of the academic year brings an immediate stress test. Thousands of students arrive on campus with multiple unmanaged devices, expecting instant, secure connectivity. When universities rely on password-based authentication like PEAP-MSCHAPv2, this influx predictably results in massive helpdesk queues, configuration errors, and severe vulnerabilities to credential theft via evil twin access points.

The architectural solution to this scale and security challenge is certificate-based authentication using EAP-TLS. To make certificate deployment viable across tens of thousands of endpoints, universities must implement the Simple Certificate Enrollment Protocol (SCEP). SCEP automates the provisioning of digital certificates to both managed devices via MDM and unmanaged student devices via self-service onboarding portals. This guide details the technical requirements for deploying SCEP in a higher education environment, providing actionable steps to eliminate password-related helpdesk tickets and secure the campus perimeter.

The Architecture of SCEP Certificate Enrollment

Transitioning to certificate-based WiFi requires a fundamental shift from validating user knowledge (a password) to validating device identity (a certificate). The SCEP protocol acts as the bridge between your device management layer and your Public Key Infrastructure (PKI).

scep_architecture_diagram.png

Core Infrastructure Components

A production-ready SCEP deployment requires six integrated components working in sequence:

  1. Identity Provider (IdP): The authoritative directory (Microsoft Entra ID, Okta, or Google Workspace) that verifies the user's identity before certificate issuance.
  2. Mobile Device Management (MDM): Platforms like Microsoft Intune or Jamf that push the SCEP payload to institution-owned devices.
  3. Certificate Authority (CA): The PKI engine that signs and issues the certificates. This can be an on-premises Microsoft ADCS deployment or a cloud-native PKI overlay.
  4. SCEP Gateway: The HTTP endpoint that receives Certificate Signing Requests (CSRs) from devices, validates the challenge password, and forwards the request to the CA.
  5. RADIUS Server: The authentication server that evaluates the presented client certificate against network access policies during the 802.1X EAP-TLS exchange.
  6. Wireless Access Network: The physical access points (Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist) configured to enforce 802.1X authentication.

The SCEP Enrollment Flow

The enrollment process executes without user intervention on managed devices. The MDM platform pushes a configuration profile containing the SCEP gateway URL and a dynamically generated challenge password. The device generates a private key locally and constructs a CSR. It then transmits this CSR to the SCEP gateway over HTTP.

The gateway intercepts the request and validates the challenge password against the MDM API to confirm the device is authorised. Once verified, the gateway forwards the CSR to the CA. The CA signs the certificate and returns it through the gateway to the device. The private key never leaves the endpoint, ensuring cryptographic integrity.

Implementation Guide: A Phased Deployment Strategy

Deploying SCEP requires precise sequencing. Profile dependencies mean that executing these steps out of order will result in authentication failures.

Step 1: Directory Synchronisation and Group Policy

Before touching certificates, ensure your identity store is clean. Create distinct security groups for students, staff, and faculty in Entra ID or Active Directory. Your RADIUS server will use these group memberships, embedded as Subject Alternative Names (SAN) in the certificates, to assign devices to the correct VLANs dynamically.

Step 2: PKI and SCEP Gateway Configuration

Establish your CA hierarchy. If building on-premises, deploy an offline Root CA and an online Issuing CA. For higher education environments looking to reduce infrastructure footprint, cloud PKI solutions offer operational simplicity. Configure the SCEP gateway to communicate with your CA and expose the enrollment endpoint to the network segment where devices will initially connect.

Step 3: RADIUS Server Integration

Import the Issuing CA certificate into your RADIUS server's trusted certificate store. Configure the authentication protocol strictly to EAP-TLS. Define network policies that map certificate attributes (such as the User Principal Name) to specific VLAN return attributes, enabling micro-segmentation across the campus.

Step 4: MDM Profile Sequencing

For institution-owned devices managed by Intune or Jamf, profile deployment order is critical. You must deploy profiles in this exact sequence:

  1. Trusted Certificate Profile: Distributes the Root CA certificate to establish trust.
  2. SCEP Certificate Profile: Directs the device to the gateway to obtain its client certificate.
  3. WiFi Profile: Configures the SSID to use WPA3-Enterprise with EAP-TLS, explicitly referencing the certificate acquired in the previous step.

Step 5: BYOD Self-Service Onboarding

Students will not manually install certificates on their personal devices. You must provide an automated onboarding pathway. Deploy an open SSID that restricts traffic exclusively to the captive portal and the SCEP gateway. When a student connects, the portal prompts them to authenticate via Single Sign-On using their university credentials. Upon successful authentication, the portal provisions the SCEP payload to the device. Purple integrates this onboarding flow directly into the captive portal experience, enabling students to complete enrollment in under two minutes without IT intervention.

Best Practices and Risk Mitigation

Transitioning to EAP-TLS eliminates credential theft, but introduces new operational considerations. Network architects must anticipate scale and lifecycle events.

scep_vs_password_comparison.png

RADIUS Capacity Planning

The computational overhead of EAP-TLS certificate validation is significantly higher than PEAP password checking. During the first week of term, thousands of devices will attempt to authenticate simultaneously. A single RADIUS node will likely exhaust its resources and drop requests, leading to widespread connection failures. You must implement load balancing across multiple RADIUS nodes and increase the authentication timeout on your access points to at least five seconds to accommodate peak latency.

Certificate Lifecycle Management

Certificates for student devices should typically carry a validity period of one to two years. This duration covers the academic cycle while limiting exposure if a device is compromised. Crucially, you must implement a robust revocation mechanism. When a student graduates or reports a lost device, the certificate must be revoked immediately. Ensure your CA publishes a Certificate Revocation List (CRL) or operates an Online Certificate Status Protocol (OCSP) responder, and configure your RADIUS server to check revocation status on every authentication attempt.

Handling Headless IoT Devices

Smart TVs, gaming consoles, and wireless printers in residence halls lack the native 802.1X supplicants required for SCEP enrollment. For these devices, implement MAC Authentication Bypass (MAB). Provide a self-service device registration portal where students can register the MAC addresses of their IoT hardware. The Network Access Control (NAC) system then authenticates these registered addresses and places them into the appropriate student VLAN.

Listen to the Technical Briefing

For a deeper dive into the architecture and real-world deployment scenarios, listen to our 10-minute technical briefing podcast.

ROI and Business Impact

The business case for SCEP deployment in higher education rests on two pillars: security posture and operational efficiency.

From a security perspective, EAP-TLS provides mutual authentication. The device verifies the RADIUS server's certificate before transmitting any data, entirely mitigating the risk of evil twin access points harvesting credentials. This architecture aligns with zero-trust principles, ensuring that only cryptographically verified devices access the campus network.

Operationally, decoupling WiFi authentication from directory passwords yields immediate financial returns. When a university forces a 90-day password reset, students using PEAP must update their credentials on every device. Inevitably, many fail, resulting in a surge of helpdesk tickets. With SCEP and EAP-TLS, the certificate remains valid regardless of password changes. Universities deploying automated certificate onboarding consistently report up to a 70% reduction in WiFi-related support tickets during peak periods, allowing IT staff to focus on strategic initiatives rather than basic connectivity troubleshooting.

Definições Principais

SCEP (Simple Certificate Enrollment Protocol)

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

Essencial para escalar implementações EAP-TLS, pois permite que os MDMs e portais de onboarding aprovisionem certificados em dezenas de milhares de dispositivos de estudantes de forma contínua.

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 como do lado do cliente para autenticação mútua.

Substitui protocolos vulneráveis baseados em palavra-passe, como o PEAP, eliminando o risco de roubo de credenciais através de pontos de acesso falsificados (evil twins).

MDM (Mobile Device Management)

Plataformas de software como o Microsoft Intune ou Jamf utilizadas para administrar e proteger dispositivos pertencentes à instituição.

Utilizado para enviar payloads SCEP e perfis de WiFi de forma silenciosa para dispositivos geridos, garantindo que estão configurados para acesso à rede antes da implementação.

CSR (Certificate Signing Request)

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

Num fluxo de trabalho SCEP, o dispositivo gera a chave privada localmente e envia apenas o CSR para o gateway, garantindo que a chave privada permanece segura no dispositivo final.

RADIUS (Remote Authentication Dial-In User Service)

O protocolo de rede que fornece gestão centralizada de autenticação, autorização e auditoria.

O servidor que avalia o certificado de 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 na qual um atacante configura um ponto de acesso nocivo com o mesmo SSID que a rede legítima para intercetar credenciais de utilizador.

O EAP-TLS previne isto porque o dispositivo cliente verifica o certificado do servidor RADIUS antes de transmitir quaisquer dados; se o atacante não possuir o certificado de servidor confiável, a ligação cai.

MAB (MAC Authentication Bypass)

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

Necessário para a integração de dispositivos IoT autónomos (como consolas de jogos) em residências universitárias que não suportam 802.1X ou SCEP.

CRL (Certificate Revocation List)

Uma lista publicada pela Autoridade de Certificação contendo os números de série dos 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 o acesso de dispositivos roubados ou de alunos graduados seja imediatamente negado.

Exemplos Práticos

Uma universidade com 20.000 estudantes está a migrar de PEAP-MSCHAPv2 para EAP-TLS. Utilizam o Microsoft Intune para 3.000 portáteis Windows pertencentes à universidade, mas os restantes 45.000 dispositivos são BYOD de estudantes (telemóveis, tablets, portáteis pessoais). Como devem desenhar a arquitetura de implementação de certificados para garantir que todos os dispositivos conseguem autenticar-se no primeiro dia de aulas?

A universidade deve implementar uma estratégia de registo bifurcada. Para os 3.000 portáteis geridos pelo Intune, a equipa de TI configura um perfil de Certificado SCEP no Intune, enviando o URL do gateway e a palavra-passe de desafio de forma silenciosa para os dispositivos. Para os 45.000 dispositivos BYOD, implementam um SSID de "Onboarding" aberto que restringe o tráfego a um Captive Portal self-service e ao gateway SCEP. Os estudantes ligam-se ao SSID de Onboarding, autenticam-se através de SSO SAML no Entra ID e descarregam um payload de configuração que aciona o registo SCEP. Assim que o certificado estiver instalado, o dispositivo associa-se automaticamente ao SSID seguro "eduroam" utilizando EAP-TLS.

Comentário do Examinador: Esta abordagem identifica corretamente que o MDM por si só não consegue resolver o desafio do BYOD. Ao tirar partido de um Captive Portal para dispositivos não geridos, a universidade alcança 100% de cobertura de certificados sem exigir que os estudantes configurem manualmente as definições 802.1X, evitando assim uma avalanche de pedidos de suporte.

Durante a primeira semana de aulas, o suporte técnico de uma universidade recebe relatórios de que os estudantes conseguem ligar-se ao WiFi com os seus portáteis, mas as suas colunas inteligentes e consolas de videojogos nas residências universitárias não conseguem ligar-se à rede 802.1X. Como deve o arquiteto de rede resolver isto?

O arquiteto deve implementar o MAC Authentication Bypass (MAB) para dispositivos sem ecrã/teclado. Como as colunas inteligentes e as consolas carecem de suplicantes 802.1X, não conseguem processar payloads SCEP nem apresentar certificados de cliente. A universidade deve implementar um portal self-service de registo de dispositivos onde os estudantes iniciam sessão com as suas credenciais universitárias e introduzem os endereços MAC dos seus dispositivos IoT. O servidor RADIUS é configurado para aceitar estes endereços MAC registados via MAB e atribuí-los à VLAN específica por quarto do estudante.

Comentário do Examinador: Esta solução aborda a limitação técnica dos dispositivos IoT sem ecrã/teclado, mantendo a segmentação da rede. Ao utilizar um portal self-service, a equipa de TI evita a introdução manual de endereços MAC, escalando a solução para acomodar milhares de dispositivos de consumo nas residências universitárias.

Perguntas de Prática

Q1. A sua universidade está a implementar EAP-TLS. Configurou o gateway SCEP e os perfis MDM. No entanto, quando os dispositivos de teste tentam ligar-se ao SSID seguro, a ligação falha silenciosamente. Os registos do RADIUS mostram que o certificado de cliente é válido, mas o dispositivo está a rejeitar o servidor. Qual é o erro de configuração mais provável?

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

Ver resposta modelo

O perfil de Certificado Confiável do MDM está provavelmente em falta ou mal configurado. 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 no seu armazenamento confiável, não conseguirá validar o certificado do servidor e irá interromper a ligação para evitar um potencial Evil Twin Attack.

Q2. Um estudante relata que o seu portátil, que foi registado com sucesso através do portal BYOD e possui um certificado de cliente válido, já não consegue aceder à rede após ter alterado a sua palavra-passe no diretório da universidade. Que falha arquitetónica é que isto indica?

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

Ver resposta modelo

Isto indica que a rede não está realmente a utilizar EAP-TLS, mas está provavelmente a recorrer ao PEAP-MSCHAPv2 ou a outro protocolo baseado em palavra-passe. Se o verdadeiro EAP-TLS estiver configurado, o servidor RADIUS valida a assinatura criptográfica do certificado, desacoplando completamente o acesso à rede da palavra-passe do diretório. O arquiteto de rede deve impor políticas rigorosas de EAP-TLS no servidor RADIUS e desativar protocolos alternativos.

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

Dica: Considere a diferença no processamento computacional entre verificar uma palavra-passe e validar uma cadeia de certificados durante a fase de ligação inicial.

Ver resposta modelo

Os timeouts são causados pelo pesado processamento computacional dos handshakes criptográficos do EAP-TLS durante a sobrecarga inicial de autenticação dos estudantes que regressam. O arquiteto deve aumentar o valor do timeout do RADIUS nos pontos de acesso sem fios (por exemplo, Cisco Meraki ou HPE Aruba) para pelo menos 5 segundos para acomodar a latência, e garantir que o balanceamento de carga está a distribuir uniformemente os pedidos de autenticação total inicial por todos os nós do RADIUS.

Continue a ler esta série

Configuring RADIUS Authentication for Guest and Staff WiFi Networks

Este guia de referência técnica descreve a arquitetura, configuração e implementação de autenticação RADIUS para redes WiFi empresariais de convidados e funcionários. Fornece aos arquitetos de rede e gestores de TI os protocolos exatos, normas de segurança e metodologias de resolução de problemas necessários para construir sistemas de controlo de acesso sem fios seguros e escaláveis.

Ler o guia →

Passpoint e OpenRoaming: Guia Completo

Este guia de referência técnica fornece uma análise abrangente das frameworks Passpoint (Hotspot 2.0) e WBA OpenRoaming em redes WiFi corporativas. Detalha os protocolos de autenticação subjacentes, componentes de arquitetura e estratégias de implementação necessárias para estabelecer uma conectividade de convidados segura e sem atritos. Os arquitetos de rede e líderes de TI aprenderão a desenhar, implementar e resolver problemas destes padrões para eliminar as barreiras de início de sessão manual, mantendo simultaneamente uma segurança de nível empresarial.

Ler o guia →

Como Implementar SCEP para Integração Segura de BYOD e Redes no Ensino Superior

Este guia técnico fornece aos arquitetos de rede e gestores de TI um plano neutro em termos de fornecedor para implementar a emissão de certificados baseada em SCEP para proteger as redes dos campus do ensino superior. Detalha como migrar de PEAP baseado em palavra-passe para 802.1X EAP-TLS, automatizar a integração de BYOD e impor uma segmentação robusta de VLAN.

Ler o guia →