Okta e RADIUS: Estender o Seu Fornecedor de Identidade à Autenticação WiFi

Este guia fornece uma referência técnica abrangente para administradores de TI em organizações centradas no Okta que pretendem estender o seu fornecedor de identidade na nuvem à autenticação WiFi utilizando o agente Okta RADIUS. Abrange a arquitetura de autenticação completa, as compensações de aplicação de MFA, a atribuição dinâmica de VLAN através de mapeamento de atributos RADIUS e a decisão crítica entre EAP-TTLS baseado em palavra-passe e EAP-TLS baseado em certificados. Os operadores de espaços e as equipas de TI empresariais encontrarão orientações de implementação práticas, casos de estudo reais dos setores da hotelaria e do retalho, e uma estrutura clara para integrar o Okta RADIUS juntamente com soluções dedicadas de WiFi para convidados.

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

Ouça este guia

Ver transcrição do podcast

Bem-vindo ao Purple Technical Briefing. Hoje vamos mergulhar num tema que se situa exatamente na interseção entre a arquitetura de rede e a gestão de identidades: Okta e RADIUS para autenticação WiFi. Se é um gestor de TI, um arquiteto de rede ou um diretor de operações de espaços, já conhece a dor de cabeça que é gerir credenciais separadas para o acesso à rede. Tem o seu diretório Okta para aplicações na nuvem, mas talvez o seu WiFi ainda dependa de um servidor Active Directory legado ou, pior, de uma palavra-passe WPA2 partilhada e afixada na parede da sala de descanso. Hoje, vamos analisar como colmatar essa lacuna utilizando o agente Okta RADIUS. Vamos abordar a arquitetura, como lidar com a Autenticação Multi-Fator em WiFi, as compensações críticas entre a autenticação baseada em palavra-passe e a baseada em certificados, e como mapear grupos Okta para atributos RADIUS para atribuição dinâmica de VLAN. Vamos a isso.

Comecemos pela arquitetura. Como funciona realmente o agente Okta RADIUS? O agente Okta RADIUS é uma aplicação leve que implementa localmente — normalmente num servidor Windows ou Linux — ou numa máquina virtual na nuvem. Funciona como um proxy. Situa-se entre a sua infraestrutura de rede, como os seus pontos de acesso sem fios ou o seu controlador de LAN sem fios, e a nuvem Okta. Quando um utilizador tenta ligar-se ao seu WiFi empresarial 802.1X, o seu dispositivo envia as credenciais para o ponto de acesso. O ponto de acesso, agindo como aquilo a que chamamos o autenticador no modelo 802.1X, encaminha um RADIUS Access-Request para o agente Okta RADIUS através da porta UDP 1812. O agente recebe esse pedido e envia-o de forma segura num túnel para a nuvem Okta através de uma chamada de API HTTPS. O Okta valida as credenciais, verifica as políticas de início de sessão e devolve uma decisão. O agente traduz então essa decisão de volta numa mensagem RADIUS Access-Accept ou Access-Reject para o ponto de acesso. É uma forma inteligente de estender o seu fornecedor de identidade na nuvem até ao limite da rede local sem expor o seu diretório diretamente à internet.

Agora, a grande questão que todos colocam: É possível impor o Okta MFA em ligaçõ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 palavra-passe em texto limpo, esta é encapsulada e protegida pelo túnel TLS externo do protocolo EAP, que significa Extensible Authentication Protocol. Esta configuração permite que o agente faça a gestão dos desafios de MFA. Pode configurar o Okta para enviar uma notificação do Okta Verify para o telemóvel do utilizador, ou pedir-lhe para acrescentar um código TOTP — uma Time-Based One-Time Password — à sua palavra-passe. No entanto, é aqui que a experiência do utilizador choca com a segurança. Imagine pedir a um funcionário de uma loja de retalho para aprovar uma notificação push sempre que o seu telemóvel se volta a ligar ao WiFi dos funcionários enquanto caminha pela loja. Isto causa fricção. Além disso, muitos dispositivos modernos perdem a ligação WiFi se o desafio de MFA demorar demasiado tempo. Por isso, embora o MFA em WiFi seja tecnicamente possível e suportado pelo Okta, geralmente recomendamo-lo apenas para acessos altamente privilegiados, como SSIDs de administradores de TI, em vez do WiFi geral dos funcionários.

Isto leva-nos ao compromisso crítico: RADIUS baseado em palavra-passe com o Okta versus autenticação baseada em certificados, especificamente EAP-TLS. Quando utiliza o agente Okta RADIUS com EAP-TTLS ou PAP, está a depender de palavras-passe. As palavras-passe podem ser roubadas, alvo de phishing ou partilhadas. Além disso, como acabámos de discutir, adicionar MFA ao WiFi é pouco prático no dia a dia. Por outro lado, o EAP-TLS utiliza certificados digitais implementados no dispositivo do utilizador. Fornece autenticação mútua — o dispositivo prova a sua identidade à rede e a rede prova a sua identidade ao dispositivo. Não há palavras-passe para introduzir e é altamente resistente ao phishing. O reverso da medalha? O agente Okta RADIUS não funciona nativamente como uma Autoridade de Certificação. Se pretender EAP-TLS, necessita de uma Infraestrutura de Chaves Públicas, ou PKI — soluções como o SecureW2, Foxpass ou Microsoft Active Directory Certificate Services — e de uma solução de Gestão de Dispositivos Móveis para distribuir os certificados pelos seus endpoints. O Okta ainda pode ser o fornecedor de identidade que autoriza a emissão de certificados, mas o próprio agente RADIUS não fará o trabalho pesado para o EAP-TLS. Para ambientes BYOD, o Okta RADIUS baseado em palavra-passe é rápido e fácil de implementar. Para dispositivos corporativos geridos, o EAP-TLS é o padrão de excelência.

