Saltar para o conteúdo principal

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.

📖 8 min de leitura📝 1,860 palavras🔧 2 exemplos práticos3 perguntas de prática📚 9 definições principais

Ouça este guia

Ver transcrição do podcast
Bem-vindo ao Briefing Técnico da Purple. Hoje estamos a abordar uma decisão crítica de infraestrutura para qualquer líder de TI empresarial: como configurar um servidor RADIUS para autenticação WiFi. Se está a gerir uma implementação em grande escala — seja uma cadeia de hotéis, uma rede de retalho ou um campus universitário em expansão — confiar numa simples chave pré-partilhada é um risco de segurança significativo. Precisamos do 802.1X, e isso significa que precisamos do RADIUS. Comecemos pelo contexto. O RADIUS, ou Remote Authentication Dial-In User Service, funciona como o guardião da sua rede. Quando um dispositivo tenta ligar-se a um ponto de acesso WiFi, o ponto de acesso atua como um autenticador e encaminha as credenciais para o servidor RADIUS. O servidor verifica essas credenciais num diretório — como o Active Directory ou uma base de dados LDAP — e depois devolve uma mensagem de aceitação ou rejeição. É a base da segurança WiFi empresarial e é o mecanismo que lhe permite aplicar políticas de acesso granulares à escala. Passemos agora à análise técnica aprofundada. A primeira grande decisão arquitetónica que irá enfrentar é escolher entre um servidor RADIUS local (on-premise) e uma solução alojada na nuvem. Historicamente, as soluções locais como o Network Policy Server da Microsoft, ou NPS, ou o FreeRADIUS de código aberto eram a norma. Oferecem controlo total sobre a infraestrutura e não dependem de uma ligação externa à Internet para a autenticação. No entanto, exigem hardware dedicado, manutenção contínua e configuração manual de redundância. Se tiver um único centro de dados e uma equipa de TI com recursos suficientes, esta é uma abordagem perfeitamente válida. Por outro lado, as soluções de RADIUS na nuvem tornaram-se cada vez mais populares, especialmente para ambientes distribuídos como cadeias de retalho ou espaços de hotelaria. O RADIUS na nuvem abstrai totalmente a gestão de hardware, oferece alta disponibilidade integrada e integra-se perfeitamente com fornecedores de identidade na nuvem como o Azure Active Directory ou o Okta. O reverso da medalha é que a autenticação requer uma ligação fiável à Internet e existe um custo de subscrição contínuo. Para um operador de espaços que gere cinquenta ou cem localizações, a poupança operacional de não implementar e manter servidores locais em cada local irá quase de certeza compensar esse custo. Ao implementar o RADIUS, o Extensible Authentication Protocol — EAP — é a peça crítica. Define a forma como o cliente e o servidor negociam e realizam a autenticação. O EAP-TLS é o padrão de excelência para a segurança porque utiliza certificados digitais tanto no cliente como no servidor, eliminando totalmente a necessidade de palavras-passe. Isto significa que, mesmo que um atacante intersete a troca de autenticação, não existem credenciais para roubar. No entanto, a implementação de certificados de cliente pode ser administrativamente pesada. Precisa de uma Infraestrutura de Chaves Públicas e de uma solução de MDM para enviar os certificados para todos os dispositivos. O PEAP-MSCHAPv2 é a alternativa mais comum. Utiliza um certificado do lado do servidor para estabelecer um túnel TLS encriptado, dentro do qual o utilizador se autentica com um nome de utilizador e palavra-passe. Isto é significativamente mais fácil de implementar do que o EAP-TLS porque apenas precisa de gerir um único certificado — o do servidor. No entanto, e isto é crítico — se os clientes não estiverem estritamente configurados para validar o certificado do servidor, ficam vulneráveis a pontos de acesso falsos (rogue access points). Um atacante pode criar um ponto de acesso falso, apresentar um certificado fraudulento e capturar credenciais. Este não é um ataque teórico. É uma ameaça real e bem documentada. Vamos falar de recomendações de implementação e armadilhas. A primeira recomendação é impor uma validação estrita de certificados em todos os dispositivos cliente. Utilize Group Policy Objects para dispositivos Windows e perfis de MDM — seja o Intune, o Jamf ou outra solução — para macOS e dispositivos móveis. O perfil deve especificar exatamente em que Autoridade de Certificação confiar e qual é o nome de servidor esperado. Não deixe esta configuração ao critério do utilizador final para ser feita manualmente. A segunda recomendação é implementar a atribuição dinâmica de VLAN. Em vez de colocar todos os utilizadores autenticados na mesma rede plana, configure o servidor RADIUS para instruir o ponto de acesso a colocar o utilizador numa VLAN específica com base na sua pertença a grupos no diretório. Isto é essencial para segmentar os dispositivos corporativos dos dispositivos BYOD ou de convidados. Um colaborador da equipa financeira deve estar num segmento de rede diferente de um consultor externo que esteja de visita durante o dia. A terceira recomendação diz respeito ao acesso de convidados. Para locais que precisam de fornecer WiFi a visitantes — hotéis, lojas de retalho, centros de conferências — integrar a sua infraestrutura RADIUS com uma solução de Captive Portal como a plataforma Guest WiFi da Purple é uma combinação poderosa. Os colaboradores e os dispositivos corporativos autenticam-se silenciosamente via 802.1X, enquanto os convidados são direcionados para um portal personalizado para autenticação. A plataforma da Purple captura então dados primários (first-party data) e fornece análises sobre o comportamento dos visitantes, transformando a sua rede de um centro de custos num ativo de inteligência de negócio. Agora, uma sessão rápida de perguntas e respostas. Primeira pergunta: Preciso de um servidor dedicado para RADIUS? Para implementações locais (on-premise), sim, é altamente recomendável executá-lo numa máquina virtual dedicada em vez de partilhar recursos com um controlador de domínio. A autenticação é uma operação sensível à latência e a contenção de recursos pode causar falhas intermitentes muito difíceis de diagnosticar. Segunda pergunta: O RADIUS pode processar a autenticação de dispositivos sem interface de utilizador (headless), como impressoras ou sensores IoT? Sim, através de MAC Authentication Bypass, ou MAB. Isto permite que dispositivos sem capacidades 802.1X sejam autenticados com base no seu endereço MAC. No entanto, como os endereços MAC são facilmente falsificados, os dispositivos autenticados por MAB devem ser sempre colocados numa VLAN altamente restrita. Terceira pergunta: Como posso gerir a redundância do servidor RADIUS? Implemente sempre pelo menos dois servidores RADIUS — um primário e um secundário. Configure todos os pontos de acesso para fazerem failover para o secundário se o primário ficar inacessível. Para o RADIUS na nuvem, esta redundância é normalmente integrada e gerida pelo fornecedor. Para resumir as principais conclusões da sessão de hoje. As chaves pré-partilhadas (PSK) não são aceitáveis para WiFi empresarial. Implemente o 802.1X. Escolha o seu modelo de implementação — local ou na nuvem — com base nos seus recursos de TI, no número de localizações que está a gerir e na sua infraestrutura de identidade existente. Se a sua organização for distribuída e priorizar a nuvem (cloud-first), o RADIUS na nuvem é quase de certeza a resposta certa. Imponha uma validação rigorosa de certificados nos clientes. Isto é inegociável. Utilize a atribuição dinâmica de VLAN para segmentar a sua rede. E, finalmente, considere como a sua infraestrutura de autenticação se pode integrar com plataformas mais amplas para fornecer valor comercial além do simples controlo de acessos. Para leituras adicionais, recomendamos a exploração dos guias da Purple sobre a configuração de autenticação WiFi 802.1X e a proteção da sua rede com políticas de DNS fortes. Obrigado por nos ouvir.

