Saltar al contenido principal
Español

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 de WiFi empresarial 802.1X. 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
📖 8 min de lectura1,945 palabras2 ejemplos prácticos3 preguntas de práctica5 definiciones clave

Video overview

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 WiFi. Si gestiona un despliegue a gran escala - ya sea una cadena de hoteles, una red de tiendas físicas 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 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 Network Policy Server de Microsoft, o NPS, o FreeRADIUS de código abierto eran el estándar. Ofrecen un control total sobre la infraestructura y no dependen de una conexión externa a Internet 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 un equipo de TI con personal suficiente, este es un enfoque perfectamente válido. Por otro lado, las soluciones de RADIUS en la nube se han vuelto cada vez más populares, especialmente para entornos distribuidos como cadenas de tiendas físicas 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 perfectamente 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 gestione cincuenta o cien ubicaciones, el ahorro operativo de no desplegar y mantener servidores locales en cada sitio casi con seguridad compensará ese coste. Al desplegar RADIUS, el Protocolo de Autenticación Extensible - EAP - es la pieza fundamental. 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 intercepta el intercambio de autenticación, no hay credenciales que robar. Sin embargo, el despliegue de certificados de cliente puede ser administrativamente pesado. Necesita una infraestructura de clave pública y una solución MDM para distribuir 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 estrictamente configurados 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. Esto 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 imponer 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 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 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 durante 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. 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 origen y ofrece análisis sobre el comportamiento de los visitantes, transformando su red de un centro de costes a un activo de inteligencia empresarial. Y ahora, una sesión rápida de preguntas y respuestas. Primera pregunta: ¿necesito un servidor dedicado para RADIUS? En el caso de despliegues locales, sí, se recomienda encarecidamente ejecutarlo en una máquina virtual dedicada en lugar de compartir recursos con un controlador de dominio. La autenticación es un proceso muy sensible a la latencia, y el conflicto de recursos puede causar fallos intermitentes muy difíciles de diagnosticar. Segunda pregunta: ¿puede RADIUS gestionar la autenticación de dispositivos sin interfaz de usuario, como impresoras o sensores IoT? Sí, a través de la omisión de autenticación MAC o MAB. Esto permite autenticar dispositivos sin capacidades 802.1X 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 ubicarse en una VLAN muy restringida. Tercera pregunta: ¿cómo gestiono la redundancia del servidor RADIUS? Despliegue siempre al menos dos servidores RADIUS: uno primario y otro secundario. Configure todos los puntos de acceso para que pasen al secundario si el primario deja de estar accesible. En el caso de 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 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 gestione y su infraestructura de identidad existente. Si su organización está distribuida y prioriza la nube, el RADIUS en la nube es casi con total seguridad la respuesta correcta. Aplique 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 que consulte 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. Muchas gracias por su atención.

Parte de nuestra serie principal: Guía de seguridad de 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 Pre-Shared Keys (PSKs) expone a las organizaciones a filtraciones de credenciales, acceso no autorizado a dispositivos y problemas administrativos cada vez que un empleado se marcha.

La configuración de 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 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, las arquitecturas modernas de Cloud RADIUS, la asignación dinámica de VLAN y el endurecimiento de seguridad frente a BlastRADIUS.

Descripción general de la arquitectura 802.1X y RADIUS

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

  1. El Suplicante (Supplicant): El dispositivo cliente (portátil, smartphone o tablet) que ejecuta el software cliente 802.1X y presenta las credenciales de identidad.
  2. El Autenticador (Authenticator): El punto de acceso (AP) inalámbrico o el controlador de LAN inalámbrica (WLC) que controla el acceso físico a la red y retransmite los mensajes de autenticación.
  3. El Servidor de Autenticación (Authentication Server): 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    |