Passemos a uma das funcionalidades mais poderosas: a atribuição dinâmica de VLAN. Num grande espaço — um hotel, um estádio, um centro de conferências — não quer toda a sua equipa no mesmo segmento de rede. Quer os terminais de ponto de venda isolados dos tablets do serviço de quartos, e quer a equipa de TI numa VLAN de gestão. Como se consegue isto com o Okta? Tudo se resume ao mapeamento de atributos RADIUS. Na Consola de Administração do Okta, nas definições da aplicação RADIUS, pode ativar uma funcionalidade chamada "Include groups in RADIUS response". Especifica quais os grupos do Okta que devem ser devolvidos na resposta de autenticação. O Okta passa esta pertença a grupos de volta para o seu controlador de rede utilizando atributos RADIUS padrão — normalmente o Atributo 11 para Filter-ID, ou o Atributo 25 para Class. O seu controlador sem fios ou sistema de Controlo de Acesso à Rede, como o Aruba ClearPass ou o Cisco ISE, recebe este nome de grupo. Em seguida, 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, colocando dinamicamente o utilizador na VLAN correta. É uma forma simples de impor a segmentação de rede baseada puramente na identidade do Okta, o que é incrivelmente poderoso para a conformidade com normas como o PCI DSS, que exige uma segmentação de rede rigorosa em torno de ambientes de dados de titulares de cartões.

Agora, vejamos alguns cenários de implementação no mundo real. Considere uma cadeia hoteleira nacional com propriedades em todo o Reino Unido. Cada propriedade tem uma mistura de pessoal de receção, serviço de quartos, restauração e gestão. Anteriormente, cada propriedade geria o seu próprio servidor NPS com um Active Directory local. A equipa de TI despendia um tempo considerável a gerir contas locais e a resolver falhas de RADIUS. Ao implementar o agente Okta RADIUS num par de máquinas virtuais redundantes na nuvem, centralizando todas as contas de utilizador no Okta e configurando a atribuição de VLAN baseada em grupos, a cadeia reduziu significativamente os seus custos operacionais de TI por propriedade. O pessoal da receção autentica-se com as suas credenciais do Okta e é automaticamente colocado na VLAN de serviços de hóspedes. O pessoal de gestão, que está num grupo diferente do Okta, entra na VLAN de gestão com acesso aos sistemas de gestão da propriedade. Toda a configuração é gerida a partir de uma única Consola de Administração do Okta, e o Okta System Log fornece um registo de auditoria completo de cada evento de autenticação em todas as propriedades.

Um segundo cenário: uma grande cadeia de retalho com mais de 300 lojas. Cada loja tem uma rede WiFi para funcionários utilizada para gestão de inventário, 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 dos titulares de cartões e o acesso geral dos funcionários. Ao integrar o Okta RADIUS com a sua infraestrutura sem fios existente, o retalhista mapeia os grupos do Okta — POS-Staff, Inventory-Staff e Store-Management — para três VLANs distintas. Quando um funcionário da loja se liga, o seu dispositivo é automaticamente colocado na VLAN correta com base na sua pertença ao grupo do Okta. Se um funcionário mudar de funções, a atualização da sua pertença ao grupo do Okta altera imediatamente o seu acesso à rede na ligação seguinte. 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 os erros mais comuns. O primeiro e mais comum erro é ignorar as definições de timeout. As chamadas de API do Okta demoram tempo, especialmente se houver um push de MFA envolvido. Se o timeout de RADIUS do seu controlador sem fios estiver definido para o padrão de três ou cinco segundos, o pedido irá expirar antes que o utilizador possa tocar em Aprovar no seu telemóvel. Deve aumentar o timeout de RADIUS no seu WLC para pelo menos trinta a sessenta segundos. Esta é uma alteração de configuração do lado da rede, não no Okta, e é frequentemente descurada. A segunda recomendação é a alta disponibilidade. Nunca implemente apenas um agente Okta RADIUS. Implemente pelo menos dois agentes em servidores separados e configure o seu controlador sem fios para fazer o balanceamento de carga entre eles. Se um servidor for abaixo para atualizações, a sua autenticação WiFi permanece ativa. O terceiro erro: tenha cuidado com o PEAP. O agente Okta RADIUS não suporta PEAP-MSCHAPv2, que é o padrão para muitos ambientes Windows mais antigos. Deve configurar os seus clientes para utilizarem EAP-TTLS com PAP. Isto normalmente requer o envio de um perfil sem fios através de Política de Grupo ou MDM, porque o Windows não assume o EAP-TTLS por defeito facilmente. Não fazer isto é a razão número um para falhas nas implementações.

