Saltar para o conteúdo principal

Configurar a Autenticação RADIUS para Redes WiFi de Convidados e Funcionários

Este guia de referência técnica descreve a arquitetura, a configuração e a implementação da autenticação RADIUS para redes WiFi empresariais de convidados e funcionários. Fornece aos arquitetos de rede e aos responsáveis de TI os protocolos exatos, as normas de segurança e as metodologias de resolução de problemas necessários para criar sistemas de controlo de acesso sem fios seguros e escaláveis.

Por Iain JewittPublicado Atualizado
📖 8 min de leitura2,145 palavras2 exemplos práticos3 perguntas de prática8 definições principais

Video overview

Parte da nossa série principal: Enterprise WiFi Security Guide →

Configurar a Autenticação RADIUS para Redes WiFi de Convidados e Funcionários

Resumo Executivo

Nos ambientes empresariais modernos, a segurança das redes sem fios é um requisito operacional crítico. Os métodos de segurança legados, como as chaves pré-partilhadas (PSKs), introduzem vulnerabilidades de segurança significativas. Se um único colaborador deixar uma organização, ou se um convidado comprometer uma palavra-passe partilhada, toda a postura de segurança da rede fica comprometida. Este guia detalha como implementar o Remote Authentication Dial-In User Service (RADIUS) para centralizar o controlo de acessos, aplicar políticas de segurança granulares e segmentar o tráfego de convidados e funcionários.

Ao transitar para uma arquitetura RADIUS centralizada, as organizações podem implementar a autenticação 802.1X para os funcionários - garantindo que cada dispositivo se autentica com credenciais exclusivas e revogáveis - ao mesmo tempo que utilizam Captive Portals seguros e MAC Authentication Bypass (MAB) para utilizadores convidados. Esta referência técnica fornece os planos arquitetónicos, os passos de configuração e as estruturas de resolução de problemas necessários para implementar uma infraestrutura de autenticação WiFi robusta e de nível empresarial.

Aprofundamento Técnico

O Modelo AAA

O RADIUS opera no modelo AAA, que define as fases fundamentais do controlo de acessos:

  1. Autenticação: Verificar a identidade do utilizador ou do dispositivo que tenta ligar-se à rede WiFi. Isto é conseguido através de credenciais, certificados digitais ou tokens.
  2. Autorização: Determinar o nível de acesso à rede concedido à entidade autenticada. Isto inclui a atribuição de VLANs específicas, a aplicação de Listas de Controlo de Acesso (ACLs) ou a imposição de limites de largura de banda.
  3. Contabilização (Accounting): Registar o consumo de recursos de rede, incluindo a duração da sessão, os dados transferidos e as horas de início/fim de sessão. Estes dados são críticos para auditoria, conformidade e planeamento de rede.
  4. Auditoria: Rever os dados de contabilização recolhidos para identificar anomalias, falhas de segurança ou violações de políticas.

Componentes da Arquitetura RADIUS

Uma implementação RADIUS empresarial padrão consiste em três componentes principais:

  • O Suplicante (Supplicant): O software cliente executado no dispositivo do utilizador (por exemplo, computador portátil, smartphone) que solicita acesso à rede e fornece credenciais ou certificados.
  • O Autenticador (Network Access Server / NAS): O dispositivo de rede físico ou virtual - normalmente um Wireless LAN Controller (WLC) ou um ponto de acesso (AP) - que controla o acesso físico à rede. O autenticador não decide se as credenciais são válidas; atua como um proxy, empacotando o pedido de autenticação em pacotes RADIUS e encaminhando-os para o servidor RADIUS.
  • O Servidor de Autenticação: O servidor central (como o FreeRADIUS, Cisco ISE, Aruba ClearPass ou o motor RADIUS baseado em nuvem da Purple) que valida as credenciais num repositório de identidades (por exemplo, Active Directory, LDAP ou um fornecedor de identidade na nuvem) e devolve uma mensagem de Aceitação de Acesso (Access-Accept) ou Rejeição de Acesso (Access-Reject) ao autenticador.

Métodos EAP para WiFi de Funcionários