header_image.png

Executive Summary

For enterprise environments — whether a sprawling university campus, a high-density stadium, or a distributed retail chain — relying on a Pre-Shared Key (PSK) for WiFi access is a significant security liability. A single compromised credential exposes the entire network, and revoking access requires changing the password for every device on the estate. Implementing 802.1X authentication via a RADIUS (Remote Authentication Dial-In User Service) server eliminates this problem entirely: each user authenticates individually, access can be revoked instantly, and network segmentation is enforced dynamically.

This guide provides a definitive roadmap for IT managers and network architects to deploy RADIUS authentication. We cover the architectural trade-offs between on-premise and cloud-hosted deployments, the configuration of Extensible Authentication Protocol (EAP) methods, and the integration with directory services like Active Directory. We also demonstrate how a robust authentication layer integrates with Guest WiFi solutions to provide seamless access for visitors, while capturing the WiFi Analytics that turn your network into a business intelligence asset.


Technical Deep-Dive

The 802.1X Architecture

The IEEE 802.1X standard defines port-based Network Access Control (PNAC). In a wireless context, it involves three primary roles working in concert:

Role Component Responsibility
Supplicant Client device (laptop, smartphone) Presents credentials to request network access
Authenticator WiFi Access Point or Controller Enforces access control; relays EAP messages
Authentication Server RADIUS Server Validates credentials; returns accept/reject and policy attributes