É hora de uma sessão rápida de perguntas e respostas baseada nas dúvidas mais comuns dos clientes. Pergunta um: Podemos usar o Okta RADIUS para WiFi de convidados? Resposta: Não. O Okta é faturado por utilizador e foi concebido para a identidade da força de trabalho. Para WiFi de convidados, deve utilizar uma solução de Captive Portal concebida especificamente para o efeito, que gere os termos de serviço, o login social e a análise de dados sem consumir licenças do Okta. Pergunta dois: O Okta RADIUS suporta YubiKeys para autenticação WiFi? Resposta: Geralmente, não. Os tokens de hardware e o WebAuthn não se traduzem bem no protocolo RADIUS. Opte pelo push do Okta Verify ou TOTP se tiver mesmo de utilizar MFA no WiFi. Pergunta três: Como é que isto interage com uma implementação da Purple? Resposta: Muito bem. Os clientes empresariais da Purple que utilizam o Okta como o seu fornecedor de identidade podem utilizar o Okta RADIUS para autenticar o WiFi dos funcionários de forma segura, enquanto utilizam o Captive Portal da Purple para o acesso de convidados num SSID separado. Isto posiciona a Purple ao lado do Okta numa pilha de autenticação unificada e moderna — funcionários num SSID com Okta RADIUS, convidados noutro 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 a sua autenticação WiFi no seu fornecedor de identidade na nuvem. Suporta a atribuição dinâmica de VLAN para uma segmentação de rede robusta, o que é fundamental para a conformidade com o PCI DSS e outras estruturas. No entanto, preste atenção à experiência do utilizador se impuser MFA no WiFi, e lembre-se de que, para dispositivos corporativos totalmente geridos, a migração para EAP-TLS baseado em certificados 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 centradas no Okta que pretendem expandir rapidamente esse investimento em identidade para a camada de rede. É tudo por este briefing. Não se esqueça de consultar o guia de referência técnica completo para obter os passos detalhados de configuração, diagramas de arquitetura e exemplos práticos. Até à próxima, mantenha as suas redes seguras e os seus utilizadores ligados.

Principais Conclusões

✓O agente Okta RADIUS faz o proxy de pedidos de autenticação WiFi 802.1X da infraestrutura de rede para a cloud Okta via HTTPS, permitindo que a identidade na cloud 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 implementação.
✓O MFA em WiFi é tecnicamente suportado (Okta Verify push, TOTP, SMS), mas requer o aumento do timeout do RADIUS no WLC para 30-60 segundos; é mais adequado para SSIDs administrativos do que para o WiFi geral de funcionários devido à fricção no roaming.
✓A atribuição dinâmica de VLAN é alcançada ao ativar "Include groups in RADIUS response" no Okta e mapear 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.
✓Implemente sempre um mínimo de duas instâncias do agente Okta RADIUS para alta disponibilidade — um único agente é um ponto crítico único de falha para toda a autenticação WiFi na infraestrutura.
✓Para ambientes de dispositivos totalmente geridos sujeitos a PCI DSS ou requisitos de alta segurança, o EAP-TLS com uma PKI na cloud é a arquitetura de longo prazo superior; o Okta RADIUS com EAP-TTLS/PAP é a escolha pragmática para cenários de BYOD ou implementação rápida.
✓O Okta RADIUS é uma ferramenta de identidade de força de trabalho — implemente uma solução de Captive Portal de WiFi de convidados dedicada para o acesso de visitantes para evitar custos de escala de licenças Okta e manter uma separação clara entre o acesso à rede de funcionários e de convidados.

Resumo Executivo

Para as equipas de TI empresariais que gerem locais distribuídos — desde cadeias de hotéis a estádios — a unificação do controlo de acessos à rede com um fornecedor de identidade na nuvem é um passo crítico em direção ao Zero Trust. O agente Okta RADIUS faz a ponte entre a identidade moderna na nuvem e a infraestrutura tradicional de WiFi 802.1X, permitindo que as organizações descontinuem servidores RADIUS locais legados e a infraestrutura Active Directory para autenticação de rede.

Este guia detalha como implementar o agente Okta RADIUS para autenticação WiFi empresarial, cobrindo a arquitetura de proxy, mecanismos de aplicação de MFA e as compensações entre EAP-TTLS baseado em palavra-passe e EAP-TLS baseado em certificados. Também fornece orientações práticas sobre como mapear a pertença a grupos Okta para atributos RADIUS para atribuição dinâmica de VLAN — uma capacidade que apoia diretamente os requisitos de segmentação de rede PCI DSS. Ao integrar a Okta para autenticação de funcionários juntamente com soluções de Guest WiFi , os operadores de locais podem alcançar uma camada de acesso unificada, segura e em conformidade, sem duplicar a infraestrutura de identidade.

Análise Técnica Aprofundada

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) — tais como pontos de acesso sem fios (WAPs) ou controladores de LAN sem fios (WLCs) — e a nuvem Okta. É normalmente implementado num servidor Windows ou Linux local ou dentro de uma VPC na nuvem, sendo gerido inteiramente a partir da Consola de Administração Okta após a instalação inicial.

O fluxo de autenticação segue um modelo de proxy 802.1X padrão. O dispositivo de um utilizador (o suplicante) liga-se a um SSID empresarial e apresenta 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 este pedido de forma segura para a nuvem Okta através de uma chamada de API HTTPS, onde o motor de políticas da Okta avalia as credenciais em relação ao seu diretório de utilizadores e a quaisquer políticas de início de sessão configuradas. Se a autenticação for bem-sucedida, o agente devolve uma mensagem Access-Accept RADIUS ao autenticador, incluindo opcionalmente atributos RADIUS para autorização, tais como a atribuição de VLAN. Se for necessário MFA, o agente envia um Access-Challenge RADIUS de volta ao cliente, solicitando um segundo fator antes de a decisão final ser devolvida.

