Cómo configurar un servidor RADIUS para la autenticación WiFi: Guía paso a paso de 802.1X

Configure FreeRADIUS, Windows Server NPS y Cloud RADIUS para la autenticación WiFi 802.1X empresarial. Guía paso a paso que cubre secretos compartidos, certificados EAP-TLS, asignación dinámica de VLAN e integración con Microsoft Entra ID.

Por Iain JewittPublicado 30 de abril de 2026

📖 8 min de lectura1,902 palabras2 ejemplos resueltos3 preguntas de práctica5 definiciones clave

Video overview

Escucha esta guía

Ver transcripción del podcast

Bienvenido a la sesión informativa técnica 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 WiFi. Si administra una implementación a gran escala - ya sea una cadena de hoteles, una red de retail o un campus universitario en expansión - depender de 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 un 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 decisión arquitectónica importante que enfrentará es elegir entre un servidor RADIUS on-premise y una solución alojada en la nube. Históricamente, las soluciones on-premise como 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 tiene 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 de cloud RADIUS se han vuelto cada vez más populares, especialmente para entornos distribuidos como cadenas de retail o establecimientos de hospitalidad. Cloud RADIUS 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 desventaja es que la autenticación requiere una conexión a internet confiable y existe un costo de suscripción continuo. Para un operador de establecimientos que administra cincuenta o cien ubicaciones, el ahorro operativo de no implementar y mantener servidores on-premise en cada sitio casi con certeza superará ese costo.

Al implementar RADIUS, el Extensible Authentication Protocol - EAP - es la pieza clave. 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, lo que elimina 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 y una solución de 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 considerablemente 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, quedan expuestos a puntos de acceso no autorizados. Un atacante puede montar un punto de acceso falso, presentar un certificado fraudulento y capturar las credenciales. Esto 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 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 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 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 de tipo BYOD o de invitados. Un miembro del personal 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 proporcionar WiFi a los visitantes (hoteles, tiendas minoristas, centros de conferencias), integrar su infraestructura RADIUS con una solución de Captive Portal como la plataforma de Guest WiFi de Purple es una combinación muy potente. El personal y los dispositivos corporativos se autentican de forma silenciosa a través de 802.1X, mientras que los invitados son dirigidos a un portal de marca 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 costos a un activo de inteligencia de negocios.

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 competencia por los recursos puede causar fallas intermitentes muy difíciles de diagnosticar. Segunda pregunta: ¿puede RADIUS gestionar la autenticación para dispositivos sin interfaz de usuario 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 gestiono la redundancia del servidor RADIUS? Siempre implemente al menos dos servidores RADIUS - un primario y un secundario. Configure todos los puntos de acceso para que pasen al secundario si el primario no está disponible. 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 previamente compartidas no son aceptables para el WiFi empresarial. Implemente 802.1X. Elija su modelo de implementación - 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, un RADIUS en la nube es casi seguro la respuesta correcta. Exija 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 finalmente, considere cómo su infraestructura de autenticación puede integrarse con plataformas más amplias para ofrecer valor empresarial más allá de simplemente controlar el acceso.

Para lecturas adicionales, 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 escuchar.

Puntos clave

✓RADIUS (Remote Authentication Dial-In User Service) actúa como la autoridad de autenticación central para redes WiFi empresariales 802.1X, eliminando las claves precompartidas (PSK).
✓EAP-TLS con certificados digitales X.509 proporciona una seguridad superior sobre PEAP-MSCHAPv2 al eliminar las vulnerabilidades de ataques de pulverización de contraseñas y la recopilación de credenciales por puntos de acceso falsos.
✓La asignación dinámica de VLAN mediante los atributos RFC 2868 y RFC 3580 segmenta automáticamente al personal autenticado, contratistas y terminales médicos o de IoT en redes separadas.
✓Las arquitecturas modernas de RADIUS en la nube se conectan directamente a proveedores de identidad en la nube como Microsoft Entra ID y Google Workspace utilizando RadSec (RFC 6614) sobre el puerto TLS 2083.

