Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication

This guide provides a comprehensive technical reference for IT administrators at Okta-centric organisations who want to extend their cloud identity provider to WiFi authentication using the Okta RADIUS agent. It covers the full authentication architecture, MFA enforcement trade-offs, dynamic VLAN assignment via RADIUS attribute mapping, and the critical decision between password-based EAP-TTLS and certificate-based EAP-TLS. Venue operators and enterprise IT teams will find actionable deployment guidance, real-world case studies from hospitality and retail, and a clear framework for integrating Okta RADIUS alongside dedicated guest WiFi solutions.

📖 11 min de leitura📝 2,672 palavras🔧 2 exemplos práticos❓ 3 questões práticas📚 10 definições principais

Ouça este guia

Ver transcrição do podcast

Bem-vindo ao Purple Technical Briefing. Hoje vamos mergulhar em um tema que está exatamente na interseção entre arquitetura de rede e gestão de identidade: Okta e RADIUS para autenticação de WiFi. Se você é um gerente de TI, um arquiteto de rede ou um diretor de operações de locais físicos, você já conhece a dor de cabeça que é gerenciar credenciais separadas para acesso à rede. Você tem o seu diretório Okta para aplicativos em nuvem, mas talvez o seu WiFi ainda dependa de um servidor Active Directory legado ou, pior, de uma senha WPA2 compartilhada fixada na parede da copa. Hoje, vamos ver como preencher essa lacuna usando o agente Okta RADIUS. Vamos cobrir a arquitetura, como lidar com a Autenticação de Múltiplos Fatores no WiFi, as compensações críticas entre autenticação baseada em senha e baseada em certificado, e como mapear grupos do Okta para atributos RADIUS para atribuição dinâmica de VLAN. Vamos começar.

Vamos começar com a arquitetura. Como o agente Okta RADIUS realmente funciona? O agente Okta RADIUS é uma aplicação leve que você implanta localmente — geralmente em um servidor Windows ou Linux — ou em uma máquina virtual na nuvem. Ele funciona como um proxy. Ele fica entre a sua infraestrutura de rede, como seus pontos de acesso sem fio ou seu controlador de LAN sem fio, e a nuvem do Okta. Quando um usuário tenta se conectar ao seu WiFi corporativo 802.1X, o dispositivo dele envia as credenciais para o ponto de acesso. O ponto de acesso, agindo como o que chamamos de autenticador no modelo 802.1X, encaminha um RADIUS Access-Request para o agente Okta RADIUS através da porta UDP 1812. O agente recebe essa solicitação e a envia de forma segura em um túnel para a nuvem do Okta por meio de uma chamada de API HTTPS. O Okta valida as credenciais, verifica as políticas de login e retorna uma decisão. O agente então traduz isso de volta em uma mensagem RADIUS Access-Accept ou Access-Reject para o ponto de acesso. É uma maneira inteligente de estender o seu provedor de identidade em nuvem até a borda da rede local sem expor seu diretório diretamente à internet.

Agora, a grande pergunta que todos fazem: você pode impor o Okta MFA em conexões WiFi? A resposta curta é sim, mas com ressalvas importantes. O agente Okta RADIUS suporta principalmente o Password Authentication Protocol, ou PAP. Como o PAP envia a senha em texto claro, ela é encapsulada e protegida pelo túnel TLS externo do protocolo EAP, que significa Extensible Authentication Protocol. Essa configuração permite que o agente gerencie os desafios de MFA. Você pode configurar o Okta para enviar uma notificação do Okta Verify para o telefone do usuário ou solicitar que ele adicione um código TOTP — uma Time-Based One-Time Password — à sua senha. No entanto, é aqui que a experiência do usuário entra em conflito com a segurança. Imagine pedir a um funcionário de uma loja de varejo para aprovar uma notificação push toda vez que seu telefone se reconectar ao WiFi da equipe enquanto ele caminha pelo salão de vendas. Isso causa atrito. Além disso, muitos dispositivos modernos desconectam do WiFi se o desafio de MFA demorar muito. Portanto, embora o MFA no WiFi seja tecnicamente possível e suportado pelo Okta, geralmente o recomendamos apenas para acessos altamente privilegiados, como SSIDs de administradores de TI, em vez do WiFi geral da equipe.

Isso nos leva ao trade-off crítico: RADIUS baseado em senha com Okta versus autenticação baseada em certificado, especificamente EAP-TLS. Quando você usa o agente Okta RADIUS com EAP-TTLS ou PAP, você está dependendo de senhas. Senhas podem ser roubadas, sofrer phishing ou ser compartilhadas. Além disso, como acabamos de discutir, adicionar MFA ao WiFi é pouco prático no dia a dia. Por outro lado, o EAP-TLS usa certificados digitais implantados no dispositivo do usuário. Ele fornece autenticação mútua — o dispositivo prova sua identidade para a rede, e a rede prova sua identidade para o dispositivo. Não há senhas para digitar e é altamente resistente a phishing. O problema? O agente Okta RADIUS não atua nativamente como uma Autoridade Certificadora. Se você deseja EAP-TLS, precisa de uma Infraestrutura de Chaves Públicas, ou PKI — soluções como SecureW2, Foxpass ou Microsoft Active Directory Certificate Services — e de uma solução de Gerenciamento de Dispositivos Móveis para distribuir os certificados aos seus endpoints. O Okta ainda pode ser o provedor de identidade que autoriza a emissão do certificado, mas o próprio agente RADIUS não fará o trabalho pesado para o EAP-TLS. Para ambientes BYOD, o Okta RADIUS baseado em senha é rápido e fácil de implantar. Para dispositivos corporativos gerenciados, o EAP-TLS é o padrão ouro.

Vamos passar para um dos recursos mais poderosos: a atribuição dinâmica de VLAN. Em um local de grande porte — um hotel, um estádio, um centro de convenções — você não quer todos os seus funcionários no mesmo segmento de rede. Você quer os terminais de ponto de venda isolados dos tablets da governança, e quer a equipe de TI em uma VLAN de gerenciamento. Como você consegue isso com o Okta? Tudo se resume ao mapeamento de atributos RADIUS. No Okta Admin Console, nas configurações do aplicativo RADIUS, você pode habilitar um recurso chamado "Include groups in RADIUS response". Você especifica quais grupos do Okta devem ser retornados na resposta de autenticação. O Okta passa essa associação de grupo de volta para o seu controlador de rede usando atributos RADIUS padrão — normalmente o Atributo 11 para Filter-ID, ou o Atributo 25 para Class. Seu controlador sem fio ou sistema de Controle de Acesso à Rede, como o Aruba ClearPass ou Cisco ISE, recebe esse nome de grupo. Em seguida, você configura uma política local no controlador que diz, por exemplo, se o Atributo RADIUS 25 for igual a Retail-POS, atribua o cliente à VLAN 40. O controlador envia os atributos de túnel padrão — Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID — para o ponto de acesso, inserindo o usuário dinamicamente na VLAN correta. É uma maneira integrada de aplicar a segmentação de rede baseada puramente na identidade do Okta, o que é extremamente poderoso para a conformidade com padrões como o PCI DSS, que exige segmentação de rede rigorosa em ambientes de dados de portadores de cartão.

