Autenticação WiFi com Okta: passos de configuração, opções e correções
Published
O conselho popular sobre a autenticação Okta WiFi é apontar os seus pontos de acesso para a Okta, ativar o MFA e reformar a palavra-passe partilhada. Não baseie a sua implementação nessa frase. A Okta não é um autenticador sem fios nos seus pontos de acesso, um suplicante 802.1X nativo muitas vezes não consegue apresentar um desafio interativo de forma limpa, e a parte que desliga um site inteiro é normalmente a confiança no certificado ou um perfil de dispositivo incorreto, não o pedido de MFA.
Isso não significa que o WiFi baseado em identidade seja a direção errada. O Okta Secure Sign-In Trends Report 2024 relatou que 66% dos utilizadores do Okta Workforce Identity iniciaram sessão com autenticação multifator a partir de janeiro de 2024, enquanto a adoção entre administradores atingiu 91%. Esses números descrevem inícios de sessão em aplicações, não sessões de WiFi, mas mostram que a garantia de identidade está a substituir as palavras-passe isoladas no mesmo diretório que utilizará para a política de rede.
Eu começaria por uma questão mais difícil. Qual o componente que termina a troca EAP, qual o sistema que emite e renova a confiança no dispositivo, e o que acontece quando qualquer um deles muda? Responda a estas três questões num laboratório e a autenticação Okta WiFi torna-se gerível. Se as ignorar, terá de depurar um SSID de produção, um sistema operativo de cada vez.
Índice
- Escolha o caminho de integração do Okta suportado pela sua rede
- Confiança no certificado e integração de dispositivos antes da ligação
- Como configurar o Okta RADIUS Agent passo a passo
- Definir regras de acesso condicional e postura do dispositivo
- Resolução de problemas de inícios de sessão de WiFi do Okta com falha
- Confirme o piloto antes de expandir para mais locais
Escolha o Caminho de Integração da Okta que a Sua Rede Suporta
A Okta não executa o 802.1X nos seus pontos de acesso por si só. Um controlador sem fios, um ponto de acesso ou um serviço RADIUS independente tem de atuar como autenticador, encaminhar cada pedido e aplicar o Access-Accept, Access-Reject, VLAN ou função que é devolvida. A Okta fornece a decisão de identidade. Não elimina o trabalho de protocolo focado na WLAN.
É por isso que a primeira escolha não é uma definição do Okta. É a arquitetura que o seu controlador e clientes conseguem efetivamente concluir. A documentação de integração do Okta Cisco Meraki RADIUS descreve uma configuração de segurança 802.1X EAP onde o cliente sem fios fornece um nome de utilizador e palavra-passe Okta durante a autenticação na rede. Esse é um caminho específico e documentado da Meraki, não uma prova de que todos os controladores e métodos EAP funcionarão da mesma forma.
Quatro Caminhos Que Resolvem Problemas Diferentes
| Opção | Credencial verificada pela Okta | Melhor adequação | Limite principal |
|---|---|---|---|
| Okta RADIUS Server Agent | Nome de utilizador e palavra-passe sobre PAP | Controladores legados com um caminho PAP validado em laboratório | A documentação da Okta não lista a infraestrutura de WiFi como suportada |
| Credenciais Okta em Cisco Meraki 802.1X | Nome de utilizador e palavra-passe Okta na troca EAP | WLANs Meraki que seguem a configuração de segurança EAP documentada pela Okta | Vinculado à configuração Meraki documentada pela Okta |
| Início de sessão SAML ou SSO num captive portal | Início de sessão no navegador através do fornecedor de identidade | Integração de convidados e BYOD | Não autentica dispositivos de colaboradores em 802.1X |
| Certificados emitidos por MDM com associação a grupos de diretório | Certificado de cliente EAP-TLS emitido pelo MDM | Dispositivos geridos de colaboradores em vários locais | Requer uma autoridade de certificação, entrega de perfis via MDM e um plano de renovação |
Leia a linha do agente RADIUS com atenção. Trate-o como uma ponte de acesso à rede legada, e não como um plano de identidade WiFi nativo. Um design convencional WPA2 ou WPA3-Enterprise baseado em EAP-TLS com certificados não pode ser considerado funcional diretamente com um agente cujo protocolo documentado é o PAP, estando o EAP-TTLS e o EAP-GTC listados apenas para cenários específicos de aplicação RADIUS.
O SSO de Captive Portal resolve um problema diferente. Proporciona aos convidados e dispositivos BYOD não geridos uma navegação no browser antes do acesso à internet, e pode registar quem está ligado. Não fornece a um portátil da equipa um acesso 802.1X encriptado desde o primeiro pacote, e os dispositivos sem ecrã/interface não o conseguem concluir. Não permita que uma demonstração simples de portal substitua a autenticação de rede da equipa.
Utilize Três Critérios para Decidir
- Suporte a controlador e EAP: Confirme o modelo exato do controlador, firmware, suplicante e método EAP em conjunto. Uma afirmação na ficha técnica sobre 802.1X não prova o seu caminho PAP, EAP-TTLS ou EAP-TLS.
- Gestão de dispositivos: Portáteis e telemóveis geridos podem receber certificados e perfis de confiança automaticamente. Dispositivos não geridos precisam de integração baseada em palavra-passe ou de uma rota por portal.
- Raio de impacto: Conte os locais, SSIDs e tipos de controlador que alteram em conjunto. Mais locais justificam uma entrega centralizada de perfis e certificados, e não uma configuração manual.
Regra de decisão: Utilize o agente RADIUS apenas após um laboratório comprovar a combinação exata de controlador e cliente. Para dispositivos de funcionários geridos, planeie primeiro o caminho do certificado e trate as palavras-passe como alternativa secundária.
Confiança no Certificado e Integração do Dispositivo Antes da Ligação
A maioria das falhas de WiFi da Okta que chegam ao suporte técnico não são falhas de MFA. São falhas de confiança. O dispositivo não confia no certificado do servidor RADIUS, o perfil 802.1X indica o método EAP ou servidor incorreto, o certificado de cliente ainda não chegou, ou o utilizador não registou o fator exigido pela política. A Okta pode avaliar a identidade corretamente enquanto o dispositivo nunca chega a avançar o suficiente para a solicitar.
O ponto de registo está documentado, não é teórico. A documentação da aplicação Okta RADIUS estabelece que o EAP-TTLS suporta autenticação por palavra-passe e código de acesso, enquanto o EAP-TTLS não suporta o registo, pelo que a autenticação pode falhar quando os utilizadores ainda não estão registados no fator exigido. A resolução de problemas do Meraki da Okta também identifica certificados inválidos ou não fidedignos e perfis 802.1X incorretamente implementados como causas de falha na ligação. Registe primeiro. Ligue em segundo.
Compare as Duas Opções EAP de Forma Honesta
| Método | Credencial enviada | Inscrição antes da primeira ligação | Onde se adequa | Falha no planeamento para |
|---|---|---|---|---|
| EAP-TTLS com palavra-passe ou código de acesso | Palavra-passe ou código de acesso Okta dentro de um túnel TLS | Obrigatório, porque o EAP-TTLS não suporta inscrição | Dispositivos mistos ou não geridos com utilizadores inscritos | Utilizadores ainda não inscritos no fator não conseguem ligar-se |
| EAP-TLS com certificado emitido por MDM | Certificado de cliente emitido via SCEP | Obrigatório, com o certificado enviado pelo MDM | Dispositivos corporativos geridos à escala | Um certificado de servidor ou cliente expirado remove o acesso em todo o local |
O EAP-TTLS mantém as palavras-passe no projeto. Ficam expostas a phishing, reutilização, reposições pelo suporte técnico e a uma gestão de desafios complicada num suplicante WiFi. O EAP-TLS remove a palavra-passe da troca sem fios e oferece autenticação mútua, mas transfere o trabalho para a sua autoridade de certificação, emissão SCEP, renovação e pipeline de revogação. Nenhum é gratuito. Está a escolher onde fica a carga operacional.
Crie o Ciclo de Vida Que a Maioria dos Guias Omite
- Escolha a autoridade de certificação: Decida qual a CA que assina o certificado do servidor RADIUS e qual a CA que emite os certificados de cliente. Não as misture no perfil e não se deixe surpreender pela expiração de um certificado de servidor público.
- Agende a renovação com antecedência: Renove o certificado do servidor bem antes de expirar, envie a nova âncora de confiança enquanto a antiga ainda funciona e confirme se os dispositivos validam o nome de servidor esperado.
- Envie perfis através do MDM: Utilize o Intune, Jamf ou o seu MDM existente para entregar o SSID, tipo de EAP, CA de confiança, nome do servidor e certificado SCEP. A instalação manual não é escalável e não pode ser auditada.
- Ordene a integração antes da imposição: Disponibilize aos dispositivos um caminho de integração temporário, confirme que o perfil e o certificado foram entregues e, em seguida, imponha o SSID de colaboradores. Um dispositivo sem confiança não pode usar a rede de colaboradores para obter a sua confiança.
- Planeie a revogação e a recuperação: Defina o que acontece quando um dispositivo é perdido, um certificado é revogado, uma CA muda ou o perfil MDM é removido. Teste a reemissão num dispositivo sobressalente.
Execute uma matriz de testes antes de qualquer alteração no local. Teste Windows, macOS, iOS e Android, cada um como gerido e não gerido, na primeira ligação, na religação, no roaming entre pontos de acesso e após uma renovação simulada de certificado. Inclua um utilizador não inscrito e um dispositivo com o perfil removido.
Imagine que o envio de um perfil falha sem qualquer aviso numa sucursal à sexta-feira. Na segunda-feira, todos os dispositivos geridos nessa localização rejeitam o certificado do servidor, enquanto a sede, que recebeu o perfil, funciona sem problemas. A política da Okta não mudou. A entrega da confiança sim. Este cenário é a razão pela qual os relatórios de perfis pertencem aos seus critérios de entrada em funcionamento, e não a uma análise pós-incidente.
Como Configurar o Agente RADIUS da Okta Passo a Passo
Comece pelo caminho do pedido, pois este indica-lhe onde procurar quando uma autenticação falha. O controlador envia um pedido RADIUS para o Okta RADIUS Server Agent, o agente chama as API da Okta, a Okta avalia a política, um desafio opcional de MFA regressa através do dispositivo de rede, e o agente envia um Access-Accept ou Access-Reject de volta para o controlador. Cada etapa pode falhar sem que as outras estejam avariadas.
A sequência de implementação abaixo segue o modelo do guia de servidor de acesso à rede da Okta, que posiciona o agente entre o servidor de acesso à rede e a avaliação de políticas da Okta na porta UDP 1812. Construa-o nesta ordem, num laboratório, com registo de pacotes e do agente disponível desde o primeiro teste.
Crie o Caminho de Laboratório por Ordem
- Instale o agente como um serviço. Instale o Okta RADIUS Server Agent num anfitrião Windows ou Linux que consiga alcançar tanto o controlador sem fios como o Okta. Não o instale numa estação de trabalho que entre em modo de suspensão, aplique atualizações de forma imprevisível ou esteja atrás de uma regra de firewall não documentada. O erro habitual é provar a acessibilidade do Okta a partir da consola do servidor, mas nunca provar a acessibilidade do controlador ao agente.
- Crie a aplicação RADIUS no Okta. Crie a aplicação, tome nota das definições de que o agente precisa e mantenha o nome associado ao SSID e ao âmbito do local que serve. Nomes de aplicações vagos tornam as pesquisas de registos posteriores lentas. Não reutilize uma aplicação RADIUS de VPN para WiFi apenas porque ambas utilizam RADIUS.
- Configure o controlador como o cliente RADIUS. Aponte o controlador sem fios ou o servidor de acesso à rede para o endereço IP do agente, defina o UDP 1812 e insira um segredo partilhado correspondente em ambas as extremidades. Digite o segredo, não o cole a partir de uma mensagem de chat que possa adicionar um espaço no final. Uma incompatibilidade de segredo parece muitas vezes uma palavra-passe incorreta no cliente.
- Restrinja a origem. Limite o IP de origem do cliente ou a zona de rede do Okta apenas aos endereços do controlador. Isto impede que anfitriões internos arbitrários enviem pedidos de autenticação para o agente. O erro comum é permitir a sub-rede de gestão durante os testes e nunca a restringir.
- Atribua os grupos Okta corretos. Atribua a aplicação RADIUS apenas aos grupos que devem ter acesso a este SSID. A atribuição de grupos é a sua barreira geral entre colaboradores, prestadores de serviços e administradores. Não atribua toda a empresa prometendo corrigir a segmentação mais tarde com regras de firewall que ninguém criou.
- Teste a aceitação e a rejeição. Ligue um cliente de laboratório com uma conta de teste dentro do grupo atribuído e, em seguida, teste a mesma conta após a remover. Precisa de ambos os resultados no registo do controlador e no registo do Okta. Testar apenas o sucesso não prova nada sobre a revogação.
- Comprove o comportamento do desafio. Se a política exigir MFA, confirme se o suplicante do cliente específico e o controlador conseguem apresentar e responder ao desafio dentro dos respetivos limites de tempo. Muitos não conseguem fazer isto de forma limpa. Se a solicitação nunca aparecer, não o resolva enfraquecendo a política em produção antes de compreender o limite do protocolo.
Antes de afinar qualquer outro elemento, observe uma autenticação completa em laboratório e compare cada etapa com os seus registos.
Para a variante Meraki, o cliente fornece um nome de utilizador e palavra-passe da Okta sob a configuração 802.1X EAP documentada pela Okta. Verifique a confiança do certificado e o perfil implementado no cliente de teste antes de continuar a alterar as definições de SSID. Um certificado inválido ou um perfil incorreto anularão uma configuração de controlador correta, pelo que deve distribuir o perfil através do MDM em vez de o instalar manualmente.
Se o seu projeto necessitar de métodos EAP ou de uma escala com a qual um agente no local lida mal, compare essa limitação com uma camada gerida de RADIUS-as-a-Service antes de multiplicar os servidores de agentes entre sites. Independentemente do que escolher, mantenha um caminho de administrador de emergência separado que não dependa do agente, das API da Okta ou do serviço MFA. Precisará dele durante o primeiro incidente de certificados ou de WAN, não depois dele.
Não promova uma configuração porque um portátil se ligou uma vez. Promova-a quando a aceitação, rejeição, remoção de grupo, tempo limite e reinício do agente se comportarem exatamente como documentou.
Definir Regras de Acesso Condicional e Postura do Dispositivo
Coloque cada controlo na camada que o pode aplicar. A Okta decide quem é o utilizador, a que grupos pertence e qual a política de fatores que se aplica. O MDM decide se o dispositivo está inscrito e em conformidade e disponibiliza o seu certificado e perfil WiFi. O agente ou controlador RADIUS transforma essas entradas em Access-Accept ou Access-Reject e aplica a VLAN ou função devolvida.
A atribuição de grupos à aplicação RADIUS decide quem pode aceder ao SSID. A política de fatores nessa aplicação decide se o MFA é obrigatório, mas o controlador e o suplicante ainda têm de transportar o desafio. A postura do dispositivo não vem de uma palavra-passe. Vem da inscrição no MDM e da presença de um certificado válido, pelo que um dispositivo pessoal não gerido não deve entrar na rede de colaboradores apenas porque o seu proprietário conhece credenciais válidas.
A pertença a grupos de diretório também pode determinar o posicionamento após a aceitação. Associe cada grupo a uma VLAN ou função, devolva esse atributo no Access-Accept e mantenha a associação suficientemente reduzida para auditoria. A restrição de origem pertence à zona de rede Okta e ao agente. Apenas os endereços do controlador devem ser origens RADIUS válidas. As decisões de acesso à rede mais amplas devem manter-se coerentes com as suas network access control solutions globais, em vez de se tornarem num conjunto de exceções específicas por SSID.
Execute Três Verificações Antes do Lançamento
- Teste de revogação: Remova uma conta de teste real do respetivo grupo atribuído e confirme que a ligação seguinte é rejeitada. Em seguida, desative a conta e repita.
- Teste de postura: Tente com um dispositivo em conformidade registado, um dispositivo não conforme registado e um dispositivo não registado. Confirme que apenas o primeiro acede à VLAN de funcionários.
- Documento de auditoria: Registe cada associação de grupo a VLAN, o proprietário de cada grupo e o conjunto independente de regras de convidados num único documento que a sua equipa de suporte possa ler.
As equipas que estão a reforçar estes limites entre identidade, pontos de extremidade e dispositivos de rede também podem considerar a proteção de TI da Wisely útil como contexto mais amplo. Para esta implementação, mantenha o teste restrito. Se não for possível demonstrar que um controlo altera uma aceitação, rejeição ou VLAN no laboratório, ele ainda não está configurado.
Resolução de Problemas em Inícios de Sessão WiFi da Okta Com Falha
Comece pelo sintoma que os utilizadores mais reportam. Um cliente que nunca apresenta um pedido de credenciais normalmente não está à espera da Okta. Está a faltar-lhe o perfil 802.1X, está a oferecer o método EAP errado ou está a rejeitar o certificado do servidor antes de as credenciais serem enviadas. Verifique o perfil do dispositivo e as definições de EAP do controlador antes de redefinir a palavra-passe de qualquer pessoa.
Trabalhe uma camada de cada vez. Confirme que o serviço do agente está em execução, leia o motivo de rejeição do controlador, depois altere uma definição e volte a testar com o mesmo dispositivo e conta. Se editar o segredo, o perfil, o grupo e o certificado ao mesmo tempo, resolverá o início de sessão sem saber qual a falha que voltará a surgir no próximo local.
Associe o Sintoma à Primeira Correção
| Sintoma | Causa provável | Primeira correção |
|---|---|---|
| O cliente nunca apresenta o pedido de credenciais | Perfil 802.1X em falta ou tipo de EAP incompatível | Volte a implementar o perfil e alinhe o método EAP com o controlador |
| A autenticação esgotou o tempo limite | UDP 1812 bloqueado ou serviço do agente inativo | Verifique o caminho da firewall e o estado do serviço do agente a partir da rede do controlador |
| Access-Reject com a palavra-passe correta | Segredo partilhado incompatível ou utilizador fora do grupo atribuído | Introduza novamente o segredo em ambas as extremidades e confirme a atribuição do grupo |
| Rejeições apenas a partir de um controlador | IP de origem ou zona de rede exclui esse controlador | Compare o endereço do controlador com a zona permitida |
| O pedido de MFA nunca aparece | O cliente ou controlador não consegue apresentar o desafio | Testar outro cliente e confirmar o caminho do desafio no laboratório |
| Funciona no Windows, falha no iOS | Confiança no certificado ou incompatibilidade de perfil | Verifique a cadeia do certificado do servidor e as definições de confiança do perfil no SO com falha |
| Local que funcionava falha após uma data definida | O certificado do servidor expirou | Renove o certificado e envie o perfil de confiança atualizado |
Separe correções rápidas de correções a nível de frota. Inserir novamente um segredo partilhado, corrigir um grupo, adicionar um endereço de origem do controlador ou reiniciar o agente pode resolver rapidamente uma falha de laboratório. Renovar um certificado de servidor, reconstruir um perfil de confiança e aguardar que milhares de dispositivos estabeleçam ligação com o MDM pode demorar dias. Não prometa uma recuperação no próprio dia para um problema na cadeia de confiança.
Suponha que os portáteis Windows se voltam a ligar após uma alteração de certificado, mas os iPhones falham num edifício inteiro. Esse padrão afasta a responsabilidade da política da Okta, porque as mesmas contas têm sucesso noutros locais. Compare a CA de confiança do perfil iOS, o nome do servidor esperado e a cadeia de certificados com os de um dispositivo Windows funcional. Um SO pode ter armazenado em cache ou recebido a nova confiança, enquanto o outro ainda não o fez.
Escaladize com provas. Se um ciclo de testes não alterar o motivo da rejeição, pare de editar as definições de produção, leve o dispositivo com falha de volta para o SSID de laboratório e compare a sua associação, troca EAP, resultado de RADIUS e VLAN atribuída com um dispositivo funcional. Traga os carimbos de data/hora consigo. Tentar adivinhar ao longo de quatro sistemas faz perder a janela de alteração.
Confirme o piloto antes de expandir para mais locais
Um início de sessão no Okta bem-sucedido não é uma sessão de WiFi funcional. O piloto tem de medir a transação completa, desde a associação até ao acesso à rede utilizável, porque os utilizadores não querem saber qual o salto que devolveu o erro. O fluxo de melhores práticas do RADIUS do Okta descreve um fluxo de desafio que envolve até onze passos lógicos, incluindo o encaminhamento de credenciais, validação de API, apresentação de desafio MFA, resposta ao desafio, segunda validação e a decisão final do RADIUS. Instrumente a cadeia em conformidade.
Utilize quatro pontos de verificação para cada dispositivo piloto. Primeiro, a associação e negociação 802.1X/EAP no ponto de acesso. Segundo, a receção do pedido RADIUS no agente. Terceiro, a política Okta e a resposta do fator. Quarto, o Access-Accept ou Access-Reject final no controlador, seguido da VLAN correta. Separe o sucesso à primeira tentativa, a latência de autenticação média e do percentil 95, a taxa de tempo limite, os pedidos repetidos e as causas de rejeição por OS do dispositivo, local, SSID, modelo do controlador e tipo de fator.
O Okta não publica nenhuma referência universal de sucesso de autenticação WiFi, por isso defina uma regra de aceitação local e defenda-a. Por exemplo, exija pelo menos 99% de conclusão à primeira tentativa no piloto controlado, zero rejeições não explicadas e nenhum tempo limite de autenticação além do seu orçamento de roaming. Trate esses valores como os seus próprios limites para o piloto e, em seguida, valide-os sob concorrência máxima e num teste de falha de WAN. Um início de sessão que funciona para cinco utilizadores de laboratório ao meio-dia pode falhar quando um turno começa e centenas de dispositivos se voltam a ligar ao mesmo tempo.
A sua evidência precisa de ser consultável em toda a propriedade. O Purple Access fornece um registo de autenticação que mostra cada aceitação e rejeição, com identidade, dispositivo, estado de inscrição no MDM, método, ponto de acesso, SSID, local, VLAN, função, motivo e marcas temporais, numa única consulta global. Esse nível de detalhe também é importante para a evidência de segmentação, especialmente porque o PCI-DSS v4.0.1 Req 2.3.2 exige que as chaves sem fios sejam alteradas quando alguém que as conhece sai, o que torna uma chave partilhada impraticável. Mantenha a estrutura subjacente do design da rede WiFi em vista, uma vez que a autenticação não consegue salvar limites de VLAN fracos.
Expanda apenas com base numa decisão clara de prosseguimento. Todos os SOs e tipos de fatores no âmbito cumprem as três condições de aceitação, as rejeições têm causas identificadas e o caminho do administrador de emergência foi testado com o agente parado. Se alguma condição falhar, permaneça no piloto e corrija essa camada. Adicionar locais multiplica uma falha não resolvida.
Se o seu projeto de autenticação Okta WiFi já ultrapassou as palavras-passe partilhadas, servidores de agentes frágeis ou trabalho manual de certificados, o Purple Access pode colocar convidados, colaboradores e dispositivos em redes separadas orientadas por identidade, utilizando os pontos de acesso que já possui. Traga os seus modelos de controladores, MDM e o plano de grupos para VLAN, e ajudá-lo-emos a validar uma implementação em laboratório antes de avançar para um site de produção.