Parte de nuestra serie principal: Guía de seguridad WiFi empresarial →

Resumen ejecutivo

Cómo configurar un servidor RADIUS para la autenticación WiFi: Guía paso a paso de 802.1X

Las redes inalámbricas empresariales requieren una gestión de identidad centralizada, segmentación basada en roles y una sólida protección criptográfica. Depender de claves compartidas (PSKs) expone a las organizaciones a filtraciones de credenciales, acceso no autorizado a dispositivos y problemas administrativos cada vez que un empleado se va.

Configurar un servidor RADIUS (Remote Authentication Dial-In User Service) permite la autenticación empresarial IEEE 802.1X. Cada dispositivo y usuario que se conecta se autentica individualmente contra un directorio central, como Microsoft Entra ID, Google Workspace, Okta o Active Directory local.

Esta guía técnica proporciona instrucciones de implementación paso a paso para configurar un servidor RADIUS para WiFi empresarial. Cubrimos la configuración de FreeRADIUS en Linux, la configuración de Network Policy Server (NPS) en Windows Server, arquitecturas modernas de Cloud RADIUS, asignación dinámica de VLAN y el fortalecimiento de la seguridad frente a BlastRADIUS.

Descripción general de la arquitectura 802.1X y RADIUS

El marco de trabajo IEEE 802.1X divide el acceso a la red en tres entidades distintas:

El Suplicante (Supplicant): El dispositivo cliente (laptop, smartphone o tableta) que ejecuta el software cliente 802.1X y presenta las credenciales de identidad.
El Autenticador (Authenticator): El punto de acceso inalámbrico (AP) o controlador de LAN inalámbrica (WLC) que controla el acceso físico a la red y retransmite los mensajes de autenticación.
El Servidor de Autenticación: El servidor RADIUS que valida las credenciales contra un directorio de identidad y devuelve las políticas de autorización de red.

+---------------+        EAP over LAN (EAPoL)        +-------------------+
|  Suplicante   | <================================> |   Autenticador    |
| (Dispositivo) |                                    | (AP / Controlador)|
+---------------+                                    +-------------------+
                                                               ||
                                                               || Protocolo RADIUS
                                                               || (UDP 1812 / TCP 2083)
                                                               \/
                                                     +-------------------+
                                                     |  Servidor RADIUS  |
                                                     |  (FreeRADIUS/NPS) |
                                                     +-------------------+
                                                               ||
                                                               || Consulta de Identidad
                                                               \/
                                                     +-------------------+
                                                     | Prov de Identidad |
                                                     | (Entra ID / LDAP) |
                                                     +-------------------+

Flujo de comunicación RADIUS

Asociación: El cliente se asocia con el SSID empresarial (WPA2-Enterprise o WPA3-Enterprise).
Iniciación EAP: El AP bloquea todo el tráfico de datos y envía una trama EAP-Request/Identity al cliente.
Respuesta de identidad: El cliente responde con una trama EAP-Response/Identity.
Encapsulación RADIUS: El AP encapsula la carga útil de EAP en un paquete RADIUS Access-Request y lo reenvía al servidor RADIUS.
Negociación EAP: El cliente y el servidor RADIUS negocian el método de autenticación criptográfica (como EAP-TLS o PEAP).
Autorización y Access-Accept: Tras una validación exitosa, el servidor RADIUS emite un paquete RADIUS Access-Accept que contiene la Clave Maestra Pareada (PMK) y atributos opcionales de asignación dinámica de VLAN.
Apertura de puerto: El AP desbloquea el puerto virtual e inicia el saludo de 4 vías para cifrar el tráfico inalámbrico por el aire.

Para conceptos arquitectónicos más profundos, explore nuestra Enterprise WiFi Security Guide y Captive Portal Guide.