Para redes de funcionários, o Extensible Authentication Protocol (EAP) é utilizado dentro do enquadramento 802.1X para negociar a autenticação. Os dois métodos EAP empresariais mais comuns são:

  • PEAP-MSCHAPv2 (PEAP Protegido): Este método estabelece um túnel TLS seguro e encriptado entre o suplicante e o servidor RADIUS utilizando o certificado digital do servidor. Dentro deste túnel seguro, o nome de utilizador e a palavra-passe do utilizador são autenticados através do protocolo MSCHAPv2. Este método é extremamente popular devido à sua facilidade de implementação, uma vez que não exige a instalação de certificados nos dispositivos dos clientes.
  • EAP-TLS: O método de autenticação mais seguro disponível. Requer autenticação mútua, o que significa que tanto o servidor RADIUS como o dispositivo cliente devem apresentar certificados digitais válidos. Isto elimina os ataques baseados em palavras-passe, mas exige uma Infraestrutura de Chaves Públicas (PKI) robusta para gerir a distribuição e revogação de certificados.

Fluxo de Autenticação de WiFi de Convidados

As redes de convidados utilizam normalmente um fluxo diferente para equilibrar a segurança com a conveniência do utilizador. Em vez do 802.1X, as redes de convidados utilizam frequentemente um SSID Aberto combinado com um Captive Portal.

Quando um convidado se liga, o Autenticador utiliza o MAC Authentication Bypass (MAB) ou uma política de redirecionamento para enviar o utilizador para um Captive Portal alojado por uma plataforma como a Purple. Assim que o utilizador conclui o processo de registo ou início de sessão no portal, a plataforma do portal comunica com o servidor RADIUS, que envia uma mensagem de Aceitação de Acesso (Access-Accept) para o WLC/AP, autorizando o endereço MAC do convidado para acesso à rede durante a duração de sessão especificada.

Transporte Seguro: RadSec

O tráfego RADIUS tradicional é enviado através de UDP (portas 1812 para autenticação e 1813 para contabilidade) em texto simples, com apenas o campo da palavra-passe do utilizador ofuscado por um segredo partilhado. Isto introduz riscos de segurança ao encaminhar o tráfego de autenticação através de ligações WAN públicas ou da internet.

Para mitigar esta situação, deve ser implementado o RadSec (RADIUS sobre TLS). O RadSec envolve os pacotes RADIUS padrão dentro de um túnel TLS seguro (normalmente utilizando a porta TCP 2083). Isto garante que todos os dados de autenticação e contabilidade, incluindo nomes de utilizador, endereços MAC e atributos de sessão, sejam totalmente encriptados em trânsito entre a rede local e os servidores RADIUS baseados na nuvem.

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.

Guia de Implementação

Passo 1: Definir Clientes RADIUS no Servidor

Antes que qualquer dispositivo de rede possa comunicar com o servidor RADIUS, este deve ser registado como cliente.

  1. Inicie sessão na consola de administração do seu servidor RADIUS.
  2. Navegue até à secção Clientes ou Dispositivos de Rede.
  3. Adicione uma nova entrada de cliente para cada WLC ou AP.
  4. Introduza o endereço IP ou a sub-rede do autenticador.
  5. Gere um Segredo Partilhado de elevada entropia. Este segredo deve ter pelo menos 22 carateres, contendo uma mistura de letras maiúsculas, letras minúsculas, números e carateres especiais. Evite usar palavras simples de dicionário.

Passo 2: Configurar o Wireless LAN Controller (WLC) / Access Points

Configure o seu hardware sem fios para apontar para o servidor RADIUS para autenticação e faturação (accounting).

  1. Inicie sessão na interface de gestão do seu WLC ou AP.
  2. Navegue para Segurança > AAA > RADIUS > Autenticação.
  3. Adicione um novo Servidor de Autenticação RADIUS:
    • Endereço IP do Servidor: Introduza o endereço IP do seu servidor RADIUS principal.
    • Segredo Partilhado: Introduza exatamente o segredo partilhado configurado no Passo 1.
    • Porta: 1812 (ou 2083 se estiver a usar RadSec).
    • Timeout: Defina para 5 segundos para permitir a latência da rede.
    • Contagem de Tentativas: Defina para 3.
  4. Navegue para RADIUS Accounting e adicione uma nova entrada de servidor usando a porta 1813 (ou 2083 para RadSec).
  5. Repita estes passos para adicionar um servidor RADIUS secundário (cópia de segurança) para alta disponibilidade.

