Saltar al contenido principal

Cómo configurar un servidor RADIUS para autenticación WiFi

Esta guía autoritativa proporciona a los líderes de TI y arquitectos de red un modelo integral para desplegar un servidor RADIUS para la autenticación WiFi empresarial. Cubre los pros y contras arquitectónicos entre los despliegues locales (on-premise) y en la nube, la selección del método EAP, la integración con Active Directory y la asignación dinámica de VLAN. Los operadores de recintos y los equipos de TI encontrarán pasos de implementación prácticos, casos de estudio del mundo real y estrategias de mitigación de riesgos para migrar de un entorno PSK inseguro a una infraestructura robusta 802.1X este trimestre.

📖 8 min de lectura📝 1,860 palabras🔧 2 ejemplos resueltos3 preguntas de práctica📚 9 definiciones clave

Escucha esta guía

Ver transcripción del podcast
Bienvenido al Technical Briefing de Purple. Hoy abordaremos una decisión de infraestructura crítica para cualquier líder de TI empresarial: cómo configurar un servidor RADIUS para la autenticación de WiFi. Si está gestionando un despliegue a gran escala —ya sea una cadena de hoteles, una red de retail o un campus universitario en expansión— confiar en una clave precompartida simple es un riesgo de seguridad significativo. Necesitamos 802.1X, y eso significa que necesitamos RADIUS. Comencemos con el contexto. RADIUS, o Remote Authentication Dial-In User Service, actúa como el guardián de su red. Cuando un dispositivo intenta conectarse a un punto de acceso WiFi, el punto de acceso actúa como autenticador y reenvía las credenciales al servidor RADIUS. El servidor verifica esas credenciales con un directorio —como Active Directory o una base de datos LDAP— y luego devuelve un mensaje de aceptación o rechazo. Es la base de la seguridad WiFi empresarial y es el mecanismo que le permite aplicar políticas de acceso granulares a escala. Ahora pasemos al análisis técnico profundo. La primera gran decisión arquitectónica a la que se enfrentará es elegir entre un servidor RADIUS on-premise y una solución alojada en la nube. Históricamente, las soluciones on-premise como el Network Policy Server de Microsoft, o NPS, o la opción de código abierto FreeRADIUS eran el estándar. Ofrecen un control completo sobre la infraestructura y no dependen de una conexión a internet externa para la autenticación. Sin embargo, requieren hardware dedicado, mantenimiento continuo y configuración manual de redundancia. Si cuenta con un solo centro de datos y un equipo de TI con suficiente personal, este es un enfoque perfectamente válido. Por otro lado, las soluciones RADIUS en la nube se han vuelto cada vez más populares, especialmente para entornos distribuidos como cadenas de retail o complejos hoteleros. El RADIUS en la nube abstrae por completo la gestión del hardware, ofrece alta disponibilidad integrada y se integra perfectamente con proveedores de identidad en la nube como Azure Active Directory u Okta. La contraparte es que la autenticación requiere una conexión a internet confiable y existe un costo de suscripción continuo. Para el operador de un establecimiento que gestiona cincuenta o cien ubicaciones, los ahorros operativos de no implementar y mantener servidores on-premise en cada sitio casi con certeza superarán ese costo. Al implementar RADIUS, el Extensible Authentication Protocol —EAP— es la pieza crítica. Define cómo el cliente y el servidor negocian y realizan la autenticación. EAP-TLS es el estándar de oro para la seguridad porque utiliza certificados digitales tanto en el cliente como en el servidor, eliminando por completo la necesidad de contraseñas. Esto significa que incluso si un atacante captura el intercambio de autenticación, no hay credenciales que robar. Sin embargo, implementar certificados de cliente puede ser administrativamente pesado. Necesita una infraestructura de clave pública (PKI) y una solución MDM para enviar certificados a cada dispositivo. PEAP-MSCHAPv2 es la alternativa más común. Utiliza un certificado del lado del servidor para establecer un túnel TLS cifrado, dentro del cual el usuario se autentica con un nombre de usuario y contraseña. Esto es significativamente más fácil de implementar que EAP-TLS porque solo necesita administrar un certificado: el del servidor. Sin embargo, y esto es fundamental: si los clientes no están configurados estrictamente para validar el certificado del servidor, son vulnerables a puntos de acceso no autorizados. Un atacante puede levantar un punto de acceso falso, presentar un certificado fraudulento y capturar credenciales. Este no es un ataque teórico. Es una amenaza del mundo real bien documentada. Hablemos de recomendaciones de implementación y errores comunes. La primera recomendación es aplicar una validación estricta de certificados en cada dispositivo cliente. Utilice Objetos de Directiva de Grupo (GPO) para dispositivos Windows y perfiles de MDM (ya sea Intune, Jamf u otra solución) para dispositivos macOS y móviles. El perfil debe especificar exactamente en qué Autoridad de Certificación confiar y cuál es el nombre de servidor esperado. No deje que el usuario final lo configure manualmente. La segunda recomendación es implementar la asignación dinámica de VLAN. En lugar de colocar a todos los usuarios autenticados en la misma red plana, configure el servidor RADIUS para indicar al punto de acceso que coloque al usuario en una VLAN específica según su pertenencia a un grupo en el directorio. Esto es esencial para segmentar los dispositivos corporativos de los dispositivos BYOD o de invitados. Un miembro del equipo de finanzas debe estar en un segmento de red diferente al de un contratista que está de visita por el día. La tercera recomendación se refiere al acceso de invitados. Para los establecimientos que necesitan ofrecer WiFi a los visitantes (hoteles, tiendas minoristas, centros de conferencias), integrar su infraestructura RADIUS con una solución de Captive Portal como la plataforma Guest WiFi de Purple es una combinación muy potente. Los dispositivos del personal y corporativos se autentican de forma silenciosa a través de 802.1X, mientras que los invitados son dirigidos a un portal personalizado para su autenticación. La plataforma de Purple luego captura datos de primera mano y proporciona análisis sobre el comportamiento de los visitantes, transformando su red de un centro de costos en un activo de inteligencia empresarial. Ahora pasemos a una sesión de preguntas y respuestas rápidas. Primera pregunta: ¿Necesito un servidor dedicado para RADIUS? Para implementaciones locales, sí, se recomienda ampliamente ejecutarlo en una máquina virtual dedicada en lugar de compartir recursos con un controlador de dominio. La autenticación es una operación sensible a la latencia, y la contención de recursos puede causar fallas intermitentes que son muy difíciles de diagnosticar. Segunda pregunta: ¿Puede RADIUS manejar la autenticación para dispositivos sin interfaz de usuario (headless) como impresoras o sensores IoT? Sí, a través de MAC Authentication Bypass o MAB. Esto permite que los dispositivos sin capacidades 802.1X se autentiquen según su dirección MAC. Sin embargo, debido a que las direcciones MAC se pueden suplantar fácilmente, los dispositivos autenticados por MAB siempre deben colocarse en una VLAN altamente restringida. Tercera pregunta: ¿Cómo manejo la redundancia del servidor RADIUS? Siempre implemente al menos dos servidores RADIUS: uno primario y uno secundario. Configure todos los puntos de acceso para que se desvíen al secundario si el primario no está disponible. Para RADIUS en la nube, esta redundancia generalmente está integrada y es gestionada por el proveedor. Para resumir los puntos clave de la sesión de hoy. Las claves precompartidas no son aceptables para el WiFi empresarial. Implemente 802.1X. Elija su modelo de implementación (local o en la nube) según sus recursos de TI, la cantidad de ubicaciones que administra y su infraestructura de identidad existente. Si su empresa está distribuida y prioriza la nube, el RADIUS en la nube es casi seguro la respuesta correcta. Exija una validación estricta de certificados en los clientes. Esto no es negociable. Use la asignación dinámica de VLAN para segmentar su red. Y finalmente, considere cómo su infraestructura de autenticación puede integrarse con plataformas más amplias para ofrecer valor comercial más allá del simple control de acceso. Para profundizar en el tema, recomendamos explorar las guías de Purple sobre cómo configurar la autenticación WiFi 802.1X y cómo proteger su red con políticas de DNS sólidas. Gracias por su atención.

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.