Configuración paso a paso: FreeRADIUS en Linux

FreeRADIUS es el estándar mundial de suites RADIUS de código abierto. A continuación se muestra la secuencia de configuración para Ubuntu 24.04 LTS / Debian 12.

Paso 1: Instalar paquetes de FreeRADIUS

sudo apt update
sudo apt install -y freeradius freeradius-utils freeradius-ldap ssl-cert

Paso 2: Definir clientes de Servidor de Acceso a la Red (NAS)

Edite /etc/freeradius/3.0/clients.conf para autorizar sus puntos de acceso inalámbrico y configurar un secreto compartido:

client enterprise_wlan {
  ipaddr: 192.168.10.0/24
  secret: Str0ngSh@redSecr3t2026!
  shortname: branch-aps
  nas_type: other
  require_message_authenticator: yes
}

Nota: Siempre aplique los atributos RFC 2869 Message-Authenticator para defenderse contra los ataques de falsificación BlastRADIUS.

Paso 3: Configurar módulos de autenticación EAP

Abra /etc/freeradius/3.0/mods-available/eap y configure el método EAP predeterminado:

eap {
  default_eap_type: tls
  timer_expire: 60
  ignore_unknown_eap_types: no
  cisco_accounting_username_bug: no
  max_sessions: 4096

  tls-config tls-common {
    certdir: ${confdir}/certs
    cadir: ${confdir}/certs
    private_key_file: ${certdir}/radius-server.key
    certificate_file: ${certdir}/radius-server.crt
    ca_file: ${cadir}/ca.crt
    cipher_list: HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH
    tls_min_version: 1.2
  }
}

Paso 4: Probar en modo de depuración

Antes de ejecutarlo como un servicio del sistema, detenga el demonio e inicie en modo de depuración en primer plano:

sudo systemctl stop freeradius
sudo freeradius -X

Pruebe la autenticación local usando radtest:

radtest testuser Password123 127.0.0.1 0 testing123

Una respuesta exitosa devuelve Received Access-Accept Id 1.

Configuración paso a paso: Windows Server NPS

Microsoft Network Policy Server (NPS) es el rol de servidor RADIUS integrado para entornos de Windows Server conectados a Active Directory Domain Services (AD DS).

+-------------------------------------------------------------------------+
|                  Windows Server Network Policy Server                   |
|                                                                         |
|  [Clientes RADIUS (AP / WLC)] ---> [Políticas de solicitud de conexión] |
|                                                  |                      |
|                                                  v                      |
|  [Active Directory DS / PKI] <--- [Políticas de red (VLAN / EAP-TLS)]   |
+-------------------------------------------------------------------------+

Paso 1: Instalar Network Policy and Access Services

Abra PowerShell como Administrador:

Install-WindowsFeature NPAS -IncludeManagementTools
Register-ActiveDirectoryServer -Server nps01.corp.local

Paso 2: Registrar clientes RADIUS (puntos de acceso)

Abra Network Policy Server (nps.msc).
Despliegue RADIUS Clients and Servers > Dé clic derecho en RADIUS Clients > New.
Ingrese Friendly Name: Cisco-Catalyst-AP-Cluster.
Ingrese la dirección IP o el CIDR de subred (por ejemplo, 10.50.0.0/24).
Genere e ingrese un Shared Secret robusto (mínimo de 24 caracteres alfanuméricos).

Paso 3: Crear política de red para autenticación WiFi

En Policies > Network Policies, dé clic derecho y seleccione New.
Policy Name: Staff-WiFi-802.1X-Policy. Type of network access server: Unspecified.
Conditions:
- Agregue Windows Groups: CORP\WiFi-Authorised-Users
- Agregue NAS-Port-Type: Wireless - IEEE 802.11 o Wireless - Other
Access Permission: Seleccione Access granted.
Authentication Methods:
- Desmarque los métodos menos seguros.
- En EAP Types, agregue Microsoft: Smart Card or other certificate (EAP-TLS).
- Edite el método y seleccione el RADIUS Server Certificate emitido por su CA empresarial de Active Directory Certificate Services (AD CS).
Constraints: Establezca Idle Timeout en 30 minutos y Session Timeout en 8 horas.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.