Passo 3: Configurar o SSID da Equipa (802.1X)

  1. Crie um novo SSID com o nome Staff_Enterprise.
  2. Defina o Tipo de Segurança para WPA3-Enterprise (ou modo de transição WPA2/WPA3-Enterprise se for necessário suporte para dispositivos legados).
  3. Selecione 802.1X como o protocolo de gestão de chaves.
  4. Associe o SSID aos servidores de autenticação e accounting RADIUS configurados no Passo 2.
  5. Mapeie o SSID para a VLAN segura da equipa (por exemplo, VLAN 10).

Passo 4: Configurar o SSID de Convidados com Captive Portal

  1. Crie um novo SSID com o nome Guest_WiFi.
  2. Defina o Tipo de Segurança para Aberto (ou Aberto Altamente Seguro / OWE para encriptação sem fios oportunista).
  3. Ative a Filtragem MAC ou Autenticação MAC e aponte-a para o servidor RADIUS.
  4. Ative o redirecionamento do Captive Portal / Portal Web.
  5. Configure o URL de redirecionamento para apontar para a página de início de sessão do Captive Portal da Purple.
  6. Configure o Walled Garden (ACLs de Pré-Autenticação) para permitir o tráfego para o domínio do Captive Portal, servidores DNS e ativos CDN necessários antes de a autenticação estar concluída.
  7. Mapeie o SSID para uma VLAN de Convidados isolada (por exemplo, VLAN 20).

Melhores Práticas

Alta Disponibilidade e Redundância

Implemente sempre servidores RADIUS em pares redundantes (principal e secundário). Garanta que estes servidores estão localizados em hardware físico diferente ou em diferentes zonas de disponibilidade na nuvem. Configure os seus WLCs para fazer failover de forma controlada para o servidor secundário caso o servidor principal deixe de responder. Implemente o balanceamento de carga onde for apropriado para distribuir o tráfego de autenticação uniformemente.

Gestão de Certificados

Para implementações PEAP e EAP-TLS, a validade e a confiança do certificado do servidor RADIUS são primordiais.

  • Utilize um certificado emitido por uma Autoridade de Certificação (CA) Pública fidedigna para portais de convidados e implementações PEAP para evitar avisos de segurança de certificados nos dispositivos dos utilizadores.
  • Para EAP-TLS, estabeleça uma CA Privada interna dedicada para emitir e gerir certificados de cliente e servidor.
  • Monitorize atentamente as datas de expiração dos certificados e implemente processos de renovação automatizados (como SCEP ou ACME) para evitar falhas repentinas de autenticação em toda a rede.

Segmentação de VLAN

Segmente rigorosamente o tráfego da sua rede utilizando VLANs. O tráfego de convidados deve ser completamente isolado dos recursos corporativos. Implemente regras de firewall no switch central ou gateway para impedir o encaminhamento inter-VLAN entre a VLAN de Convidados e as VLANs de Colaboradores/Gestão. Permita apenas que o tráfego de convidados seja encaminhado diretamente para a internet.

Limite de Tempo de Sessão e Intervalos de Contabilidade

Configure limites de tempo de sessão adequados para evitar que sessões inativas consumam endereços IP e recursos de rede.

  • Para redes de colaboradores, defina um limite de tempo de sessão de 8 a 12 horas, alinhando-se com um turno de trabalho padrão.
  • Para redes de convidados, defina um limite de tempo de sessão mais curto, de 2 a 4 horas.
  • Configure o intervalo de atualização intermédia de contabilidade RADIUS para 10 ou 15 minutos. Isto garante que o servidor RADIUS recebe atualizações regulares sobre a conectividade do dispositivo e a utilização de dados sem sobrecarregar o servidor com pacotes de contabilidade.

Resolução de Problemas e Mitigação de Riscos

Modos de Falha Comuns e Soluções