Agora, vamos analisar alguns cenários reais de implementação. Considere uma rede hoteleira nacional com propriedades em todo o Reino Unido. Cada propriedade tem uma mistura de funcionários de recepção, governança, alimentos e bebidas, e gerência. Anteriormente, cada propriedade executava seu próprio servidor NPS com um Active Directory local. A equipe de TI gastava um tempo considerável gerenciando contas locais e solucionando falhas de RADIUS. Ao implantar o agente Okta RADIUS em um par de máquinas virtuais redundantes na nuvem, centralizando todas as contas de usuário no Okta e configurando a atribuição de VLAN baseada em grupo, a rede reduziu significativamente os custos operacionais de TI por propriedade. Os funcionários da recepção se autenticam com suas credenciais do Okta e são colocados automaticamente na VLAN de serviços aos hóspedes. A equipe de gerência, que está em um grupo diferente do Okta, entra na VLAN de gerenciamento com acesso aos sistemas de gestão da propriedade. Toda a configuração é gerenciada a partir de um único Okta Admin Console, e o Okta System Log fornece uma trilha de auditoria completa de cada evento de autenticação em todas as propriedades.

Um segundo cenário: uma grande rede de varejo com mais de 300 lojas. Cada loja possui uma rede WiFi para funcionários usada para gerenciamento de estoque, terminais de ponto de venda e operações de back-office. A conformidade com o PCI DSS exige uma segmentação de rede rigorosa entre o ambiente de dados do portador do cartão e o acesso geral dos funcionários. Ao integrar o Okta RADIUS com sua infraestrutura sem fio existente, o varejista mapeia os grupos do Okta — POS-Staff, Inventory-Staff e Store-Management — para três VLANs distintas. Quando um associado da loja se conecta, seu dispositivo é colocado automaticamente na VLAN correta com base em sua associação ao grupo do Okta. Se um funcionário muda de função, a atualização de sua associação ao grupo do Okta altera imediatamente seu acesso à rede na próxima conexão. Sem regras de firewall para atualizar, sem configurações de VLAN para enviar para lojas individuais.

Agora, vamos abordar as recomendações de implementação e as armadilhas comuns. A primeira e mais comum armadilha é ignorar as configurações de timeout. As chamadas de API do Okta levam tempo, especialmente se houver um push de MFA envolvido. Se o timeout do RADIUS do seu controlador sem fio estiver definido para o padrão de três ou cinco segundos, a solicitação expirará antes que o usuário possa tocar em Aprovar em seu telefone. Você deve aumentar o timeout do RADIUS em seu WLC para pelo menos trinta a sessenta segundos. Esta é uma alteração de configuração no lado da rede, não no Okta, e é frequentemente negligenciada. A segunda recomendação é a alta disponibilidade. Nunca implante apenas um agente Okta RADIUS. Implante pelo menos dois agentes em servidores separados e configure seu controlador sem fio para fazer o balanceamento de carga entre eles. Se um servidor ficar inativo para atualização, sua autenticação WiFi continuará ativa. A terceira armadilha: cuidado com o PEAP. O agente Okta RADIUS não suporta PEAP-MSCHAPv2, que é o padrão para muitos ambientes Windows mais antigos. Você deve configurar seus clientes para usar EAP-TTLS com PAP. Isso geralmente requer o envio de um perfil sem fio via Diretiva de Grupo ou MDM, porque o Windows não adota o EAP-TTLS facilmente por padrão. Deixar de fazer isso é o motivo número um para falhas nas implantações.

Hora de uma sessão rápida de perguntas e respostas baseada em dúvidas comuns de clientes. Pergunta um: Podemos usar o Okta RADIUS para WiFi de convidados? Resposta: Não. O Okta é cobrado por usuário e projetado para identidade de força de trabalho. Para WiFi de convidados, você deve usar uma solução de Captive Portal desenvolvida especificamente para isso, que gerencia termos de serviço, login social e análises sem consumir licenças do Okta. Pergunta dois: O Okta RADIUS suporta YubiKeys para autenticação WiFi? Resposta: Geralmente, não. Tokens de hardware e WebAuthn não funcionam bem com o protocolo RADIUS. Utilize o Okta Verify push ou TOTP se você precisar usar MFA no WiFi. Pergunta três: Como isso interage com uma implantação da Purple? Resposta: Muito bem. Clientes corporativos da Purple que usam o Okta como seu provedor de identidade podem usar o Okta RADIUS para autenticar o WiFi da equipe com segurança, enquanto usam o Captive Portal da Purple para acesso de convidados em um SSID separado. Isso posiciona a Purple ao lado do Okta em uma pilha de autenticação moderna e unificada — equipe em um SSID com Okta RADIUS, convidados em outro com o portal personalizado da Purple.

Para resumir o briefing de hoje: O agente Okta RADIUS é uma ferramenta poderosa para eliminar diretórios legados locais e unificar sua autenticação WiFi no seu provedor de identidade em nuvem. Ele suporta atribuição dinâmica de VLAN para uma segmentação de rede robusta, o que é crítico para a conformidade com o PCI DSS e outras estruturas. No entanto, fique atento à experiência do usuário se você exigir MFA no WiFi e lembre-se de que, para dispositivos corporativos totalmente gerenciados, a migração para EAP-TLS baseado em certificado com uma PKI dedicada é a estratégia de longo prazo mais segura. O agente Okta RADIUS é uma excelente solução de transição, especialmente para organizações que são focadas no Okta e desejam estender esse investimento em identidade para a camada de rede rapidamente. Isso é tudo para este briefing. Certifique-se de verificar o guia de referência técnica completo para etapas detalhadas de configuração, diagramas de arquitetura e exemplos práticos. Até a próxima, mantenha suas redes seguras e seus usuários conectados.

Principais conclusões