Cloud RADIUS: Arquitectura moderna zero-trust

Los servidores RADIUS locales tradicionales presentan importantes desafíos operativos:

Altos costos de licencias de servidor y mantenimiento de parches.
Sin API de autenticación nativas para directorios de identidad en la nube como Microsoft Entra ID o Google Workspace.
Vulnerabilidad a interrupciones de WAN en las sucursales.

Las redes empresariales modernas implementan Cloud RADIUS para centralizar la autenticación con cero infraestructura de servidores locales.

Característica	Legacy Windows NPS / FreeRADIUS	Arquitectura Cloud RADIUS
Integración de directorio	LDAP / Kerberos local	Native Microsoft Entra ID, Google Workspace, Okta
Seguridad de transporte	UDP 1812/1813 sin cifrar	RadSec (RFC 6614) TLS sobre TCP 2083
Automatización de Certificados	Configuración manual de SCEP / NDES	Conectores PKI automatizados para Intune y Jamf
Alta Disponibilidad	Failover manual activo-pasivo	Redundancia global Anycast multirregión
Mantenimiento	Parcheo de sistema operativo y licenciamiento de OS	Servicio en la nube gestionado con actualizaciones continuas

Para modelar su arquitectura, explore nuestra Guía de WiFi Multinquilino y nuestras Soluciones de WiFi para el Personal.

Configuración de asignación dinámica de VLAN

La asignación dinámica de VLAN (definida bajo RFC 2868 y RFC 3580) permite que un solo SSID empresarial segmente dinámicamente a los usuarios en distintas subredes de red según su pertenencia a grupos de directorio.

                          [Enterprise Staff SSID]
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
        [VLAN 10: Exec]       [VLAN 20: Engineering]  [VLAN 30: Contractors]
        (10.10.10.0/24)        (10.10.20.0/24)        (10.10.30.0/24)

Atributos RADIUS estándar requeridos

Cuando el servidor RADIUS valida las credenciales, añade estos atributos a la respuesta Access-Accept:

Tunnel-Type = 13 (VLAN)
Tunnel-Medium-Type = 6 (802 - incluye todos los medios 802 además del formato canónico de Ethernet)
Tunnel-Private-Group-ID = 20 (o nombre de VLAN "CORP_ENG")

Ejemplo de mapeo dinámico de VLAN en FreeRADIUS

En /etc/freeradius/3.0/users:

DEFAULT Group == "Engineering-Team"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "20"

DEFAULT Group == "Contractors"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "30"

Reglas de firewall de red y configuración de puertos

Asegúrese de que los firewalls de red permitan la comunicación entre los puntos de acceso y los servidores RADIUS:

Protocolo	Número de Puerto	Descripción	Origen	Destino
UDP	`1812`	Autenticación RADIUS (RFC 2865)	Puntos de Acceso / WLC	Servidor RADIUS
UDP	`1813`	Contabilidad RADIUS (RFC 2866)	Puntos de Acceso / WLC	Servidor RADIUS
TCP	`2083`	RadSec - RADIUS sobre TLS (RFC 6614)	Puntos de Acceso / WLC	Cloud RADIUS
UDP	`1645` / `1646`	Autenticación / Contabilidad RADIUS heredada (Obsoleto)	Dispositivos NAS heredados	Servidor RADIUS

Fortalecimiento de seguridad y mitigación de BlastRADIUS

Mitigación de BlastRADIUS (CVE-2024-3596)