Este modelo de proxy significa que o agente Okta RADIUS não precisa de armazenar credenciais de utilizador localmente. Toda a lógica de autenticação, avaliação de políticas e registo de auditoria ocorrem na nuvem Okta, proporcionando aos administradores um painel de controlo único para a governação de identidades tanto em aplicações na nuvem como no acesso à rede.

Protocolos EAP Suportados e Limitações Críticas

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

Criticamente, o PEAP-MSCHAPv2 não é suportado. Este é o protocolo 802.1X predefinido para clientes Windows e muitos ambientes empresariais legados. As organizações que estejam a migrar de uma configuração RADIUS tradicional NPS/Active Directory devem reconfigurar os seus suplicantes de cliente para utilizar EAP-TTLS com PAP — uma alteração que normalmente requer um perfil de rede sem fios distribuído via MDM ou Política de Grupo. Não prever esta alteração é a causa mais comum de falhas nas implementações do Okta RADIUS.

O EAP-TLS, que depende inteiramente de autenticação mútua baseada em certificados, também não é suportado nativamente pelo agente Okta RADIUS. As organizações que necessitem de EAP-TLS devem implementar uma PKI dedicada ou uma solução de cloud RADIUS que se integre com a Okta como IdP via SAML ou OIDC, em vez de utilizarem diretamente o agente Okta RADIUS.

Imposição de MFA em Ligações WiFi

O agente Okta RADIUS suporta MFA para acesso WiFi, mas introduz desafios na experiência do utilizador que devem ser cuidadosamente considerados antes da implementação. Quando uma política de MFA é acionada, o agente envia um Access-Challenge RADIUS para o cliente. A 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 utilizador toca em Aprovar no telemóvel
TOTP (Okta Verify / Google Auth)	Suportado	Suportado	O utilizador anexa o OTP à palavra-passe (ex: `Pass123,456789`)
SMS / E-mail / Voz	Suportado	Suportado	O utilizador envia primeiro a string de ativação (SMS, EMAIL, CALL)
Duo Push / SMS / Código de Acesso	Suportado	Suportado	Código de acesso Duo apenas para EAP-TTLS
YubiKey / U2F / Windows Hello	Não Suportado	Não Suportado	Tokens de hardware incompatíveis com o protocolo RADIUS

A limitação prática é o roaming. Em ambientes de Hospitality , o tablet de um funcionário de limpeza pode fazer roaming entre pontos de acesso dezenas de vezes por turno, acionando a reautenticação de cada vez. Exigir a aprovação de uma notificação push a cada roaming é operacionalmente insustentável. Para o WiFi geral dos funcionários, as políticas de palavras-passe fortes combinadas com a confiança no dispositivo da Okta e as políticas de zona de rede são normalmente preferidas em detrimento de solicitações ativas de MFA. O MFA em WiFi deve ser reservado para SSIDs administrativos ou cenários de acesso com privilégios elevados.

Autenticação Baseada em Palavra-passe vs. Baseada em Certificado

A escolha entre RADIUS baseado em palavra-passe (através do agente Okta RADIUS) e EAP-TLS baseado em certificados é uma das decisões mais consequentes numa implementação de WiFi empresarial. As compensações não se referem apenas à segurança; envolvem a complexidade da implementação, a maturidade da gestão de dispositivos e os custos operacionais.

A autenticação baseada em palavra-passe através do agente Okta RADIUS oferece um caminho rápido para uma identidade unificada. Se a sua organização já gere utilizadores no Okta, a implementação pode ser concluída em horas em vez de semanas. Não há PKI para construir, nem certificados para distribuir, nem dependência de MDM. A contrapartida é que as palavras-passe continuam a ser 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 "evil twin" em ambientes de alto risco.

O EAP-TLS baseado em certificados elimina totalmente as palavras-passe 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 implementação local do Microsoft ADCS ou um serviço de PKI na nuvem — e uma plataforma MDM capaz de distribuir certificados a todos os endpoints geridos. Para ambientes de Retalho com centenas de dispositivos de ponto de venda geridos, este investimento é plenamente justificado. Para ambientes com forte presença de BYOD ou implementaçõ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 oferece o seu valor operacional mais tangível. Ao mapear a pertença a grupos do Okta para atributos RADIUS, os administradores de rede podem impor a segmentação de rede baseada em funções sem manter políticas de VLAN separadas por dispositivo ou por localização.

O Okta passa os dados de pertença a grupos na mensagem Access-Accept do RADIUS utilizando um de três atributos, configuráveis nas Definições Avançadas de RADIUS da aplicação Okta:

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

O controlador de rede (WLC, dispositivo NAC) recebe o nome do grupo Okta no atributo escolhido e mapeia-o 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 utilizador no grupo do Okta Retail-POS-Staff teria Class: Retail-POS-Staff devolvido no Access-Accept. A política do WLC mapearia isto para Tunnel-Private-Group-ID: 40, colocando o dispositivo na VLAN 40 — a rede POS isolada. Um utilizador em Store-Management seria colocado na VLAN 50. Esta lógica é aplicada na periferia da rede, não no Okta, mas é inteiramente impulsionada pela pertença ao grupo do Okta.

Guia de Implementação

Passo 1: Implementar o Agente RADIUS do Okta (Alta Disponibilidade)

Implemente o agente RADIUS do Okta num mínimo de dois servidores — no local ou numa VPC na nuvem — para garantir a alta disponibilidade. As implementações com um único agente constituem 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 o seu WLC ou dispositivo NAC para equilibrar a carga das solicitações RADIUS entre ambos os agentes.