✓O agente Okta RADIUS faz o proxy de solicitações de autenticação WiFi 802.1X da infraestrutura de rede para a nuvem Okta via HTTPS, permitindo que a identidade em nuvem governe o acesso à rede sem servidores de diretório locais.
✓O agente suporta EAP-TTLS com PAP e EAP-GTC, mas NÃO suporta PEAP-MSCHAPv2 (o padrão do Windows) ou EAP-TLS — os suplicantes dos clientes devem ser reconfigurados via MDM ou GPO antes da implantação.
✓MFA em WiFi é tecnicamente suportado (Okta Verify push, TOTP, SMS), mas exige o aumento do timeout do RADIUS no WLC para 30-60 segundos; é melhor reservá-lo para SSIDs administrativos em vez de WiFi geral de funcionários devido ao atrito de roaming.
✓A atribuição dinâmica de VLAN é obtida ativando 'Include groups in RADIUS response' no Okta e mapeando a Class (Atributo 25) ou Filter-Id (Atributo 11) retornada para os atributos de túnel VLAN (64, 65, 81) no WLC ou dispositivo NAC.
✓Sempre implante no mínimo duas instâncias do agente Okta RADIUS para alta disponibilidade — um único agente é um ponto único crítico de falha para toda a autenticação WiFi na infraestrutura.
✓Para ambientes de dispositivos totalmente gerenciados sujeitos a PCI DSS ou requisitos de alta segurança, o EAP-TLS com uma PKI em nuvem é a arquitetura de longo prazo superior; o Okta RADIUS com EAP-TTLS/PAP é a escolha pragmática para cenários de BYOD ou implantação rápida.
✓O Okta RADIUS é uma ferramenta de identidade de força de trabalho — implante uma solução de Captive Portal de WiFi para visitantes dedicada para acesso de convidados para evitar custos de dimensionamento de licença Okta e manter uma separação clara entre o acesso à rede de funcionários e convidados.

Resumo Executivo

Para equipes de TI corporativas que gerenciam locais distribuídos — de redes de hotéis a estádios —, unificar o controle de acesso à rede com um provedor de identidade em nuvem é um passo crítico em direção ao Zero Trust. O agente Okta RADIUS preenche a lacuna entre a identidade em nuvem moderna e a infraestrutura tradicional de WiFi 802.1X, permitindo que as organizações descontinuem servidores RADIUS locais legados e a infraestrutura do Active Directory para autenticação de rede.

Este guia detalha como implantar o agente Okta RADIUS para autenticação WiFi corporativa, cobrindo a arquitetura de proxy, mecanismos de aplicação de MFA e as compensações entre EAP-TTLS baseado em senha e EAP-TLS baseado em certificado. Ele também fornece orientações práticas sobre o mapeamento de associações de grupo do Okta para atributos RADIUS para atribuição dinâmica de VLAN — uma capacidade que apoia diretamente os requisitos de segmentação de rede do PCI DSS. Ao integrar o Okta para autenticação de funcionários juntamente com soluções de Guest WiFi , os operadores de locais podem obter uma camada de acesso unificada, segura e em conformidade, sem duplicar a infraestrutura de identidade.

Aprofundamento Técnico

Como Funciona o Agente Okta RADIUS

O agente Okta RADIUS é um serviço de sistema leve que atua como um proxy entre os Servidores de Acesso à Rede (NAS) — como pontos de acesso sem fio (WAPs) ou controladores de LAN sem fio (WLCs) — e a nuvem Okta. Ele é normalmente implantado em um servidor Windows ou Linux local ou dentro de uma VPC na nuvem, e é gerenciado inteiramente a partir do Okta Admin Console após a instalação inicial.

O fluxo de autenticação segue um modelo de proxy 802.1X padrão. O dispositivo de um usuário (o suplicante) conecta-se a um SSID corporativo e apresenta as credenciais. O WAP ou WLC (o autenticador) encaminha um Access-Request RADIUS para o agente Okta RADIUS através da porta UDP 1812. O agente canaliza essa solicitação de forma segura para a nuvem Okta por meio de uma chamada de API HTTPS, onde o mecanismo de política do Okta avalia as credenciais em relação ao seu diretório de usuários e a quaisquer políticas de login configuradas. Se a autenticação for bem-sucedida, o agente retorna uma mensagem Access-Accept do RADIUS para o autenticador, incluindo opcionalmente atributos RADIUS para autorização, como atribuição de VLAN. Se o MFA for exigido, o agente envia um Access-Challenge do RADIUS de volta ao cliente, solicitando um segundo fator antes que a decisão final seja retornada.

Este modelo de proxy significa que o agente Okta RADIUS não precisa armazenar credenciais de usuário localmente. Toda a lógica de autenticação, avaliação de políticas e registro de auditoria ocorrem na nuvem Okta, oferecendo aos administradores um painel único para governança de identidade tanto em aplicativos em nuvem quanto no acesso à rede.

Protocolos EAP Suportados e Limitações Críticas

Uma restrição arquitetônica fundamental do agente Okta RADIUS é sua dependência do Password Authentication Protocol (PAP) para autenticação primária. Embora o PAP transmita senhas em texto simples na camada interna, isso é encapsulado e protegido pelo túnel TLS externo do Extensible Authentication Protocol (EAP). Os protocolos externos suportados são EAP-TTLS (com PAP como método interno) e EAP-GTC. Para uma comparação mais detalhada dos métodos EAP, consulte o guia de referência Comparativa de métodos EAP: PEAP, EAP-TLS, EAP-TTLS y EAP-FAST .

Criticamente, PEAP-MSCHAPv2 não é suportado. Este é o protocolo 802.1X padrão para clientes Windows e muitos ambientes corporativos legados. As organizações que estão migrando de uma configuração tradicional de RADIUS NPS/Active Directory devem reconfigurar seus suplicantes de cliente para usar EAP-TTLS com PAP — uma mudança que normalmente exige um perfil de WiFi enviado via MDM ou Diretiva de Grupo. Não planejar essa mudança é a causa mais comum de falhas em implantações do Okta RADIUS.

EAP-TLS, que depende inteiramente de autenticação mútua baseada em certificados, também não é suportado nativamente pelo agente Okta RADIUS. Organizações que necessitam de EAP-TLS devem implantar uma PKI dedicada ou uma solução de RADIUS em nuvem que se integre ao Okta como IdP via SAML ou OIDC, em vez de usar o agente Okta RADIUS diretamente.

Imposição de MFA em Conexões WiFi

O agente Okta RADIUS suporta MFA para acesso WiFi, mas apresenta desafios de experiência do usuário que devem ser cuidadosamente considerados antes da implantação. Quando uma política de MFA é acionada, o agente envia um Access-Challenge RADIUS para o cliente. O Okta suporta vários fatores para aplicações RADIUS:

