VPN-autentiseringsrike: hvilket kontonavnerom vinner?

Hver VPN-pålogging havner i et eller annet kontonavnerom, og riket er velgeren som avgjør hvilket. Det sier ingenting om landet, serverplasseringen eller tillitsnivået. To identiske brukernavn kan leve i forskjellige riker, og derfor autentiserer et riktig passord noen ganger feil konto. Denne runboken fikser først identitetsformen, og sporer deretter forespørselen til systemet som faktisk svarte.

Hva riket velger

En gateway mottar et brukernavn og må avgjøre hvor det skal sjekkes. Riket er den delen av navnet, eller attributtet ved siden av det, som velger databasen: en katalog, en RADIUS-pool, en lokal kontofil. Microsofts NPS kaller dette et rikenavn og ruter tilkoblingsforespørsler med det, mens EAP-nettverkstilgangsidentifikatoren bærer den samme ideen som et suffiks etter at-tegnet i RFC 7542. Begge er velgere, og ingen av dem avgjør om legitimasjonen er god.

Denne separasjonen gir to svært forskjellige feil. Et rike som ruter riktig med feil passord gir én avvisning, mens et rike som ruter til feil database kan avvise et riktig passord eller godta noen andres. Ingen av feilene nevner riket, og derfor er den første diagnosen alltid den samme: finn ut hvilket system som svarte.

Rikets syntaks tilhører utrullingen. Noen tjenester vil ha et ukvalifisert navn pluss et attributt, andre vil ha user@domain, og noen få forventer en form med omvendt skråstrek som de fleste veiledninger ikke nevner.

Bruk formen backend forventer

Spør operatøren hvilken form som skal skrives før du prøver suffikser fra en veiledning. Et domenekvalifisert navn som når en backend som forventer et enkelt navn, feiler vanligvis i oppslaget, ikke i passordkontrollen. Det samme korte navnet i to kataloger er tilfellet der et manglende rike gjør mest skade.

Ikke behandle administrasjonskontoen som bevis. Nettkonsollen der du administrerer tjenesten kan autentisere mot en lokal fil, mens tunnelen sjekker en helt annen katalog. Test med legitimasjonen en ekte bruker ville brukt, i grensesnittet en ekte bruker ville brukt. En vellykket konsollpålogging sier ingenting om riket gatewayen bruker for VPN-autentisering.

Nettlesere og e-postklienter hurtiglagrer noen ganger en tidligere identitet og sender den inn igjen i det stille. Når det rapporterte brukernavnet avviker fra det som ble skrevet, er den hurtiglagringen det første stedet å se.

Spor forespørselen gjennom proxyen

På en FreeRADIUS-front er riker deklarert i proxy-konfigurasjonen, og det deklarerte suffikset avgjør hvilken hjemmeserver som mottar forespørselen. Les den filen før du endrer noe, fordi en forespørsel som ikke samsvarer med noe rike, håndteres 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 viser hvilke suffikser som finnes og hvilken pool hvert av dem peker på. radtest-kallet sender et navn med et rike og et bevisst feil passord, så en avvisning beviser at både rutingen og legitimasjonskontrollen kjørte. Logglinjene rundt det forsøket viser om navnet ble strippet før proxyen og hvilken hjemmeserver som tok det. Hvis loggen ikke viser noen rikesamsvar i det hele tatt, forlot forespørselen aldri den lokale serveren, og problemet er suffikset, ikke passordet.

Endre én ting om gangen og gjenta forsøket, fordi loggen bare skiller ruting fra legitimasjonsfeil når inndata er forskjellig mellom kjøringene. Hold den delte hemmeligheten utenfor skallhistorikken der verktøyet støtter lesing fra fil eller ledetekst.

Registrer forsøket uten å lekke det

Skriv feilen i en form en administrator kan handle på: grensesnittet, identitetsformen, om et rike var til stede, og den nøyaktige ikke-hemmelige feilen. Hold det aktive brukernavnet utenfor offentlige rapporter og riket innenfor. Å sladde hver identitet til samme plassholder skjuler nettopp avviket du leter etter. Tidsstempelet betyr også noe, siden gatewayen, proxyen og katalogen fører separate logger.

Dokumenter deretter den vinnende formen for brukere, fordi neste person som skriver den feil, åpner samme sak. En passordtilbakestilling retter ikke en forespørsel som fortsetter å lande i feil navnerom. Riket er en rutingbeslutning, og rutingbeslutninger rettes ved å navngi dem riktig.