Definiciones clave

RADIUS (Remote Authentication Dial-In User Service)

Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan a un servicio de red. Definido en RFC 2865.

El componente de servidor principal que valida las credenciales del usuario contra un directorio antes de otorgar acceso WiFi. Cada implementación de WiFi empresarial que utiliza 802.1X requiere un servidor RADIUS.

802.1X

Un estándar IEEE para el Control de Acceso a la Red Basado en Puertos (PNAC). Proporciona un mecanismo de autenticación para los dispositivos que desean conectarse a una LAN o WLAN, bloqueando todo el tráfico que no sea EAP hasta que la autenticación sea exitosa.

El estándar de marco de trabajo general que define cómo se comunican el Supplicant, el Authenticator y el Servidor de Autenticación. Cuando los equipos de TI se refieren a la "seguridad WiFi empresarial", generalmente se refieren a WPA2/WPA3-Enterprise con 802.1X.

Supplicant

El dispositivo cliente — o más precisamente, la pila de software 802.1X en ese dispositivo — que inicia el proceso de autenticación al presentar credenciales a la red.

En Windows, el supplicant integrado es el servicio Wireless AutoConfig. En macOS e iOS, es nativo del SO. Asegurar que el supplicant esté correctamente configurado (especialmente para la validación de certificados) es la fuente más común de problemas de implementación.