Durante a instalação, o agente solicitará as credenciais de um administrador do Okta para autorizar o agente e associá-lo ao inquilino do Okta. Uma vez autorizado, o agente aparece na Consola de Administração do Okta em Definições > Transferências > Estado do Agente RADIUS, onde a integridade e a conectividade podem ser monitorizadas.

Passo 2: Configurar a Aplicação RADIUS no Okta

Na Consola de Administração do Okta, navegue até Aplicações > Aplicações e pesquise no catálogo de aplicações por Aplicação RADIUS.
Adicione a aplicação, atribua-lhe um nome descritivo (ex: Corporate-WiFi-Staff) e clique em Seguinte.
No separador Iniciar Sessão, configure a Porta RADIUS (predefinição 1812) e gere um Segredo Partilhado forte e gerado aleatoriamente com pelo menos 32 carateres.
Em Definições Avançadas de RADIUS, ative Aceitar palavra-passe e token de segurança no mesmo pedido de início de sessão se pretender suportar TOTP anexado a palavras-passe.
Opcionalmente, ative Permitir Push Automático para Utilizadores Registados no Okta Verify para uma MFA baseada em push simplificada.
Atribua a aplicação aos grupos do Okta relevantes que representam a sua equipa.

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

Nas definições de Iniciar Sessão da aplicação RADIUS, clique em Editar na secção Definições Avançadas de RADIUS.
Selecione Incluir grupos na resposta RADIUS.
Selecione o atributo RADIUS: 25 Class é recomendado para ambientes Aruba e Cisco; 11 Filter-Id para Fortinet e outros.
Adicione os nomes específicos dos grupos do Okta a incluir (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 os Suplicantes do Cliente

Como o PEAP-MSCHAPv2 não é suportado, os dispositivos cliente devem ser configurados para usar EAP-TTLS com PAP como o método interno. Implemente um perfil de rede sem fios através da sua plataforma MDM (por exemplo, Microsoft Intune, Jamf Pro) ou através de Objetos de Diretiva de Grupo (GPO) para dispositivos associados ao domínio Windows. O perfil deve especificar:

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

Passo 5: Configurar os Tempos de Espera (Timeouts) do RADIUS

Aumente o tempo de espera do RADIUS no seu WLC do valor padrão de 3-5 segundos para 30-60 segundos. Isto é fundamental se as notificações push de MFA estiverem em uso, pois o utilizador deve ter tempo suficiente para aprovar a notificação no seu dispositivo antes que o WLC abandone a tentativa de autenticação.

Boas Práticas

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

Segmente o tráfego de convidados e de funcionários ao nível do SSID. O Okta RADIUS é uma ferramenta de identidade de força de trabalho. Para acesso de visitantes e convidados, implemente uma solução de Captive Portal dedicada. Isto evita que os custos de licenciamento da Okta aumentem com o volume de convidados e garante uma separação clara de responsabilidades. Os clientes empresariais da Purple podem implementar o Guest WiFi num SSID separado, enquanto utilizam o Okta RADIUS para a autenticação de funcionários na mesma infraestrutura física.

Utilize 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ços MAC ou estado do certificado, juntamente com a identidade do utilizador, implemente um dispositivo NAC intermédio (Aruba ClearPass, Cisco ISE ou Portnox) para fazer o proxy dos pedidos 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.

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

Rode os segredos partilhados de forma programada. O segredo partilhado entre a aplicação Okta RADIUS e o seu NAS é uma credencial de segurança crítica. Implemente um calendário de rotação (recomenda-se trimestralmente) e atualize a aplicação Okta e a configuração do WLC/NAC em simultâneo.

Restrinja os endereços do serviço RADIUS. Na configuração do agente Okta RADIUS, restrinja quais os endereços IP que têm permissão para enviar pedidos RADIUS. Isto evita que dispositivos NAS não autorizados tentem a autenticação contra o seu inquilino 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 palavras-passe de WiFi PSK partilhadas por autenticação 802.1X por utilizador elimina a partilha de credenciais, um vetor comum para ameaças internas e acessos não autorizados. Combinado com a atribuição dinâmica de VLAN, isto reforça o princípio do privilégio mínimo na camada de rede. O Okta System Log fornece um registo de auditoria completo e inviolável de cada evento de autenticação WiFi, o que é essencial para a resposta a incidentes.

Prontidão para Conformidade. O Requisito 8.3 do PCI DSS 4.0 exige MFA para todos os acessos administrativos que não sejam por consola. O Requisito 1.3 exige a segmentação de rede entre o ambiente de dados dos titulares de cartões e outras redes. O Okta RADIUS com atribuição de VLAN baseada em grupos responde diretamente a ambos os requisitos. Para a conformidade com o GDPR, o Okta System Log fornece os registos de acesso necessários para demonstrar controlos técnicos adequados sobre os sistemas de processamento de dados pessoais. Para locais que implementam Modern Hospitality WiFi Solutions , esta abordagem unificada à identidade e ao acesso à rede é cada vez mais um pré-requisito para a aquisição empresarial.

As organizações que concluíram esta integração reportam tipicamente uma redução nos pedidos de suporte de TI relacionados com WiFi (menos pedidos de reposição de palavras-passe, menos incidentes de configuração incorreta de VLAN) e uma melhoria mensurável nas pontuações de auditoria de segurança. O investimento na implementação e configuração do agente Okta RADIUS — normalmente medido em dias em vez de semanas para uma implementação num único local — proporciona poupanças operacionais contínuas que se multiplicam em toda a infraestrutura distribuída.

Definições Principais

Okta RADIUS Agent

Um serviço de proxy leve, local ou alojado na nuvem, que traduz os pedidos 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 equipas de TI deparam-se com isto ao implementar a autenticação WiFi empresarial suportada pelo Okta. É o componente de ponte crítico entre a infraestrutura de rede legada baseada em RADIUS e a identidade moderna na nuvem.

802.1X

Uma norma IEEE para Controlo de Acesso à Rede (NAC) baseado em portas que define uma estrutura de autenticação para redes com e sem fios. Utiliza 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 WiFi empresarial. Qualquer implementação que utilize WPA2-Enterprise ou WPA3-Enterprise utiliza o 802.1X. As equipas de TI devem compreender o modelo de três partes (suplicante, autenticador, servidor de autenticação) para resolver problemas de conectividade.

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

Um método EAP que estabelece um túnel TLS utilizando 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. Isto protege as credenciais internas contra a interceção, exigindo apenas a infraestrutura de certificados do lado do servidor.

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

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

Um método EAP que utiliza autenticação mútua baseada em certificados — tanto o cliente como o servidor apresentam certificados digitais. É o método 802.1X mais seguro, proporcionando uma autenticação sem palavra-passe e resistente a phishing.

O EAP-TLS é o padrão de excelência para ambientes de dispositivos corporativos geridos. Requer uma infraestrutura PKI e MDM para a distribuição de certificados. O agente RADIUS do Okta não suporta nativamente o EAP-TLS; é necessário um serviço PKI na nuvem ou RADIUS dedicado.

PAP (Password Authentication Protocol)

Um protocolo de autenticação simples que transmite nomes de utilizador e palavras-passe em texto simples. No contexto do 802.1X, o PAP é utilizado como o método de autenticação interno dentro de um túnel EAP-TTLS, onde a camada TLS externa fornece a encriptação.

O PAP é o principal mecanismo de autenticação suportado pelo agente RADIUS do Okta. As equipas de TI devem compreender que o PAP por si só é inseguro, mas o PAP dentro do EAP-TTLS é aceitável para WiFi empresarial quando o certificado do servidor é devidamente validado.

Dynamic VLAN Assignment

Uma técnica de controlo de acesso à rede onde um servidor RADIUS devolve atributos de atribuição de VLAN na mensagem Access-Accept, fazendo com que o controlador sem fios ou switch coloque o cliente autenticado numa VLAN específica com base na sua identidade ou pertença a um 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 POS de dispositivos de funcionários gerais). É configurada devolvendo os atributos RADIUS 64, 65 e 81 na mensagem Access-Accept.