When a supplicant associates with an access point, the AP blocks all data traffic except EAP (Extensible Authentication Protocol) messages. The AP encapsulates these EAP messages in RADIUS packets and forwards them to the RADIUS server. The server verifies the credentials against a backend database — typically LDAP or Active Directory — and returns an Access-Accept or Access-Reject message. If accepted, the AP unblocks the port and the client's traffic flows freely.

architecture_overview.png

Choosing an EAP Method

The security of your RADIUS deployment depends heavily on the EAP method selected. The two most prevalent in enterprise deployments are:

EAP-TLS (Transport Layer Security) is the gold standard. It requires digital certificates on both the RADIUS server and every client device, eliminating passwords entirely. Even if an attacker captures the full authentication exchange, there are no credentials to extract. The trade-off is administrative overhead: deploying and managing client certificates requires a functioning Public Key Infrastructure (PKI) and an MDM solution (e.g., Microsoft Intune, Jamf) to distribute certificates to endpoints.

PEAP-MSCHAPv2 (Protected EAP) is the most widely deployed method in practice. It uses a server-side certificate to establish an encrypted TLS tunnel, inside which the client authenticates with a username and password. This is significantly easier to deploy than EAP-TLS because only one certificate — the server's — needs to be managed. However, it carries a critical caveat: if client devices are not explicitly configured to validate the RADIUS server's certificate, they are vulnerable to Man-in-the-Middle (MitM) attacks via rogue access points.

> Critical Security Note: Failing to enforce strict certificate validation on client devices effectively nullifies the security benefits of PEAP-MSCHAPv2. An attacker can deploy a rogue AP, present a fraudulent certificate, and capture user credentials in plaintext. This is not a theoretical risk — it is a well-documented attack vector that has been exploited in real-world environments.


Implementation Guide

Step 1: Architectural Decision — On-Premise vs. Cloud RADIUS

The first decision is where to host the RADIUS infrastructure. This is primarily an operational and cost question, not a security one — both models can be deployed securely.

comparison_chart.png

On-Premise RADIUS (e.g., Microsoft NPS, FreeRADIUS, Cisco ISE) is suited for organisations with dedicated IT staff, existing on-premise directory infrastructure, and stringent data sovereignty or compliance requirements. It does not depend on internet connectivity for authentication, which is a meaningful advantage for environments where internet uptime cannot be guaranteed.

Cloud RADIUS is increasingly the preferred model for distributed environments — Retail chains, Hospitality groups, and Transport hubs where deploying servers at every location is operationally impractical. Cloud RADIUS integrates natively with cloud identity providers (Azure AD, Google Workspace, Okta) and provides built-in high availability and global scalability.

Step 2: Install and Configure the RADIUS Server

For an on-premise deployment using Microsoft NPS (the most common choice in Windows-centric environments):

  1. Install the Network Policy Server role via Server Manager.
  2. Register the NPS server in Active Directory to allow it to read user dial-in properties.
  3. Create a RADIUS Client entry for each access point or wireless controller, specifying the AP's IP address and a strong, unique Shared Secret.
  4. Configure a Network Policy defining the conditions (e.g., user group membership) and constraints (e.g., EAP method, session timeout) for access.
  5. Configure the Connection Request Policy to process requests locally.

For FreeRADIUS on Linux:

  1. Install via package manager: sudo apt-get install freeradius freeradius-ldap.
  2. Configure /etc/freeradius/3.0/clients.conf to define RADIUS clients (APs) and their shared secrets.
  3. Configure the LDAP module in /etc/freeradius/3.0/mods-available/ldap to point to your Active Directory or LDAP server.
  4. Enable the LDAP module: sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/.
  5. Define EAP methods in /etc/freeradius/3.0/mods-available/eap.