Authenticator

El dispositivo de red — típicamente un punto de acceso WiFi o controlador inalámbrico — que actúa como intermediario entre el Supplicant y el servidor RADIUS, aplicando el control de acceso según el resultado de la autenticación.

El AP bloquea todo el tráfico de datos en el puerto hasta que recibe un Access-Accept del servidor RADIUS. También lee los atributos RADIUS (por ejemplo, la asignación de VLAN) de la respuesta Access-Accept y los aplica a la sesión.

EAP (Extensible Authentication Protocol)

Un marco de autenticación definido en RFC 3748 que proporciona un mecanismo de transporte estandarizado para varios métodos de autenticación (TLS, PEAP, TTLS, etc.) entre el Supplicant y el Servidor de Autenticación.

EAP es el "idioma" que se habla entre el cliente y el servidor RADIUS. La elección del método EAP (EAP-TLS frente a PEAP) determina la solidez de la seguridad y la complejidad de la implementación del sistema de autenticación.

PEAP (Protected EAP)

Un método EAP que primero establece un túnel TLS utilizando el certificado del servidor, y luego realiza una autenticación secundaria (típicamente MSCHAPv2 con nombre de usuario y contraseña) dentro de ese túnel cifrado.

El método de autenticación WiFi empresarial más común debido a su equilibrio entre seguridad y simplicidad de implementación. Requiere solo un certificado del lado del servidor, lo que hace que sea mucho más fácil de implementar que EAP-TLS.

Dynamic VLAN Assignment

Una función de RADIUS donde el servidor incluye atributos específicos de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) en la respuesta Access-Accept, indicando al AP que coloque al cliente autenticado en una VLAN específica.

Permite que un solo SSID atienda a múltiples poblaciones de usuarios con diferentes requisitos de seguridad. Elimina la necesidad de transmitir múltiples SSIDs para diferentes grupos de usuarios, reduciendo la sobrecarga de RF y simplificando la experiencia del usuario.

Shared Secret

Una cadena de texto preconfigurada que solo conocen el Authenticator (AP) y el servidor RADIUS, utilizada para firmar y cifrar paquetes RADIUS, garantizando la integridad y autenticidad de la comunicación.

Un elemento crítico de configuración de seguridad. Si el secreto compartido es débil o está comprometido, un atacante podría falsificar respuestas Access-Accept de RADIUS, otorgando acceso no autorizado a la red. Utilice secretos únicos por ubicación y almacénelos en un administrador de secretos.

MAC Authentication Bypass (MAB)

Un mecanismo de autenticación alternativo donde la dirección MAC de un dispositivo se utiliza como su credencial de identidad, lo que permite el acceso a la red para dispositivos que no admiten supplicants 802.1X.

Se utiliza para dispositivos sin interfaz (impresoras, sensores IoT, cámaras IP). Debido a que las direcciones MAC son públicamente visibles y fáciles de falsificar, MAB proporciona identificación de dispositivos en lugar de una autenticación sólida. Siempre debe asociarse con una asignación de VLAN restrictiva.

Ejemplos resueltos

Una cadena minorista nacional con 500 sucursales necesita implementar WiFi seguro para las tabletas y terminales de punto de venta (POS) de los gerentes de tienda. Actualmente utilizan una única clave PSK en todas las tiendas, la cual se comparte con frecuencia con personal y contratistas no autorizados. Utilizan Azure AD para la gestión de identidades y no tienen personal de TI dedicado en las sucursales.

Desplegar una solución de Cloud RADIUS integrada directamente con Azure AD. Esto elimina la necesidad de desplegar y gestionar servidores RADIUS locales en 500 ubicaciones. El equipo de TI utiliza Microsoft Intune para enviar un perfil de WiFi a todas las tabletas y terminales POS de los gerentes de tienda configurado para PEAP-MSCHAPv2, exigiendo estrictamente la validación del certificado del servidor Cloud RADIUS. La política de Cloud RADIUS verifica la pertenencia al grupo de Azure AD del usuario antes de otorgar el acceso: el grupo "Store_Managers" recibe la VLAN 10 (acceso completo a POS y oficina administrativa), el grupo "Contractors" recibe la VLAN 20 (solo Internet). Cuando finaliza el contrato de un contratista, eliminarlo del grupo de Azure AD revoca inmediatamente su acceso a la WiFi en las 500 ubicaciones de forma simultánea, sin necesidad de cambiar la PSK.