En julio de 2024, unos investigadores revelaron BlastRADIUS, una vulnerabilidad de colisión MD5 en el protocolo RADIUS que permite a un atacante posicionado entre el punto de acceso y el servidor RADIUS falsificar respuestas Access-Accept.

Para proteger su implementación:

Forzar Message-Authenticator: Requiera el atributo Message-Authenticator (RFC 2869) en todos los paquetes Access-Request y Access-Accept.
Transición a EAP-TLS: El uso de EAP-TLS basado en certificados es criptográficamente inmune a la falsificación de proxy porque las claves criptográficas TLS se derivan de extremo a extremo entre el cliente y el servidor RADIUS.
Implementar RadSec (RFC 6614): Encapsule el tráfico RADIUS dentro de túneles TLS para evitar la manipulación de paquetes por intermediarios (man-in-the-middle).

Solución de problemas de fallas de autenticación de 802.1X

Síntoma del error	Causa raíz	Solución técnica
El cliente recibe una falla de conexión de inmediato	Discrepancia de secreto compartido entre el AP y el servidor RADIUS	Verifique la cadena de secreto compartido en el controlador del AP y en la configuración de RADIUS.
Tiempo de espera de autenticación agotado tras 10 a 15 segundos	El firewall está bloqueando el puerto UDP 1812 o falta el enrutamiento	Verifique las ACL del firewall y confirme que el AP pueda hacer ping a la IP del servidor RADIUS a través de la VLAN de administración.
Registro de RADIUS: "CA desconocida" o "Certificado no confiable"	Al cliente o al servidor RADIUS les falta el certificado de la CA raíz	Instale los certificados de la CA raíz e intermedia en el almacén de confianza del cliente y en el directorio de certificados del servidor RADIUS.
El cliente se autentica pero recibe una IP APIPA (169.254.x.x)	El ID de VLAN dinámica no existe en el puerto troncal del switch del AP	Verifique que la configuración troncal del switch transporte el ID de VLAN de destino especificado en Tunnel-Private-Group-ID.
Registro de RADIUS: "Falta Message-Authenticator"	El cliente NAS no es compatible con RFC 2869 o requiere una actualización de firmware	Actualice el firmware del controlador del AP o habilite la aplicación de Message-Authenticator en el perfil del NAS.

Preguntas frecuentes

¿Qué puerto utiliza un servidor RADIUS para la autenticación de WiFi?

La autenticación RADIUS estándar opera en el puerto UDP 1812, y el registro de actividad (accounting) en el puerto UDP 1813. Las implementaciones heredadas utilizaban los puertos UDP 1645 y 1646. Las implementaciones modernas de Cloud RADIUS utilizan RadSec sobre el puerto TCP 2083 con cifrado TLS.

¿Debería elegir FreeRADIUS o Windows Server NPS?

Elija Windows Server NPS si su organización depende estrictamente de Active Directory Domain Services de forma local. Elija FreeRADIUS para obtener un alto rendimiento, flexibilidad de código abierto y entornos Linux. Si su organización utiliza proveedores de identidad en la nube como Microsoft Entra ID o Google Workspace, elija Cloud RADIUS.

¿Cómo conecto Microsoft Entra ID (Azure AD) a un servidor RADIUS?

Microsoft Entra ID no admite de forma nativa los protocolos de autenticación heredados LDAP o NTLM de forma local. Para conectar Entra ID a la red WiFi empresarial, implemente Cloud RADIUS junto con la implementación de certificados Microsoft Intune SCEP para autenticar los dispositivos finales mediante EAP-TLS.

¿Por qué se prefiere EAP-TLS sobre PEAP-MSCHAPv2?

EAP-TLS utiliza autenticación mutua de certificados X.509, donde tanto el cliente como el servidor validan las identidades criptográficas. PEAP-MSCHAPv2 depende de contraseñas de usuario dentro de un túnel TLS, lo que deja a las redes vulnerables a ataques de pulverización de contraseñas (password spraying), phishing y robo de credenciales mediante puntos de acceso falsos.