Fator MFA	PAP	EAP-TTLS	Notas
Okta Verify Push	Suportado	Suportado	Enviado fora de banda; o usuário toca em Aprovar no celular
TOTP (Okta Verify / Google Auth)	Suportado	Suportado	O usuário anexa o OTP à senha (ex: `Pass123,456789`)
SMS / E-mail / Voz	Suportado	Suportado	O usuário envia a string de ativação (SMS, EMAIL, CALL) primeiro
Duo Push / SMS / Passcode	Suportado	Suportado	Duo passcode apenas para EAP-TTLS
YubiKey / U2F / Windows Hello	Não Suportado	Não Suportado	Tokens de hardware incompatíveis com o protocolo RADIUS

A restrição prática é o roaming. Em ambientes de Hospitality , o tablet de um camareiro pode fazer roaming entre pontos de acesso dezenas de vezes por turno, acionando a reautenticação a cada vez. Exigir uma aprovação de notificação push a cada roaming é operacionalmente inviável. Para o WiFi geral da equipe, políticas de senha fortes combinadas com a confiança de dispositivos do Okta e políticas de zona de rede são normalmente preferidas em vez de solicitações ativas de MFA. O MFA no WiFi deve ser reservado para SSIDs administrativos ou cenários de acesso de alto privilégio.

Autenticação Baseada em Senha vs. Baseada em Certificado

A escolha entre RADIUS baseado em senha (via agente Okta RADIUS) e EAP-TLS baseado em certificado é uma das decisões mais consequentes em uma implantação de WiFi corporativo. As compensações não se referem apenas à segurança; elas envolvem complexidade de implantação, maturidade de gerenciamento de dispositivos e sobrecarga operacional.

A autenticação baseada em senha via agente Okta RADIUS oferece um caminho rápido para a identidade unificada. Se a sua organização já gerencia usuários no Okta, a implantação pode ser concluída em horas, em vez de semanas. Não há PKI para construir, nem certificados para distribuir e nenhuma dependência de MDM. A contrapartida é que as senhas continuam sendo a credencial primária, e a ausência de autenticação mútua significa que o cliente não pode verificar criptograficamente a identidade da rede — um vetor para ataques de "evil twin" em ambientes de alto risco.

O EAP-TLS baseado em certificado elimina totalmente as senhas da equação de autenticação WiFi. O cliente apresenta um certificado de dispositivo e o servidor RADIUS apresenta um certificado de servidor, fornecendo autenticação mútua. Esta é a abordagem recomendada para IEEE 802.1X em redes WPA3-Enterprise, particularmente em ambientes sujeitos a PCI DSS ou NCSC Cyber Essentials Plus. O pré-requisito é uma PKI funcional — seja uma implantação local do Microsoft ADCS ou um serviço de PKI em nuvem — e uma plataforma MDM capaz de distribuir certificados para todos os endpoints gerenciados. Para ambientes de Varejo com centenas de dispositivos de ponto de venda gerenciados, esse investimento é totalmente justificado. Para ambientes com forte presença de BYOD ou implantações rápidas, o Okta RADIUS com EAP-TTLS é a escolha pragmática.

Mapeamento de Atributos RADIUS para Atribuição Dinâmica de VLAN

A atribuição dinâmica de VLAN é onde a integração do Okta RADIUS entrega seu valor operacional mais tangível. Ao mapear a associação de grupos do Okta para atributos RADIUS, os administradores de rede podem aplicar a segmentação de rede baseada em funções sem a necessidade de manter políticas de VLAN separadas por dispositivo ou por local.

O Okta passa os dados de associação de grupo na mensagem Access-Accept do RADIUS usando um de três atributos, configuráveis nas Configurações Avançadas de RADIUS do aplicativo Okta:

Atributo 11 (Filter-Id): Um atributo de string contendo o nome do grupo. Amplamente suportado por diversos fornecedores.
Atributo 25 (Class): Um atributo opaco usado para autorização. Suportado por Cisco ISE, Aruba ClearPass e Fortinet.
Atributo 26 (Vendor-Specific): Permite subatributos específicos do fornecedor para um controle mais granular.

O controlador de rede (WLC, dispositivo NAC) recebe o nome do grupo Okta no atributo escolhido e o mapeia para os atributos de túnel RADIUS padrão necessários para a atribuição de VLAN:

Atributo RADIUS	Valor	Finalidade
64 (Tunnel-Type)	13 (VLAN)	Especifica o tunelamento de VLAN
65 (Tunnel-Medium-Type)	6 (802)	Especifica o meio IEEE 802
81 (Tunnel-Private-Group-ID)	ex: `40`	O ID da VLAN de destino

Por exemplo, um usuário no grupo do Okta Retail-POS-Staff teria Class: Retail-POS-Staff retornado no Access-Accept. A política do WLC mapearia isso para Tunnel-Private-Group-ID: 40, colocando o dispositivo na VLAN 40 — a rede de POS isolada. Um usuário em Store-Management seria colocado na VLAN 50. Essa lógica é aplicada na borda da rede, não no Okta, mas é orientada inteiramente pela associação ao grupo do Okta.

Guia de Implementação

Passo 1: Implantar o Okta RADIUS Agent (Alta Disponibilidade)

Implante o Okta RADIUS agent em no mínimo dois servidores — localmente ou em uma VPC na nuvem — para garantir alta disponibilidade. Implantações com um único agente representam um risco crítico: se o servidor estiver indisponível para atualizações ou sofrer uma falha, toda a autenticação WiFi 802.1X falhará em toda a infraestrutura. Configure seu WLC ou dispositivo NAC para balancear a carga das solicitações RADIUS entre ambos os agentes.

Durante a instalação, o agente solicitará o login de um administrador do Okta para autorizar o agente e vinculá-lo ao tenant do Okta. Uma vez autorizado, o agente aparece no Okta Admin Console em Settings > Downloads > RADIUS Agent Status, onde a integridade e a conectividade podem ser monitoradas.

Passo 2: Configurar o Aplicativo RADIUS no Okta

No Okta Admin Console, navegue até Applications > Applications e pesquise no catálogo de aplicativos por RADIUS Application.
Adicione o aplicativo, atribua um nome descritivo (ex: Corporate-WiFi-Staff) e clique em Next.
Na guia Sign On, configure a RADIUS Port (padrão 1812) e gere um Shared Secret forte e gerado aleatoriamente com pelo menos 32 caracteres.
Em Advanced RADIUS Settings, ative Accept password and security token in the same login request se pretender oferecer suporte a TOTP anexado a senhas.
Opcionalmente, ative Permit Automatic Push for Okta Verify Enrolled Users para MFA baseado em push contínuo.
Atribua o aplicativo aos grupos relevantes do Okta que representam sua equipe.

Passo 3: Configurar Atribuição de VLAN Baseada em Grupo