Comentario del examinador: Este enfoque aborda la vulnerabilidad principal (PSK compartida) al tiempo que reconoce las limitaciones operativas (sin personal de TI en sucursales, entorno de Azure AD). Cloud RADIUS proporciona la escalabilidad necesaria y se integra de forma nativa con el proveedor de identidad existente. El uso de la asignación dinámica de VLAN garantiza que, incluso si el dispositivo de un contratista está en el sitio después de que finalice su contrato, eliminarlo del grupo del directorio es la única acción requerida para revocar el acceso.

Un hotel de 400 habitaciones en el centro de la ciudad necesita proporcionar WiFi seguro tanto para el personal (recepción, limpieza, administración) como para los huéspedes. El personal requiere acceso al sistema de gestión de la propiedad (PMS) y a los servidores internos. Los huéspedes requieren únicamente acceso a Internet. El hotel cuenta con un único entorno local de Windows Server.

Desplegar Microsoft NPS en una máquina virtual dedicada de Windows Server. Configurar dos SSIDs en la infraestructura inalámbrica: "Hotel_Staff" (WPA2-Enterprise, 802.1X) y "Hotel_Guest" (abierto o WPA2-Personal, que redirige a un Captive Portal). Para el SSID del personal, NPS valida las credenciales contra Active Directory y devuelve asignaciones dinámicas de VLAN: grupo de AD "Management" → VLAN 10 (acceso completo), "FrontDesk" → VLAN 20 (acceso al PMS), "Housekeeping" → VLAN 30 (solo Internet + aplicación de programación). Para los huéspedes, integrar el Captive Portal con la plataforma de Guest WiFi de Purple para proporcionar una experiencia de inicio de sesión personalizada con la marca, recopilar datos de primera mano (correo electrónico, consentimiento de marketing) y obtener análisis sobre el tiempo de permanencia y las visitas recurrentes. El modelo de dos SSIDs mantiene el tráfico del personal y de los huéspedes completamente separado en la capa de red.

Comentario del examinador: El modelo de dos SSIDs es el enfoque correcto en este caso, en lugar de un único SSID con un enrutamiento de políticas complejo. Proporciona una separación operativa clara y simplifica la resolución de problemas. Integrar Purple para el SSID de invitados es la decisión comercialmente inteligente: convierte la red de invitados de un centro de costos en un canal de captura de datos y marketing, con un ROI medible a través de las tasas de visitas recurrentes y el compromiso de marketing por correo electrónico.

Preguntas de práctica

Q1. Tu organización está migrando 2,000 laptops Windows de una PSK compartida a 802.1X con PEAP-MSCHAPv2. Tu equipo de seguridad advierte que PEAP es vulnerable a la obtención de credenciales a través de puntos de acceso no autorizados (rogue APs). ¿Cuál es el paso de configuración más importante para mitigar este riesgo y cómo lo implementas a escala?

Sugerencia: Considera qué evita que un cliente confíe en un servidor RADIUS fraudulento que presenta un certificado autofirmado.

Ver respuesta modelo

El paso crítico es aplicar una validación estricta del certificado del servidor en cada dispositivo cliente. Utilizando Objetos de Directiva de Grupo (GPO), distribuye un perfil de WiFi a las 2,000 laptops que especifique: (1) el certificado de la CA Raíz exacto que emitió el certificado del servidor RADIUS, (2) el nombre de servidor esperado (CN/SAN), y (3) que el cliente no debe solicitar al usuario que confíe en nuevos certificados. Esto asegura que incluso si un atacante implementa un AP no autorizado con un certificado fraudulento, el cliente rechazará el saludo TLS y se negará a enviar credenciales. Sin esta configuración, PEAP no ofrece ninguna protección significativa contra ataques de AP no autorizados.

Q2. Un director de TI de un hospital necesita proporcionar acceso a la red para 300 dispositivos IoT médicos (bombas de infusión, equipos de monitoreo) que no son compatibles con 802.1X. Estos dispositivos se encuentran junto a las estaciones de trabajo del personal en la misma infraestructura inalámbrica. ¿Cómo debe manejar la infraestructura RADIUS estos dispositivos y qué controles de red deben implementarse?