1. Incompatibilidade de Segredo Partilhado

  • Sintoma: Os registos do WLC mostram "Servidor RADIUS não responde" e os registos do servidor RADIUS mostram "Pacote rejeitado - autenticador inválido" ou "Autenticador incorreto no pedido".
  • Causa Raiz: O segredo partilhado configurado no WLC não corresponde ao segredo partilhado configurado no servidor RADIUS.
  • Mitigação: Introduza novamente o segredo partilhado em ambos os dispositivos, garantindo que não são copiados espaços no final ou carateres ocultos.

2. Problemas de Confiança de Certificados

  • Sintoma: Os dispositivos clientes não conseguem ligar ao SSID de Colaboradores, exibindo erros como "Certificado de Servidor Não Fidedigno" ou "Ligação Rejeitada".
  • Causa Raiz: O dispositivo cliente não confia na CA que assinou o certificado do servidor RADIUS, ou o certificado expirou.
  • Mitigação: Certifique-se de que os certificados de CA raiz e intermédia estão instalados no repositório de raiz fidedigno do dispositivo cliente. Para dispositivos geridos pela empresa, envie estes certificados através de MDM ou Diretiva de Grupo.

3. Bloqueios de Firewall

  • Sintoma: O servidor RADIUS não recebe nenhum tráfego do WLC, embora o encaminhamento esteja verificado.
  • Causa Raiz: Firewalls intermédias estão a bloquear as portas UDP 1812 e 1813.
  • Mitigação: Crie regras de firewall explícitas para permitir UDP 1812 e 1813 (ou TCP 2083 para RadSec) entre o IP de gestão do WLC e o IP do servidor RADIUS.

4. Limites de Tempo Induzidos por Latência

  • Sintoma: Falhas de autenticação intermitentes, particularmente durante as horas de ponta ou ao utilizar servidores RADIUS baseados na nuvem.
  • Causa Raiz: A latência de rede excede o limite de tempo de espera (timeout) de RADIUS do WLC, fazendo com que o WLC assuma que o servidor está offline.
  • Mitigação: Aumente a definição de timeout de RADIUS do WLC do valor predefinido (normalmente 2 segundos) para 5 ou 7 segundos. Otimize o encaminhamento de WAN ou implemente proxies RADIUS locais para colocar pedidos de autenticação em cache.

Retorno do Investimento (ROI) e Impacto no Negócio

A transição para um modelo de autenticação RADIUS centralizado proporciona um valor comercial mensurável em várias áreas-chave:

  • Redução de Custos Operacionais: Elimina o esforço manual necessário para alterar periodicamente as palavras-passe partilhadas de WiFi quando os colaboradores saem da organização. As contas de utilizador podem ser desativadas instantaneamente no Active Directory ou no seu fornecedor de identidade, revogando imediatamente o seu acesso à rede.
  • Melhoria da Postura de Segurança: Mitiga o risco de violações de dados causadas por roubo de credenciais ou acesso não autorizado à rede. Ao impor a autenticação 802.1X e baseada em certificados, as organizações garantem que apenas dispositivos autorizados e em conformidade podem aceder a recursos corporativos confidenciais.
  • Otimização das Operações do Espaço: Ao integrar o WiFi de convidados com a plataforma cloud RADIUS da Purple, os operadores do espaço recolhem dados demográficos e comportamentais valiosos. Estes dados podem ser utilizados para desenhar campanhas de marketing direcionadas, melhorar o envolvimento dos visitantes e otimizar a utilização do espaço físico com base em análises de fluxo de pessoas.
  • Conformidade Regulamentar: Os registos centralizados de contabilidade (accounting) do RADIUS fornecem uma pista de auditoria do acesso à rede, ajudando as organizações a cumprir os requisitos de conformidade para normas como PCI-DSS, ISO 27001 e GDPR.

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 Accounting para utilizadores que se ligam e utilizam um serviço de rede.

É o protocolo padrão da indústria utilizado para ligar hardware de rede sem fios a bases de dados de identidade centrais.

Suplicante

O software ou dispositivo cliente (como um portátil, telemóvel ou tablet) que solicita acesso a uma rede e fornece credenciais ou certificados para verificação.

O suplicante deve suportar o método EAP específico configurado no servidor RADIUS para se autenticar com sucesso.

Autenticador