RADIUS Attribute 25 (Class)

Um atributo RADIUS padrão utilizado para passar dados de autorização arbitrários do servidor de autenticação para o NAS. O Okta utiliza este atributo para devolver informações de pertença a grupos do Okta ao controlador sem fios, que pode depois utilizá-las para atribuição de VLAN ou decisões de política de acesso.

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

NAS (Network Access Server)

Na terminologia RADIUS, o NAS é o dispositivo de rede que recebe o pedido de ligação do utilizador e o encaminha para o servidor RADIUS para autenticação. Em implementações WiFi, o NAS é normalmente o ponto de acesso sem fios ou o controlador de LAN sem fios.

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

Shared Secret

Uma palavra-passe partilhada previamente utilizada para autenticar mensagens RADIUS entre o NAS (WLC/AP) e o servidor RADIUS (agente RADIUS do Okta). É utilizada para calcular um hash Message-Authenticator que verifica a integridade dos pacotes RADIUS.

O segredo partilhado deve ser idêntico tanto na configuração da aplicação RADIUS do Okta como na entrada do servidor RADIUS da WLC/NAC. Deve ter pelo menos 32 carateres, ser gerado aleatoriamente e rodado regularmente. Uma incompatibilidade é 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 para o NAS quando são necessários fatores de autenticação adicionais. O NAS retransmite o desafio para o cliente, que deve responder com o fator apropriado (por exemplo, OTP, aprovação push) antes que a autenticação possa ser concluída.

O mecanismo Access-Challenge é a forma como o Okta impõe o MFA através de RADIUS. As equipas de TI devem garantir que a WLC suporta a troca de desafio-resposta e que o tempo limite do RADIUS é suficientemente longo para que o utilizador conclua o passo de MFA.

Exemplos Práticos

Uma cadeia de hotéis com 150 propriedades utiliza 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 equipa de TI pretende centralizar a gestão de identidades no Okta e eliminar a infraestrutura NPS por propriedade. Como devem abordar a migração?

