VPN-authenticatierijk: welke accountnaamruimte wint?

Elke VPN-login belandt in een of andere accountnaamruimte, en het rijk is de selector die bepaalt welke. Het zegt niets over het land, de serverlocatie of het vertrouwensniveau. Twee identieke gebruikersnamen kunnen in verschillende rijken leven, daarom authenticeert een juist wachtwoord soms het verkeerde account. Deze runbook legt eerst de identiteitsvorm vast en volgt daarna het verzoek tot het systeem dat daadwerkelijk antwoordde.

Wat het rijk selecteert

Een gateway ontvangt een gebruikersnaam en moet beslissen waar die te controleren. Het rijk is het deel van die naam, of het attribuut ernaast, dat de database kiest: een directory, een RADIUS-pool, een lokaal accountbestand. Microsofts NPS noemt dit een rijknaam en routeert er verbindingsverzoeken mee, terwijl de EAP-netwerktoegangsidentificatie hetzelfde idee draagt als achtervoegsel na het at-teken in RFC 7542. Beide zijn selectors, en geen van beide beslist of de credential goed is.

Die scheiding levert twee heel verschillende storingen op. Een rijk dat correct routeert met een verkeerd wachtwoord geeft één afwijzing, terwijl een rijk dat naar de verkeerde database routeert een juist wachtwoord kan afwijzen of dat van iemand anders kan accepteren. Geen van beide fouten noemt het rijk, daarom is de eerste diagnose altijd dezelfde: uitzoeken welk systeem antwoordde.

De syntaxis van het rijk hoort bij de uitrol. Sommige diensten willen een ongekwalificeerde naam plus een attribuut, andere willen user@domain, en enkele verwachten een vorm met een backslash die de meeste handleidingen niet noemen.

Gebruik de vorm die de backend verwacht

Vraag de operator welke vorm je moet typen voordat je achtervoegsels uit een tutorial probeert. Een domeingekwalificeerde naam die bij een backend aankomt die een eenvoudige naam verwacht, faalt meestal in de opzoeking, niet in de wachtwoordcontrole. Dezelfde korte naam in twee directory's is het geval waarin een ontbrekend rijk de meeste schade aanricht.

Beschouw het beheeraccount niet als bewijs. De webconsole waarin je de dienst beheert, kan tegen een lokaal bestand authenticeren, terwijl de tunnel een heel andere directory controleert. Test met de inloggegevens die een echte gebruiker zou gebruiken, op de interface die een echte gebruiker zou gebruiken. Een geslaagde consolelogin zegt niets over het rijk dat de gateway op VPN-authenticatie toepast.

Browsers en mailclients cachen soms een eerdere identiteit en dienen die stil opnieuw in. Wanneer de gerapporteerde gebruikersnaam afwijkt van de getypte, is die cache de eerste plek om te kijken.

Volg het verzoek door de proxy

Op een FreeRADIUS-front worden rijken in de proxyconfiguratie gedeclareerd, en het gedeclareerde achtervoegsel bepaalt welke thuisserver het verzoek ontvangt. Lees dat bestand voordat je iets wijzigt, want een verzoek dat bij geen enkel rijk past, wordt standaard lokaal afgehandeld.

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 toont welke achtervoegsels bestaan en op welke pool elk mikt. De radtest-aanroep stuurt een naam met een rijk en een opzettelijk verkeerd wachtwoord, dus een afwijzing bewijst dat zowel de routering als de credentialcontrole liep. Logregels rond die poging tonen of de naam vóór de proxy werd gestript en welke thuisserver hem overnam. Als de log helemaal geen rijkovereenkomst toont, heeft het verzoek de lokale server nooit verlaten en is het achtervoegsel het probleem, niet het wachtwoord.

Wijzig één ding tegelijk en herhaal de poging, want de log scheidt routering van credentialfalen alleen wanneer de invoer tussen runs verschilt. Houd het gedeelde geheim buiten de shellgeschiedenis waar de tool het lezen uit een bestand of prompt ondersteunt.

Leg de poging vast zonder te lekken

Schrijf de storing in een vorm waarop een beheerder kan handelen: de interface, de identiteitsvorm, of er een rijk aanwezig was, en de exacte niet-geheime fout. Houd de actieve gebruikersnaam buiten openbare rapporten en het rijk erin. Elke identiteit tot dezelfde plaatshouder redigeren verbergt precies de mismatch die je zoekt. De tijdstempel telt ook, omdat de gateway, de proxy en de directory aparte logboeken bijhouden.

Documenteer daarna de winnende vorm voor gebruikers, want de volgende persoon die hem verkeerd typt, opent hetzelfde ticket. Een wachtwoordreset lost een verzoek dat steeds in de verkeerde naamruimte belandt niet op. Het rijk is een routeringsbeslissing, en routeringsbeslissingen worden opgelost door ze correct te benoemen.