O dispositivo de rede (normalmente um Wireless LAN Controller ou Access Point) que controla o acesso físico à rede e atua como um proxy entre o suplicante e o servidor RADIUS.

O autenticador não valida as credenciais por si mesmo; limita-se a encaminhá-las para o servidor RADIUS.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. Um método de autenticação extremamente seguro que utiliza certificados digitais mútuos tanto no cliente como no servidor para verificação de identidade.

É o método de autenticação preferido para dispositivos geridos pela empresa em redes WiFi de colaboradores.

PEAP-MSCHAPv2

Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2. Um método de autenticação baseado em credenciais que protege a transmissão de palavras-passe dentro de um túnel TLS encriptado.

É amplamente utilizado para redes de colaboradores porque não exige certificados no lado do cliente, tornando-o mais fácil de implementar do que o EAP-TLS.

RadSec

Um protocolo que protege o tráfego RADIUS ao envolver os pacotes RADIUS padrão dentro de um túnel Transport Layer Security (TLS), sendo executado normalmente através da porta TCP 2083.

Essencial para redes WiFi geridas na nuvem onde o tráfego de autenticação deve viajar pela internet pública.

Captive Portal

Uma página web apresentada a utilizadores sem fios recém-ligados antes de lhes ser concedido um acesso mais amplo à rede. É habitualmente utilizada para a autenticação de convidados, aceitação de termos de serviço e recolha de dados de marketing.

A Purple fornece um captive portal alojado na nuvem que se integra com o hardware de rede local via RADIUS.

MAC Authentication Bypass (MAB)

Um mecanismo que permite o controlo de acesso à rede com base no endereço MAC de um dispositivo cliente. É normalmente utilizado para dispositivos que não suportam a autenticação 802.1X.

Frequentemente utilizado em redes WiFi de convidados para permitir que os dispositivos se voltem a ligar de forma transparente sem verem o captive portal repetidamente.

Exemplos Práticos

A multi-site retail brand with 150 stores wants to deploy a secure staff WiFi network. They currently use a single pre-shared key (PSK) across all stores, which is frequently leaked. They require a solution that integrates with their existing Microsoft Azure Active Directory (now Microsoft Entra ID) and ensures that staff can only authenticate using corporate-managed laptops.

To resolve this, we will implement WPA3-Enterprise with EAP-TLS authentication, integrated with Microsoft Entra ID via a cloud-based RADIUS service.

  1. Establish a Private CA: Deploy a cloud-based Public Key Infrastructure (PKI) or utilise an existing Active Directory Certificate Services (AD CS) deployment to issue device certificates to all corporate-managed laptops.
  2. Certificate Distribution: Configure the organisation's Mobile Device Management (MDM) system (e.g., Microsoft Intune) to automatically distribute the Root CA certificate and a unique client certificate to each managed laptop. The client certificate must include the device's host name or serial number in the Subject Alternative Name (SAN).
  3. Configure the Cloud RADIUS Server: Set up a cloud RADIUS service that integrates with Microsoft Entra ID. Configure the RADIUS server to validate incoming client certificates against the trusted Private CA.
  4. Configure the WLCs/APs: On the wireless controllers at each retail store, configure a new SSID named Retail_Staff. Set the security to WPA3-Enterprise and point the authentication to the cloud RADIUS server IPs using RadSec (TCP port 2083) to secure the authentication traffic over the public internet.
  5. Define Access Policies: On the RADIUS server, create a policy that allows access only if the client certificate is valid, the certificate is not revoked (checked via CRL or OCSP), and the device identity exists and is active within Microsoft Entra ID.
Comentário do Examinador: This solution addresses both security and scalability. By choosing EAP-TLS over PEAP-MSCHAPv2, the brand eliminates the risk of credential-based attacks (such as password spraying or man-in-the-middle attacks). Utilising RadSec is critical here because the authentication traffic must travel over the public internet from individual retail stores to the cloud RADIUS server. This ensures complete encryption of the authentication payload.

A large convention centre hosting up to 20,000 concurrent users needs to deploy a guest WiFi network. The network must offer a seamless login experience via a captive portal, enforce a 3-hour session limit to prevent bandwidth hoarding, and collect marketing consent in compliance with GDPR. The infrastructure consists of Cisco Catalyst WLCs.

