Saltar al contenido principal

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

Esta guía autorizada ofrece a los líderes de TI y arquitectos de red un plan integral para implementar un servidor RADIUS para la autenticación WiFi empresarial. Cubre las ventajas y desventajas arquitectónicas entre las implementaciones locales 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 reales y estrategias de mitigación de riesgos para pasar de un entorno PSK inseguro a una infraestructura 802.1X sólida este trimestre.

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

Escuchar esta guía

Ver transcripción del podcast
Bienvenido al Informe Técnico de Purple. Hoy abordamos 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 gestiona un despliegue a gran escala —ya sea una cadena hotelera, 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 comprueba 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. Pasemos ahora al análisis técnico detallado. La primera gran decisión arquitectónica a la que se enfrentará es elegir entre un servidor RADIUS local y una solución alojada en la nube. Históricamente, las soluciones locales como el Network Policy Server de Microsoft (NPS) o el software de código abierto FreeRADIUS eran el estándar. Ofrecen un control total 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 la redundancia. Si dispone de un único centro de datos y de 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 establecimientos de hostelería. El RADIUS en la nube abstrae por completo la gestión del hardware, ofrece alta disponibilidad integrada y se integra a la perfección con proveedores de identidad en la nube como Azure Active Directory u Okta. La contrapartida es que la autenticación requiere una conexión a internet fiable y existe un coste de suscripción continuo. Para un operador de establecimientos que gestiona cincuenta o cien ubicaciones, el ahorro operativo de no tener que desplegar y mantener servidores locales en cada sitio compensará casi con total seguridad ese coste. Al desplegar RADIUS, el Protocolo de Autenticación Extensible —EAP— es la pieza clave. Define cómo negocian y realizan la autenticación el cliente y el servidor. 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, el despliegue de certificados de cliente puede resultar administrativamente pesado. Necesita una infraestructura de clave pública y una solución MDM para enviar los 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 es necesario gestionar 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 las credenciales. Este no es un ataque teórico. Es una amenaza real y 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 MDM (ya sea Intune, Jamf u otra solución) para macOS y dispositivos 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 esto en manos del usuario final para que 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 que indique al punto de acceso que coloque al usuario en una VLAN específica en función de 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 debería 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 potente. El personal y los dispositivos corporativos se autentican de forma silenciosa a través de 802.1X, mientras que los invitados son redirigidos a un portal personalizado para su autenticación. La plataforma de Purple captura entonces datos de primera mano y proporciona análisis sobre el comportamiento de los visitantes, transformando su red de un centro de costes a 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 despliegues locales (on-premise), sí, es muy recomendable 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 competencia por los recursos puede causar fallos intermitentes muy difíciles de diagnosticar. Segunda pregunta: ¿Puede RADIUS gestionar la autenticación de 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 en función de su dirección MAC. Sin embargo, dado que las direcciones MAC se pueden suplantar fácilmente, los dispositivos autenticados mediante MAB siempre deben colocarse en una VLAN muy restringida. Tercera pregunta: ¿Cómo gestiono la redundancia del servidor RADIUS? Despliegue siempre al menos dos servidores RADIUS: uno principal y otro secundario. Configure todos los puntos de acceso para que pasen al secundario si el principal deja de estar accesible. Para RADIUS en la nube, esta redundancia suele estar integrada y gestionada por el proveedor. Para resumir los puntos clave de la sesión de hoy: Las claves precompartidas (PSK) no son aceptables para el WiFi empresarial. Implemente 802.1X. Elija su modelo de despliegue —local o en la nube— en función de sus recursos de TI, el número de ubicaciones que gestiona y su infraestructura de identidad existente. Si su organización está distribuida y prioriza la nube, RADIUS en la nube es casi con seguridad la respuesta correcta. Imponga una validación estricta de certificados en los clientes; esto no es negociable. Utilice la asignación dinámica de VLAN para segmentar su red. Y, por último, considere cómo su infraestructura de autenticación puede integrarse con plataformas más amplias para aportar valor empresarial más allá del simple control de acceso. Para profundizar en el tema, le 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 de usuario contra un directorio antes de otorgar acceso WiFi. Cada despliegue de WiFi empresarial que utiliza 802.1X requiere un servidor RADIUS.

802.1X

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

El estándar de marco global 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", normalmente 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 presentando las credenciales a la red.

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

Authenticator

