VPN Authentication Realm: Which Account Namespace Wins?

Every VPN login lands in some account namespace, and the realm is the selector that decides which one. It says nothing about the country, the server location or the trust level. Two identical usernames can live in different realms, which is why a correct password sometimes authenticates the wrong account. This runbook fixes the identity form first, then traces the request to the system that actually answered.

What the Realm Selects

A gateway receives a username and must decide where to check it. The realm is the part of that name, or the attribute beside it, that picks the database: a directory, a RADIUS pool, a local account file. Microsoft's NPS calls this a realm name and routes connection requests with it, while the EAP network access identifier carries the same idea as a suffix after the at sign in RFC 7542. Both are selectors, and neither one decides whether the credential is any good.

That separation produces two very different failures. A realm that routes correctly with a wrong password gives one rejection, while a realm that routes to the wrong database can reject a correct password or accept one belonging to somebody else. Neither error mentions the realm, which is why the first diagnostic is always the same: find out which system answered.

Realm syntax belongs to the deployment. Some services want an unqualified name plus an attribute, others want user@domain, and a few expect a backslash-qualified form that most guides never mention.

Use the Form the Backend Expects

Ask the operator which form to type before trying suffixes from a tutorial. A domain-qualified name that reaches a backend expecting a plain one usually fails the lookup rather than the password check. The same short name in two directories is the case where a missing realm does the most damage.

Do not treat the management account as proof. The web console where you administer the service may authenticate against a local file, while the tunnel checks a completely different directory. Test with the credentials a real user would use, on the interface a real user would use. A successful console login says nothing about the realm the gateway applies to VPN authentication.

Browsers and mail clients sometimes cache a previous identity and resubmit it silently. When the reported username differs from the one typed, that cache is the first place to look.

Trace the Request Through the Proxy

On a FreeRADIUS front end, realms are declared in the proxy configuration, and the declared suffix decides which home server receives the request. Read that file before changing anything, because a request matching no realm is handled locally by default.

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'

The grep shows which suffixes exist and which pool each one targets. The radtest call sends a name with a realm and a deliberately wrong password, so a rejection proves both the route and the credential check ran. Journal lines around that attempt show whether the name was stripped before proxying and which home server took it. If the log shows no realm match at all, the request never left the local server and the suffix is the problem rather than the password.

Change one thing at a time and repeat the attempt, because the log separates routing from credential failure only when the input differs between runs. Keep the shared secret out of shell history where the tool supports reading it from a file or a prompt.

Record the Attempt Without Leaking It

Write the failure in a form an administrator can act on: the interface, the identity form, whether a realm was present, and the exact non-secret error. Keep the live username out of public reports and keep the realm in. Redacting every identity to the same placeholder hides precisely the mismatch you are trying to find. The timestamp matters too, since the gateway, the proxy and the directory keep separate logs.

Then document the winning form for users, because the next person to mistype it opens the same ticket. A password reset does not fix a request that keeps landing in the wrong namespace. The realm is a routing decision, and routing decisions get fixed by naming them correctly.