| (Disp. Cliente)|                                    | (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

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

Para profundizar en los conceptos de arquitectura, explore nuestra Guía de seguridad WiFi empresarial y nuestra Guía de Captive Portal.

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 detalla la secuencia de configuración para Ubuntu 24.04 LTS / Debian 12.

Paso 1: Instalar los paquetes de FreeRADIUS

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

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

Edite /etc/freeradius/3.0/clients.conf para autorizar sus puntos de acceso inalámbricos 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: Aplique siempre los atributos Message-Authenticator de la norma RFC 2869 para protegerse contra los ataques de falsificación BlastRADIUS.

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

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

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: Realizar pruebas en modo depuración

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

sudo systemctl stop freeradius
sudo freeradius -X

Pruebe la autenticación local utilizando radtest:

radtest testuser Password123 127.0.0.1 0 testing123

Una respuesta correcta 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 Windows Server conectados a Active Directory Domain Services (AD DS).

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

Paso 1: Instalar Servicios de acceso y directivas de redes

Abra PowerShell como Administrador:

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

Paso 2: Registrar clientes RADIUS (puntos de acceso)

  1. Abra Servidor de directivas de redes (nps.msc).
  2. Expanda Clientes y servidores RADIUS > Haga clic derecho en Clientes RADIUS > Nuevo.
  3. Introduzca el Nombre descriptivo: Cisco-Catalyst-AP-Cluster.
  4. Introduzca la Dirección IP o Subred CIDR (por ejemplo, 10.50.0.0/24).
  5. Genere e introduzca un Secreto compartido seguro (mínimo de 24 caracteres alfanuméricos).

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

  1. En Directivas > Directivas de red, haga clic derecho y seleccione Nueva.
  2. Nombre de la directiva: Staff-WiFi-802.1X-Policy. Tipo de servidor de acceso a la red: No especificado.
  3. Condiciones:
    • Añada Grupos de Windows: CORP\WiFi-Authorised-Users
    • Añada Tipo de puerto NAS: Inalámbrica - IEEE 802.11 o Inalámbrica - Otra
  4. Permiso de acceso: Seleccione Acceso concedido.
  5. Métodos de autenticación:
    • Desactive los métodos menos seguros.
    • En Tipos de EAP, añada Microsoft: Tarjeta inteligente u otro certificado (EAP-TLS).
    • Edite el método y seleccione el Certificado de servidor RADIUS emitido por su Entidad de certificación (CA) empresarial de Active Directory Certificate Services (AD CS).
  6. Restricciones: Establezca el Tiempo de espera de inactividad en 30 minutos y el Tiempo de espera de sesión en 8 horas.

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

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

Cloud RADIUS: Arquitectura moderna zero-trust

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

  • Elevados costes 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 cortes de WAN en las oficinas sucursales.

Las redes empresariales modernas implementan Cloud RADIUS para centralizar la autenticación con una infraestructura física de servidor local cero.

Característica Windows NPS heredado / FreeRADIUS Arquitectura Cloud RADIUS
Integración de directorio LDAP local / Kerberos Integración nativa con 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 Conmutación por error activa-pasiva manual Redundancia Anycast global multirregión
Mantenimiento Parcheo de sistemas operativos y licencias de SO Servicio en la nube gestionado con actualizaciones continuas

Para diseñar 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 único SSID empresarial segmente dinámicamente a los usuarios en diferentes 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 asignación dinámica 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 cortafuegos de red y configuración de puertos

Asegúrese de que los cortafuegos de red permiten 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 (obsoleta) Dispositivos NAS heredados Servidor RADIUS

Refuerzo 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 despliegue:

  1. Forzar Message-Authenticator: Requiera el atributo Message-Authenticator (RFC 2869) en todos los paquetes Access-Request y Access-Accept.
  2. Transición a EAP-TLS: 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.
  3. Desplegar RadSec (RFC 6614): Encapsular 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 fallos de autenticación 802.1X

Síntoma del error Causa raíz Solución técnica
El cliente recibe un fallo de conexión de forma inmediata Desajuste de secreto compartido entre el AP y el servidor RADIUS Verificar 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 - 15 segundos El cortafuegos está bloqueando el puerto UDP 1812 o falta enrutamiento Verificar las ACL del cortafuegos y confirmar que el AP puede hacer ping a la IP del servidor RADIUS a través de la VLAN de gestión.
Registro de RADIUS: "Unknown CA" o "Certificate Untrusted" Al cliente o al servidor RADIUS les falta el certificado de la CA raíz Instalar 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 trunk del switch del AP Verificar que la configuración de trunk del switch admita el ID de VLAN de destino especificado en Tunnel-Private-Group-ID.
Registro de RADIUS: "Message-Authenticator is missing" El cliente NAS no es compatible con RFC 2869 o carece de actualización de firmware Actualizar el firmware del controlador del AP o habilitar la aplicación de Message-Authenticator en el perfil del NAS.

Preguntas frecuentes

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

La autenticación RADIUS estándar funciona en el puerto UDP 1812, y la contabilidad en el puerto UDP 1813. Las implementaciones heredadas utilizaban los puertos UDP 1645 y 1646. Los despliegues modernos 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, la flexibilidad del 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 es compatible de forma nativa con los protocolos de autenticación heredados LDAP o NTLM locales. Para conectar Entra ID a redes WiFi empresariales, despliegue Cloud RADIUS junto con el despliegue de certificados SCEP de Microsoft Intune para autenticar los endpoints mediante EAP-TLS.

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

EAP-TLS utiliza autenticación de certificados mutuos X.509 donde tanto el cliente como el servidor validan identidades criptográficas. PEAP-MSCHAPv2 se basa en contraseñas de usuario dentro de un túnel TLS, lo que deja a las redes vulnerables al password spraying, al phishing y al robo de credenciales mediante AP no autorizados.

Para una arquitectura de seguridad WiFi empresarial a medida, consulte nuestra Guía de analítica 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 las tramas EAP entre el suplicante (dispositivo final) 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 del sector para WiFi empresarial basado en Zero Trust, que elimina las contraseñas.

RadSec (RFC 6614)

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

Asegura 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.

Asignación dinámica de VLAN (RFC 3580)

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

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

Ejemplos prácticos

¿Cómo debe configurar un ingeniero de redes 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 el secreto compartido 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 el alcance de una subred completa 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).