Sugerencia: Piensa en el método de autenticación disponible para dispositivos sin interfaz de usuario (headless) y cómo compensar su debilidad inherente.

Ver respuesta modelo

Configura MAC Authentication Bypass (MAB) en el servidor RADIUS para estos dispositivos específicos. Registra la dirección MAC de cada dispositivo en un grupo dedicado de Active Directory o en la base de datos de RADIUS. Debido a que las direcciones MAC se pueden suplantar fácilmente, el servidor RADIUS debe utilizar la Asignación Dinámica de VLAN para colocar todos los dispositivos autenticados por MAB en una VLAN dedicada y altamente restringida (por ejemplo, VLAN 30 - IoT). Esta VLAN debe estar protegida por un firewall para permitir la comunicación únicamente con direcciones IP de servidores médicos específicos y bloquear todo el demás tráfico, incluido el acceso a internet y el movimiento lateral hacia las VLAN del personal. Las estaciones de trabajo del personal se autentican mediante 802.1X y se colocan en una VLAN separada. Esta arquitectura cumple con los requisitos de segmentación de red de HIPAA para dispositivos adyacentes a ePHI.

Q3. Eres el arquitecto de red de una cadena de restaurantes de 50 sucursales. La autenticación funciona correctamente en 49 sucursales utilizando Cloud RADIUS, pero una sucursal específica informa que todos los dispositivos fallan al autenticarse. El portal de administración de Cloud RADIUS muestra cero solicitudes de autenticación entrantes de esa sucursal. ¿Cuál es tu enfoque de diagnóstico?

Sugerencia: Si el servidor RADIUS no recibe ninguna solicitud, el problema está en la ruta de comunicación entre el autenticador y el servidor, no en la lógica de autenticación en sí.

Ver respuesta modelo

Dado que el servidor RADIUS recibe cero solicitudes de esta sucursal, la falla radica entre los puntos de acceso y el servidor Cloud RADIUS. Pasos de diagnóstico en orden: (1) Verifica la dirección IP del servidor RADIUS y el puerto (UDP 1812) configurados en los AP o en el controlador inalámbrico de la sucursal; un error de dedo aquí es la causa más común. (2) Revisa las reglas del firewall o router local en esa sucursal para confirmar que se permite el tráfico UDP 1812 saliente hacia el rango de IP de Cloud RADIUS. (3) Verifica que el Secreto Compartido configurado en los AP coincida con el secreto configurado para esa sucursal en el portal de Cloud RADIUS; una discrepancia hace que el servidor RADIUS descarte los paquetes de forma silenciosa. (4) Comprueba si la conexión a internet de la sucursal funciona; Cloud RADIUS requiere conectividad a internet confiable. Ejecutar una captura de paquetes en el AP o en el router ascendente confirmará si se están enviando paquetes RADIUS y si se están recibiendo respuestas.

Continúe leyendo esta serie

Server RADIUS: una guía completa para empresas

Esta guía proporciona a directores de TI, arquitectos de redes y directores de tecnología una referencia técnica definitiva sobre la autenticación de server RADIUS para WiFi empresarial. Abarca el marco AAA, la arquitectura 802.1X, la selección del método EAP, las ventajas y desventajas de la implementación en la nube frente a la local, y la asignación dinámica de VLAN. Los operadores de recintos en los sectores de hotelería, comercio minorista, eventos y el sector público encontrarán orientación de implementación práctica, casos de estudio del mundo real y los marcos de decisión necesarios para migrar de claves precompartidas inseguras a una arquitectura de control de acceso a la red segura y basada en la identidad.

Leer la guía →

Aruba ClearPass vs. Purple WiFi: Comparando Funciones y Co-implementación

Una guía técnica exhaustiva que detalla la arquitectura de co-implementación de Aruba ClearPass y Purple WiFi. Cubre la configuración del proxy RADIUS, la asignación dinámica de VLAN y las mejores prácticas para ofrecer redes de invitados seguras y basadas en analíticas junto con el NAC empresarial.

Leer la guía →

Cisco ISE vs. Purple WiFi: How They Compare and Work Together

Esta guía explica cómo Cisco ISE y Purple WiFi desempeñan funciones distintas pero complementarias en las redes empresariales. Detalla cómo utilizar Cisco ISE para un acceso corporativo seguro 802.1X, al tiempo que se aprovecha Purple para ofrecer WiFi para invitados que cumpla con el GDPR, análisis de marketing e integración con CRM.

Leer la guía →