Cómo probar la autenticación de RADIUS paso a paso
Published
Usted se encuentra en un sitio con una laptop, un punto de acceso y un servidor RADIUS que "ya debería estar funcionando bien". Alguien realizó un ping. El puerto UDP 1812 está abierto. Incluso una prueba de panel de control respondió correctamente. Nada de eso le indica si un dispositivo del personal se asigna a la VLAN del personal, o si un certificado revocado aún obtiene una sesión.
Cómo probar la autenticación RADIUS es una cadena de demostraciones, no un solo inicio de sesión. Trate cada Access-Accept como una hipótesis. Aún 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 son incorrectos.
Comience con una solicitud controlada. Luego amplíe los casos hasta que una falsa aprobación no tenga dónde ocultarse.
Tabla de contenido
- Envíe su primera prueba con radtest
- Por qué Access-Accept no demuestra el acceso a la red
- Casos de prueba que requiere toda implementación de RADIUS
- Mida la carga y la latencia con radclient
- Rutas de falla, conmutación por error y comprobaciones de seguridad
- Lea los registros para confirmar cada resultado de 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 lo define 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. Coloque un nombre de usuario y una contraseña conocidos donde el servidor pueda encontrarlos. Necesita una credencial que pueda escribir sin tener que buscar en un directorio.
- Enumere el cliente. El host o NAS desde el que envía debe estar en
clients.confcon el secreto que escribirá. Un origen desconocido representa una falla diferente a una contraseña incorrecta. - Inicie el servidor en modo de depuración. Cada paquete y motivo de rechazo debe imprimirse en la terminal. Una falla silenciosa echa a perder la prueba.
- Envíe las cinco entradas. Nombre de usuario, contraseña, servidor, NAS-Port y secreto. Un NAS-Port de
0es suficiente para esta primera comprobación. - Lea el código y luego el motivo. Access-Accept significa que el servidor aprobó esas credenciales. Access-Reject significa que las rechazó. La salida de depuración permite diferenciar entre un secreto compartido incorrecto, un cliente desconocido, credenciales no válidas y una falla de directiva.
- Repita el proceso desde el NAS. Genere la misma solicitud desde la dirección del punto de acceso o del switch, 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 debe llegar y la decisión de autorización debe ser la esperada. Ante una respuesta de aceptación, inspeccione los atributos devueltos, tales como VLAN, el tipo de servicio o la dirección delimitada. Una aceptación que asigna la VLAN incorrecta no es una prueba superada, incluso si el código parece correcto.
Después de esa aceptación básica, el mismo manual enumera ocho métodos que pueden funcionar para la cuenta de ejemplo: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC y EAP-MD5. No intente probar los ocho hoy.
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 línea base con la que se juzga cada caso posterior.
Por qué Access-Accept no demuestra el acceso a la red
Una prueba de infraestructura en verde es la falsa aprobación que yo no daría por buena. A menudo solo muestra que alguna solicitud obtuvo alguna respuesta.
La guía de resolución de problemas de Meraki RADIUS indica que la prueba de su panel utiliza PEAP con MS-CHAPv2. Esa prueba falla, o no proporciona una validación significativa, para EAP-TLS, porque el punto de acceso no tiene un certificado de cliente. El WiFi basado en certificados se debe probar con un suplicante real que posea el certificado y la cadena de confianza correctos.
Cuatro capas, cuatro preguntas diferentes
Transporte pregunta si algo respondió. El tiempo de espera agotado no es un rechazo.
La autenticación verifica si la contraseña o el certificado eran válidos para esa identidad.
La autorización verifica si la respuesta incluyó el VLAN, el rol o la ACL que usted pretendía enviar.
Alcanzabilidad evalúa si el punto final obtuvo la dirección esperada, la directiva de 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, analizada 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 real a la red por parte del cliente. Una sola prueba de conectividad no constituye dicha evaluación.
Verifique 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 de reloj hace fallar a un buen certificado. Supongamos que una laptop del personal se autentica y luego se ubica en la VLAN predeterminada en lugar del segmento del personal. La aceptación fue genuina. La ubicación en la red fue incorrecta. Ese es el error que la mayoría de las listas de verificación nunca registran.
Mantenga filas separadas para usuarios con contraseña, dispositivos EAP-TLS, identidades xPSK y directivas impulsadas por el directorio. Una aceptación PAP no debe sustituir la incorporación por certificado.
Pruebe EAP-TLS en un dispositivo de repuesto
- Emita un certificado de cliente de prueba desde la misma CA en la que confía el servidor.
- Instale el certificado y la cadena de CA en una laptop o teléfono de repuesto.
- Confirme que el suplicante valide 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 finalice en la VLAN esperada con acceso a la red real.
Una vista breve de ese intercambio facilita reconocer la captura cuando su propio rastreo presente ruido.
Casos de prueba que toda implementación de RADIUS necesita
Una credencial válida puede generar un Access-Accept mientras el usuario termina en la red equivocada. Pruebe cada capa por separado: el manejo de solicitudes, la autenticación, los atributos de autorización y el acceso real del punto de conexión. La guía de pruebas de rendimiento de FreeRADIUS cubre tanto la carga como la precisión. Incluya también casos negativos: las credenciales no válidas deben devolver Access-Reject, mientras que las solicitudes malformadas, un NAS no reconocido y un secreto compartido incorrecto no deben generar un inicio de sesión exitoso.
El flujo de trabajo radtest se utiliza desde hace mucho tiempo y sigue empleando las mismas cinco entradas. Para 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 PEAP sea el método externo. Esto ayuda a aislar si la falla se encuentra en el intercambio EAP externo, en la configuración de certificados o TLS, o en la verificación interna de credenciales.
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 mapear uno faltante a un VLAN predeterminado. Verifique los atributos devueltos, luego confirme la dirección del punto de conexión, la VLAN, la ACL, la política de 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 evidencia de preparación inalámbrica. Utilícelo solo para pruebas cableadas limitadas.
Decida los segmentos previstos antes de realizar las pruebas de autorización; el WiFi control de acceso explica cómo estructurar esa directiva.
Nueve filas que cuentan como el mínimo
| Caso de prueba | Cómo ejecutarlo | Resultado esperado |
|---|---|---|
| Aceptación inicial | 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 se ubica en esa VLAN |
| Contraseña incorrecta | Ejecute radtest con una contraseña incorrecta |
Access-Reject con un motivo registrado en la bitácora |
| Secreto compartido incorrecto | Envíe la solicitud 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 la solicitud desde una dirección IP no definida como cliente | Descartado o rechazado y registrado en la bitácora |
| Dispositivo EAP-TLS válido | Conecte un suplicante real con un certificado válido y una cadena de confianza | Access-Accept y el VLAN correcto para su grupo; confirme el acceso a la red desde el dispositivo |
| Certificado expirado o revocado | Conecte un dispositivo con un certificado expirado o revocado | Access-Reject, sin alternancia hacia una red predeterminada |
| Cambio de grupo en el directorio | Mueva al usuario de prueba a otro grupo y vuelva a autenticarlo | El 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 la contabilidad. Repita cada prueba para detectar pérdidas intermitentes de UDP. Una sola ejecución limpia puede omitir un VLAN incorrecto o una decisión de directiva inconsistente.
Una aceptación que ubique al cliente en la red equivocada se considera una prueba fallida.
Mida la carga y la latencia con radclient
Una aceptación silenciosa oculta la saturación de la cola. Las pruebas de volumen necesitan una herramienta creada para lotes, no otro inicio de sesión individual.
- Genere un archivo de autenticación de nombres de usuario y contraseñas aleatorios. Combine 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 de Unix
timemientrasradclientimpulsa el servidor. - Registre los conteos brutos. 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. También obtenga la latencia promedio y percentil.
- Repita en la hora pico. El registro de la mañana o el inicio de clases mostrarán encolamientos que una ejecución de laboratorio a la hora del almuerzo nunca mostrará.
| Métrica | Cómo calcularla | Objetivo |
|---|---|---|
| Solicitudes totales | Conteo de líneas enviadas desde el archivo de autenticación | Igual a la longitud del archivo |
| Tasa de aceptación | Aceptaciones divididas entre las solicitudes totales | Coincide con la proporción válida del archivo |
| Tasa de rechazo | Rechazos divididos entre las solicitudes totales | Coincide con la proporción no válida del archivo |
| Tiempos de espera agotados y errores | Conteo de respuestas sin respuesta y de error en la ejecución | Cero en una ruta limpia |
| Latencia promedio | Tiempo de respuesta medio en todas las solicitudes | Dentro de su objetivo de latencia en horas pico |
| Tiempo transcurrido | Salida de tiempo Unix para todo el lote | Estable en ejecuciones repetidas |
Separe el túnel del almacén de cuentas
Si la tasa de aceptación es inferior a la proporción válida, no culpe a la "carga" hasta que sepa qué mitad falló. Para PEAP, pruebe el método interno por sí solo con una solicitud MS-CHAP contra el servidor interno. Una aceptación interna con una conexión externa rota apunta a certificados o configuraciones TLS. Un protocolo de enlace externo que falle en la verificación interna apunta al almacén de cuentas, al hash de la contraseña o al grupo que espera la directiva.
Conserve estos tiempos en el mismo registro que los resultados funcionales. Un cambio posterior en el firmware o en el directorio debe compararse con esa línea base y no con la sensación de que "se sintió más lento".
Si los tiempos de espera aumentan solo en las horas pico, solucione la capacidad o la ruta antes de agregar sitios. Un servidor que sea correcto pero lento seguirá fallando a los clientes que se rindan primero.
Rutas de falla, conmutación por error y verificaciones de seguridad
Un intercambio en funcionamiento aún puede ser inseguro. El diagnóstico que solo 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 de RFC 2865. Un atacante local capaz de modificar el tráfico podría convertir una respuesta válida en otra mediante una colisión de prefijo elegido de MD5. Un mensaje de "Autenticación exitosa" no es evidencia de que la implementación esté protegida.
Verificaciones que deben incluirse en la misma ejecución que la conmutación por error
Proteja la ruta donde la plataforma lo permita. Confirme que la manipulación en la ruta esté bloqueada y que la validación de Message-Authenticator se aplique 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 basados en certificados o contraseñas, compárelos en EAP-TLS frente a PEAP antes de dejar ambos activos.
Haga fallar el servidor a propósito. Cada uno de los siguientes escenarios debe mostrar la falla segura prevista o la alternancia controlada, además de una línea de registro, una alerta y una experiencia de usuario que usted pueda explicar al administrador del sitio.
| Escenario de falla | Cómo activarlo | Condición de aprobación |
|---|---|---|
| Tiempo de espera agotado | Bloquear UDP 1812 hacia el servidor | Falla segura (fail-closed) o alternancia controlada, registrada y alertada |
| Access-Reject | Usar una contraseña incorrecta | Acceso denegado sin red de alternancia |
| Certificado vencido | Dispositivo con un certificado vencido | Access-Reject sin VLAN predeterminado |
| Certificado revocado | Dispositivo con un certificado revocado | Access-Reject sin VLAN predeterminado |
| IP de origen NAS desconocida | Enviar desde una dirección no definida | Omitido o rechazado y registrado |
| Secreto compartido incorrecto | Secreto no coincidente en el cliente | Sin Access-Accept y error de secreto en la salida de depuración |
| Directorio inaccesible | Detener la conectividad del directorio | Rechazado o alternancia controlada según la directiva |
| Respuesta de autorización demorada | Agregar demora a la respuesta de autorización | Tiempo de espera agotado gestionado sin acceso abierto |
Lo que debe preservar la conmutación por error regional
Que otro servidor responda no significa que haya consistencia en la directiva. Al detener el servidor primario, compare los valores de VLAN, los límites de ancho de banda, el estado de revocación y los atributos de auditoría del servidor de respaldo con los del primario. Si un invitado conmuta por error hacia un segmento del personal, la prueba se considera fallida, aunque la conexión haya sido rápida.
Marque cualquier escenario que recurra a un acceso abierto como fallido, independientemente de si el usuario logra conectarse o no. Escriba cada resultado en el mismo registro de pruebas que la línea base 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 usted pueda coincidir con un ID de prueba o una cuenta conocida. En un entorno con mucha actividad, esa etiqueta es la forma en que usted encontrará su ejecución sin tener que desplazarse por las actividades de la mañana de los demás.
Para cada autenticación, alinee estos campos:
- Identidad y dispositivo: quién o qué se unió, no solo una MAC que espera que sea suya.
- Método: EAP-TLS, PEAP o una PSK individual. Un método que no implementó es un hallazgo.
- Lugar: punto de acceso, SSID y sitio.
- Decisión: VLAN y rol devuelto, o el motivo de rechazo.
- Hora: marca de tiempo que se encuentra dentro de la ventana que probó.
Nuestro registro de autenticación está diseñado para ese tipo de coincidencia. Una sola consulta en toda la propiedad 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 muchos puntos de acceso y necesite verificar si el mismo error ocurre en todas partes o solo en un controlador.
Tres patrones que indican que las notas son incorrectas
El motivo no coincide con la prueba. Envió una contraseña incorrecta y el registro indica cliente desconocido. Probó algo incorrecto o se acumularon dos fallas.
La aceptación nombra el VLAN predeterminado. Las credenciales funcionaron. La asignación no. No cierre el caso.
La contabilidad inició y nunca se detuvo. El registro de la sesión está incompleto, por lo que no puede probar que el cliente se desconectó cuando usted cree que lo hizo. Compare el inicio y la detención con la sesión que ejecutó, no con la de un usuario cercano.
Establezca una alerta para los picos de rechazo durante la ventana de prueba, de modo que un secreto compartido incorrecto no parezca que "los usuarios escribieron mal". Conserve el extracto del registro junto con las notas de la prueba. Ese extracto es la evidencia de auditoría cuando alguien pregunte, semanas después, qué fue lo que comprobó usted.
Decida cuándo RADIUS está listo para el despliegue
Pase a producción solo cuando la evidencia cumpla con cinco criterios. La confianza de un ingeniero no es uno de ellos.
- Cada fila de la matriz se aprueba en cada tipo de NAS que implemente, incluida cada SSID o política de acceso que pretenda mantener.
- La conmutación por error mantiene la misma VLAN, política y comportamiento de revocación que el primario. Un segundo servidor que responda con un rol diferente no supera esta verificación.
- Ningún escenario de falla queda abierto. Una contraseña incorrecta, un directorio caído, un certificado vencido y 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 pico, con una tasa de aceptación que coincide con la proporción válida del archivo de prueba.
- Los registros muestran el motivo esperado y VLAN para cada ejecución que afirme como aprobada.
Detenga el despliegue general hasta que esas cinco condiciones se cumplan en un sitio real, no solo en un laboratorio VLAN.
Le permitimos probar esto primero en un solo sitio. Coloque las nuevas redes abiertas, seguras y xPSK en los puntos de acceso que ese sitio ya ejecuta, junto a la red que utiliza hoy en día, y evalúe el resultado en función de los tickets y la evidencia de auditoría antes de que cambie cualquier otro sitio. Durante ese piloto, el registro debe responder a dos preguntas sin necesidad de una reunión: qué dispositivos se unieron en qué VLAN, y qué motivo de aceptación o rechazo apareció con mayor frecuencia.
Extiéndalo únicamente cuando los tickets 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 después de cada renovación de certificado, actualización de firmware o cambio de directorio, en comparación con la misma línea de base, antes de que los usuarios vean el cambio. Para saber cómo debe diseñarse ese sitio piloto, comience con el diseño de red de WiFi y pruebe el diseño que planea conservar, no uno SSID temporal que vaya a eliminar la próxima semana.
Purple Access le brinda RADIUS en la nube que ubica a cada dispositivo en la red abierta, segura o xPSK por identidad, con la VLAN y el motivo de rechazo visibles en el registro de autenticación. Si desea que ese plan de prueba se ejecute en los puntos de acceso que ya tiene, comience con un sitio y lea el resultado antes de continuar con la implementación. Visite Purple Access y coloque el primer sitio en una línea de base que pueda defender.