Para obtener una arquitectura de seguridad de WiFi empresarial a la medida, consulte nuestra Guía de analítica de WiFi o hable con un especialista en redes empresariales.

Definiciones clave

RADIUS (RFC 2865)

Remote Authentication Dial-In User Service. Un protocolo de red cliente - servidor que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA).

Funciona como el servidor de autenticación que valida las credenciales de dispositivos y usuarios enviadas a través de los puntos de acceso inalámbricos.

IEEE 802.1X

Un estándar de la IEEE para el Control de Acceso a Redes Basado en Puertos (PNAC) que proporciona autenticación protegida para dispositivos que intentan conectarse a una LAN o WLAN.

Define la encapsulación de tramas EAP entre el suplicante (dispositivo terminal) y el autenticador (punto de acceso).

EAP-TLS (RFC 5216)

Extensible Authentication Protocol - Transport Layer Security. Protocolo de autenticación mutua basado en certificados donde tanto el servidor RADIUS como el cliente validan certificados digitales.

El método de autenticación estándar de la industria para WiFi de confianza cero (zero-trust) empresarial, el cual elimina el uso de contraseñas.

RadSec (RFC 6614)

RADIUS sobre TLS. Un estándar que encapsula los paquetes tradicionales UDP de RADIUS dentro de túneles seguros TLS en el puerto TCP 2083.

Protege el tráfico de autenticación RADIUS que atraviesa enlaces WAN públicos no confiables entre los puntos de acceso locales y los servidores Cloud RADIUS.

Dynamic VLAN Assignment (RFC 3580)

Un mecanismo de RADIUS que devuelve IDs de VLAN en las respuestas Access-Accept según el rol del usuario o el estado de seguridad del dispositivo.

Permite que un único SSID empresarial asigne dinámicamente a los usuarios a segmentos de red aislados.

Ejemplos resueltos

Un ingeniero de redes necesita configurar FreeRADIUS para autenticar clientes inalámbricos que se conectan a través de 12 puntos de acceso Cisco Catalyst en la subred 10.20.0.0/24 con la clave secreta compartida SecretAuthKey2026. ¿Qué configuración debe colocarse en clients.conf?

client branch_aps { ipaddr = 10.20.0.0/24 secret = SecretAuthKey2026 nas_type = cisco require_message_authenticator = yes }

Comentario del examinador: Definir un alcance de subred completo en clients.conf simplifica la adición de puntos de acceso. Establecer require_message_authenticator = yes mitiga los ataques de falsificación BlastRADIUS (CVE-2024-3596).

¿Cómo debe actualizarse la infraestructura RADIUS para admitir la autenticación WiFi sin contraseña sin mantener controladores de dominio locales, en un departamento de TI que está migrando 2,000 laptops corporativas con Windows 11 desde Active Directory hacia Microsoft Entra ID e Intune?

Implementar Cloud RADIUS con integración nativa de Microsoft Entra ID. 2. Configurar perfiles de certificados SCEP o PKCS en Microsoft Intune para emitir automáticamente certificados de cliente a las laptops administradas. 3. Configurar el controlador inalámbrico para dirigir la autenticación 802.1X al servidor Cloud RADIUS utilizando RadSec (puerto TLS 2083). 4. Imponer EAP-TLS como el método de autenticación principal en el perfil de configuración WiFi de Intune.

Comentario del examinador: Debido a que Microsoft Entra ID no expone puntos de conexión nativos de NTLM o Kerberos para el protocolo heredado PEAP-MSCHAPv2, la opción de EAP-TLS basada en certificados combinada con Cloud RADIUS es la ruta de migración empresarial recomendada.

Preguntas de práctica

Q1. Durante un despliegue de 802.1X inalámbrico, los dispositivos cliente se conectan y se autentican con éxito, pero reciben una dirección IP en la VLAN nativa predeterminada en lugar de la VLAN corporativa asignada. ¿Qué atributos de RADIUS debe devolver el servidor?