Nas configurações de Sign On do aplicativo RADIUS, clique em Edit na seção Advanced RADIUS Settings.
Marque Include groups in RADIUS response.
Selecione o atributo RADIUS: 25 Class é recomendado para ambientes Aruba e Cisco; 11 Filter-Id para Fortinet e outros.
Adicione os nomes dos grupos específicos do Okta a serem incluídos (ex: Retail-POS-Staff, Store-Management, IT-Admins).
No seu WLC ou dispositivo NAC, crie políticas de aplicação que mapeiem cada nome de grupo para os atributos de túnel VLAN correspondentes.

Passo 4: Configurar Supplicants de Clientes

Como o PEAP-MSCHAPv2 não é suportado, os dispositivos clientes devem ser configurados para usar EAP-TTLS com PAP como o método interno. Implante um perfil de rede sem fio por meio de sua plataforma MDM (por exemplo, Microsoft Intune, Jamf Pro) ou por meio de Objetos de Diretiva de Grupo (GPO) para dispositivos ingressados no domínio Windows. O perfil deve especificar:

SSID: O nome do seu SSID corporativo
Segurança: WPA2-Enterprise ou WPA3-Enterprise
Método EAP: EAP-TTLS
Autenticação Interna: PAP
Validação de Certificado do Servidor: Ativado (vincular ao CN do certificado do servidor do seu agente RADIUS)

Passo 5: Configurar Tempos Limite (Timeouts) do RADIUS

Aumente o tempo limite do RADIUS no seu WLC do padrão de 3-5 segundos para 30-60 segundos. Isso é crítico se as notificações push de MFA estiverem em uso, pois o usuário deve ter tempo suficiente para aprovar a notificação em seu dispositivo antes que o WLC abandone a tentativa de autenticação.

Melhores Práticas

A implantação do Okta RADIUS para autenticação de WiFi é simples, mas várias melhores práticas operacionais separam uma implantação de produção resiliente de uma prova de conceito frágil.

Segmente o tráfego de convidados e funcionários no nível do SSID. O Okta RADIUS é uma ferramenta de identidade de força de trabalho. Para acesso de visitantes e convidados, implante uma solução de Captive Portal dedicada. Isso evita que os custos de licença da Okta aumentem com o volume de convidados e garante uma separação clara de responsabilidades. Os clientes corporativos da Purple podem implantar o Guest WiFi em um SSID separado enquanto usam o Okta RADIUS para autenticação de funcionários na mesma infraestrutura física.

Use um dispositivo NAC para ambientes de políticas complexas. Se o seu ambiente exigir acesso condicional com base na postura do dispositivo, filtragem de endereço MAC ou status do certificado junto com a identidade do usuário, implante um dispositivo NAC intermediário (Aruba ClearPass, Cisco ISE ou Portnox) para fazer o proxy das solicitações para o agente Okta RADIUS. O dispositivo NAC pode enriquecer a resposta RADIUS com atributos de túnel adicionais que o agente Okta sozinho não consegue gerar.

Monitore por meio do Okta System Log. Cada evento de autenticação — sucesso, falha, desafio de MFA e tipo de fator — é registrado no Okta System Log. Configure o streaming de logs para o seu SIEM para alertas em tempo real sobre anomalias de autenticação. Isso é particularmente valioso para organizações de Saúde e do setor público sujeitas a requisitos de auditoria.

Rotacione segredos compartilhados em um cronograma. O segredo compartilhado entre o aplicativo Okta RADIUS e seu NAS é uma credencial de segurança crítica. Implemente um cronograma de rotação (recomenda-se trimestralmente) e atualize o aplicativo Okta e a configuração do WLC/NAC simultaneamente.

Restrinja os endereços de serviço RADIUS. Na configuração do agente Okta RADIUS, restrinja quais endereços IP têm permissão para enviar solicitações RADIUS. Isso evita que dispositivos NAS não autorizados tentem autenticação contra o seu locatário Okta. For guidance on the broader network architecture context, see The Core SD WAN Benefits for Modern Businesses and Wireless Access Points Definition Your Ultimate 2026 Guide .

Troubleshooting & Risk Mitigation

The following table summarises the most common failure modes encountered in Okta RADIUS WiFi deployments and their recommended mitigations.

Failure Mode	Root Cause	Mitigation
Authentication Timeouts	WLC RADIUS timeout too short for Okta API or MFA response	Increase WLC RADIUS timeout to 30-60 seconds
Windows Clients Rejected	Windows defaults to PEAP-MSCHAPv2, which Okta RADIUS rejects	Push EAP-TTLS/PAP wireless profile via MDM or GPO
Users in Wrong VLAN	Okta group name mismatch or missing tunnel attributes on WLC	Verify WLC maps `Class`/`Filter-Id` to `Tunnel-Private-Group-ID`; check Okta System Log
Agent Unreachable	Server offline, API token expired, or firewall blocking HTTPS to Okta	Deploy redundant agents; monitor agent status in Okta Admin Console; verify outbound HTTPS
MFA Push Not Delivered	User not enrolled in Okta Verify, or mobile device offline	Enforce Okta Verify enrolment policy; consider TOTP as fallback
Certificate Validation Errors	Client cannot validate RADIUS server certificate	Pin server certificate CN in client wireless profile; ensure CA chain is trusted
VLAN Attributes Not Sent	Okta group not included in RADIUS response configuration	Verify group is listed in Advanced RADIUS Settings; confirm user is a member of the group in Okta

For Transport and public-sector environments where network uptime is mission-critical, implement synthetic monitoring that periodically tests RADIUS authentication end-to-end and alerts on failure before users are impacted.

ROI & Business Impact

The business case for Okta RADIUS WiFi authentication rests on three pillars: operational efficiency, security posture improvement, and compliance readiness.

Operational Efficiency. Consolidating WiFi authentication into Okta eliminates the need to maintain separate on-premises RADIUS infrastructure (NPS servers, local AD) at each venue or site. For a hotel chain with 50 properties, this can represent a significant reduction in per-site infrastructure costs and IT support overhead. User provisioning and deprovisioning become atomic: adding a user to the correct Okta group grants both application access and the appropriate WiFi VLAN access simultaneously. When an employee leaves, deactivating their Okta account immediately revokes WiFi access across all sites.

Postura de Segurança. A substituição de senhas de WiFi PSK compartilhadas pela autenticação 802.1X por usuário elimina o compartilhamento de credenciais, um vetor comum para ameaças internas e acessos não autorizados. Combinado com a atribuição dinâmica de VLAN, isso reforça o princípio do menor privilégio na camada de rede. O Okta System Log fornece uma trilha de auditoria completa e inviolável de cada evento de autenticação WiFi, o que é essencial para a resposta a incidentes.

