Como Configurar um Servidor RADIUS para Autenticação WiFi
Este guia de referência fornece aos líderes de TI e arquitetos de rede um plano abrangente para implementar um servidor RADIUS para autenticação WiFi empresarial. Abrange as compensações arquitetónicas entre implementações locais (on-premise) e na nuvem, a seleção do método EAP, a integração com o Active Directory e a atribuição dinâmica de VLAN. Os operadores de espaços e as equipas de TI encontrarão etapas de implementação práticas, estudos de caso reais e estratégias de mitigação de riscos para transitar de um ambiente PSK inseguro para uma infraestrutura 802.1X robusta ainda este trimestre.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
Para ambientes empresariais — quer se trate de um campus universitário em expansão, de um estádio de alta densidade ou de uma cadeia de retalho distribuída —, depender de uma Chave Pré-Partilhada (PSK) para acesso ao WiFi é uma vulnerabilidade de segurança significativa. Uma única credencial comprometida expõe toda a rede, e a revogação do acesso exige a alteração da palavra-passe em todos os dispositivos da propriedade. A implementação da autenticação 802.1X através de um servidor RADIUS (Remote Authentication Dial-In User Service) elimina este problema por completo: cada utilizador autentica-se individualmente, o acesso pode ser revogado instantaneamente e a segmentação de rede é aplicada de forma dinâmica.
Este guia fornece um roteiro definitivo para gestores de TI e arquitetos de rede implementarem a autenticação RADIUS. Abordamos as compensações arquitetónicas entre implementações locais (on-premise) e alojadas na nuvem, a configuração de métodos EAP (Extensible Authentication Protocol) e a integração com serviços de diretório como o Active Directory. Também demonstramos como uma camada de autenticação robusta se integra com soluções de Guest WiFi para fornecer um acesso contínuo aos visitantes, enquanto captura os WiFi Analytics que transformam a sua rede num ativo de business intelligence.
Análise Técnica Detalhada
A Arquitetura 802.1X
O padrão IEEE 802.1X define o Controlo de Acesso à Rede baseado em portas (PNAC). Num contexto sem fios, envolve três funções principais a trabalhar em conjunto:
| Função | Componente | Responsabilidade |
|---|---|---|
| Suplicante (Supplicant) | Dispositivo cliente (portátil, smartphone) | Apresenta credenciais para solicitar acesso à rede |
| Autenticador (Authenticator) | Ponto de Acesso WiFi ou Controlador | Aplica o controlo de acesso; retransmite mensagens EAP |
| Servidor de Autenticação | Servidor RADIUS | Valida credenciais; devolve atributos de aceitação/rejeição e de política |
Quando um suplicante se associa a um ponto de acesso, o AP bloqueia todo o tráfego de dados, exceto as mensagens EAP (Extensible Authentication Protocol). O AP encapsula estas mensagens EAP em pacotes RADIUS e encaminha-as para o servidor RADIUS. O servidor verifica as credenciais numa base de dados de backend — normalmente LDAP ou Active Directory — e devolve uma mensagem Access-Accept ou Access-Reject. Se for aceite, o AP desbloqueia a porta e o tráfego do cliente flui livremente.
Escolher um Método EAP
A segurança da sua implementação RADIUS depende fortemente do método EAP selecionado. Os dois mais prevalentes em implementações empresariais são:
EAP-TLS (Transport Layer Security) é o padrão de excelência. Requer certificados digitais tanto no servidor RADIUS como em cada dispositivo cliente, eliminando totalmente as palavras-passe. Mesmo que um atacante capture a troca de autenticação completa, não existem credenciais para extrair. A contrapartida é a sobrecarga administrativa: a implementação e gestão de certificados de cliente requer uma Infraestrutura de Chaves Públicas (PKI) funcional e uma solução MDM (por exemplo, Microsoft Intune, Jamf) para distribuir os certificados pelos endpoints.
PEAP-MSCHAPv2 (Protected EAP) é o método mais amplamente implementado na prática. Utiliza um certificado do lado do servidor para estabelecer um túnel TLS encriptado, dentro do qual o cliente se autentica com um nome de utilizador e palavra-passe. Isto é significativamente mais fácil de implementar do que o EAP-TLS porque apenas um certificado — o do servidor — precisa de ser gerido. No entanto, acarreta uma advertência crítica: se os dispositivos clientes não forem explicitamente configurados para validar o certificado do servidor RADIUS, ficam vulneráveis a ataques Man-in-the-Middle (MitM) através de pontos de acesso fraudulentos.
> Nota de Segurança Crítica: A não imposição de uma validação estrita de certificados nos dispositivos clientes anula eficazmente os benefícios de segurança do PEAP-MSCHAPv2. Um atacante pode implementar um AP fraudulento, apresentar um certificado falso e capturar as credenciais do utilizador em texto simples. Este não é um risco teórico — é um vetor de ataque bem documentado que tem sido explorado em ambientes reais.
Guia de Implementação
Passo 1: Decisão Arquitetural — RADIUS Local vs. na Nuvem
A primeira decisão é onde alojar a infraestrutura RADIUS. Esta é principalmente uma questão operacional e de custos, não de segurança — ambos os modelos podem ser implementados de forma segura.
RADIUS Local (por exemplo, Microsoft NPS, FreeRADIUS, Cisco ISE) é adequado para organizações com equipas de TI dedicadas, infraestrutura de diretório local existente e requisitos rigorosos de soberania de dados ou conformidade. Não depende de conectividade à internet para a autenticação, o que é uma vantagem significativa para ambientes onde o tempo de atividade da internet não pode ser garantido.
Cloud RADIUS é cada vez mais o modelo preferido para ambientes distribuídos — cadeias de Retalho , grupos de Hotelaria e centros de Transportes onde a implementação de servidores em cada local é operacionalmente inviável. O Cloud RADIUS integra-se nativamente com fornecedores de identidade na nuvem (Azure AD, Google Workspace, Okta) e oferece alta disponibilidade integrada e escalabilidade global.
Passo 2: Instalar e Configurar o Servidor RADIUS
Para uma implementação local utilizando o Microsoft NPS (a escolha mais comum em ambientes centrados em Windows):
- Instale a função Network Policy Server através do Server Manager.
- Registe o servidor NPS no Active Directory para permitir a leitura das propriedades de dial-in do utilizador.
- Crie uma entrada de RADIUS Client para cada ponto de acesso ou controlador sem fios, especificando o endereço IP do AP e um Shared Secret forte e exclusivo.
- Configure uma Network Policy que defina as condições (ex.: pertença a grupo de utilizadores) e restrições (ex.: método EAP, tempo limite de sessão) para o acesso.
- Configure a Connection Request Policy para processar pedidos localmente.
Para FreeRADIUS em Linux:
- Instale através do gestor de pacotes:
sudo apt-get install freeradius freeradius-ldap. - Configure
/etc/freeradius/3.0/clients.confpara definir os clientes RADIUS (APs) e os respetivos shared secrets. - Configure o módulo LDAP em
/etc/freeradius/3.0/mods-available/ldappara apontar para o seu Active Directory ou servidor LDAP. - Ative o módulo LDAP:
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/. - Defina os métodos EAP em
/etc/freeradius/3.0/mods-available/eap.
Passo 3: Configurar Pontos de Acesso
No seu controlador sem fios ou pontos de acesso individuais:
- Defina o(s) endereço(s) IP do servidor RADIUS e a porta de autenticação (predefinição: UDP 1812).
- Configure o Shared Secret — utilize um mínimo de 22 carateres, misturando carateres alfanuméricos e especiais. Utilize um segredo exclusivo por localização ou grupo de APs.
- Configure o SSID para utilizar o modo de segurança WPA2-Enterprise ou WPA3-Enterprise com gestão de chaves 802.1X.
- Configure um servidor RADIUS secundário para failover.
Passo 4: Integração de Diretório
Para a integração com AD local, o servidor RADIUS deve estar associado ao domínio ou ter acesso de leitura LDAP. Certifique-se de que as contas de serviço utilizadas para a ligação LDAP têm as permissões mínimas necessárias. Para RADIUS na nuvem, configure a sincronização baseada em API ou a integração SAML/OIDC com o seu IdP.
Defina grupos de utilizadores claros no seu diretório, pois estes irão orientar as políticas de autorização. Estrutura de grupos recomendada:
| Grupo | VLAN | Nível de Acesso |
|---|---|---|
Corp_Staff |
VLAN 10 | Rede interna total |
Corp_Contractors |
VLAN 20 | Internet + recursos internos específicos |
Corp_IoT |
VLAN 30 | Apenas portas isoladas e específicas do dispositivo |
Corp_Guests |
VLAN 100 | Apenas Internet através de Captive Portal |
Passo 5: Configuração do Cliente e Validação de Certificados
Este é o passo mais crítico a nível operacional. Utilize Políticas de Grupo (GPO) para Windows e perfis de MDM para macOS/iOS/Android para enviar configurações de WiFi de forma silenciosa para dispositivos geridos. O perfil deve especificar:
- A Root CA que emitiu o certificado do servidor RADIUS.
- O nome do servidor esperado (CN ou SAN do certificado do servidor).
- O método EAP e o protocolo de autenticação interno.
Para dispositivos BYOD não geridos, forneça instruções claras de integração em self-service, idealmente através de um portal de Network Access Control (NAC).
Passo 6: Implementar Atribuição Dinâmica de VLAN
Configure o servidor RADIUS para retornar os atributos de atribuição de VLAN na resposta Access-Accept:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id= ``
O ponto de acesso lê estes atributos e coloca o cliente autenticado na VLAN especificada — sem necessidade de reconfiguração manual à medida que os utilizadores mudam de funções ou de localizações.
Melhores Práticas
A redundância não é negociável. Implemente no mínimo dois servidores RADIUS (primário e secundário) e configure todos os pontos de acesso para failover automático. Para implementações locais, considere colocar o servidor secundário numa localização física ou zona de disponibilidade diferente. Uma falha no RADIUS significa que ninguém se consegue autenticar, o que representa uma falha total de rede para SSIDs protegidos por 802.1X.
Monitorize a expiração de certificados proativamente. A expiração do certificado do servidor RADIUS é uma das causas mais comuns de falhas de autenticação repentinas e generalizadas. Implemente a monitorização para alertar os administradores pelo menos 30 dias antes da expiração. Isto aplica-se tanto ao certificado do servidor como a quaisquer certificados de CA intermédios na cadeia.
Trate o Segredo Partilhado como uma credencial crítica. O segredo partilhado entre o AP e o servidor RADIUS cifra os pacotes RADIUS. Utilize segredos únicos por localização ou grupo de APs, guarde-os num gestor de segredos e rode-os periodicamente. Consulte o nosso guia sobre Protect Your Network with Strong DNS and Security para recomendações mais amplas de higiene de segurança de rede.
Alinhe com as estruturas de conformidade. Para ambientes sujeitos a PCI DSS (por exemplo, redes de pagamento de retalho), a autenticação 802.1X apoia diretamente os requisitos de controlo de acesso à rede e registo de auditoria. Para conformidade com o GDPR, os registos de contabilidade RADIUS (porta 1813) fornecem um registo de auditoria detalhado de quem acedeu à rede, a partir de onde e quando — valioso para a resposta a incidentes. Para ambientes de Saúde , a segmentação de rede através de atribuição dinâmica de VLAN apoia os requisitos da HIPAA para proteger informações de saúde eletrónicas protegidas (ePHI).
Resolução de Problemas e Mitigação de Riscos
| Modo de Falha | Sintoma | Resolução |
|---|---|---|
| Expiração de certificado | Falhas de autenticação em massa repentinas | Monitorizar expiração; renovar e reimplementar o certificado |
| Dessincronização de NTP | Falhas intermitentes de EAP-TLS | Garantir que o servidor RADIUS e os DCs sincronizam com a mesma fonte NTP |
| Perda de conectividade LDAP | A autenticação falha quando o AD está inacessível | Implementar DCs redundantes; configurar o RADIUS para colocar em cache autenticações recentes |
| Segredo Partilhado Incorreto | Os registos do AP mostram RADIUS timeout ou Bad authenticator |
Verificar se o segredo coincide tanto no AP como no servidor RADIUS |
| Incompatibilidade de certificado de cliente | Falhas de EAP-TLS para dispositivos específicos | Verificar se o certificado de cliente é emitido por uma CA fidedigna; verificar o período de validade do certificado |
| VLAN não atribuída | Utilizador autenticado mas no segmento de rede errado | Verificar se os atributos RADIUS são devolvidos corretamente; verificar a configuração de VLAN do AP |
Para uma análise mais aprofundada do próprio processo de configuração do 802.1X, o How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide fornece tutoriais de configuração detalhados e específicos de cada fabricante.
ROI e Impacto no Negócio
A transição de PSK para 802.1X baseado em RADIUS requer um investimento inicial em configuração e, potencialmente, licenciamento para soluções cloud ou hardware para implementações locais. O caso de ROI é simples:
Mitigação de riscos: O custo médio de uma violação de dados no Reino Unido ultrapassa os 3 milhões de libras (Relatório IBM Cost of a Data Breach). Uma PSK comprometida pode expor toda a rede. O 802.1X limita o raio de impacto a uma única conta de utilizador comprometida, que pode ser desativada em segundos através do diretório.
Eficiência operacional: A atribuição dinâmica de VLAN elimina a reconfiguração manual da rede à medida que os colaboradores mudam de funções. Integrar um novo colaborador significa adicioná-lo ao grupo de AD correto — o acesso à rede segue automaticamente.
Postura de conformidade: Para organizações sujeitas a PCI DSS, ISO 27001 ou Cyber Essentials Plus, o 802.1X é um controlo direto que os auditores esperam ver. A sua implementação reforça a sua postura de conformidade e reduz os custos de remediação de auditorias.
Experiência de convidados e analítica: Para operadores de espaços físicos, a integração do RADIUS para autenticação de funcionários com a plataforma de Guest WiFi da Purple para acesso de visitantes cria um modelo de acesso unificado e em camadas. Os funcionários autenticam-se silenciosamente via 802.1X; os convidados ligam-se através de um Captive Portal personalizado. A plataforma de WiFi Analytics da Purple fornece então visibilidade em tempo real sobre os tempos de permanência dos visitantes, taxas de visitas repetidas e métricas de envolvimento — dados que informam diretamente as decisões de investimento em marketing e operações do espaço.
Para leituras adicionais, consulte o Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo para obter orientações de implementação em português, e What Is a Leased Line? Dedicated Business Internet para orientações sobre como garantir que a conectividade subjacente cumpre os requisitos empresariais.
Definições Principais
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Contabilização (AAA) para utilizadores que se ligam a um serviço de rede. Definido no RFC 2865.
O componente de servidor central que valida as credenciais do utilizador num diretório antes de conceder acesso ao WiFi. Qualquer implementação de WiFi empresarial que utilize o 802.1X requer um servidor RADIUS.
802.1X
Uma norma IEEE para Controlo de Acesso à Rede baseado em portas (PNAC). Fornece um mecanismo de autenticação para dispositivos que pretendem ligar-se a uma LAN ou WLAN, bloqueando todo o tráfego não-EAP até que a autenticação seja bem-sucedida.
A norma de enquadramento global que define como o Supplicant, o Authenticator e o Servidor de Autenticação comunicam. Quando as equipas de TI se referem à "segurança de WiFi empresarial", referem-se tipicamente a WPA2/WPA3-Enterprise com 802.1X.
Supplicant
O dispositivo cliente — ou, mais precisamente, a pilha de software 802.1X nesse dispositivo — que inicia o processo de autenticação ao apresentar credenciais à rede.
No Windows, o supplicant integrado é o serviço Wireless AutoConfig. No macOS e iOS, é nativo do SO. Garantir que o supplicant está corretamente configurado (especialmente para validação de certificados) é a fonte mais comum de problemas de implementação.
Authenticator
O dispositivo de rede — tipicamente um ponto de acesso WiFi ou controlador sem fios — que atua como intermediário entre o Supplicant e o servidor RADIUS, aplicando o controlo de acesso com base no resultado da autenticação.
O AP bloqueia todo o tráfego de dados na porta até receber um Access-Accept do servidor RADIUS. Também lê os atributos RADIUS (por exemplo, atribuição de VLAN) da resposta Access-Accept e aplica-os à sessão.
EAP (Extensible Authentication Protocol)
Uma estrutura de autenticação definida no RFC 3748 que fornece um mecanismo de transporte padronizado para vários métodos de autenticação (TLS, PEAP, TTLS, etc.) entre o Supplicant e o Servidor de Autenticação.
O EAP é a "linguagem" falada entre o cliente e o servidor RADIUS. A escolha do método EAP (EAP-TLS vs PEAP) determina a força da segurança e a complexidade de implementação do sistema de autenticação.
PEAP (Protected EAP)
Um método EAP que primeiro estabelece um túnel TLS utilizando o certificado do servidor e, em seguida, realiza uma autenticação secundária (tipicamente MSCHAPv2 com nome de utilizador/palavra-passe) dentro desse túnel encriptado.
O método de autenticação de WiFi empresarial mais comum devido ao seu equilíbrio entre segurança e simplicidade de implementação. Requer apenas um certificado do lado do servidor, tornando-o muito mais fácil de implementar do que o EAP-TLS.
Dynamic VLAN Assignment
Uma funcionalidade RADIUS em que o servidor inclui atributos específicos de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) na resposta Access-Accept, instruindo o AP a colocar o cliente autenticado numa VLAN específica.
Permite que um único SSID sirva várias populações de utilizadores com diferentes requisitos de segurança. Elimina a necessidade de transmitir múltiplos SSIDs para diferentes grupos de utilizadores, reduzindo a sobrecarga de RF e simplificando a experiência do utilizador.
Shared Secret
Uma cadeia de texto pré-configurada conhecida apenas pelo Authenticator (AP) e pelo servidor RADIUS, utilizada para assinar e encriptar pacotes RADIUS, garantindo a integridade e a autenticidade da comunicação.
Um elemento crítico de configuração de segurança. Se o shared secret for fraco ou estiver comprometido, um atacante poderá forjar respostas RADIUS Access-Accept, concedendo acesso não autorizado à rede. Utilize segredos exclusivos por localização e armazene-os num gestor de segredos.
MAC Authentication Bypass (MAB)
Um mecanismo de autenticação alternativo em que o endereço MAC de um dispositivo é utilizado como a sua credencial de identidade, permitindo o acesso à rede para dispositivos que não suportam supplicants 802.1X.
Utilizado para dispositivos sem interface de utilizador (impressoras, sensores IoT, câmaras IP). Como os endereços MAC são visíveis publicamente e facilmente falsificados, o MAB fornece identificação de dispositivos em vez de uma autenticação forte. Combine sempre com uma atribuição de VLAN restritiva.
Exemplos Práticos
Uma cadeia de retalho nacional com 500 localizações precisa de implementar WiFi seguro para os tablets dos gerentes de loja e terminais POS. Atualmente, utilizam uma única PSK em todas as lojas, que é frequentemente partilhada com funcionários e prestadores de serviços não autorizados. Utilizam o Azure AD para a gestão de identidades e não têm pessoal de TI dedicado nas filiais.
Implementar uma solução Cloud RADIUS integrada diretamente com o Azure AD. Isto elimina a necessidade de implementar e gerir servidores RADIUS locais nas 500 localizações. A equipa de TI utiliza o Microsoft Intune para enviar um perfil de WiFi para todos os tablets dos gerentes de loja e terminais POS configurados para PEAP-MSCHAPv2, impondo estritamente a validação do certificado do servidor Cloud RADIUS. A política do Cloud RADIUS verifica a pertença ao grupo do Azure AD do utilizador antes de conceder o acesso: o grupo 'Store_Managers' recebe a VLAN 10 (acesso total ao POS e back-office), o grupo 'Contractors' recebe a VLAN 20 (apenas internet). Quando o contrato de um prestador de serviços termina, a sua remoção do grupo do Azure AD revoga imediatamente o seu acesso ao WiFi em todas as 500 localizações em simultâneo — sem necessidade de alterar a PSK.
Um hotel de 400 quartos no centro da cidade precisa de fornecer WiFi seguro tanto para os funcionários (receção, limpeza, gerência) como para os hóspedes. Os funcionários necessitam de acesso ao sistema de gestão de propriedade (PMS) e aos servidores internos. Os hóspedes necessitam apenas de acesso à internet. O hotel possui um único ambiente Windows Server local.
Implementar o Microsoft NPS numa VM Windows Server dedicada. Configurar dois SSIDs na infraestrutura sem fios: 'Hotel_Staff' (WPA2-Enterprise, 802.1X) e 'Hotel_Guest' (aberto ou WPA2-Personal, redirecionando para um Captive Portal). Para o SSID dos funcionários, o NPS valida as credenciais no Active Directory e devolve atribuições dinâmicas de VLAN: grupo AD 'Management' → VLAN 10 (acesso total), 'FrontDesk' → VLAN 20 (acesso ao PMS), 'Housekeeping' → VLAN 30 (apenas internet + aplicação de agendamento). Para os hóspedes, integrar o Captive Portal com a plataforma Purple WiFi para fornecer uma experiência de início de sessão personalizada, recolher dados primários (email, consentimento de marketing) e obter análises sobre o tempo de permanência e visitas repetidas. O modelo de dois SSIDs mantém o tráfego de funcionários e hóspedes completamente separado na camada de rede.
Perguntas de Prática
Q1. A sua organização está a migrar 2.000 portáteis Windows de uma PSK partilhada para 802.1X com PEAP-MSCHAPv2. A sua equipa de segurança alerta que o PEAP é vulnerável à recolha de credenciais através de pontos de acesso falsos (rogue APs). Qual é o passo de configuração mais importante para mitigar este risco e como o implementa em escala?
Dica: Considere o que impede um cliente de confiar num servidor RADIUS fraudulento que apresenta um certificado autoassinado.
Ver resposta modelo
O passo crítico é impor uma validação estrita do certificado do servidor em cada dispositivo cliente. Utilizando Objetos de Política de Grupo (GPO), envie um perfil de WiFi para todos os 2.000 portáteis que especifique: (1) o certificado de CA Raiz exato que emitiu o certificado do servidor RADIUS, (2) o nome do servidor esperado (CN/SAN) e (3) que o cliente não deve solicitar ao utilizador que confie em novos certificados. Isto garante que, mesmo que um atacante implemente um rogue AP com um certificado fraudulento, o cliente rejeitará o handshake TLS e recusará enviar credenciais. Sem esta configuração, o PEAP não oferece qualquer proteção significativa contra ataques de rogue AP.
Q2. Um diretor de TI de um hospital precisa de fornecer acesso à rede para 300 dispositivos IoT médicos (bombas de infusão, equipamento de monitorização) que não suportam 802.1X. Estes dispositivos partilham a mesma infraestrutura sem fios com as estações de trabalho dos funcionários. Como deve a infraestrutura RADIUS lidar com estes dispositivos e que controlos de rede devem ser implementados?
Dica: Pense no método de autenticação disponível para dispositivos sem ecrã/interface (headless) e como compensar a sua fraqueza inerente.
Ver resposta modelo
Configure o MAC Authentication Bypass (MAB) no servidor RADIUS para estes dispositivos específicos. Registe o endereço MAC de cada dispositivo num grupo dedicado do Active Directory ou numa base de dados RADIUS. Como os endereços MAC são facilmente falsificados, o servidor RADIUS deve utilizar a Atribuição Dinâmica de VLAN para colocar todos os dispositivos autenticados por MAB numa VLAN dedicada e altamente restrita (ex: VLAN 30 - IoT). Esta VLAN deve ser protegida por firewall para permitir a comunicação apenas com endereços IP de servidores médicos específicos e bloquear todo o restante tráfego, incluindo o acesso à Internet e o movimento lateral para as VLANs dos funcionários. As estações de trabalho dos funcionários autenticam-se via 802.1X e são colocadas numa VLAN separada. Esta arquitetura cumpre os requisitos de segmentação de rede HIPAA para dispositivos adjacentes a ePHI.
Q3. É o arquiteto de rede de uma cadeia de restaurantes com 50 estabelecimentos. A autenticação está a funcionar corretamente em 49 estabelecimentos utilizando Cloud RADIUS, mas um estabelecimento específico reporta que todos os dispositivos falham a autenticação. O portal de gestão do Cloud RADIUS mostra zero pedidos de autenticação provenientes desse estabelecimento. Qual é a sua abordagem de diagnóstico?
Dica: Se o servidor RADIUS não estiver a receber qualquer pedido, o problema está no caminho de comunicação entre o Autenticador e o servidor — e não na lógica de autenticação em si.
Ver resposta modelo
Uma vez que o servidor RADIUS está a receber zero pedidos deste estabelecimento, a falha reside entre os pontos de acesso e o servidor Cloud RADIUS. Passos de diagnóstico por ordem: (1) Verifique o endereço IP e a porta do servidor RADIUS (UDP 1812) configurados nos APs ou no controlador sem fios do estabelecimento — um erro de digitação aqui é a causa mais comum. (2) Verifique as regras de firewall local ou do router nesse estabelecimento para confirmar se o tráfego UDP 1812 de saída é permitido para a gama de IPs do Cloud RADIUS. (3) Verifique se o Segredo Partilhado (Shared Secret) configurado nos APs corresponde ao segredo configurado para esse estabelecimento no portal Cloud RADIUS — uma incompatibilidade faz com que o servidor RADIUS descarte silenciosamente os pacotes. (4) Verifique se a ligação à Internet do estabelecimento está a funcionar — o Cloud RADIUS requer conectividade de Internet fiável. Executar uma captura de pacotes no AP ou no router a montante confirmará se os pacotes RADIUS estão a ser enviados e se as respostas estão a ser recebidas.
Continue a ler esta série
Per-Device PSK por Fabricante: iPSK, DPSK, MPSK e PPSK Comparados (e Suporte a WPA3)
Uma comparação abrangente de implementações de per-device PSK na Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet e Ubiquiti UniFi. Saiba como o WPA3-SAE afeta as estratégias de chaves por dispositivo e quando implementar modos de transição versus migrar para o 802.1X.
Métodos de Autenticação de Captive Portal Comparados
Este guia de referência técnica de autoridade avalia as compensações arquitetónicas, operacionais e de conformidade de cinco métodos principais de autenticação de captive portal. Fornece aos arquitetos de rede, diretores de TI e gestores de marketing os dados quantitativos e as estruturas de decisão necessários para equilibrar a fricção no registo de convidados com os requisitos de recolha de dados em locais empresariais.
O que é a Autenticação por Endereço MAC? Quando Usar e Quando Evitar
Este guia de referência técnica abrangente aborda a autenticação por endereço MAC em ambientes de WiFi empresarial — como funciona a autenticação MAC baseada em RADIUS na Camada 2, as suas vulnerabilidades de segurança inerentes (incluindo falsificação de MAC e o impacto da randomização de MAC ao nível do SO) e os contextos operacionais precisos onde continua a ser uma ferramenta válida para gerir IoT e dispositivos headless. Fornece orientações de implementação práticas para gestores de TI e arquitetos de rede em setores como hotelaria, retalho, saúde e espaços públicos, com exemplos práticos reais, estruturas de decisão e contexto de integração para a plataforma de guest WiFi e analytics da Purple.