Royaume d'authentification VPN : quel espace de noms de compte gagne ?

Chaque connexion VPN atterrit dans un espace de noms de compte, et le royaume est le sélecteur qui décide lequel. Il ne dit rien sur le pays, l'emplacement du serveur ni le niveau de confiance. Deux noms d'utilisateur identiques peuvent vivre dans des royaumes différents, ce qui explique qu'un mot de passe correct authentifie parfois le mauvais compte. Ce guide corrige d'abord la forme de l'identité, puis suit la requête jusqu'au système qui a réellement répondu.

Ce que le royaume sélectionne

Une passerelle reçoit un nom d'utilisateur et doit décider où le vérifier. Le royaume est la partie de ce nom, ou l'attribut qui l'accompagne, qui choisit la base de données : un annuaire, un pool RADIUS, un fichier de comptes local. Le NPS de Microsoft l'appelle nom de royaume et achemine les demandes de connexion avec lui, tandis que l'identifiant d'accès réseau EAP porte la même idée comme suffixe après l'arobase dans RFC 7542. Les deux sont des sélecteurs, et aucun ne décide si le justificatif est bon.

Cette séparation produit deux échecs très différents. Un royaume qui achemine correctement avec un mot de passe erroné donne un refus, tandis qu'un royaume qui achemine vers la mauvaise base peut refuser un mot de passe correct ou accepter celui d'une autre personne. Aucune des deux erreurs ne mentionne le royaume, c'est pourquoi le premier diagnostic est toujours le même : déterminez quel système a répondu.

La syntaxe du royaume appartient au déploiement. Certains services veulent un nom non qualifié plus un attribut, d'autres veulent user@domain, et quelques-uns attendent une forme avec barre oblique inverse que la plupart des guides ne mentionnent jamais.

Utilisez la forme attendue par le backend

Demandez à l'exploitant quelle forme saisir avant d'essayer des suffixes tirés d'un tutoriel. Un nom qualifié par domaine qui arrive sur un backend attendant un nom simple échoue généralement à la recherche, pas à la vérification du mot de passe. Le même nom court dans deux annuaires est le cas où un royaume manquant cause le plus de dégâts.

Ne prenez pas le compte d'administration comme preuve. La console web où vous administrez le service peut s'authentifier contre un fichier local, tandis que le tunnel vérifie un annuaire complètement différent. Testez avec les identifiants qu'un utilisateur réel utiliserait, sur l'interface qu'un utilisateur réel utiliserait. Une connexion réussie à la console ne dit rien du royaume que la passerelle applique à l'authentification VPN.

Les navigateurs et les clients de messagerie mettent parfois en cache une identité précédente et la renvoient silencieusement. Quand le nom d'utilisateur signalé diffère de celui saisi, ce cache est le premier endroit où regarder.

Suivez la requête dans le proxy

Sur un frontend FreeRADIUS, les royaumes sont déclarés dans la configuration du proxy, et le suffixe déclaré décide quel serveur domestique reçoit la requête. Lisez ce fichier avant de changer quoi que ce soit, car une requête ne correspondant à aucun royaume est traitée localement par défaut.

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 montre quels suffixes existent et vers quel pool chacun pointe. L'appel radtest envoie un nom avec royaume et un mot de passe volontairement erroné, donc un refus prouve que la route et la vérification du justificatif ont toutes deux tourné. Les lignes de journal autour de cette tentative montrent si le nom a été retiré avant le proxy et quel serveur domestique l'a pris. Si le journal ne montre aucune correspondance de royaume, la requête n'a jamais quitté le serveur local et le problème est le suffixe, pas le mot de passe.

Changez une chose à la fois et répétez la tentative, car le journal ne sépare le routage de l'échec du justificatif que lorsque l'entrée diffère entre les exécutions. Gardez le secret partagé hors de l'historique du shell là où l'outil permet de le lire depuis un fichier ou une invite.

Consignez la tentative sans la divulguer

Écrivez l'échec sous une forme exploitable par un administrateur : l'interface, la forme de l'identité, la présence d'un royaume et l'erreur exacte non secrète. Gardez le nom d'utilisateur actif hors des rapports publics et le royaume dedans. Masquer chaque identité par le même espace réservé cache précisément l'incohérence que vous cherchez. L'horodatage compte aussi, car la passerelle, le proxy et l'annuaire tiennent des journaux séparés.

Documentez ensuite la forme gagnante pour les utilisateurs, car la personne suivante qui la saisit mal ouvrira le même ticket. Une réinitialisation de mot de passe ne corrige pas une requête qui continue d'atterrir dans le mauvais espace de noms. Le royaume est une décision de routage, et les décisions de routage se corrigent en les nommant correctement.