Korleis ei VPN-pålogging når RADIUS og identitetsleverandøren din

Førre veke kunne ein brukar logge på VPN og enda likevel på eit nettverk der ingenting vart løyst. Klienten sa tilkopla, gateway-loggen sa Access-Accept, og identitetsteamet sa at kontoen var i orden. Pålogginga hadde fungert; autorisasjonen bak henne ikkje. Når ei VPN-pålogging mislykkast, går eg vegen førespurnaden faktisk tek — klient, gateway, RADIUS-server, identitetsleverandør — og stoppar ved det første hoppet der svaret ikkje stemmer med det neste.

Klienten snakkar aldri RADIUS

Uansett kva appen på laptoppen viser, er første hopp VPN-protokollen: IKEv2, OpenVPN, WireGuard eller ein TLS-basert klient. RADIUS finst ikkje i den utvekslinga. Klienten autentiserer seg mot gatewayen med eit sertifikat, eit brukarnamn og passord, eller ein EAP-metode som blir boren inne i tunneloppsettet.

Det har noko å seie når du les loggar, fordi den generiske autentiseringsfeilen brukaren ser, blir produsert av gatewayen etter at han allereie har snakka med noko anna. Viss klienten aldri når gatewayen, finst det ingen RADIUS-førespurnad å feilsøkje, og ein time på RADIUS-serveren er bortkasta. Stadfest at tunnelen i det heile kom opp før du rører backenden.

Gatewayen er RADIUS-klienten

Når tunneloppsettet når punktet der legitimasjon må kontrollerast, blir gatewayen ein nettverkstilgangsserver. Han byggjer ein Access-Request: User-Name, eit passord eller EAP-nyttelast, NAS-IP-Address eller NAS-Identifier, og ein Message-Authenticator når metoden krev det. Førespurnaden går som standard til UDP 1812, og rekneskapen til 1813. Eldre installasjonar brukar framleis 1645 og 1646, så ein brannmurregel skriven for eitt par forklarer mange stille feil.

Begge sider deler ein hemmelegheit, og ho er ikkje ein brukarlegitimasjon. Ho signerer utvekslinga, og kvart svar blir verifisert mot henne. Konfigurer hemmelegheita ulikt på dei to sidene, og serveren svarar ikkje med feil hemmelegheit — han slepp førespurnaden eller svaret feilar verifiseringa, så gatewayen rapporterer tidsavbrot. Ei feil hemmelegheit og ein død server ser identiske ut frå gatewayen, derfor testar eg hoppet med eit klientverktøy før eg klandrar katalogen.

Protokollen er liten og gammal — RFC 2865 definerer autentiseringsutvekslinga — men attributta han ber, er det meste av VPN-policy er bygd på.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

RADIUS-serveren er kanskje berre fronten for identitetsleverandøren

Folk snakkar om RADIUS og identitetsleverandør som om dei var same boks. Ofte er dei ikkje det. RADIUS-serveren tek imot Access-Request og spør deretter noko anna — Active Directory over LDAP eller Kerberos, ei lokal brukarfil eller ein ekstern teneste — før han svarar. FreeRADIUS med LDAP- eller krb5-modulen, Windows NPS og Cisco ISE står alle i denne posisjonen.

Forskjellen avgjer kvar du ser. Eit avvist passord er eit svar frå identitetsleverandøren som RADIUS videresender. Eit tidsavbrot er vanlegvis strekninga RADIUS-til-katalog: ein utløpen bind-konto, ein utilgjengeleg katalog eller ein førespurnad ruta til feil backend. Viss brukarnamnet har eit domenesuffiks, kan serveren rute på det, og same konto send som CORP\alice og [email protected] kan enda på ulike stader. På Windows NPS registrerer Security-loggen 6272 for ei innvilging og 6273 for ei avvising, noko som fortel om avgjerda i det heile kom frå NPS.

Les feilen ved hoppet som produserte han

Éi kan-ikkje-kople-til-melding dekkjer fire ulike feil. Før du endrar noko, match symptomet til hoppet som produserte det.

Den siste rada er den som sender folk til feil team. Access-Accept betyr at legitimasjonen vart akseptert; det betyr ikkje at gatewayen har plassert brukaren i riktig pool eller dytta ruter. Gruppeattributt betyr berre noko viss gateway-policyen les dei. Eg har sett ei korrekt pålogging enda i ein gjestepool fordi gruppemappinga var konfigurert på RADIUS-sida for eit anna attributt enn det gatewayen undersøkjer.

Følg éi pålogging frå start til slutt

Vel éin testkonto og éin gateway, og sjå deretter det same forsøket på alle fire punkt. Start ein feilsøkingskøyring på RADIUS-sida — freeradius -X skriv ut førespurnaden og kvar modul han rører — følg autentiseringsloggen til gatewayen, og køyr tcpdump for UDP-utvekslinga. Kople til éin gong og les dei fire spora i rekkjefølgje.

Det du vil sjå, er semje: gatewayen spurde om brukaren du venta, RADIUS-serveren valde backenden du venta, den backenden returnerte ei avgjerd, og attributta i svaret samsvarar med policyen gatewayen brukar. Det første staden spora er usamde, er feilgrensa di. Viss svaret ikkje ber eit gruppeattributt, er problemet på RADIUS-sida, ikkje i VPN-profilen; viss attributtet er der og gatewayen ignorerer det, er gateway-policyen problemet.

Ei tryggingsmerknad medan du er der. Den delte hemmelegheita vernar utvekslinga, men ho krypterer ikkje dei fleste attributta. Viss gatewayen og RADIUS-serveren ligg i ulike segment, legg det hoppet på RADIUS over TLS eller ein privat veg. Ein kryptert brukartunnel seier ingenting om backend-tilkoplinga.

Før du lukkar saka, stadfest fire ting. Gatewayen når RADIUS-serveren på porten han faktisk er konfigurert for. Den delte hemmelegheita stemmer på begge sider. RADIUS-serveren løyser opp den nøyaktige brukarnamnforma gatewayen sender. Aksepten ber attributta gateway-policyen treng. Når alle fire held, er ei pålogging som framleis feilar eit gateway-policyproblem, ikkje eit autentiseringsproblem.