Reino de autenticación VPN: ¿qué espacio de nombres de cuenta gana?

Cada inicio de sesión VPN cae en algún espacio de nombres de cuenta, y el reino es el selector que decide en cuál. No dice nada sobre el país, la ubicación del servidor ni el nivel de confianza. Dos nombres de usuario idénticos pueden vivir en reinos diferentes, por eso una contraseña correcta a veces autentica la cuenta equivocada. Este manual corrige primero la forma de la identidad y luego sigue la petición hasta el sistema que realmente respondió.

Qué selecciona el reino

Una pasarela recibe un nombre de usuario y debe decidir dónde comprobarlo. El reino es la parte de ese nombre, o el atributo que lo acompaña, que elige la base de datos: un directorio, un grupo RADIUS, un archivo de cuentas local. El NPS de Microsoft lo llama nombre de reino y enruta las peticiones de conexión con él, mientras que el identificador de acceso a la red EAP lleva la misma idea como sufijo tras la arroba en RFC 7542. Ambos son selectores, y ninguno decide si la credencial es buena.

Esa separación produce dos fallos muy distintos. Un reino que enruta correctamente con una contraseña incorrecta da un rechazo, mientras que un reino que enruta a la base de datos equivocada puede rechazar una contraseña correcta o aceptar una ajena. Ninguno de los dos errores menciona el reino, por eso el primer diagnóstico siempre es el mismo: averigüe qué sistema respondió.

La sintaxis del reino pertenece al despliegue. Algunos servicios quieren un nombre sin cualificar más un atributo, otros quieren user@domain, y unos pocos esperan una forma con barra invertida que la mayoría de las guías nunca menciona.

Use la forma que espera el backend

Pregunte al operador qué forma escribir antes de probar sufijos de un tutorial. Un nombre cualificado por dominio que llega a un backend que espera uno simple suele fallar en la búsqueda, no en la comprobación de la contraseña. El mismo nombre corto en dos directorios es el caso en que un reino ausente hace más daño.

No tome la cuenta de gestión como prueba. La consola web donde administra el servicio puede autenticarse contra un archivo local, mientras que el túnel comprueba un directorio completamente distinto. Pruebe con las credenciales que usaría un usuario real, en la interfaz que usaría un usuario real. Un inicio de sesión correcto en la consola no dice nada sobre el reino que la pasarela aplica a la autenticación VPN.

Los navegadores y clientes de correo a veces almacenan una identidad anterior y la reenvían en silencio. Cuando el nombre de usuario reportado difiere del escrito, esa caché es el primer lugar donde mirar.

Siga la petición por el proxy

En un frontend FreeRADIUS, los reinos se declaran en la configuración del proxy, y el sufijo declarado decide qué servidor principal recibe la petición. Lea ese archivo antes de cambiar nada, porque una petición que no coincide con ningún reino se trata localmente por defecto.

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

grep muestra qué sufijos existen y a qué grupo apunta cada uno. La llamada radtest envía un nombre con reino y una contraseña deliberadamente incorrecta, así que un rechazo demuestra que se ejecutaron tanto la ruta como la comprobación de la credencial. Las líneas de registro alrededor de ese intento muestran si el nombre se recortó antes del proxy y qué servidor principal lo tomó. Si el registro no muestra ninguna coincidencia de reino, la petición nunca salió del servidor local y el problema es el sufijo, no la contraseña.

Cambie una cosa a la vez y repita el intento, porque el registro separa el enrutamiento del fallo de credenciales solo cuando la entrada difiere entre ejecuciones. Mantenga el secreto compartido fuera del historial del intérprete donde la herramienta admita leerlo de un archivo o de un aviso.

Registre el intento sin filtrarlo

Escriba el fallo en una forma sobre la que un administrador pueda actuar: la interfaz, la forma de la identidad, si había un reino y el error exacto no secreto. Mantenga el nombre de usuario vivo fuera de los informes públicos y el reino dentro. Redactar cada identidad con el mismo marcador oculta precisamente el desajuste que busca. La marca de tiempo también importa, porque la pasarela, el proxy y el directorio llevan registros separados.

Después documente la forma ganadora para los usuarios, porque la siguiente persona que la escriba mal abrirá el mismo tique. Restablecer la contraseña no arregla una petición que sigue cayendo en el espacio de nombres equivocado. El reino es una decisión de enrutamiento, y las decisiones de enrutamiento se corrigen nombrándolas correctamente.