VPN-autentiseringsrike: vilket kontonamnrymd vinner?

Varje VPN-inloggning landar i någon kontonamnrymd, och riket är väljaren som avgör vilken. Det säger ingenting om landet, serverns placering eller förtroendenivån. Två identiska användarnamn kan leva i olika riken, därför autentiserar ett korrekt lösenord ibland fel konto. Den här runboken låser först identitetsformen och spårar sedan begäran till systemet som faktiskt svarade.

Vad riket väljer

En gateway tar emot ett användarnamn och måste avgöra var det ska kontrolleras. Riket är den del av namnet, eller attributet bredvid det, som väljer databasen: en katalog, en RADIUS-pool, en lokal kontofil. Microsofts NPS kallar detta ett rikesnamn och dirigerar anslutningsbegäranden med det, medan EAP:s nätverksåtkomstidentifierare bär samma idé som suffix efter at-tecknet i RFC 7542. Båda är väljare, och ingen av dem avgör om uppgifterna är bra.

Denna separation ger två mycket olika fel. Ett rike som dirigerar rätt med fel lösenord ger en avvisning, medan ett rike som dirigerar till fel databas kan avvisa ett korrekt lösenord eller acceptera någon annans. Ingen av felen nämner riket, därför är den första diagnosen alltid densamma: ta reda på vilket system som svarade.

Rikets syntax hör till driftsättningen. Vissa tjänster vill ha ett okvalificerat namn plus ett attribut, andra vill ha user@domain, och några få förväntar sig en form med omvänt snedstreck som de flesta guider inte nämner.

Använd formen som backend förväntar sig

Fråga operatören vilken form som ska skrivas innan du provar suffix från en guide. Ett domänkvalificerat namn som når en backend som förväntar sig ett enkelt namn misslyckas oftast i uppslaget, inte i lösenordskontrollen. Samma korta namn i två kataloger är fallet där ett saknat rike gör störst skada.

Behandla inte administrationskontot som bevis. Webbkonsolen där du administrerar tjänsten kan autentisera mot en lokal fil, medan tunneln kontrollerar en helt annan katalog. Testa med de uppgifter en riktig användare skulle använda, i det gränssnitt en riktig användare skulle använda. En lyckad konsolinloggning säger ingenting om det rike som gatewayen tillämpar för VPN-autentisering.

Webbläsare och e-postklienter cachar ibland en tidigare identitet och skickar in den igen tyst. När det rapporterade användarnamnet skiljer sig från det inskrivna är den cachen första stället att titta på.

Spåra begäran genom proxyn

På en FreeRADIUS-front deklareras riken i proxykonfigurationen, och det deklarerade suffixet avgör vilken hemserver som tar emot begäran. Läs den filen innan du ändrar något, eftersom en begäran som inte matchar något rike hanteras lokalt som standard.

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 visar vilka suffix som finns och vilken pool varje pekar på. radtest-anropet skickar ett namn med ett rike och ett avsiktligt fel lösenord, så en avvisning bevisar att både dirigeringen och kontrollen av uppgifterna kördes. Loggraderna runt det försöket visar om namnet ströks före proxyn och vilken hemserver som tog det. Om loggen inte visar någon rikesmatchning alls lämnade begäran aldrig den lokala servern, och problemet är suffixet, inte lösenordet.

Ändra en sak i taget och upprepa försöket, eftersom loggen bara skiljer dirigering från uppgiftsfel när indata skiljer sig mellan körningarna. Håll den delade hemligheten utanför skallhistoriken där verktyget stöder läsning från fil eller prompt.

Registrera försöket utan att läcka det

Skriv felet i en form en administratör kan agera på: gränssnittet, identitetsformen, om ett rike fanns och det exakta icke-hemliga felet. Håll det aktiva användarnamnet utanför offentliga rapporter och riket innanför. Att maskera varje identitet till samma platshållare döljer just den diskrepans du letar efter. Tidsstämpeln spelar också roll, eftersom gatewayen, proxyn och katalogen för separata loggar.

Dokumentera sedan den vinnande formen för användare, eftersom nästa person som skriver den fel öppnar samma ärende. En lösenordsåterställning rättar inte en begäran som fortsätter att landa i fel namnrymd. Riket är ett dirigeringsbeslut, och dirigeringsbeslut rättas genom att namnge dem korrekt.