A abordagem recomendada é uma migração faseada utilizando o agente Okta RADIUS implementado numa VPC cloud centralizada, em vez de em cada propriedade. Fase 1: Implementar duas instâncias do agente Okta RADIUS numa VPC cloud (ex. AWS ou Azure) na mesma região que a maioria das propriedades. Configurar os agentes para escutar na porta UDP 1812. Fase 2: Para cada propriedade, adicionar os IPs do agente Okta RADIUS como servidores RADIUS secundários no WLC, mantendo o NPS existente como primário. Isto permite o funcionamento em paralelo e a realização de testes sem interromper a autenticação em tempo real. Fase 3: Migrar os utilizadores do AD local para o Okta. Utilizar o agente AD do Okta para sincronizar inicialmente as contas existentes e, em seguida, migrar progressivamente para o Okta como a fonte de autoridade. Fase 4: Para cada propriedade, configurar o WLC para utilizar EAP-TTLS/PAP e enviar o novo perfil de rede sem fios para os dispositivos dos funcionários via MDM. Fase 5: Assim que todos os dispositivos estiverem confirmados em EAP-TTLS, alterar a prioridade do RADIUS no WLC para os agentes Okta como primários e desativar os servidores NPS. Configurar grupos no Okta (Front-Desk, Housekeeping, F&B, Management, IT-Admins) e ativar a atribuição de VLAN baseada em grupos utilizando o Atributo 25 (Class). Mapear cada grupo para a VLAN apropriada no WLC. Aumentar o timeout do RADIUS no WLC para 45 segundos para acomodar a latência da API do Okta.

Comentário do Examinador: Esta abordagem faseada é preferível porque elimina o risco de uma transição abrupta em 150 propriedades em simultâneo. Executar o NPS e o Okta RADIUS em paralelo durante o período de transição significa que qualquer configuração incorreta pode ser detetada e corrigida sem afetar os utilizadores ativos. A implementação dos agentes RADIUS numa VPC cloud é arquitetonicamente superior à implementação por propriedade, pois centraliza a gestão, reduz a pegada de infraestrutura e garante a aplicação consistente de políticas, independentemente da propriedade a partir da qual o utilizador se autentica. O principal risco a mitigar é a latência WAN entre a propriedade e a VPC cloud — a autenticação RADIUS deve ser concluída em menos de 2 segundos para uma boa experiência do utilizador, pelo que a seleção da região da VPC deve minimizar o tempo de ida e volta (RTT).

Uma cadeia de retalho nacional com 320 lojas precisa de obter a conformidade PCI DSS 4.0 para o WiFi dos seus funcionários. Os colaboradores das lojas utilizam dispositivos portáteis para gestão de inventário, e um conjunto separado de dispositivos lida com transações de ponto de venda (POS). A cadeia utiliza o Okta para toda a identidade da força de trabalho. Como implementam a segmentação de VLAN utilizando o Okta RADIUS para satisfazer os requisitos de segmentação de rede do PCI DSS?

Criar três grupos no Okta: POS-Staff (para funcionários que operam terminais POS), Inventory-Staff (para colaboradores de armazém e loja) e Store-Management. Na aplicação Okta RADIUS, ativar 'Include groups in RADIUS response' e selecionar o Atributo 25 (Class). Adicionar os três grupos à configuração de resposta. No controlador sem fios de cada loja (ou centralmente através de um WLC na cloud), criar três políticas de aplicação: (1) Se Class = POS-Staff, atribuir Tunnel-Private-Group-ID = 40 (a VLAN de POS, que está no âmbito do PCI DSS e tem regras de firewall que restringem o acesso apenas ao processador de pagamentos). (2) Se Class = Inventory-Staff, atribuir Tunnel-Private-Group-ID = 50 (a VLAN de inventário, fora do âmbito do PCI). (3) Se Class = Store-Management, atribuir Tunnel-Private-Group-ID = 60 (a VLAN de gestão com acesso aos sistemas de gestão da loja). Os dispositivos que se ligam com credenciais de um utilizador no grupo POS-Staff são automaticamente colocados na VLAN 40. Se a função de um colaborador de loja mudar, a atualização da sua pertença ao grupo no Okta altera imediatamente a sua atribuição de VLAN na ligação seguinte — sem necessidade de reconfiguração do WLC. Documentar o mapeamento de grupo Okta para VLAN no diagrama de segmentação de rede para a auditoria PCI DSS QSA.

Comentário do Examinador: Esta implementação satisfaz diretamente o Requisito 1.3 do PCI DSS 4.0 (segmentação de rede) e o Requisito 7 (controlo de acesso baseado nas necessidades do negócio). A perspicácia crítica é que a atribuição de VLAN é orientada pela identidade, e não pelo endereço MAC do dispositivo ou pela configuração estática de VLAN — o que significa que escala em 320 lojas sem manutenção de políticas de VLAN por loja. O QSA quererá ver provas de que a VLAN de POS está genuinamente isolada de outros segmentos de rede, pelo que as configurações do WLC e da firewall devem refletir os limites da VLAN. O System Log do Okta fornece o registo de auditoria de autenticação exigido pelo Requisito 10 do PCI DSS (registo e monitorização). Uma ressalva importante: se os dispositivos POS não forem geridos ou forem partilhados (ou seja, não atribuídos a um utilizador específico), considere utilizar o MAC Authentication Bypass (MAB) para esses dispositivos em vez do 802.1X, utilizando o Okta RADIUS apenas para dispositivos autenticados por utilizador.

Perguntas de Prática

Q1. Um centro de conferências de média dimensão utiliza o Okta para toda a gestão de identidade dos funcionários. Pretendem implementar WiFi 802.1X para os funcionários utilizando os seus pontos de acesso Cisco Meraki existentes. Os seus computadores portáteis Windows são geridos através do Microsoft Intune. O gestor de TI pretende impor o MFA push do Okta Verify para todas as ligações WiFi. Quais são os três passos de configuração mais críticos que devem concluir e qual é o modo de falha mais provável se ignorarem algum deles?

