Hur en VPN-inloggning når RADIUS och din identitetsleverantör

Förra veckan kunde en användare logga in på VPN och hamnade ändå på ett nätverk där ingenting löstes. Klienten sa ansluten, gateway-loggen sa Access-Accept och identitetsteamet sa att kontot var i ordning. Inloggningen hade fungerat; auktoriseringen bakom den inte. När en VPN-inloggning misslyckas går jag vägen som begäran faktiskt tar — klient, gateway, RADIUS-server, identitetsleverantör — och stannar vid det första hopp vars svar inte stämmer med nästa.

Klienten talar aldrig RADIUS

Vad appen på laptopen än visar är dess första hopp VPN-protokollet: IKEv2, OpenVPN, WireGuard eller en TLS-baserad klient. RADIUS förekommer inte i det utbytet. Klienten autentiserar sig mot gatewayen med ett certifikat, ett användarnamn och lösenord, eller en EAP-metod som bärs inne i tunneluppsättningen.

Det spelar roll när du läser loggar, eftersom det generiska autentiseringsfelet som användaren ser produceras av gatewayen efter att den redan har talat med något annat. Om klienten aldrig når gatewayen finns ingen RADIUS-begäran att felsöka, och en timme på RADIUS-servern är bortkastad. Bekräfta att tunneln överhuvudtaget kom upp innan du rör backend.

Gatewayen är RADIUS-klienten

Så snart tunneluppsättningen når punkten där uppgifterna måste kontrolleras blir gatewayen en nätverksåtkomstserver. Den bygger en Access-Request: User-Name, ett lösenord eller EAP-nyttolast, NAS-IP-Address eller NAS-Identifier, och en Message-Authenticator när metoden kräver det. Begäran går som standard till UDP 1812 och redovisningen till 1813. Äldre installationer använder fortfarande 1645 och 1646, så en brandväggsregel skriven för ett par förklarar många tysta fel.

Båda sidor delar en hemlighet, och den är inte en användaruppgift. Den signerar utbytet, och varje svar verifieras mot den. Konfigurera hemligheten olika på de två sidorna och servern svarar inte med fel hemlighet — den släpper begäran eller svaret klarar inte verifieringen, så gatewayen rapporterar timeout. En fel hemlighet och en död server ser identiska ut från gatewayen, därför testar jag hoppet med ett klientverktyg innan jag skyller på katalogen.

Protokollet är litet och gammalt — RFC 2865 definierar autentiseringsutbytet — men attributen det bär är den grund som det mesta av VPN-policyn bygger 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-servern är kanske bara fronten för identitetsleverantören

Folk pratar om RADIUS och identitetsleverantör som om de vore samma låda. Ofta är de inte det. RADIUS-servern tar emot Access-Request och frågar sedan något annat — Active Directory över LDAP eller Kerberos, en lokal användarfil eller en extern tjänst — innan den svarar. FreeRADIUS med LDAP- eller krb5-modulen, Windows NPS och Cisco ISE står alla i den här positionen.

Skillnaden avgör var du tittar. Ett avvisat lösenord är ett svar från identitetsleverantören som RADIUS vidarebefordrar. En timeout är vanligen sträckan RADIUS-till-katalog: ett utgånget bind-konto, en oåtkomlig katalog eller en begäran routad till fel backend. Om användarnamnet bär ett domänsuffix kan servern routa på det, och samma konto skickat som CORP\alice och [email protected] kan hamna på olika ställen. I Windows NPS registrerar Security-loggen 6272 för ett beviljande och 6273 för ett avslag, vilket säger om beslutet alls kom från NPS.

Läs felet vid det hopp som producerade det

Ett enda kan-inte-ansluta-meddelande täcker fyra olika fel. Innan du ändrar något, matcha symptomet mot hoppet som producerade det.

Den sista raden är den som skickar folk till fel team. Access-Accept betyder att uppgifterna accepterades; det betyder inte att gatewayen har placerat användaren i rätt pool eller tryckt ut rutter. Gruppattribut spelar bara roll om gateway-policyn läser dem. Jag har sett en korrekt inloggning hamna i en gästpool eftersom gruppmappningen var konfigurerad på RADIUS-sidan för ett annat attribut än det gatewayen inspekterar.

Följ en inloggning från början till slut

Välj ett testkonto och en gateway och observera sedan samma försök på alla fyra punkterna. Starta en felsökningskörning på RADIUS-sidan — freeradius -X skriver ut begäran och varje modul den berör — följ gatewayens autentiseringslogg och kör tcpdump för UDP-utbytet. Anslut en gång och läs de fyra spåren i ordning.

Det du vill se är enighet: gatewayen frågade om användaren du förväntade dig, RADIUS-servern valde backendet du förväntade dig, det backendet returnerade ett beslut, och attributen i svaret matchar policyn gatewayen tillämpar. Den första platsen där spåren inte stämmer är din felgräns. Om svaret inte bär ett gruppattribut ligger problemet på RADIUS-sidan, inte i VPN-profilen; om attributet finns och gatewayen ignorerar det är gateway-policyn problemet.

En säkerhetsnotering medan du är där. Den delade hemligheten skyddar utbytet men krypterar inte de flesta attributen. Om gatewayen och RADIUS-servern ligger i olika segment, lägg det hoppet på RADIUS över TLS eller en privat väg. En krypterad användartunnel säger ingenting om backend-länken.

Innan du stänger ärendet, bekräfta fyra saker. Gatewayen når RADIUS-servern på den port den faktiskt är konfigurerad för. Den delade hemligheten stämmer på båda sidor. RADIUS-servern löser upp den exakta användarnamnsform som gatewayen skickar. Accepten bär de attribut som gateway-policyn behöver. När alla fyra håller är en inloggning som fortfarande misslyckas ett gateway-policyproblem, inte ett autentiseringsproblem.