Step 3: Configure Access Points

On your wireless controller or individual access points:

  1. Define the RADIUS server IP address(es) and authentication port (default: UDP 1812).
  2. Configure the Shared Secret — use a minimum of 22 characters, mixing alphanumeric and special characters. Use a unique secret per location or AP group.
  3. Configure the SSID to use WPA2-Enterprise or WPA3-Enterprise security mode with 802.1X key management.
  4. Configure a secondary RADIUS server for failover.

Step 4: Directory Integration

For on-premise AD integration, the RADIUS server must be joined to the domain or have LDAP read access. Ensure service accounts used for LDAP binding have the minimum required permissions. For cloud RADIUS, configure the API-based synchronization or SAML/OIDC integration with your IdP.

Define clear user groups in your directory, as these will drive authorization policies. Recommended group structure:

Group VLAN Access Level
Corp_Staff VLAN 10 Full internal network
Corp_Contractors VLAN 20 Internet + specific internal resources
Corp_IoT VLAN 30 Isolated, device-specific ports only
Corp_Guests VLAN 100 Internet only via captive portal

Step 5: Client Configuration and Certificate Validation

This is the most operationally critical step. Use Group Policy (GPO) for Windows and MDM profiles for macOS/iOS/Android to push WiFi configurations silently to managed devices. The profile must specify:

  • The Root CA that issued the RADIUS server's certificate.
  • The expected server name (CN or SAN of the server certificate).
  • The EAP method and inner authentication protocol.

For unmanaged BYOD devices, provide clear self-service onboarding instructions, ideally via a Network Access Control (NAC) portal.

Step 6: Implement Dynamic VLAN Assignment

Configure the RADIUS server to return VLAN assignment attributes in the Access-Accept response:

  • Tunnel-Type = VLAN (13)
  • Tunnel-Medium-Type = IEEE-802 (6)
  • Tunnel-Private-Group-Id = ``

The access point reads these attributes and places the authenticated client on the specified VLAN — no manual reconfiguration required as users change roles or locations.


Best Practices

Redundancy is non-negotiable. Deploy a minimum of two RADIUS servers (primary and secondary) and configure all access points to fail over automatically. For on-premise deployments, consider placing the secondary server in a different physical location or availability zone. A RADIUS outage means nobody can authenticate, which is a complete network outage for 802.1X-protected SSIDs.

Monitor certificate expiry proactively. A RADIUS server certificate expiry is one of the most common causes of sudden, widespread authentication failures. Implement monitoring to alert administrators at least 30 days before expiry. This applies to both the server certificate and any intermediate CA certificates in the chain.

Treat the Shared Secret as a critical credential. The shared secret between the AP and the RADIUS server encrypts RADIUS packets. Use unique secrets per location or AP group, store them in a secrets manager, and rotate them periodically. See our guide on Protect Your Network with Strong DNS and Security for broader network security hygiene recommendations.

Align with compliance frameworks. For environments subject to PCI DSS (e.g., retail payment networks), 802.1X authentication directly supports requirements for network access control and audit logging. For GDPR compliance, RADIUS accounting logs (port 1813) provide a detailed audit trail of who accessed the network, from where, and when — valuable for incident response. For Healthcare environments, network segmentation via dynamic VLAN assignment supports HIPAA requirements for protecting electronic protected health information (ePHI).


Troubleshooting & Risk Mitigation

Failure Mode Symptom Resolution
Certificate expiry Sudden mass authentication failures Monitor expiry; renew and redeploy certificate
NTP desynchronisation Intermittent EAP-TLS failures Ensure RADIUS server and DCs sync to same NTP source
LDAP connectivity loss Authentication fails when AD is unreachable Deploy redundant DCs; configure RADIUS to cache recent authentications
Incorrect Shared Secret AP logs show RADIUS timeout or Bad authenticator Verify secret matches on both AP and RADIUS server
Client certificate mismatch EAP-TLS failures for specific devices Verify client cert is issued by trusted CA; check cert validity period
VLAN not assigned User authenticated but on wrong network segment Verify RADIUS attributes are correctly returned; check AP VLAN configuration