Prontidão de Conformidade. O Requisito 8.3 do PCI DSS 4.0 exige MFA para todo acesso administrativo que não seja via console. O Requisito 1.3 exige a segmentação de rede entre o ambiente de dados do portador do cartão e outras redes. O Okta RADIUS com atribuição de VLAN baseada em grupo atende diretamente a ambos os requisitos. Para a conformidade com a GDPR, o Okta System Log fornece os registros de acesso necessários para demonstrar os controles técnicos apropriados sobre os sistemas de processamento de dados pessoais. Para estabelecimentos que implantam Modern Hospitality WiFi Solutions , essa abordagem unificada de identidade e acesso à rede é cada vez mais um pré-requisito para compras corporativas.

As organizações que concluíram essa integração geralmente relatam uma redução nos chamados de suporte de TI relacionados ao WiFi (menos solicitações de redefinição de senha, menos incidentes de configuração incorreta de VLAN) e uma melhoria mensurável nas pontuações de auditoria de segurança. O investimento na implantação e configuração do agente Okta RADIUS — normalmente medido em dias, e não em semanas, para uma implantação em um único local — proporciona economias operacionais contínuas que se acumulam em uma infraestrutura distribuída.

Definições principais

Okta RADIUS Agent

Um serviço de proxy leve local ou hospedado na nuvem que traduz solicitações de autenticação RADIUS da infraestrutura de rede (pontos de acesso, WLCs) em chamadas de API do Okta, permitindo que a nuvem do Okta funcione como o backend de autenticação para WiFi 802.1X.

As equipes de TI encontram isso ao implantar a autenticação WiFi corporativa apoiada pelo Okta. É o componente de ponte crítico entre a infraestrutura de rede legada baseada em RADIUS e a identidade em nuvem moderna.

802.1X

Um padrão IEEE para Controle de Acesso à Rede (NAC) baseado em porta que define uma estrutura de autenticação para redes cabeadas e sem fio. Ele usa o Extensible Authentication Protocol (EAP) para transportar credenciais de autenticação entre o suplicante (dispositivo), o autenticador (AP/switch) e o servidor de autenticação (RADIUS).

O 802.1X é a base da segurança de WiFi corporativo. Qualquer implantação que use WPA2-Enterprise ou WPA3-Enterprise utiliza o 802.1X. As equipes de TI devem entender o modelo de três partes (suplicante, autenticador, servidor de autenticação) para solucionar problemas de conectividade.

EAP-TTLS (Extensible Authentication Protocol - Tunnelled Transport Layer Security)

Um método EAP que estabelece um túnel TLS usando apenas um certificado do lado do servidor e, em seguida, transporta um protocolo de autenticação interno mais simples (como o PAP) dentro do túnel. Isso protege as credenciais internas contra interceptação, exigindo apenas a infraestrutura de certificado do lado do servidor.

O EAP-TTLS com PAP é o protocolo recomendado para autenticação WiFi Okta RADIUS. Ele é mais seguro do que o PAP puro, mas não exige certificados do lado do cliente, tornando-o prático para ambientes BYOD e de dispositivos mistos.

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

Um método EAP que usa autenticação mútua baseada em certificados — tanto o cliente quanto o servidor apresentam certificados digitais. É o método 802.1X mais seguro, fornecendo autenticação sem senha e resistente a phishing.

O EAP-TLS é o padrão de excelência para ambientes de dispositivos corporativos gerenciados. Ele exige uma infraestrutura PKI e MDM para distribuição de certificados. O agente Okta RADIUS não oferece suporte nativo ao EAP-TLS; é necessário um serviço de PKI em nuvem ou RADIUS dedicado.

PAP (Password Authentication Protocol)

Um protocolo de autenticação simples que transmite nomes de usuário e senhas em texto simples. No contexto do 802.1X, o PAP é usado como o método de autenticação interno dentro de um túnel EAP-TTLS, onde a camada TLS externa fornece a criptografia.

O PAP é o principal mecanismo de autenticação suportado pelo agente Okta RADIUS. As equipes de TI devem entender que o PAP sozinho é inseguro, mas o PAP dentro do EAP-TTLS é aceitável para WiFi corporativo quando o certificado do servidor é validado corretamente.

Dynamic VLAN Assignment

Uma técnica de controle de acesso à rede na qual um servidor RADIUS retorna atributos de atribuição de VLAN na mensagem Access-Accept, fazendo com que o controlador sem fio ou switch coloque o cliente autenticado em uma VLAN específica com base em sua identidade ou associação de grupo, em vez de uma VLAN estática por SSID.

A atribuição dinâmica de VLAN é essencial para a segmentação de rede em ambientes com múltiplas funções (por exemplo, separar terminais de PDV dos dispositivos da equipe geral). Ela é configurada retornando os atributos RADIUS 64, 65 e 81 na mensagem Access-Accept.

RADIUS Attribute 25 (Class)

Um atributo RADIUS padrão usado para passar dados de autorização arbitrários do servidor de autenticação para o NAS. O Okta usa esse atributo para retornar informações de associação de grupo do Okta para o controlador sem fio, que pode então usá-las para atribuição de VLAN ou decisões de política de acesso.

As equipes de TI que configuram a atribuição de VLAN baseada em grupo do Okta configurarão o WLC para ler o valor do atributo Class e mapeá-lo para um ID de VLAN. O atributo exato a ser usado (11, 25 ou 26) depende da documentação do fornecedor do WLC.

NAS (Network Access Server)

Na terminologia RADIUS, o NAS é o dispositivo de rede que recebe a solicitação de conexão do usuário e a encaminha para o servidor RADIUS para autenticação. Em implantações de WiFi, o NAS é normalmente o ponto de acesso sem fio ou o controlador de LAN sem fio.

O NAS é o autenticador no modelo 802.1X. As equipes de TI devem configurar o NAS com o endereço IP do servidor RADIUS, a porta e o segredo compartilhado. O endereço IP do NAS deve ser incluído na lista de permissões na configuração de filtragem de endereço de serviço do agente Okta RADIUS.

Shared Secret

Uma senha pré-compartilhada usada para autenticar mensagens RADIUS entre o NAS (WLC/AP) e o servidor RADIUS (agente Okta RADIUS). É usada para calcular um hash Message-Authenticator que verifica a integridade dos pacotes RADIUS.

O segredo compartilhado deve ser idêntico tanto na configuração do aplicativo Okta RADIUS quanto na entrada do servidor RADIUS do WLC/NAC. Ele deve ter pelo menos 32 caracteres, ser gerado aleatoriamente e rotacionado regularmente. Uma divergência é uma causa comum de falhas de autenticação RADIUS.

MFA Challenge (RADIUS Access-Challenge)

Um tipo de mensagem RADIUS enviada pelo servidor de autenticação ao NAS quando fatores de autenticação adicionais são necessários. O NAS retransmite o desafio para o cliente, que deve responder com o fator apropriado (por exemplo, OTP, aprovação por push) antes que a autenticação possa ser concluída.

