Enterprise WiFi authentication without Active Directory or an on-prem server
Este guia explica como implantar a autenticação WiFi segura WPA2/3-Enterprise sem um Active Directory local, Windows NPS ou servidor RADIUS. Ele aborda a incompatibilidade de protocolo entre provedores de identidade em nuvem e 802.1X, os argumentos a favor do EAP-TLS em relação ao PEAP-MSCHAPv2 e como implantar o RADIUS em nuvem com certificados emitidos por MDM no Microsoft Entra ID, Okta ou Google Workspace. Escrito para líderes de TI em organizações focadas em nuvem e com forte presença de Mac/Chromebook que estão prontas para aposentar a infraestrutura local.
Ouça este guia
Ver transcrição do podcast
📚 Part of our core series: Segurança e autenticação WiFi corporativa: o guia completo →
Resumo executivo
A maioria das organizações migrou sua identidade para a nuvem. O Microsoft Entra ID, Okta e Google Workspace agora gerenciam usuários, grupos e políticas de acesso para e-mail, aplicativos SaaS e gerenciamento de dispositivos. Mas o WiFi corporativo não acompanhou esse ritmo. Os pontos de acesso ainda esperam um servidor RADIUS, e esse servidor RADIUS historicamente tem sido o Windows Network Policy Server (NPS) conectado a um controlador de domínio Active Directory local.
Essa incompatibilidade força as equipes de TI a manter uma infraestrutura local redundante apenas para manter o WiFi funcionando. A solução é o RADIUS em nuvem: um serviço de autenticação totalmente gerenciado que se comunica via RADIUS com seus pontos de acesso e via OAuth2, SCIM e SAML com seu provedor de identidade em nuvem. Combine-o com a entrega de certificados EAP-TLS por meio do seu MDM e você terá uma implantação 802.1X completa, sem servidores locais, sem aplicação de patches de SO e com revogação instantânea de acesso vinculada diretamente ao seu diretório em nuvem.
A Purple opera o RADIUS em nuvem em mais de 80.000 locais globalmente, com 99,999% de tempo de atividade (dados internos da Purple, 2024) e integrações nativas com Microsoft Entra ID, Okta e Google Workspace. Você pode estar ativo em seus pontos de acesso existentes da Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet em menos de uma hora.
Análise técnica detalhada
A incompatibilidade de protocolo no cerne do problema
O desafio fundamental é que os provedores de identidade em nuvem e os pontos de acesso WiFi falam linguagens totalmente diferentes. O Microsoft Entra ID (antigo Azure AD) autentica usuários via SAML, OIDC e OAuth2 - os protocolos que navegadores e aplicativos SaaS usam. Os pontos de acesso WiFi usam RADIUS (Remote Authentication Dial-In User Service, RFC 2865), um protocolo baseado em UDP projetado na década de 1990 para conexões discadas e VPN. A Microsoft nunca lançou um endpoint RADIUS nativo para o Entra ID. Você não pode apontar um ponto de acesso Meraki ou Aruba diretamente para o Azure e esperar que o 802.1X funcione.
Esse é o obstáculo que toda equipe de TI focada em nuvem enfrenta ao tentar proteger o WiFi de funcionários com WPA2-Enterprise ou WPA3-Enterprise. Algo precisa preencher a lacuna entre o ponto de acesso e o provedor de identidade em nuvem. Esse algo é o RADIUS em nuvem.
Por que o PEAP-MSCHAPv2 falha sem o Active Directory
Historicamente, as implantações 802.1X dependiam do PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2). O usuário digitava seu nome de usuário e senha, o ponto de acesso encaminhava a solicitação para o servidor RADIUS e o servidor RADIUS validava a senha em relação a um hash NTLM armazenado no Active Directory.
O Microsoft Entra ID não armazena hashes NTLM. Isso não é uma lacuna de configuração — é uma decisão arquitetônica deliberada. O Entra ID é um provedor de identidade em nuvem moderno, não um controlador de domínio. Consequentemente, um servidor RADIUS apontado para o Entra ID não pode validar um desafio PEAP-MSCHAPv2. A única maneira de fazer o PEAP funcionar com o Entra ID é implantar o Entra Domain Services, um Active Directory gerenciado pago que sincroniza a partir do Entra ID, e então executar o NPS com base nele. Isso reintroduz a maior parte do que você estava tentando eliminar: VMs do Windows Server, aplicação de patches de SO, armazenamento de hash NTLM e gerenciamento manual de certificados.
EAP-TLS: a resposta certa para organizações focadas em nuvem
O EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) substitui senhas por certificados digitais X.509. O dispositivo apresenta um certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação a uma Autoridade Certificadora (CA) confiável. Como não há senha na troca, o servidor RADIUS não precisa de um armazenamento de hash NTLM. Ele precisa apenas confiar na CA e verificar a associação de grupo do usuário no provedor de identidade para aplicar a VLAN e a política de acesso corretas.
O EAP-TLS é resistente a phishing por design. Não há credenciais para roubar. Ele atende às diretrizes da CISA sobre autenticação multifator resistente a phishing e se alinha aos requisitos do PCI DSS para autenticação forte em redes que lidam com dados de titulares de cartões. É o método de autenticação recomendado pelo IEEE 802.1X para frotas de dispositivos gerenciados.
Arquitetura de autenticação 802.1X focada em nuvem: os dispositivos se autenticam via EAP-TLS através do RADIUS em nuvem da Purple, que valida os certificados e aplica políticas baseadas em grupo a partir do Entra ID, Okta ou Google Workspace.
Como o MDM substitui a CA local
Em uma implantação 802.1X tradicional, os certificados eram emitidos por uma Autoridade Certificadora local que executava o Active Directory Certificate Services (AD CS). Em uma implantação focada em nuvem, o MDM assume essa função usando o SCEP (Simple Certificate Enrollment Protocol). O Microsoft Intune, Jamf Pro e outras plataformas MDM podem solicitar certificados de uma CA hospedada na nuvem e enviá-los silenciosamente para dispositivos gerenciados.
O fluxo funciona da seguinte forma. O administrador de TI cria um perfil de certificado SCEP no MDM, direcionado aos grupos de dispositivos que exigem acesso WiFi. O MDM envia o certificado para dispositivos Windows, macOS, iOS, iPadOS, Android Enterprise e ChromeOS automaticamente. O usuário não vê nada. O certificado é vinculado à identidade do dispositivo no MDM e é renovado automaticamente antes do vencimento. Quando o dispositivo se conecta ao WiFi, ele apresenta o certificado ao servidor RADIUS em nuvem, que o valida em relação à CA e aplica a política de rede correta.
Para organizações que usam o Microsoft Intune, o Microsoft Cloud PKI fornece uma CA totalmente gerenciada que se integra diretamente com os perfis SCEP do Intune, eliminando a necessidade de um servidor NDES (Network Device Enrollment Service) local. Para frotas Mac e iOS gerenciadas pelo Jamfets, a CA integrada do Jamf ou uma CA em nuvem de terceiros servem ao mesmo propósito.
SCIM e revogação instantânea de acesso
Um dos aspectos operacionalmente mais importantes do RADIUS em nuvem é o provisionamento SCIM (System for Cross-domain Identity Management). O SCIM é um padrão aberto que envia alterações de identidade da fonte da verdade — seu provedor de identidade em nuvem — para os sistemas dependentes em tempo real. Quando um funcionário é desativado no Entra ID ou Okta, o SCIM envia essa alteração para o serviço RADIUS em nuvem imediatamente. Na próxima vez que o dispositivo tentar se autenticar, o servidor RADIUS retornará Access-Reject. Com um curto tempo limite de sessão configurado no ponto de acesso, o dispositivo é removido da rede poucos minutos após a desativação da conta.
Esta é uma melhoria de segurança significativa em relação às redes PSK compartilhadas, onde a única maneira de revogar o acesso é alterar a senha em todos os dispositivos, e em relação às implantações legadas de RADIUS que dependem de sincronizações periódicas de LDAP com uma janela de horas ou dias.
RadSec: protegendo o tráfego RADIUS pela internet
O RADIUS tradicional usa UDP e fornece apenas autenticação básica de mensagens. Quando o seu servidor RADIUS está no mesmo data center que os seus pontos de acesso, isso é aceitável. Quando o seu servidor RADIUS é um serviço em nuvem, o tráfego de autenticação atravessa a internet pública. O RadSec (RADIUS sobre TLS, RFC 6614) criptografa a troca RADIUS usando TLS, fornecendo confidencialidade e integridade para o tráfego de autenticação. A Purple oferece suporte nativo ao RadSec, com fallback de IPsec para pontos de acesso que ainda não suportam RadSec.
Guia de implementação
A implantação do RADIUS em nuvem com EAP-TLS requer quatro etapas coordenadas. Um SSID piloto pode estar ativo em menos de uma hora se o Entra ID e um MDM já estiverem configurados.
Etapa 1: Conecte o RADIUS em nuvem ao seu provedor de identidade
Conecte a Purple ao seu provedor de identidade via consentimento do administrador OAuth2 (para Entra ID) ou token de API (para Okta e Google Workspace). Isso autoriza a Purple a ler usuários, grupos e associações de grupo do diretório. Configure o provisionamento SCIM para enviar alterações de status do usuário para a Purple em tempo real. Nenhuma credencial de entidade de serviço é armazenada em disco. As alterações de grupo são propagadas no próximo evento de autenticação, e não em um cronograma de sincronização.
Etapa 2: Configure seu MDM e perfil SCEP
No Microsoft Intune, crie um Perfil de Certificado Confiável para a CA raiz e, em seguida, crie um perfil de certificado SCEP apontando para a CA gerenciada pela Purple. Defina o escopo de ambos os perfis para os grupos de dispositivos que exigem acesso WiFi. Para o Jamf, configure um payload SCEP em um perfil de configuração. O MDM envia os certificados de forma silenciosa. Verifique a entrega dos certificados no painel de conformidade do MDM antes de prosseguir.
Etapa 3: Defina as políticas de rede no painel do RADIUS em nuvem
Crie políticas RADIUS que mapeiem grupos de provedores de identidade para VLANs e controles de acesso específicos. For exemplo, mapeie o grupo do Entra ID "Staff-Finance" para a VLAN 20 com acesso total à internet, e mapeie "Staff-Contractors" para a VLAN 30 com acesso por tempo limitado que expira automaticamente. O painel da Purple aplica essas políticas no momento da autenticação, sem a necessidade de alterações no firewall.
Etapa 4: Atualize a configuração do ponto de acesso
Atualize a configuração do SSID em seus pontos de acesso para usar WPA2-Enterprise ou WPA3-Enterprise com 802.1X. Insira os hostnames ou endereços IP dos endpoints primário e secundário do RADIUS em nuvem da Purple, junto com o segredo compartilhado. Configure os pontos de acesso para usar atribuição dinâmica de VLAN com base nos atributos RADIUS retornados pela Purple. Teste com um único SSID em um subconjunto de pontos de acesso antes de implementar em toda a infraestrutura.
RADIUS em nuvem vs. RADIUS local: uma comparação direta entre tempo de implantação, dependência do Active Directory, alta disponibilidade, aplicação de patches de SO, integração de identidade e gerenciamento do ciclo de vida de certificados.
Boas práticas
Estas recomendações refletem os padrões IEEE 802.1X, os requisitos do PCI DSS v4.0 e a experiência operacional em mais de 80.000 estabelecimentos da Purple.
Exija EAP-TLS para dispositivos gerenciados. As senhas são suscetíveis a phishing e preenchimento de credenciais (credential stuffing). Os certificados fornecem prova criptográfica de identidade e conformidade do dispositivo. O EAP-TLS é o único método 802.1X resistente a phishing por design.
Use SCIM para revogação instantânea. Sincronizações periódicas de LDAP deixam uma janela de tempo onde um funcionário desligado mantém o acesso à rede. O SCIM garante que o acesso seja revogado no momento em que a conta é desativada no provedor de identidade.
Implante RADIUS multirregião. Configure seus pontos de acesso com pelo menos dois endpoints RADIUS em diferentes regiões geográficas. A Purple oferece failover multirregião ativo-ativo por padrão, com o failover sendo concluído em segundos.
Segmente o tráfego com VLANs dinâmicas. Use as associações de grupo do provedor de identidade para atribuir usuários a VLANs específicas de forma dinâmica. Isso isola o tráfego confidencial e limita o raio de alcance de um dispositivo comprometido sem exigir alterações manuais no firewall.
Habilite o RadSec. Se os seus pontos de acesso suportarem RadSec, habilite-o para criptografar o tráfego de autenticação entre o ponto de acesso e o servidor RADIUS em nuvem. Isso é particularmente importante para filiais e locais onde o ponto de acesso está em um segmento de rede não confiável.
Monitore o ciclo de vida dos certificados. Defina a renovação automática do MDM para ser acionada em 80% do tempo de vida do certificado. Para um certificado de um ano, a renovação começa na marca de 10 meses. Crie alertas para dispositivos que não conseguirem renovar antes que o certificado expire.
Para uma abordagem mais ampla sobre padrões e frameworks de segurança de WiFi corporativo, consulte nosso Segurança de WiFi Corporativo: Um Guia Completo para 2026 .
Solução de problemas e mitigação de riscos
A transição para o RADIUS em nuvem introduz novas dependências. Prepare-se para esses modos de falha comuns antes que eles afetem a produção.
CerExpiração de certificado.** Se o certificado de um dispositivo expirar antes que o MDM o renove, a autenticação do dispositivo falhará silenciosamente. O usuário verá um erro de conexão sem explicação. Mitigue isso configurando a renovação automática do MDM em 80% do tempo de vida do certificado e monitorando o painel de conformidade do MDM para dispositivos com certificados prestes a expirar.
Falhas de sincronização do MDM. Um dispositivo que saia da conformidade do MDM ou falhe ao realizar o check-in pode não receber um certificado renovado. Implemente políticas de conformidade que sinalizem dispositivos problemáticos e alertem os administradores antes que o certificado expire.
Firewall bloqueando o tráfego RADIUS. Os pontos de acesso devem alcançar os endpoints do RADIUS na nuvem na porta UDP 1812 (autenticação) e porta UDP 1813 (accounting), ou porta TCP 2083 para RadSec. Regras de firewall de saída em filiais frequentemente bloqueiam essas portas. Teste a conectividade a partir da VLAN de gerenciamento do ponto de acesso antes da implantação.
Falhas de provisionamento SCIM. Se a conexão SCIM entre o provedor de identidade e a Purple for interrompida, as alterações de status do usuário não serão propagadas. Monitore o status de sincronização do SCIM tanto no provedor de identidade quanto no painel da Purple. Configure alertas para falhas de sincronização.
Dispositivos legados sem suporte a certificado. Dispositivos IoT, impressoras e hardwares mais antigos podem não suportar EAP-TLS. Para esses dispositivos, use iPSK (chaves pré-compartilhadas individuais) em vez de uma PSK compartilhada. A Purple suporta iPSK nativamente, atribuindo uma chave exclusiva por dispositivo e colocando cada dispositivo na VLAN correta sem exigir suporte ao suplicante 802.1X.
ROI e impacto nos negócios
A migração do RADIUS local para o RADIUS na nuvem entrega valor mensurável em infraestrutura, operações e segurança.
| Dimensão | NPS local | RADIUS na nuvem (Purple) |
|---|---|---|
| Custo de infraestrutura | Licenças de Windows Server, computação de VM, armazenamento | Assinatura por AP, sem hardware de servidor |
| Tempo de implantação | Dias a semanas | Menos de uma hora |
| Alta disponibilidade | Manual - dois servidores mais replicação | Ativo-ativo multi-região, padrão |
| Atualização de SO | Mensal, sua equipe | Gerenciado pelo fornecedor |
| Chamados de suporte de WiFi | Alto - redefinições de senha, integração manual | Redução de 80% (dados de clientes Purple) |
| Revogação de acesso | Horas a dias via sincronização LDAP | Segundos via SCIM |
As equipes de TI que usam o Staff WiFi da Purple normalmente veem os chamados de suporte de WiFi caírem em 80% (dados internos da Purple, 2024), impulsionados pela eliminação de redefinições de senha e integração manual de dispositivos. A autenticação baseada em certificado também atende ao requisito 8.3 do PCI DSS para autenticação forte e ao controle A.9.4 da ISO 27001 para controle de acesso a sistemas e aplicativos, reduzindo a carga de auditoria sobre sua equipe de segurança.
Para organizações nos setores de varejo e hotelaria , a capacidade de gerenciar o Staff WiFi e o Guest WiFi a partir de um único painel na nuvem - com uma camada de identidade unificada - reduz a complexidade operacional em propriedades de vários locais. Para operadores de transporte e provedores de saúde , a capacidade de revogação instantânea e a trilha de auditoria completa atendem aos requisitos regulatórios sem a necessidade de ferramentas adicionais.
A camada de WiFi Analytics da Purple adiciona dados de ocupação e trabalho híbrido sobre a infraestrutura de autenticação, transformando o Staff WiFi de um centro de custo em uma fonte de inteligência operacional.
Leitura relacionada: Segurança de WiFi Corporativo: Um Guia Completo para 2026 - Integração de Firmware Personalizado OpenWrt com o Purple WiFi
Definições principais
802.1X
An IEEE standard (IEEE 802.1X-2020) for port-based network access control. It requires devices to authenticate before the access point grants network access, using an EAP exchange mediated by a RADIUS server.
IT teams use 802.1X to ensure only authorised users and devices connect to the corporate network. It provides per-user encryption, per-session keys, and a full audit trail of every connection event.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). A networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA) management for network access.
Access points forward every connection request to the RADIUS server, which decides whether to admit the device and which VLAN to assign it to. Cloud RADIUS replaces on-premises NPS or FreeRADIUS servers.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). An 802.1X authentication method that uses mutual X.509 certificate exchange instead of passwords.
EAP-TLS is the gold standard for managed device fleets. It is phishing-resistant, requires no password hash store, and is the only 802.1X method that satisfies CISA phishing-resistant MFA guidance.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2. A legacy 802.1X method that validates passwords against NTLM hashes stored in Active Directory.
PEAP-MSCHAPv2 fails in cloud-only environments because Entra ID does not store NTLM hashes. Organisations migrating from on-premises AD must replace PEAP with EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. A protocol used by MDM platforms to request and install digital certificates on devices automatically, without user interaction.
IT teams use SCEP with Intune or Jamf to silently provision WiFi certificates to employee devices. SCEP replaces the on-premises NDES (Network Device Enrollment Service) server in cloud-first deployments.
SCIM
System for Cross-domain Identity Management (RFC 7644). An open standard that automates the real-time exchange of user identity information between IT systems.
SCIM ensures that when an employee is disabled in Entra ID or Okta, that change is pushed to the cloud RADIUS service immediately, revoking WiFi access within seconds rather than hours.
NPS
Network Policy Server. Microsoft's RADIUS implementation, typically run on Windows Server as part of an on-premises Active Directory environment.
Cloud-first organisations are retiring NPS to eliminate Windows Server VMs, OS patching, and the dependency on on-premises Active Directory. Cloud RADIUS is the direct replacement.
RadSec
RADIUS over TLS (RFC 6614). A protocol that encrypts RADIUS authentication traffic using TLS, replacing the UDP-based cleartext transport used by traditional RADIUS.
RadSec is essential when using cloud RADIUS, as authentication traffic must traverse the public internet between the access point and the cloud service. Purple supports RadSec natively.
iPSK
Individual Pre-Shared Key. A variant of WPA2-Personal that assigns a unique pre-shared key to each device, rather than a single shared key for all devices.
iPSK is used for IoT devices, printers, and other hardware that cannot support 802.1X EAP-TLS. It provides per-device accountability and VLAN assignment without requiring certificate support.
Dynamic VLAN
A network segmentation technique where the RADIUS server returns a VLAN identifier in the Access-Accept response, and the access point places the device on that VLAN automatically.
Dynamic VLANs allow IT teams to segment staff, contractors, IoT devices, and guests onto separate network segments based on identity provider group membership, without manual firewall changes.
Exemplos práticos
A 400-site retail chain needs to secure Staff WiFi across all locations. They run Cisco Meraki access points and use Microsoft Entra ID with Intune for device management. They currently use a shared WPA2-Personal PSK because they have no on-premises Active Directory to run NPS. A recent internal audit flagged the shared PSK as a PCI DSS compliance gap.
The chain deploys Purple's cloud RADIUS. First, they connect Purple to Entra ID via OAuth admin consent and configure SCIM provisioning. In Intune, they create a Trusted Certificate Profile for the Purple CA root and a SCEP certificate profile scoped to the 'Staff-Retail' device group. Intune silently pushes certificates to all managed point-of-sale terminals and staff tablets. In the Meraki dashboard, they update the Staff SSID to WPA2-Enterprise, enter the Purple cloud RADIUS primary and secondary endpoints, and enable dynamic VLAN assignment. When a device connects, it presents its Intune-issued certificate, Purple validates it against the CA and checks the Entra ID group, and the device is placed on VLAN 10 (staff network) or VLAN 20 (management network) based on group membership. The shared PSK is retired. Rollout across 400 sites takes one weekend, as no on-site hardware is deployed - only SSID configuration changes in Meraki.
A 15,000-student university uses Google Workspace as its primary identity provider. The IT team wants to provide secure WiFi for staff and students on a BYOD estate of MacBooks, Chromebooks, and Android phones. They have no on-premises Active Directory and no appetite to run servers.
The university integrates Purple's cloud RADIUS with Google Workspace. For managed Chromebooks, they use Google Admin to push a WiFi certificate profile via SCEP, silently enrolling each device. For BYOD MacBooks and Android phones, they deploy a lightweight onboarding application that authenticates the user with their Google credentials and installs a certificate on the device in a single tap. Subsequent connections use EAP-TLS silently. Purple maps Google Workspace Organisational Units to VLANs: staff land on VLAN 10, students on VLAN 20, and guest visitors on a captive portal SSID. When a student graduates and their Google account is suspended, SCIM pushes the change to Purple and their WiFi access is revoked within minutes.
Questões práticas
Q1. Your organisation has fully migrated from on-premises Active Directory to Microsoft Entra ID. Your current Staff WiFi uses PEAP-MSCHAPv2 against an NPS server that was joined to the old domain. After decommissioning the domain controller, staff report they can no longer connect to the WiFi. What is the root cause, and what is the correct long-term fix?
Dica: Consider what PEAP-MSCHAPv2 requires from the directory, and whether Entra ID provides it.
Ver resposta modelo
The root cause is that PEAP-MSCHAPv2 requires the RADIUS server to validate the user's password against an NTLM hash stored in Active Directory. With the domain controller decommissioned, NPS has no directory to validate against. Entra ID does not store NTLM hashes, so NPS cannot be redirected to Entra ID. The correct long-term fix is to replace NPS with a cloud RADIUS service, migrate from PEAP-MSCHAPv2 to EAP-TLS, and use the MDM (Intune) to issue device certificates via SCEP. This eliminates the dependency on any on-premises directory.
Q2. You are deploying cloud RADIUS for a 200-device fleet of corporate MacBooks managed by Jamf Pro. Your identity provider is Okta. What is the most secure and operationally efficient way to provision the WiFi credentials to these devices?
Dica: Look for a method that requires no user interaction, avoids passwords, and integrates with your existing MDM.
Ver resposta modelo
Configure Jamf Pro to use SCEP to silently push device certificates to the MacBooks. Create a SCEP payload in a Jamf configuration profile, pointing at the CA managed by your cloud RADIUS provider. Scope the profile to the relevant device group. Jamf will push the certificate to each MacBook automatically, with no user interaction. Configure the WiFi profile in the same configuration profile to use EAP-TLS with the SCEP-issued certificate. Connect the cloud RADIUS service to Okta via SCIM to ensure that when an employee is disabled in Okta, their WiFi access is revoked immediately.
Q3. An employee is terminated at 9am on a Monday. Their Entra ID account is disabled by HR at 9:05am. At 9:30am, a security alert shows the employee's laptop is still connected to the corporate WiFi from the car park. What configuration is missing, and how do you fix it?
Dica: How does the RADIUS server learn that the user's status has changed in the identity provider?
Ver resposta modelo
The deployment is relying on periodic LDAP syncs rather than SCIM provisioning. The LDAP sync has not yet run since the account was disabled, so the cloud RADIUS service still considers the user active. The fix is to enable SCIM provisioning between Entra ID and the cloud RADIUS service. SCIM pushes user state changes in real time, so when the account is disabled in Entra ID at 9:05am, the RADIUS service receives the change immediately. The next time the device attempts to re-authenticate (controlled by the session timeout on the access point), it receives an Access-Reject. Setting a short session timeout (15 to 30 minutes) on the access point limits the maximum window between account disable and network eviction.
Q4. Your venue has 50 IoT devices - digital signage players, environmental sensors, and printers - that do not support 802.1X EAP-TLS. How do you secure these devices on the same WiFi infrastructure as your EAP-TLS staff network?
Dica: Consider what authentication method provides per-device accountability without requiring certificate support.
Ver resposta modelo
Use iPSK (individual pre-shared keys) for the IoT devices. Assign a unique pre-shared key to each device in the cloud RADIUS dashboard, along with a VLAN assignment. Each device authenticates with its unique key, which the RADIUS server validates and uses to place the device on the IoT VLAN, isolated from the staff network. If a device is compromised or decommissioned, you revoke only that device's key without affecting any other device. This approach provides per-device accountability and network segmentation without requiring 802.1X supplicant support on the IoT hardware.
Continue a ler esta série
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).
The Security Benefits of RADIUS as a Service for Hybrid Workforces
Este guia de referência técnica explica como o RADIUS as a Service protege o acesso à rede para forças de trabalho híbridas em locais distribuídos. Ele aborda a arquitetura, os benefícios de segurança e as etapas de implantação para substituir a infraestrutura RADIUS local por um serviço de autenticação gerenciado na nuvem. Para gerentes de TI e arquitetos de rede em hotéis, redes de varejo, estádios e organizações do setor público, este guia fornece as evidências necessárias para avaliar e agir em uma migração para o RADIUS na nuvem neste trimestre.
Integrando RADIUS as a Service com Diretórios em Nuvem (Azure AD e Google Workspace)
Este guia de referência técnica detalha como integrar o RADIUS as a Service com diretórios em nuvem - Microsoft Entra ID e Google Workspace - para autenticação WiFi corporativa. Ele aborda a transição arquitetônica do NPS local para o RADIUS nativo da nuvem, a implantação de autenticação EAP-TLS baseada em certificados e as melhores práticas operacionais para proteger o acesso sem fio em ambientes de hotelaria, varejo e setor público. Para gerentes de TI e arquitetos de rede que já investem em identidade em nuvem, este guia preenche a lacuna entre o gerenciamento de diretórios e a segurança de rede física.