Iremos implementar um SSID aberto com MAC Authentication Bypass (MAB) e redirecionamento de captive portal integrado com a plataforma Purple.

  1. Configurar o SSID de Convidados: No Cisco WLC, crie um SSID chamado Convention_Guest. Defina a segurança como Aberta. Ative a Filtragem MAC e selecione o grupo de servidores RADIUS associado à Purple.
  2. Configurar o Redirecionamento: Configure uma política de Web Auth no WLC para redirecionar utilizadores não autenticados para o URL do captive portal da Purple: https://portal.purplewifi.net/....
  3. Configurar o Walled Garden: Crie uma Lista de Controlo de Acesso (ACL) no WLC chamada GUEST_RED_ACL. Esta ACL deve permitir tráfego DNS (porta UDP 53), tráfego DHCP (portas UDP 67 e 68) e tráfego de e para as gamas de IP e CDNs da Purple. Todo o restante tráfego HTTP/HTTPS deve ser redirecionado.
  4. Configurar o RADIUS Accounting: Ative o RADIUS accounting no WLC, apontando para os servidores de accounting da Purple com um intervalo de atualização provisório de 10 minutos.
  5. Configurar os Limites de Sessão: No painel do portal Purple, configure o percurso de acesso para aplicar um limite de tempo de sessão de 3 horas. Assim que o utilizador concluir o login e aceitar os termos de marketing em conformidade com o GDPR, o servidor RADIUS da Purple envia um pacote Access-Accept para o Cisco WLC contendo o atributo Session-Timeout definido para 10800 segundos (3 horas).
  6. Fluxo de Reautenticação: Após 3 horas, o WLC termina a sessão. Se o utilizador tentar ligar-se novamente, é redirecionado de volta para o captive portal para se reautenticar.
Comentário do Examinador: Em ambientes de alta densidade como centros de exposições, a gestão de pools de endereços IP e estados de sessão é crítica. A aplicação de um limite estrito de tempo de sessão de 3 horas através de atributos RADIUS garante que os dispositivos inativos não fiquem a reter endereços IP, evitando o esgotamento do pool DHCP. O uso de MAB garante que, uma vez autenticado, o endereço MAC do utilizador é armazenado em cache durante a sessão, evitando desligamentos irritantes se o dispositivo entrar temporariamente em suspensão.

Perguntas de Prática

Q1. Uma organização renovou recentemente o certificado SSL no seu servidor RADIUS. Imediatamente a seguir, vários computadores portáteis Windows geridos pela empresa não conseguiram ligar-se à rede WiFi dos colaboradores, enquanto os dispositivos macOS e iOS se ligaram sem problemas. Qual é a causa mais provável deste problema e como deve ser resolvido?

Dica: Considere a forma como diferentes sistemas operativos validam os certificados do servidor e o papel da cadeia de Autoridades de Certificação (CA).

Ver resposta modelo

A causa mais provável é que o novo certificado do servidor RADIUS tenha sido emitido por uma Autoridade de Certificação (CA) diferente ou por uma CA intermédia que não é confiada pelos computadores portáteis Windows afetados, ou que a Política de Grupo do Windows esteja configurada para validar a ligação a um nome de servidor específico ou a uma CA raiz que não corresponde ao novo certificado. Os dispositivos macOS e iOS são frequentemente mais permissivos ou solicitam ao utilizador que confie no novo certificado manualmente, ao passo que as configurações empresariais do Windows bloqueiam estritamente as ligações a certificados não confiáveis sem qualquer aviso. Para resolver isto, verifique se os certificados raiz e intermédios da nova CA são distribuídos por todos os dispositivos Windows via Política de Grupo ou MDM, e atualize a configuração do perfil sem fios para confiar na nova CA.

Q2. Durante as horas de ponta num grande estádio desportivo, os utilizadores do WiFi de convidados relatam que concluem com sucesso o registo no captive portal, mas não são redirecionados para a internet. Em vez disso, é-lhes mostrada repetidamente a página de login do captive portal. Os registos do WLC mostram "RADIUS authentication timeout." Como diagnosticaria e resolveria este problema?