O mecanismo Access-Challenge é como o Okta impõe o MFA via RADIUS. As equipes de TI devem garantir que o WLC ofereça suporte à troca de desafio-resposta e que o tempo limite do RADIUS seja longo o suficiente para o usuário concluir a etapa de MFA.

Exemplos práticos

Uma rede de hotéis com 150 propriedades usa atualmente servidores NPS locais em cada propriedade para autenticação WiFi de funcionários via 802.1X. Cada servidor NPS está associado a um domínio local do Active Directory. A equipe de TI deseja centralizar o gerenciamento de identidade no Okta e eliminar a infraestrutura de NPS por propriedade. Como eles devem abordar a migração?

A abordagem recomendada é uma migração em fases usando o agente Okta RADIUS implantado em uma VPC em nuvem centralizada, em vez de em cada propriedade. Fase 1: Implante duas instâncias do agente Okta RADIUS em uma VPC em nuvem (por exemplo, AWS ou Azure) na mesma região que a maioria das propriedades. Configure os agentes para escutar na porta UDP 1812. Fase 2: Para cada propriedade, adicione os IPs do agente Okta RADIUS como servidores RADIUS secundários no WLC, mantendo o NPS existente como primário. Isso permite a operação e os testes em paralelo sem interromper a autenticação ativa. Fase 3: Migre os usuários do AD local para o Okta. Use o agente AD do Okta para sincronizar as contas existentes inicialmente e, em seguida, mude progressivamente para o Okta como a fonte autoritativa. Fase 4: Para cada propriedade, configure o WLC para usar EAP-TTLS/PAP e envie o novo perfil sem fio para os dispositivos dos funcionários via MDM. Fase 5: Assim que todos os dispositivos forem confirmados no EAP-TTLS, altere a prioridade do RADIUS no WLC para os agentes Okta como primários e desative os servidores NPS. Configure os grupos do Okta (Front-Desk, Housekeeping, F&B, Management, IT-Admins) e ative a atribuição de VLAN baseada em grupo usando o Atributo 25 (Class). Mapeie cada grupo para a VLAN apropriada no WLC. Aumente o timeout do RADIUS no WLC para 45 segundos para acomodar a latência da API do Okta.

Comentário do examinador: Esta abordagem em fases é preferível porque elimina o risco de uma transição abrupta em 150 propriedades simultaneamente. Executar o NPS e o Okta RADIUS em paralelo durante o período de transição significa que qualquer configuração incorreta pode ser detectada e corrigida sem impactar os usuários ativos. A implantação dos agentes RADIUS em uma VPC em nuvem é arquitetonicamente superior à implantação por propriedade porque centraliza o gerenciamento, reduz a pegada de infraestrutura e garante a aplicação consistente de políticas, independentemente de qual propriedade o usuário se autentique. O principal risco a ser mitigado é a latência de WAN entre a propriedade e a VPC em nuvem — a autenticação RADIUS deve ser concluída em menos de 2 segundos para uma boa experiência do usuário, portanto, a seleção da região da VPC deve minimizar o tempo de ida e volta (RTT).

Uma rede varejista nacional com 320 lojas precisa obter a conformidade com o PCI DSS 4.0 para o seu WiFi de funcionários. Os associados da loja usam dispositivos portáteis para gerenciamento de inventário, e um conjunto separado de dispositivos lida com transações de ponto de venda. A rede usa o Okta para toda a identidade da força de trabalho. Como eles implementam a segmentação de VLAN usando o Okta RADIUS para atender aos requisitos de segmentação de rede do PCI DSS?

Crie três grupos no Okta: POS-Staff (para funcionários que operam terminais de PDV), Inventory-Staff (para associados de estoque e loja) e Store-Management. No aplicativo Okta RADIUS, ative "Include groups in RADIUS response" e selecione o Atributo 25 (Class). Adicione todos os três grupos à configuração de resposta. No controlador sem fio de cada loja (ou centralmente via um WLC em nuvem), crie três políticas de aplicação: (1) Se Class = POS-Staff, atribua Tunnel-Private-Group-ID = 40 (a VLAN de PDV, que está no escopo do PCI DSS e possui regras de firewall que restringem o acesso apenas ao processador de pagamentos). (2) Se Class = Inventory-Staff, atribua Tunnel-Private-Group-ID = 50 (a VLAN de inventário, fora do escopo do PCI). (3) Se Class = Store-Management, atribua Tunnel-Private-Group-ID = 60 (a VLAN de gerenciamento com acesso aos sistemas de gestão da loja). Os dispositivos que se conectam com as credenciais de um usuário no grupo POS-Staff são colocados automaticamente na VLAN 40. Se a função de um associado de loja mudar, a atualização de sua associação ao grupo do Okta altera imediatamente sua atribuição de VLAN na próxima conexão — sem necessidade de reconfiguração do WLC. Documente o mapeamento de grupo do Okta para VLAN no diagrama de segmentação de rede para a auditoria do PCI DSS QSA.

Comentário do examinador: Esta implementação atende diretamente ao Requisito 1.3 (segmentação de rede) e ao Requisito 7 (controle de acesso baseado na necessidade de negócios) do PCI DSS 4.0. O ponto crítico é que a atribuição de VLAN é orientada pela identidade, não pelo endereço MAC do dispositivo ou pela configuração estática de VLAN — o que significa que ela se escala por 320 lojas sem a manutenção de políticas de VLAN por loja. O QSA desejará ver evidências de que a VLAN de PDV está genuinamente isolada de outros segmentos de rede, portanto, as configurações do WLC e do firewall devem refletir os limites da VLAN. O System Log do Okta fornece a trilha de auditoria de autenticação exigida pelo Requisito 10 do PCI DSS (registro e monitoramento). Uma ressalva importante: se os dispositivos de PDV não forem gerenciados ou forem compartilhados (ou seja, não atribuídos a um usuário específico), considere o uso de MAC Authentication Bypass (MAB) para esses dispositivos em vez do 802.1X, utilizando o Okta RADIUS apenas para dispositivos autenticados por usuário.

Questões práticas

Q1. Um centro de convenções de médio porte usa o Okta para todo o gerenciamento de identidade da equipe. Eles desejam implantar o WiFi 802.1X para a equipe usando seus pontos de acesso Cisco Meraki existentes. Seus laptops Windows são gerenciados via Microsoft Intune. O gerente de TI deseja impor o MFA por push do Okta Verify para todas as conexões WiFi. Quais são as três etapas de configuração mais críticas que eles devem concluir e qual é o modo de falha mais provável se ignorarem alguma delas?

Dica: Considere a compatibilidade do protocolo EAP entre o Okta RADIUS e os padrões do Windows, a configuração de timeout do RADIUS e a configuração do perfil wireless do cliente.