For a deeper dive into the 802.1X configuration process itself, the How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide provides granular, vendor-specific configuration walkthroughs.


ROI & Business Impact

Transitioning from PSK to RADIUS-backed 802.1X requires an initial investment in configuration, and potentially licensing for cloud solutions or hardware for on-premise deployments. The ROI case is straightforward:

Risk mitigation: The average cost of a data breach in the UK is in excess of £3 million (IBM Cost of a Data Breach Report). A compromised PSK can expose the entire network. 802.1X limits the blast radius to a single compromised user account, which can be disabled in seconds via the directory.

Operational efficiency: Dynamic VLAN assignment eliminates manual network reconfiguration as staff change roles. Onboarding a new employee means adding them to the correct AD group — the network access follows automatically.

Compliance posture: For organisations subject to PCI DSS, ISO 27001, or Cyber Essentials Plus, 802.1X is a direct control that auditors expect to see. Deploying it strengthens your compliance posture and reduces audit remediation costs.

Guest experience and analytics: For venue operators, integrating RADIUS for staff authentication with Purple's Guest WiFi platform for visitor access creates a unified, tiered access model. Staff authenticate silently via 802.1X; guests connect via a branded captive portal. Purple's WiFi Analytics platform then provides real-time visibility into visitor dwell times, repeat visit rates, and engagement metrics — data that directly informs marketing spend and venue operations decisions.


For further reading, see the Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo for Portuguese-language implementation guidance, and What Is a Leased Line? Dedicated Business Internet for guidance on ensuring the underlying connectivity meets enterprise requirements.

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.

Comentário do Examinador: Esta abordagem aborda a vulnerabilidade central (PSK partilhada) ao mesmo tempo que reconhece as restrições operacionais (sem pessoal de TI nas filiais, ambiente Azure AD). O Cloud RADIUS fornece a escalabilidade necessária e integra-se nativamente com o fornecedor de identidade existente. O uso de atribuição dinâmica de VLAN garante que, mesmo que o dispositivo de um prestador de serviços esteja no local após o término do seu contrato, a remoção do grupo de diretório é a única ação necessária para revogar o acesso.

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.

Comentário do Examinador: O modelo de dois SSIDs é a abordagem correta neste caso, em vez de um único SSID com encaminhamento de políticas complexo. Proporciona uma separação operacional clara e simplifica a resolução de problemas. Integrar a Purple para o SSID de hóspedes é a decisão comercialmente inteligente: converte a rede de hóspedes de um centro de custos num canal de captura de dados e marketing, com um ROI mensurável através de taxas de visitas repetidas e envolvimento em campanhas de email marketing.

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

Server RADIUS: um guia abrangente para empresas

Este guia fornece aos gestores de TI, arquitetos de rede e CTOs uma referência técnica definitiva sobre a autenticação de server RADIUS para WiFi empresarial. Abrange a estrutura AAA, a arquitetura 802.1X, a seleção do método EAP, as vantagens e desvantagens da implementação na cloud versus local, e a atribuição dinâmica de VLAN. Os operadores de espaços nos setores da hotelaria, retalho, eventos e setor público encontrarão orientações de implementação práticas, estudos de caso do mundo real e as estruturas de decisão necessárias para migrar de chaves pré-partilhadas inseguras para uma arquitetura de controlo de acesso à rede segura e orientada pela identidade.

Ler o guia →

Aruba ClearPass vs. Purple WiFi: Comparando Funcionalidades e Co-implementação

Um guia técnico abrangente que detalha a arquitetura de co-implementação do Aruba ClearPass e do Purple WiFi. Abrange a configuração de proxy RADIUS, atribuição dinâmica de VLAN e as melhores práticas para fornecer redes de convidados seguras e orientadas por análise de dados, em conjunto com o NAC empresarial.

Ler o guia →

Cisco ISE vs. Purple WiFi: Como se Comparam e Trabalham em Conjunto

Este guia explica como o Cisco ISE e o Purple WiFi desempenham funções distintas mas complementares em redes empresariais. Detalha como utilizar o Cisco ISE para acesso corporativo seguro 802.1X enquanto aproveita o Purple para WiFi de convidados em conformidade com o GDPR, análises de marketing e integração com CRM.

Ler o guia →