Reino de autenticación VPN: que espazo de nomes de conta gaña?
Un reino encamiña un inicio de sesión a un sistema de identidade, non a un país. Fixe a forma do nome, siga a petición polo proxy e anote quen respondeu.
Cada inicio de sesión VPN cae nalgún espazo de nomes de conta, e o reino é o selector que decide en cal. Non di nada sobre o país, a localización do servidor nin o nivel de confianza. Dous nomes de usuario idénticos poden vivir en reinos diferentes, por iso un contrasinal correcto ás veces autentica a conta equivocada. Este manual corrixe primeiro a forma da identidade e despois segue a petición ata o sistema que realmente respondeu.
Que selecciona o reino
Unha pasarela recibe un nome de usuario e debe decidir onde comprobalo. O reino é a parte dese nome, ou o atributo que o acompaña, que escolle a base de datos: un directorio, un conxunto RADIUS, un ficheiro de contas local. O NPS de Microsoft chámao nome de reino e encamiña as solicitudes de conexión con el, mentres que o identificador de acceso á rede EAP leva a mesma idea como sufixo tras o arroba en RFC 7542. Ambos son selectores, e ningún decide se a credencial é boa.
Esa separación produce dous fallos moi distintos. Un reino que encamiña correctamente cun contrasinal incorrecto dá un rexeitamento, mentres que un reino que encamiña á base de datos equivocada pode rexeitar un contrasinal correcto ou aceptar un doutra persoa. Ningún dos dous erros menciona o reino, por iso o primeiro diagnóstico sempre é o mesmo: descubra que sistema respondeu.
A sintaxe do reino pertence ao despregamento. Algúns servizos queren un nome sen cualificar máis un atributo, outros queren user@domain, e uns poucos esperan unha forma con barra invertida que a maioría das guías nunca menciona.
Use a forma que espera o backend
Pregunte ao operador que forma escribir antes de probar sufixos dun titorial. Un nome cualificado por dominio que chega a un backend que espera un simple adoita fallar na busca, non na comprobación do contrasinal. O mesmo nome curto en dous directorios é o caso en que un reino ausente fai máis dano.
Non tome a conta de xestión como proba. A consola web onde administra o servizo pode autenticarse contra un ficheiro local, mentres que o túnel comproba un directorio completamente distinto. Probe coas credenciais que usaría un usuario real, na interface que usaría un usuario real. Un inicio de sesión correcto na consola non di nada sobre o reino que a pasarela aplica á autenticación VPN.
Os navegadores e clientes de correo ás veces almacenan unha identidade anterior e reenvíana en silencio. Cando o nome de usuario reportado difire do escrito, esa caché é o primeiro lugar onde mirar.
Siga a petición polo proxy
Nun frontend FreeRADIUS, os reinos decláranse na configuración do proxy, e o sufixo declarado decide que servidor principal recibe a petición. Lea ese ficheiro antes de cambiar nada, porque unha petición que non coincide con ningún reino trátase 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 mostra que sufixos existen e a que conxunto apunta cada un. A chamada radtest envía un nome con reino e un contrasinal deliberadamente incorrecto, así que un rexeitamento demostra que se executaron tanto a ruta como a comprobación da credencial. As liñas de rexistro arredor dese intento mostran se o nome se retirou antes do proxy e que servidor principal o tomou. Se o rexistro non mostra ningunha coincidencia de reino, a petición nunca saíu do servidor local e o problema é o sufixo, non o contrasinal.
Cambie unha cousa á vez e repita o intento, porque o rexistro separa o encamiñamento do fallo de credenciais só cando a entrada difire entre execucións. Manteña o segredo compartido fóra do historial da consola onde a ferramenta admite lelo dun ficheiro ou dunha solicitude.
Rexiste o intento sen filtralo
Escriba o fallo nunha forma sobre a que un administrador poida actuar: a interface, a forma da identidade, se había un reino e o erro exacto non secreto. Manteña o nome de usuario vivo fóra dos informes públicos e o reino dentro. Redactar cada identidade co mesmo marcador oculta precisamente o desaxuste que busca. A marca de tempo tamén importa, porque a pasarela, o proxy e o directorio levan rexistros separados.
Despois documente a forma gañadora para os usuarios, porque a seguinte persoa que a escriba mal abrirá o mesmo tícket. Restablecer o contrasinal non arranxa unha petición que segue caendo no espazo de nomes equivocado. O reino é unha decisión de encamiñamento, e as decisións de encamiñamento corríxense nomeándoas correctamente.