Dica: Considere a compatibilidade do protocolo EAP entre o Okta RADIUS e as predefinições do Windows, a configuração do timeout do RADIUS e a configuração do perfil sem fios do cliente.

Ver resposta modelo

Os três passos críticos são: (1) Implementar um perfil sem fios através do Intune que configure os clientes Windows para utilizar EAP-TTLS com PAP como método interno — o Windows predefine para PEAP-MSCHAPv2, que 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 dos 5 segundos predefinidos para pelo menos 45-60 segundos — sem isto, o pedido de autenticação irá expirar antes que o utilizador possa aprovar a notificação push do Okta Verify. (3) Ativar 'Permit Automatic Push for Okta Verify Enrolled Users' nas Definições Avançadas de RADIUS da aplicação Okta RADIUS — sem isto, os utilizadores poderão ser solicitados a selecionar manualmente o seu fator MFA em vez de receberem um push automático. O modo de falha mais provável se o passo 1 for ignorado é uma falha total de autenticação para todos os dispositivos Windows. Se o passo 2 for ignorado, a autenticação falhará intermitentemente para os utilizadores que demorem mais de 5 segundos a aprovar o push. Se o passo 3 foi ignorado, os utilizadores irão deparar-se com um pedido de desafio confuso em vez de uma notificação push fluida.

Q2. A equipa de segurança de uma grande cadeia de retalho sinalizou que a sua atual implementação de WiFi Okta RADIUS utiliza um único servidor de agente RADIUS. Durante uma recente janela de atualização, o servidor esteve offline durante 45 minutos, fazendo com que a autenticação WiFi falhasse em todas as 80 lojas. Que alterações arquiteturais deve a equipa de TI implementar para evitar isto e quais são as duas opções de implementação para os agentes?

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

Ver resposta modelo

A equipa de TI deve implementar um mínimo de duas instâncias do agente Okta RADIUS e configurar o WLC em cada loja para utilizar ambos os agentes. Existem duas opções de implementação: Opção A (VMs de Nuvem Centralizadas) — implementar ambos os agentes numa VPC de nuvem (por exemplo, AWS ou Azure), idealmente em diferentes zonas de disponibilidade. 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). Isto minimiza a infraestrutura por local, mas introduz dependência da WAN. Opção B (Par Redundante Local) — implementar dois servidores de agentes num centro de dados central ou instalação de co-location, com o WLC a utilizar 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 'Dead Server Detection' se for suportada pelo fornecedor do WLC. Adicionalmente, a equipa de TI deve configurar a monitorização de integridade na Consola de Administração do Okta e configurar alertas se um agente ficar offline. Para lojas com servidores locais, um agente local pode servir como um terceiro recurso para resiliência contra falhas de WAN.

Q3. Uma organização empresarial está a avaliar se deve utilizar o agente Okta RADIUS com EAP-TTLS/PAP ou investir numa solução PKI em nuvem para EAP-TLS para o seu WiFi corporativo. Têm 2000 dispositivos Windows e macOS geridos e registados no Microsoft Intune, e estão sujeitos ao PCI DSS 4.0. Qual é a abordagem recomendada e qual é a principal justificação de segurança?

Dica: Considere os requisitos do PCI DSS, a maturidade da gestão de dispositivos (todos os dispositivos estão registados 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 PKI em nuvem. A principal justificação de segurança é a autenticação mútua: o EAP-TLS exige que tanto o cliente como o servidor RADIUS apresentem certificados digitais, o que significa que o dispositivo prova criptograficamente a sua identidade à rede e a rede prova a sua identidade ao dispositivo. Isto elimina o risco de ataques "evil twin" (onde um AP não autorizado se faz passar pelo SSID corporativo) e remove totalmente as palavras-passe 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 satisfaz o Requisito 8.3 (MFA para acesso administrativo não-consola) implicitamente através de autenticação baseada em certificados, e suporta o modo WPA3-Enterprise de 192 bits (Requisito 4.2.1 para criptografia forte). O pré-requisito — todos os 2000 dispositivos registados no Intune — já está cumprido, tornando a distribuição de certificados através de perfis SCEP do Intune simples. O agente Okta RADIUS com EAP-TTLS/PAP seria uma solução provisória aceitável durante a construção da PKI, mas dado o âmbito do PCI DSS e o parque de dispositivos totalmente gerido, o EAP-TLS é a arquitetura correta a longo prazo. O investimento adicional num serviço de PKI em nuvem (normalmente 3 a 8 dólares por dispositivo por ano) é justificado pelo aumento de segurança e pela redução dos custos de gestão de credenciais.

Continue a ler esta série

Integração do CommScope Ruckus com o Purple WiFi: Guia de Instalação e Configuração

Este guia de referência técnica fornece um manual de configuração autoritativo para integrar arquiteturas CommScope Ruckus com o Purple WiFi. 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 utilizando Ruckus Dynamic PSK.

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

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

Integração de Pontos de Acesso Grandstream GWN com o Purple WiFi

Este guia de referência técnica detalha como integrar os pontos de acesso Grandstream GWN com a plataforma de Guest WiFi e analítica da Purple. Abrange a configuração do Captive Portal da Grandstream, definições de RADIUS AAA, configuração de walled garden, autenticação segura de funcionários 802.1X com direcionamento dinâmico de VLAN e segmentação PPSK multi-tenant — fornecendo orientações práticas e passo a passo para MSPs e equipas de TI que implementam WiFi para convidados e funcionários em grande escala.