Sådan når et VPN-login frem til RADIUS og din identitetsudbyder

I sidste uge kunne en bruger logge ind på VPN'en og alligevel ende på et netværk, hvor intet blev opløst. Klienten sagde forbundet, gateway-loggen sagde Access-Accept, og identitetsteamet sagde, at kontoen var i orden. Login'et havde virket; autorisationen bag det havde ikke. Når et VPN-login fejler, følger jeg den vej, anmodningen faktisk tager — klient, gateway, RADIUS-server, identitetsudbyder — og stopper ved det første hop, hvis svar ikke stemmer med det næste.

Klienten taler aldrig RADIUS

Uanset hvad appen på bærbaren viser, er dens første hop VPN-protokollen: IKEv2, OpenVPN, WireGuard eller en TLS-baseret klient. RADIUS optræder ikke i den udveksling. Klienten autentificerer sig over for gatewayen med et certifikat, et brugernavn og en adgangskode eller en EAP-metode, der bæres inde i tunnelopsætningen.

Det betyder noget, når du læser logs, fordi den generiske godkendelsesfejl, brugeren ser, produceres af gatewayen, efter at den allerede har talt med noget andet. Hvis klienten aldrig når gatewayen, findes der ingen RADIUS-anmodning at fejlfinde, og en time på RADIUS-serveren er spildt. Bekræft, at tunnelen overhovedet kom op, før du rører backenden.

Gatewayen er RADIUS-klienten

Når tunnelopsætningen når det punkt, hvor legitimationsoplysninger skal kontrolleres, bliver gatewayen en netværksadgangsserver. Den bygger en Access-Request: User-Name, en adgangskode eller EAP-nyttelast, NAS-IP-Address eller NAS-Identifier og en Message-Authenticator, når metoden kræver det. Anmodningen går som standard til UDP 1812 og regnskab til 1813. Ældre installationer bruger stadig 1645 og 1646, så en firewallregel skrevet til det ene par forklarer mange tavse fejl.

Begge sider deler en hemmelighed, og den er ikke en brugerlegitimation. Den signerer udvekslingen, og hvert svar verificeres mod den. Konfigurer hemmeligheden forskelligt på de to sider, og serveren svarer ikke med en dårlig hemmelighed — den dropper anmodningen, eller svaret fejler verifikationen, så gatewayen rapporterer en timeout. En forkert hemmelighed og en død server ser ens ud fra gatewayen, og derfor tester jeg hoppet med et klientværktøj, før jeg bebrejder mappen.

Protokollen er lille og gammel — RFC 2865 definerer godkendelsesudvekslingen — men de attributter, den bærer, er det, som det meste VPN-politik bygges 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 måske kun front for identitetsudbyderen

Folk taler om RADIUS og identitetsudbyder, som om de var samme boks. Det er de ofte ikke. RADIUS-serveren modtager Access-Request og spørger derefter noget andet — Active Directory over LDAP eller Kerberos, en lokal brugerfil eller en ekstern tjeneste — før den svarer. FreeRADIUS med LDAP- eller krb5-modulet, Windows NPS og Cisco ISE står alle i denne position.

Forskellen afgør, hvor du kigger. En afvist adgangskode er et svar fra identitetsudbyderen, videregivet af RADIUS. En timeout er normalt strækningen RADIUS-til-mappe: en udløbet bind-konto, en utilgængelig mappe eller en anmodning sendt til den forkerte backend. Hvis brugernavnet bærer et domænesuffiks, kan serveren rute på det, og den samme konto sendt som CORP\alice og [email protected] kan ende forskellige steder. På Windows NPS registrerer Security-loggen 6272 for en tilladelse og 6273 for en afvisning, hvilket fortæller, om beslutningen overhovedet kom fra NPS.

Læs fejlen ved det hop, der producerede den

Én kan-ikke-forbinde-besked dækker fire forskellige fejl. Før du ændrer noget, skal du matche symptomet med det hop, der producerede det.

Den sidste række er den, der sender folk til det forkerte team. Access-Accept betyder, at legitimationsoplysningerne blev accepteret; det betyder ikke, at gatewayen har placeret brugeren i den rigtige pool eller skubbet ruter. Gruppeattributter betyder kun noget, hvis gateway-politikken læser dem. Jeg har set et korrekt login ende i en gæstepool, fordi gruppemappingen var konfigureret på RADIUS-siden til et andet attribut end det, gatewayen undersøger.

Følg ét login fra start til slut

Vælg én testkonto og én gateway, og se derefter det samme forsøg på alle fire punkter. Start en fejlfindingskørsel på RADIUS-siden — freeradius -X udskriver anmodningen og hvert modul, den rører — følg gatewayens godkendelseslog, og kør tcpdump for UDP-udvekslingen. Forbind én gang, og læs de fire spor i rækkefølge.

Det, du vil se, er enighed: gatewayen spurgte om den bruger, du forventede, RADIUS-serveren valgte den backend, du forventede, den backend returnerede en beslutning, og attributterne i svaret matcher den politik, gatewayen anvender. Det første sted, sporene er uenige, er din fejlgrænse. Hvis svaret ikke bærer et gruppeattribut, er problemet på RADIUS-siden, ikke i VPN-profilen; hvis attributtet er der, og gatewayen ignorerer det, er gateway-politikken problemet.

En sikkerhedsnote, mens du er der. Den delte hemmelighed beskytter udvekslingen, men den krypterer ikke de fleste attributter. Hvis gatewayen og RADIUS-serveren ligger i forskellige segmenter, skal det hop ligge på RADIUS over TLS eller en privat vej. En krypteret brugertunnel siger intet om backend-forbindelsen.

Før du lukker sagen, skal du bekræfte fire ting. Gatewayen kan nå RADIUS-serveren på den port, den faktisk er konfigureret til. Den delte hemmelighed stemmer på begge sider. RADIUS-serveren opløser den præcise brugernavnsform, gatewayen sender. Accepten bærer de attributter, gateway-politikken har brug for. Når alle fire holder, er et login, der stadig fejler, et gateway-politikproblem, ikke et godkendelsesproblem.