Un departamento de TI está migrando 2000 portátiles corporativos con Windows 11 de Active Directory a Microsoft Entra ID e Intune. ¿Cómo se debe actualizar la infraestructura RADIUS para admitir la autenticación WiFi sin contraseñas sin mantener controladores de dominio locales?

  1. Implemente Cloud RADIUS con integración nativa con Microsoft Entra ID. 2. Configure los perfiles de certificado SCEP o PKCS de Microsoft Intune para emitir automáticamente certificados de cliente a los portátiles administrados. 3. Configure el controlador inalámbrico para dirigir la autenticación 802.1X al servidor Cloud RADIUS utilizando RadSec (puerto TLS 2083). 4. Aplique EAP-TLS como método de autenticación principal en el perfil de configuración de WiFi de Intune.
Comentario del examinador: Dado que Microsoft Entra ID no expone endpoints nativos de NTLM o Kerberos para el sistema heredado PEAP-MSCHAPv2, el uso de EAP-TLS basado en certificados combinado con Cloud RADIUS es la ruta de migración empresarial recomendada.

Preguntas de práctica

Q1. Durante un despliegue inalámbrico 802.1X, los dispositivos cliente se conectan y se autentican correctamente, pero reciben una dirección IP en la VLAN nativa por defecto en lugar de la VLAN corporativa asignada. ¿Qué atributos 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 del switch del punto de acceso también debe estar configurado como un puerto de enlace (trunk) que transporte dicha VLAN.

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

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

Ver respuesta modelo

Si los dispositivos cliente no validan el certificado del servidor RADIUS, un atacante puede desplegar un punto de acceso no autorizado que emita el mismo SSID. Cuando el cliente se conecta, el servidor no autorizado captura el saludo de desafío-respuesta de MS-CHAPv2, lo que permite al atacante descifrar la contraseña sin conexión utilizando herramientas como asleap.

Q3. ¿Qué puertos de firewall deben estar abiertos entre un punto de acceso inalámbrico local y un servidor Cloud RADIUS al utilizar RadSec frente a un RADIUS estándar?

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

Ver respuesta modelo

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

Continúe leyendo esta serie

Microsoft Cloud PKI para WiFi: despliegue de certificados EAP-TLS con Intune y Microsoft Entra ID

Podrá decidir si Microsoft Cloud PKI, una entidad de certificación (CA) raíz en la nube o su propia CA (BYOCA) se adapta mejor a su infraestructura. A continuación, podrá desplegar certificados WiFi EAP-TLS en dispositivos gestionados por Intune sin necesidad de NDES. La guía también cubre cómo hacer que RADIUS confíe en la cadena, revocar certificados a través de la CRL y solucionar los ocho fallos más comunes.

Leer la guía →

Configuración de 802.1X en Juniper Mist con cloud RADIUS

Podrá configurar una WLAN WPA2 o WPA3-Enterprise en Juniper Mist que se autentique contra cloud RADIUS, decidir entre UDP RADIUS, RadSec y un proxy Mist Edge, y mapear atributos RADIUS a VLANs dinámicas. También sabrá exactamente en qué punto falló una autenticación gracias al cronograma de información sobre clientes de Mist y a Marvis.

Leer la guía →

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

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

Leer la guía →

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

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