Sugerencia: Revise los atributos de túnel de RFC 2868 y RFC 3580.

Ver respuesta modelo

El servidor RADIUS debe devolver tres atributos específicos en la respuesta Access-Accept: 1. Tunnel-Type = 13 (VLAN), 2. Tunnel-Medium-Type = 6 (802), 3. Tunnel-Private-Group-ID = [VLAN_ID_o_Nombre]. El puerto de switch del punto de acceso también debe estar configurado como puerto troncal (trunk) para transportar esa VLAN.

Q2. ¿Cuál es el riesgo de seguridad al implementar PEAP-MSCHAPv2 en redes BYOD sin imponer el certificado de la CA raíz del servidor RADIUS en los dispositivos cliente?

Sugerencia: Considere los ataques de punto de acceso no autorizado y de gemelo malvado (evil twin).

Ver respuesta modelo

Si los dispositivos clientes no validan el certificado del servidor RADIUS, un atacante puede implementar un punto de acceso falso que transmita el mismo SSID. Cuando el cliente se conecta, el servidor falso captura el saludo de desafío y respuesta de MS-CHAPv2, lo que permite al atacante descifrar la contraseña fuera de línea con herramientas como asleap.

Q3. ¿Qué puertos de firewall deben estar abiertos entre un punto de acceso inalámbrico local y un servidor RADIUS en la nube cuando se utiliza RadSec en comparación con el RADIUS estándar?

Sugerencia: Compare los puertos UDP heredados con el RADIUS moderno encapsulado en TLS.

Ver respuesta modelo

RADIUS estándar requiere el puerto de salida UDP 1812 (autenticación) y el puerto UDP 1813 (contabilidad). RadSec requiere el puerto de salida TCP 2083 con cifrado TLS, lo que proporciona una validación de certificados mutua y elimina la transmisión UDP en texto plano a través de la internet pùblica.

Continúe leyendo esta serie

Resolución de problemas de 802.1X en iOS y macOS: una lista de verificación de implementación para Intune, Jamf y Microsoft Entra ID

Use esta lista de verificación para diagnosticar por qué los iPhones, iPads y Macs fallan al conectarse a 802.1X en Intune o Jamf Pro. Cada falla se debe a una de cuatro causas: confianza en el servidor, certificado de identidad, modo de macOS o alcance de grupo de Microsoft Entra ID. Confirmará la causa mediante los registros de eapolclient y RADIUS, aplicará la solución y programará las futuras rotaciones de certificados.

Confianza en servidor de perfil de WiFi de Intune: nombres de servidor de certificado y lista de verificación de CA raíz para Microsoft Entra ID

Podrá configurar la parte de validación de servidor de un perfil de WiFi de Intune para que EAP-TLS y PEAP se conecten en Windows, Apple y Android. Hará coincidir los nombres de servidor de certificado con el certificado RADIUS, implementará la CA raíz correcta, alineará las asignaciones de grupos de Microsoft Entra ID y programará las renovaciones de certificados antes de que interrumpan las conexiones de forma silenciosa.

Resolución de problemas de Android 802.1X y EAP-TLS: una lista de verificación de implementación para Intune y Microsoft Entra ID

Podrá identificar con precisión por qué los teléfonos Android administrados fallan al usar EAP-TLS en su SSID de personal y solucionarlo en Intune. Relacione cada síntoma con las cuatro causas habituales: falta de CA o dominio, certificado de cliente en el perfil incorrecto, un valor de nombres de servidor RADIUS no coincidente o una raíz de confianza no entregada. Luego, aplique una lista de verificación de implementación que evite interrupciones repetidas.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.

First name *

Last name *

Company name *

Business email *

Phone number

Country *

What product are you interested in?

Anything you'd like us to know?