Dica: Analise o caminho do pacote RADIUS e as definições de timeout no controlador sem fios.

Ver resposta modelo

Este é um problema clássico de timeout induzido pela latência. Durante as horas de ponta, o elevado volume de tráfego provoca congestionamento na ligação WAN ou uma elevada utilização de CPU no servidor RADIUS, atrasando a resposta RADIUS Access-Accept. Dado que o timeout predefinido do WLC está definido para um valor demasiado baixo (normalmente 2 segundos), o WLC assume que o servidor RADIUS está offline e desiste da sessão, forçando o utilizador a voltar ao captive portal. Para diagnosticar, verifique o tempo de ida e volta (RTT) dos pacotes RADIUS durante as horas de ponta. Para resolver: 1) Aumente o timeout do RADIUS no WLC para 5 ou 7 segundos. 2) Aumente o número de tentativas para 3. 3) Implemente a Qualidade de Serviço (QoS) no gateway WAN para priorizar o tráfego RADIUS (UDP 1812/1813) face ao tráfego geral de internet de convidados.

Q3. Uma auditoria de segurança revela que os utilizadores do WiFi de convidados conseguem aceder às interfaces de gestão interna dos switches de rede e WLCs. A rede de convidados está configurada como um SSID aberto com um captive portal. Que alterações arquitetónicas devem ser efetuadas para mitigar esta vulnerabilidade?

Dica: Pense na segmentação de rede e onde as políticas de controlo de acesso devem ser aplicadas.

Ver resposta modelo

Para mitigar esta vulnerabilidade, deve ser aplicada uma segmentação de rede estrita. Primeiro, certifique-se de que o SSID de convidados está mapeado para uma VLAN de convidados dedicada (por exemplo, VLAN 20) que esteja completamente separada da VLAN dos colaboradores e da VLAN de gestão (onde residem os switches e WLCs). Segundo, configure Listas de Controlo de Acesso (ACLs) ou regras de firewall no router principal ou gateway para bloquear todo o tráfego com origem na VLAN de convidados destinado a quaisquer sub-redes de IP privados internos (gamas RFC 1918), visando especificamente os IPs de gestão da infraestrutura de rede. A VLAN de convidados apenas deve ter caminhos de encaminhamento para a internet e para os servidores DNS específicos e IPs do captive portal necessários para a pré-autenticação.

Continue a ler esta série

Resolução de problemas de 802.1X em iOS e macOS: uma lista de verificação de implementação para Intune, Jamf e Microsoft Entra ID

Utilize esta lista de verificação para diagnosticar por que razão iPhones, iPads e Macs falham o 802.1X no Intune ou Jamf Pro. Cada falha corresponde a uma de quatro causas: fidedignidade do servidor, certificado de identidade, modo macOS ou âmbito do grupo do Microsoft Entra ID. Irá confirmar a causa a partir dos registos do eapolclient e RADIUS, aplicar a correção e preparar futuras rotações de certificados.

Ler o guia →

Fidedignidade do servidor do perfil WiFi do Intune: nomes de servidor de certificados e lista de verificação de CA raiz para Entra ID

Será capaz de configurar a metade da validação de servidor de um perfil WiFi do Intune para que o EAP-TLS e o PEAP se liguem no Windows, Apple e Android. Irá fazer corresponder os nomes dos servidores de certificados ao certificado RADIUS, implementar a CA raiz correta, alinhar as atribuições de grupos do Entra ID e programar as renovações de certificados antes que estas quebrem silenciosamente as ligações.

Ler o guia →

Resolução de problemas de Android 802.1X e EAP-TLS: uma lista de verificação de implementação para o Intune e Microsoft Entra ID

Será capaz de identificar com precisão o motivo pelo qual os telemóveis Android geridos falham o EAP-TLS no seu SSID de funcionários e corrigi-lo no Intune. Associe cada sintoma às quatro causas habituais - CA ou domínio em falta, certificado de cliente no perfil errado, um valor incorreto de nomes de servidores RADIUS ou uma raiz fidedigna não entregue. Em seguida, aplique uma lista de verificação de implementação que impeça a repetição de interrupções.

Ler o guia →

Tem dúvidas sobre a sua configuração específica?

A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.