El dispositivo de red — normalmente un punto de acceso WiFi o un controlador inalámbrico — que actúa como intermediario entre el Supplicant y el servidor RADIUS, aplicando el control de acceso en función del 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 del despliegue 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 (normalmente MSCHAPv2 con usuario/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 despliegue. Requiere solo un certificado en el 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 en la que 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 único SSID sirva a múltiples poblaciones de usuarios con diferentes requisitos de seguridad. Elimina la necesidad de transmitir múltiples SSID para diferentes grupos de usuarios, reduciendo la sobrecarga de RF y simplificando la experiencia del usuario.

Shared Secret

Una cadena de texto preconfigurada conocida únicamente por 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 shared secret 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 gestor de secretos.

MAC Authentication Bypass (MAB)

Un mecanismo de autenticación alternativo en el que 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 de usuario (impresoras, sensores IoT, cámaras IP). Debido a que las direcciones MAC son visibles públicamente y fáciles de suplantar, MAB proporciona identificación de dispositivos en lugar de una autenticación sólida. Emparéjelo siempre con una asignación de VLAN restrictiva.

Ejemplos prácticos

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

Implementar una solución 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 de los gerentes de tienda y terminales POS configuradas para PEAP-MSCHAPv2, aplicando estrictamente la validación del certificado del servidor Cloud RADIUS. La política de Cloud RADIUS comprueba la pertenencia al grupo de Azure AD del usuario antes de conceder el acceso: el grupo "Store_Managers" recibe la VLAN 10 (acceso completo a POS y back-office), el grupo "Contractors" recibe la VLAN 20 (solo internet). Cuando finaliza el contrato de un colaborador externo, al eliminarlo del grupo de Azure AD se 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 las sucursales, entorno 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 las instalaciones después de que finalice su contrato, eliminarlo del grupo de 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 solo necesitan acceso a internet. El hotel dispone de un único entorno local de Windows Server.

Implementar 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, integre el Captive Portal con la plataforma Guest WiFi de Purple para ofrecer una experiencia de inicio de sesión personalizada, recopilar datos de origen (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 comercial más inteligente: convierte la red de invitados de un centro de costes en un canal de captación de datos y marketing, con un ROI medible a través de las tasas de visitas recurrentes y la interacción con las campañas de marketing por correo electrónico.

Preguntas de práctica

Q1. Su organización está migrando 2.000 portátiles Windows de una PSK compartida a 802.1X con PEAP-MSCHAPv2. Su equipo de seguridad advierte que PEAP es vulnerable a la recopilación de credenciales a través de puntos de acceso no autorizados (rogue AP). ¿Cuál es el paso de configuración más importante para mitigar este riesgo y cómo lo despliega a escala?

Sugerencia: Considere qué impide 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. Mediante Objetos de Directiva de Grupo (GPO), envíe un perfil de WiFi a los 2.000 portátiles 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 garantiza que incluso si un atacante despliega 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 proporciona ninguna protección significativa contra ataques de AP no autorizados.

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

Sugerencia: Piense 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

Configure MAC Authentication Bypass (MAB) en el servidor RADIUS para estos dispositivos específicos. Registre la dirección MAC de cada dispositivo en un grupo dedicado de Active Directory o en la base de datos RADIUS. Dado que las direcciones MAC se pueden suplantar fácilmente, el servidor RADIUS debe utilizar la asignación dinámica de VLAN para ubicar 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 cortafuegos 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 ubican en una VLAN independiente. Esta arquitectura cumple con los requisitos de segmentación de red de HIPAA para dispositivos adyacentes a ePHI.

Q3. Usted es el arquitecto de red de una cadena de restaurantes con 50 establecimientos. La autenticación funciona correctamente en 49 de ellos utilizando Cloud RADIUS, pero un establecimiento específico informa de que todos los dispositivos fallan al autenticarse. El portal de gestión de Cloud RADIUS muestra cero solicitudes de autenticación procedentes de ese establecimiento. ¿Cuál es su 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 no recibe ninguna solicitud de este establecimiento, el fallo se encuentra entre los puntos de acceso y el servidor Cloud RADIUS. Pasos de diagnóstico en orden: (1) Verificar la dirección IP y el puerto del servidor RADIUS (UDP 1812) configurados en los AP o en el controlador inalámbrico del establecimiento (un error tipográfico aquí es la causa más común). (2) Comprobar las reglas del cortafuegos local o del router en ese establecimiento para confirmar que se permite el tráfico UDP 1812 saliente hacia el rango de IP de Cloud RADIUS. (3) Verificar que el Secreto Compartido (Shared Secret) configurado en los AP coincide con el secreto configurado para ese establecimiento en el portal de Cloud RADIUS (una discrepancia hace que el servidor RADIUS descarte silenciosamente los paquetes). (4) Comprobar si la conexión a Internet del establecimiento funciona (Cloud RADIUS requiere conectividad a Internet fiable). Realizar 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 (CTO) una referencia técnica definitiva sobre la autenticación mediante server RADIUS para WiFi empresarial. Cubre el marco AAA, la arquitectura 802.1X, la selección del método EAP, las ventajas y desventajas del despliegue en la nube frente a local y la asignación dinámica de VLAN. Los operadores de recintos del sector de la hostelería, retail, eventos y el sector público encontrarán pautas de implementación prácticas, casos de estudio reales y los marcos de decisión necesarios para migrar de claves precompartidas no seguras 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: comparativa de funciones y codespliegue

Una guía técnica exhaustiva que detalla la arquitectura de codespliegue de Aruba ClearPass y Purple WiFi. Cubre la configuración de proxy RADIUS, la asignación dinámica de VLAN y las mejores prácticas para ofrecer redes de invitados seguras y basadas en analítica 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 802.1X seguro, al tiempo que se aprovecha Purple para ofrecer un WiFi de invitados que cumpla con el GDPR, análisis de marketing e integración con CRM.

Leer la guía →