Cómo probar la autenticación RADIUS paso a paso
Published
Está en una ubicación con un ordenador portátil, un punto de acceso y un servidor RADIUS que «ya debería estar bien». Alguien hizo un ping. El puerto UDP 1812 está abierto. Incluso una verificación del panel de control dio resultado positivo. Nada de eso le indica si el dispositivo de un empleado acaba en la red VLAN de empleados, o si un certificado revocado sigue obteniendo una sesión.
Cómo probar la autenticación de RADIUS es una cadena de demostraciones, no un único inicio de sesión. Trate cada Access-Accept como una hipótesis. Todavía debe verificar el método, los atributos, la dirección de origen y el comportamiento de la red cuando el servidor, el directorio o el certificado fallan.
Comience con una solicitud controlada. A continuación, amplíe los casos de prueba hasta que un falso positivo no tenga dónde esconderse.
Índice de contenidos
- Envíe su primera prueba con radtest
- Por qué Access-Accept no demuestra el acceso a la red
- Casos de prueba que toda implementación de RADIUS necesita
- Mida la carga y la latencia con radclient
- Rutas de fallo, conmutación por error y comprobaciones de seguridad
- Lea los registros para confirmar el resultado de cada prueba
- Decida cuándo RADIUS está listo para el despliegue
Envíe su primera prueba con radtest
El comando que puede ejecutar en los próximos cinco minutos es radtest testing password 127.0.0.1 0 testing123. El manual de radtest de FreeRADIUS define esto como un Access-Request controlado con cinco entradas: nombre de usuario, contraseña, dirección del servidor, NAS-Port y secreto compartido. PAP es la opción predeterminada. La misma utilidad también puede enviar CHAP, MS-CHAP o EAP-MD5.
Ejecute la línea base antes de cambiar cualquier otra cosa
- Defina una cuenta de prueba. Introduzca un nombre de usuario y una contraseña conocidos donde el servidor pueda encontrarlos. Es preferible una credencial que pueda escribir sin necesidad de buscar en un directorio.
- Enumere el cliente. El host o NAS desde el que realiza el envío debe figurar en
clients.confcon el secreto que vaya a escribir. Un origen desconocido es un fallo diferente a una contraseña errónea. - Inicie el servidor en modo de depuración. Cada paquete y motivo de rechazo debe mostrarse en la terminal. Un fallo silencioso arruina la ejecución.
- Envíe las cinco entradas. Nombre de usuario, contraseña, servidor, NAS-Port, secreto. Un NAS-Port de
0es suficiente para esta primera comprobación. - Lea el código y, a continuación, el motivo. Access-Accept significa que el servidor ha aprobado esas credenciales. Access-Reject significa que las ha denegado. La salida de depuración permite diferenciar entre un secreto compartido incorrecto, un cliente desconocido, credenciales no válidas y un fallo de directiva.
- Repita desde el NAS. Envíe la misma solicitud desde la dirección del punto de acceso o del conmutador, no solo desde localhost. Por lo general, los clientes se autorizan combinando la dirección de origen y el secreto compartido.
La alcanzabilidad no es el resultado final. El paquete tiene que llegar y la decisión de autorización debe ser la esperada. Tras una aceptación, inspeccione los atributos devueltos, tales como VLAN, el tipo de servicio o la dirección asignada. Una aceptación que indique una VLAN incorrecta no es válida, incluso si el código parece correcto.
Tras esa aceptación básica, el mismo manual enumera ocho métodos que pueden funcionar para la cuenta del ejemplo: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC y EAP-MD5. No intente abarcar los ocho hoy mismo.
Regla práctica: Guarde un Access-Accept de la dirección NAS real y un Access-Reject de una contraseña incorrecta. Esas dos notas son la referencia con la que se juzgará cualquier caso posterior.
Por qué Access-Accept no demuestra el acceso a la red
Una prueba de infraestructura en verde es el falso positivo que yo no daría por bueno. A menudo solo muestra que alguna solicitud obtuvo algún tipo de respuesta.
La guía de resolución de problemas de Meraki RADIUS indica que la prueba de su panel de control utiliza PEAP con MS-CHAPv2. Dicha prueba falla, o no proporciona una validación significativa, para EAP-TLS, porque el punto de acceso no tiene un certificado de cliente. La red inalámbrica basada en certificados debe probarse con un suplicante real que posea el certificado y la cadena de confianza adecuados.
Cuatro capas, cuatro preguntas diferentes
Transporte pregunta si algo ha respondido. Un tiempo de espera agotado no es un rechazo.
La autenticación comprueba si la contraseña o el certificado eran válidos para esa identidad.
La autorización comprueba si la respuesta contenía la VLAN, el rol o la ACL que pretendía enviar.
La alcanzabilidad cuestiona si el punto de conexión obtuvo la dirección esperada, la directiva DNS y el acceso a los recursos que ese segmento debería permitir.
Una prueba superada en una capa no garantiza nada sobre las otras tres. La misma guía de Meraki, leída junto con el comportamiento de FreeRADIUS EAP, describe una prueba exitosa de EAP-TLS como un intercambio multipaquete de Access-Request y Access-Challenge, seguido del acceso a la red del cliente real. Una simple prueba de conectividad no constituye esa verificación.
Compruebe el nombre de servidor en el que confía el suplicante, la cadena de CA, el vencimiento del certificado y el reloj del dispositivo. El desvío del reloj hace que falle un certificado correcto. Supongamos que el portátil de un empleado se autentica y luego se ubica en la VLAN predeterminada en lugar de en el segmento de empleados. El Accept era auténtico, pero la ubicación en la red era incorrecta. Ese es el fallo que la mayoría de las listas de comprobación nunca registran.
Mantenga filas separadas para usuarios con contraseña, dispositivos EAP-TLS, identidades xPSK y directivas dirigidas por directorio. Una aceptación PAP no debe sustituir a la incorporación de un certificado.
Pruebe EAP-TLS en un dispositivo de repuesto
- Emita un certificado cliente de prueba desde la misma CA en la que confía el servidor.
- Instale el certificado y la cadena de CA en un portátil o teléfono de repuesto.
- Confirme que el suplicante valida el nombre de servidor que configuró.
- Conéctese y capture el intercambio de desafío, no un sondeo de un solo paquete.
- Confirme que la sesión finaliza en la VLAN esperada con acceso real a la red.
Una vista breve de ese intercambio facilita el reconocimiento de la captura cuando su propia traza contiene demasiado ruido.
Casos de prueba necesarios en toda implementación de RADIUS
Una credencial válida puede generar un Access-Accept mientras el usuario termina en la red equivocada. Pruebe cada capa por separado: gestión de solicitudes, autenticación, atributos de autorización y el acceso real del extremo. La guía de pruebas de rendimiento de FreeRADIUS cubre tanto la carga como la corrección. Incluya también casos negativos: las credenciales no válidas deben devolver un Access-Reject, mientras que las solicitudes mal formadas, un NAS no reconocido y un secreto compartido incorrecto no deben generar un inicio de sesión correcto.
El flujo de trabajo de radtest está plenamente consolidado y sigue utilizando las mismas cinco entradas. Para los métodos con túnel, pruebe el servidor de autenticación interno por separado en el puerto UDP 18120. Utilice una prueba interna de MS-CHAP cuando el método externo sea PEAP. Esto ayuda a aislar si el fallo se encuentra en el intercambio EAP externo, en la configuración del certificado o TLS, o bien en la comprobación de credenciales interna.
Un Access-Accept es una hipótesis que se debe verificar, no una prueba de un acceso a la red correcto. La guía de implementación de FreeRADIUS describe cómo un NAS puede descartar un atributo VLAN no compatible o asignar uno faltante a una VLAN predeterminada. Compruebe los atributos devueltos y, a continuación, verifique la dirección del punto final, la VLAN, la ACL, la directiva DNS y la alcanzabilidad. EAP-MD5 no proporciona el material de clave que la red inalámbrica necesita, por lo que una aceptación de EAP-MD5 no es prueba de disponibilidad para la red inalámbrica. Utilícela solo para pruebas limitadas por cable.
Determine los segmentos previstos antes de ejecutar las pruebas de autorización; el WiFi control de acceso explica cómo estructurar esa directiva.
Nueve filas que constituyen el mínimo requerido
| Caso de prueba | Cómo ejecutarlo | Resultado esperado |
|---|---|---|
| Aceptación básica | Ejecute radtest con una cuenta de prueba válida desde la IP del NAS |
Access-Accept con el atributo VLAN esperado; confirme que el punto de extremo aterriza en esa VLAN |
| Contraseña incorrecta | Ejecute radtest con una contraseña incorrecta |
Access-Reject con un motivo registrado |
| Secreto compartido incorrecto | Envíe desde un cliente configurado con un secreto no coincidente | Sin Access-Accept; error de secreto visible en la salida de depuración |
| NAS desconocido | Envíe desde una dirección IP no definida como cliente | Descartado o rechazado y registrado |
| Dispositivo EAP-TLS válido | Conecte un suplicante real con un certificado válido y una cadena de confianza | Access-Accept y la VLAN correcta para su grupo; confirme el acceso a la red desde el dispositivo |
| Certificado caducado o revocado | Conecte un dispositivo con un certificado caducado o revocado | Access-Reject, sin alternativa a una red predeterminada |
| Cambio de grupo de directorio | Mueva el usuario de prueba a otro grupo y vuelva a autenticarlo | La VLAN o el rol cambia para coincidir con el nuevo grupo, o se deniega el acceso |
| Servidor primario no disponible | Bloquee el puerto UDP 1812 hacia el primario o deténgalo | Conmutación por error al secundario dentro del tiempo de espera, aplicando la misma directiva |
| Inicio y fin de contabilidad (Accounting) | Inicie una sesión y luego finalícela | Los registros de inicio y fin coinciden con la sesión |
Para cada fila, registre la llegada de la solicitud, el código de respuesta, la latencia de ida y vuelta, la directiva seleccionada, los atributos devueltos y el inicio y fin de contabilidad. Repita cada prueba para detectar posibles pérdidas intermitentes de UDP. Una sola ejecución limpia puede pasar por alto una VLAN incorrecta o una decisión de directiva incoherente.
Una aceptación que ubique al cliente en la red incorrecta se considera una prueba fallida.
Mida la carga y la latencia con radclient
Un accept silencioso oculta la formación de colas. Las pruebas de volumen requieren una herramienta diseñada para procesamiento por lotes, no otro inicio de sesión individual.
- Cree un archivo de autenticación con nombres de usuario y contraseñas aleatorios. Mezcle entradas válidas y no válidas para que los rechazos se contabilicen y no se traten como ruido.
- Envíe el archivo y mida el tiempo del lote con el comando
timede Unix mientrasradclientejecuta el servidor. - Registre los recuentos sin procesar. Solicitudes totales, aceptaciones, rechazos, tiempos de espera agotados, respuestas de error y tiempo transcurrido.
- Calcule las tasas. La tasa de aceptación debe coincidir con la proporción válida del archivo. La tasa de rechazo debe coincidir con la proporción no válida. Tome también la latencia media y de percentil.
- Repita el proceso en la hora punta. El registro de entrada por la mañana o el inicio de la jornada escolar mostrarán colas de espera que una prueba de laboratorio a la hora del almuerzo nunca mostrará.
| Métrica | Cómo calcularla | Objetivo |
|---|---|---|
| Solicitudes totales | Recuento de líneas enviadas desde el archivo de autenticación | Igual a la longitud del archivo |
| Tasa de aceptación | Aceptaciones divididas por solicitudes totales | Coincide con la proporción válida del archivo |
| Tasa de rechazo | Rechazos divididos por solicitudes totales | Coincide con la proporción no válida del archivo |
| Tiempos de espera agotados y errores | Recuento de respuestas de error y sin respuesta en la ejecución | Cero en una ruta limpia |
| Latencia media | Tiempo de respuesta medio en todas las solicitudes | Dentro de su objetivo de latencia en horas punta |
| Tiempo transcurrido | Salida de tiempo Unix para el lote completo | Estable en repeticiones de ejecución |
Separe el túnel del almacén de cuentas
Si la tasa de aceptación es inferior a la cuota válida, no atribuya la culpa a la "carga" hasta que sepa qué mitad ha fallado. Para PEAP, pruebe el método interno por separado con una solicitud MS-CHAP contra el servidor interno. Una aceptación interna con una unión externa con fallos apunta a certificados o ajustes TLS. Un intercambio de señales externo que se interrumpe en la comprobación interna apunta al depósito de cuentas, al hash de la contraseña o al grupo que espera la directiva.
Guarde estos tiempos en el mismo registro que los resultados funcionales. Cualquier cambio posterior de firmware o directorio debe compararse con esa referencia, no con la sensación de que "parecía más lento".
Si los tiempos de espera aumentan solo en momentos de máxima actividad, corrija la capacidad o la ruta antes de añadir sedes. Un servidor correcto pero lento seguirá fallando ante clientes que desistan primero.
Rutas de fallo, conmutación por error y comprobaciones de seguridad
Un intercambio operativo aún puede ser inseguro. La resolución de problemas que únicamente pregunta si el puerto UDP 1812 obtuvo respuesta se detiene demasiado pronto.
El boletín de seguridad de 2025 de Juniper describe la exposición a Blast-RADIUS en el Response Authenticator del RFC 2865. Un atacante local capaz de modificar el tráfico podría convertir potencialmente una respuesta válida en otra mediante una colisión de prefijo elegido de MD5. Un mensaje de "Autenticación correcta" no es prueba de que el despliegue esté protegido.
Comprobaciones que deben incluirse en la misma ejecución que la conmutación por error
Proteja la ruta donde la plataforma lo permita. Confirme que se ha bloqueado la manipulación en la ruta y que la validación de Message-Authenticator se aplique obligatoriamente en los paquetes que la requieran.
Desactive los métodos débiles. Los tipos de EAP obsoletos deben deshabilitarse, no dejarse «por si acaso». Si aún está eligiendo entre métodos externos de certificado y de contraseña, compárelos en EAP-TLS frente a PEAP antes de dejarlos ambos habilitados.
Fuerce un fallo en el servidor a propósito. Cada uno de los escenarios siguientes debe mostrar la conmutación por error segura prevista o la alternativa controlada, además de una línea de registro, una alerta y una experiencia de usuario que pueda explicar a un responsable de las instalaciones.
| Escenario de fallo | Cómo activarlo | Condición de aprobación |
|---|---|---|
| Tiempo de espera agotado | Bloquear UDP 1812 hacia el servidor | Fallo seguro o alternancia controlada, registrado y con alerta emitida |
| Access-Reject | Utilizar una contraseña incorrecta | Acceso denegado sin red de alternancia |
| Certificado caducado | Dispositivo con un certificado caducado | Access-Reject sin VLAN predeterminada |
| Certificado revocado | Dispositivo con un certificado revocado | Access-Reject sin VLAN predeterminada |
| IP de origen NAS desconocida | Enviar desde una dirección no definida | Descartado o rechazado y registrado |
| Secreto compartido incorrecto | Secreto no coincidente en el cliente | Sin Access-Accept y con error de secreto en la salida de depuración |
| Directorio no accesible | Detener la conectividad con el directorio | Rechazado o alternancia controlada según la directiva |
| Respuesta de autorización retrasada | Añadir retraso a la respuesta de autorización | Tiempo de espera gestionado sin acceso abierto |
Lo que la conmutación por error regional debe preservar
Que responda otro servidor no significa que haya coherencia en las directivas. Al detener el servidor secundario, compare la VLAN, los límites de ancho de banda, el estado de revocación y los atributos de auditoría de la copia de seguridad con los del primario. Un invitado que conmuta por error a un segmento de empleados se considera una prueba fallida, aunque la conexión haya sido rápida.
Marque como fallido cualquier escenario que recurra a un acceso abierto, independientemente de si el usuario consigue conectarse o no. Escriba cada resultado en el mismo registro de pruebas que la referencia funcional para que cualquier cambio posterior en la conmutación por error resulte evidente.
Lea los registros para confirmar el resultado de cada prueba
Cada prueba debe dejar un rastro que pueda vincular a un ID de prueba o a una cuenta conocida. En una infraestructura con mucha actividad, esa etiqueta es la forma de encontrar su ejecución sin tener que desplazarse por el registro de toda la mañana del resto del equipo.
Para cada autenticación, alinee estos campos:
- Identidad y dispositivo: quién o qué se ha unigo, no solo una MAC que espera que sea suya.
- Método: EAP-TLS, PEAP o una PSK individual. Un método que no haya desplegado constituye un hallazgo.
- Lugar: punto de acceso, SSID y sede.
- Decisión: VLAN y rol devuelto, o el motivo de rechazo.
- Hora: marca de tiempo que se encuentre dentro del intervalo probado.
Nuestro registro de autenticación está diseñado para ese tipo de coincidencia. Una sola consulta en todas las instalaciones muestra cada aceptación y rechazo con la identidad, el dispositivo, el estado de inscripción, el método, el punto de acceso, SSID, el sitio, VLAN, el rol, el motivo y las marcas de tiempo. Utilícelo cuando un sitio tenga varios puntos de acceso y necesite comprobar si el mismo fallo se produce en todas partes o solo en un controlador.
Tres patrones que indican que las notas son incorrectas
El motivo no coincide con la prueba. Ha enviado una contraseña incorrecta y el registro indica cliente desconocido. Ha probado algo equivocado o se han acumulado dos fallos.
El accept nombra la VLAN por defecto. Las credenciales funcionaron. La asignación, no. No cierre el caso.
Accounting comenzó y nunca se detuvo. El registro de la sesión está incompleto, por lo que no se puede probar que el cliente se haya desconectado cuando usted cree. Compare el inicio y la detención con la sesión que ejecutó, no con la de un usuario cercano.
Configure una alerta para los picos de rechazo durante la ventana de prueba, de modo que un secreto compartido erróneo no parezca un "los usuarios han escrito mal la contraseña". Conserve el extracto de registro junto con las notas de la prueba. Ese extracto es la evidencia de auditoría cuando alguien pregunte, semanas después, qué ha demostrado.
Decida cuándo RADIUS está listo para el despliegue
Inicie la puesta en producción únicamente cuando las pruebas superen cinco controles. La confianza de un ingeniero no es uno de ellos.
- Cada fila de la matriz se supera en cada tipo de NAS que despliegue, incluida cada SSID o directiva de acceso que pretenda conservar.
- La conmutación por error mantiene el mismo comportamiento de VLAN, directiva y revocación que el servidor primario. Un segundo servidor que responda con un rol diferente no superará este control.
- Ningún escenario de fallo deja el acceso abierto. Una contraseña incorrecta, un directorio inactivo, un certificado caducado o una respuesta retrasada no deben dejar al usuario en una red sin restricciones.
- La carga se mantiene dentro de su objetivo de latencia en horas punta, coincidiendo la tasa de aceptación con la proporción válida del archivo de prueba.
- Los registros muestran el motivo esperado y la VLAN para cada ejecución que considere superada.
Detenga la implementación general hasta que estas cinco condiciones se cumplan en un entorno real, no solo en un laboratorio VLAN.
Le permitimos probar esto primero en una sede. Incorpore las nuevas redes abierta, segura y de xPSK en los puntos de acceso que ya utiliza dicha sede, junto a la red que usa hoy en día, y evalúe el resultado en las incidencias y las evidencias de auditoría antes de realizar cambios en cualquier otra sede. Durante esa prueba piloto, el registro debería responder a dos preguntas sin necesidad de celebrar una reunión: qué dispositivos se unieron en qué VLAN y qué motivo de aceptación o rechazo apareció con mayor frecuencia.
Realice ampliaciones únicamente cuando las incidencias y el extracto de auditoría no muestren rechazos inesperados ni dispositivos en el segmento equivocado. Mantenga la matriz como una suite de regresión permanente. Vuelva a ejecutarla tras cada renovación de certificado, actualización de firmware o cambio de directorio, con respecto a la misma línea base, antes de que los usuarios vean el cambio. Para saber cómo debe diseñarse dicho sitio piloto, comience por el WiFidiseño de red de y pruebe el diseño que prevé mantener, no uno temporal SSID que vaya a eliminar la semana que viene.
Purple Access le proporciona RADIUS en la nube que ubica cada dispositivo en la red abierta, segura o de xPSK por identidad, con el VLAN y el motivo de rechazo visibles en el registro de autenticación. Si desea ejecutar ese plan de prueba en los puntos de acceso que ya tiene, comience con una sede y analice el resultado antes de continuar con el despliegue. Visite Purple Access y establezca para la primera sede una línea base que pueda defender.