Ver resposta modelo

As três etapas críticas são: (1) Implantar um perfil wireless via Intune que configure os clientes Windows para usar EAP-TTLS com PAP como método interno — o Windows usa PEAP-MSCHAPv2 por padrão, o qual o agente Okta RADIUS não suporta, fazendo com que todas as tentativas de autenticação sejam rejeitadas. (2) Aumentar o timeout do RADIUS do Cisco Meraki de 5 segundos (padrão) para pelo menos 45-60 segundos — sem isso, a solicitação de autenticação expirará antes que o usuário possa aprovar a notificação push do Okta Verify. (3) Habilitar 'Permit Automatic Push for Okta Verify Enrolled Users' nas configurações avançadas de RADIUS do aplicativo Okta RADIUS — sem isso, os usuários podem ser solicitados a selecionar manualmente seu fator de MFA em vez de receberem um push automático. O modo de falha mais provável se a etapa 1 for ignorada é uma falha completa de autenticação para todos os dispositivos Windows. Se a etapa 2 for ignorada, a autenticação falhará intermitentemente para usuários que levam mais de 5 segundos para aprovar o push. Se a etapa 3 for ignorada, os usuários experimentarão uma solicitação de desafio confusa em vez de uma notificação push contínua.

Q2. A equipe de segurança de uma grande rede de varejo sinalizou que sua implantação atual do Okta RADIUS WiFi usa um único servidor de agente RADIUS. Durante uma janela de atualização recente, o servidor ficou offline por 45 minutos, fazendo com que a autenticação WiFi falhasse em todas as 80 lojas. Quais mudanças de arquitetura a equipe de TI deve implementar para evitar isso e quais são as duas opções de implantação para os agentes?

Dica: Considere tanto a topologia de implantação do agente quanto a configuração do WLC necessária para suportar redundância.

Ver resposta modelo

A equipe de TI deve implantar no mínimo duas instâncias do agente Okta RADIUS e configurar o WLC em cada loja para usar ambos os agentes. Existem duas opções de implantação: Opção A (VMs em Nuvem Centralizadas) — implantar ambos os agentes em uma VPC na nuvem (por exemplo, AWS ou Azure), idealmente em zonas de disponibilidade diferentes. O WLC em cada loja aponta para ambos os IPs de nuvem, com um como primário e outro como secundário (ou com balanceamento de carga ativado). Isso minimiza a infraestrutura por site, mas introduz dependência de WAN. Opção B (Par Redundante Local) — implantar dois servidores de agentes em um data center central ou instalação de co-location, com o WLC usando failover de RADIUS. No WLC, configure o servidor RADIUS primário como Agente 1 e o secundário como Agente 2, com um timeout de failover de 3-5 segundos. Ative a 'Detecção de Servidor Morto' se suportada pelo fornecedor do WLC. Além disso, a equipe de TI deve configurar o monitoramento de integridade no Okta Admin Console e configurar alertas se um agente ficar offline. Para lojas com servidores locais, um agente local pode servir como um fallback terciário para resiliência contra interrupções de WAN.

Q3. Uma organização empresarial está avaliando se deve usar o agente Okta RADIUS com EAP-TTLS/PAP ou investir em uma solução de PKI em nuvem para EAP-TLS para o seu WiFi corporativo. Eles têm 2.000 dispositivos Windows e macOS gerenciados registrados no Microsoft Intune e estão sujeitos ao PCI DSS 4.0. Qual é a abordagem recomendada e qual é a principal justificativa de segurança?

Dica: Considere os requisitos do PCI DSS, a maturidade do gerenciamento de dispositivos (todos os dispositivos são registrados em MDM) e as propriedades de segurança de cada método de autenticação.

Ver resposta modelo

A abordagem recomendada é investir em EAP-TLS com uma solução de PKI em nuvem. A principal justificativa de segurança é a autenticação mútua: o EAP-TLS exige que tanto o cliente quanto o servidor RADIUS apresentem certificados digitais, o que significa que o dispositivo prova criptograficamente sua identidade para a rede e a rede prova sua identidade para o dispositivo. Isso elimina o risco de ataques de evil twin (onde um AP invasor se passa pelo SSID corporativo) e remove completamente as senhas da equação de autenticação WiFi, eliminando o roubo de credenciais e o phishing como vetores de ataque. Para o PCI DSS 4.0, o EAP-TLS atende implicitamente ao Requisito 8.3 (MFA para acesso administrativo fora do console) por meio de autenticação baseada em certificado e suporta o modo WPA3-Enterprise de 192 bits (Requisito 4.2.1 para criptografia forte). O pré-requisito — todos os 2.000 dispositivos registrados no Intune — já foi atendido, tornando a distribuição de certificados via perfis SCEP do Intune simples. O agente Okta RADIUS com EAP-TTLS/PAP seria uma solução temporária aceitável durante a construção da PKI, mas dado o escopo do PCI DSS e a frota de dispositivos totalmente gerenciada, o EAP-TLS é a arquitetura correta de longo prazo. O investimento adicional em um serviço de PKI em nuvem (normalmente de US$ 3 a US$ 8 por dispositivo por ano) é justificado pelo aumento de segurança e pela redução da sobrecarga de gerenciamento de credenciais.

Continue a ler esta série

CommScope Ruckus Integration with Purple WiFi: Setup and Configuration Guide

Este guia de referência técnica fornece um manual de configuração definitivo para integrar arquiteturas CommScope Ruckus com o Purple WiFi. Ele detalha implementações passo a passo para Captive Portals de Guest WiFi, WiFi seguro para funcionários via 802.1X e isolamento de rede multi-tenant usando Ruckus Dynamic PSK.

Integração de Access Points Allied Telesis com o Purple WiFi

Este guia fornece um manual de configuração abrangente para integrar os access points Allied Telesis Série TQ com o Purple WiFi. Ele aborda o redirecionamento de Captive Portal externo, autenticação RADIUS 802.1X e direcionamento dinâmico de VLAN usando Private Pre-Shared Keys (PPSK) para implantações seguras de múltiplos inquilinos (multi-tenant).

Integração de Access Points Grandstream GWN com Purple WiFi

Este guia de referência técnica detalhado explica como integrar os access points Grandstream GWN com o Guest WiFi e a plataforma de analytics da Purple. Ele abrange a configuração do Captive Portal Grandstream, definições de RADIUS AAA, configuração de walled garden, autenticação segura de funcionários via 802.1X com direcionamento dinâmico de VLAN e segmentação PPSK multi-tenant — fornecendo orientações práticas passo a passo para MSPs e equipes de TI que implantam WiFi para visitantes e funcionários em escala.