VPN-autentikaasjerûmte: hokke akkountnammeromte wint?

Elke VPN-oanmelding bedarret yn in akkountnammeromte, en de romte is de selektor dy't beslút hokker. It seit neat oer it lân, de serverlokaasje of it fertrouwensnivo. Twa identike brûkersnammen kinne yn ferskate romten libje, dêrom autentisearret in korrekt wachtwurd soms it ferkearde akkount. Dizze hantlieding makket earst de identiteitsfoarm goed en folget dêrnei it fersyk oant it systeem dat wier antwurde.

Wat de romte selektearret

In gateway krijt in brûkersnamme en moat beslute wêr't dy kontrolearre wurde moat. De romte is it part fan dy namme, of it attribút derneist, dat de databank kiest: in map, in RADIUS-pool, in lokaal akkountbestân. Microsoft syn NPS neamt dit in romtenamme en liedt ferbiningsfersiken dermei, wylst de EAP-netwurktoegongsidentifikaasje itselde idee draacht as efterheaksel nei it @-teken yn RFC 7542. Beide binne selektors, en gjinien beslút oft de oanmeldgegevens goed binne.

Dy skieding produsearret twa hiel ferskate flaters. In romte dy't korrekt liedt mei in ferkeard wachtwurd jout ien wegering, wylst in romte dy't nei de ferkearde databank liedt in korrekt wachtwurd wegerje kin of dat fan in oar akseptearje. Gjin fan beide flaters neamt de romte, dêrom is de earste diagnoaze altyd itselde: fyn út hokker systeem antwurde.

De syntaksis fan de romte heart by de útrôl. Guon tsjinsten wolle in net-kwalifisearre namme plus in attribút, oaren wolle user@domain, en in pear ferwachtsje in foarm mei in efteroer skaasline dy't de measte hantliedings nea neame.

Brûk de foarm dy't de backend ferwachtet

Freegje de operator hokker foarm oft der yntypen wurde moat foardat jo efterheaksels út in tutorial besykje. In namme kwalifisearre mei domein dy't by in backend komt dy't in gewoane namme ferwachtet, falt meastentiids by it sykjen, net by de wachtwurdkontrôle. Deselde koarte namme yn twa mappen is it gefal dêr't in ûntbrekkende romte de measte skea docht.

Nim it beheardersakkount net as bewiis. De webkonsôle dêr't jo de tsjinst beheare, autentisearret miskien tsjin in lokaal bestân, wylst de tunnel in hiel oare map kontrolearret. Test mei de oanmeldgegevens dy't in echte brûker brûke soe, op 'e ynterface dy't in echte brûker brûke soe. In slagge konsôle-oanmelding seit neat oer de romte dy't de gateway op VPN-autentikaasje tapast.

Browsers en mailklanten bewarje soms in eardere identiteit en stjoere dy stil opnij. As de rapportearre brûkersnamme ferskilt fan 'e yntype, is dy cache it earste plak om te sjen.

Folgje it fersyk troch de proxy

Op in FreeRADIUS-frontend wurde romten yn 'e proxy-konfiguraasje ferklearre, en it ferklearre efterheaksel beslút hokker thússerver it fersyk krijt. Lês dat bestân foardat jo eat feroarje, want in fersyk dat by gjin inkelde romte past, wurdt by definysje lokaal behannele.

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 lit sjen hokker efterheaksels bestean en op hokker pool elk rjochtet. De radtest-oprop stjoert in namme mei romte en in bewust ferkeard wachtwurd, dus in wegering bewiist dat sawol de rûte as de kontrôle fan 'e oanmeldgegevens rûn. Logregels om dy poging hinne litte sjen oft de namme foar de proxy fuorthelle waard en hokker thússerver dy naam. As it log hielendal gjin romte-oerienkomst sjen lit, hat it fersyk de lokale server nea ferlitten en is it efterheaksel it probleem, net it wachtwurd.

Feroarje ien ding tagelyk en werhelje de poging, want it log skiedt routing fan flaters yn 'e oanmeldgegevens allinnich as de ynfier tusken runs ferskilt. Hâld it dielde geheim bûten de shell-skiednis dêr't it ark it lêzen út in bestân of in opdracht stypje.

Skriuw de poging op sûnder dy út te lekken

Skriuw de flater yn in foarm dêr't in behearder op tastean kin: de ynterface, de identiteitsfoarm, oft der in romte wie, en de krekte net-geheime flater. Hâld de libjende brûkersnamme bûten iepenbiere rapporten en de romte deryn. Eltse identiteit nei deselde plekhâlder redigearje ferberget krekt de misferhâlding dy't jo sykje. De tiidstimpel is ek fan belang, want de gateway, de proxy en de map hâlde aparte logs by.

Dokumintearje dan de winnende foarm foar brûkers, want de folgjende persoan dy't him ferkeard yntype fynt itselde ticket. In wachtwurd weromsette reparearret gjin fersyk dat yn 'e ferkearde nammeromte bliuwt bedarjen. De romte is in routingbeslissing, en routingbeslissingen wurde reparearre troch se korrekt te neamen.