Hoe't in VPN-oanmelding RADIUS en jo identiteitsprovider berikt

Ferline wike koe in brûker oanmelde by de VPN en kaam dochs op in netwurk telâne dêr't neat oplost waard. De klient sei ferbûn, it loch fan 'e poarte sei Access-Accept, en it identiteitsteam sei dat it akkount yn oarder wie. De oanmelding hie wurke; de autorisaasje derachter net. As in VPN-oanmelding mislearret, folgje ik it paad dat it fersyk eins nimt — klient, poarte, RADIUS-tsjinner, identiteitsprovider — en stopje by de earste sprong waans antwurd net mei de folgjende oerienkomt.

De klient praat nea RADIUS

Wat de app op 'e laptop ek lit sjen, syn earste sprong is it VPN-protokol: IKEv2, OpenVPN, WireGuard of in TLS-basearre klient. RADIUS ferskynt net yn dy útwikseling. De klient autentisearret him by de poarte mei in sertifikaat, in brûkersnamme en wachtwurd, of in EAP-metoade dy't yn 'e tunnelopsetsjen meidroegen wurdt.

Dat makket út as jo lochs lêze, want de algemiene autentikaasjeflater dy't de brûker sjocht, wurdt troch de poarte makke neidat dy al mei wat oars praat hat. As de klient de poarte nea berikt, bestiet der gjin RADIUS-fersyk om te debuggen, en in oere op 'e RADIUS-tsjinner is ferkuolle. Befestigje dat de tunnel uberhaupt omheech kaam foardat jo de backend oanreitsje.

De poarte is de RADIUS-klient

Sa gau't de tunnelopsetsjen it punt berikt dêr't de oanmeldgegevens kontrolearre wurde moatte, wurdt de poarte in netwurktoegongstsjinjer. Hy bout in Access-Request: User-Name, in wachtwurd of EAP-lading, NAS-IP-Address of NAS-Identifier, en in Message-Authenticator as de metoade dat freget. It fersyk giet by default nei UDP 1812, en de boekhâlding nei 1813. Aldere ynstallaasjes brûke noch 1645 en 1646, dus in firewallregel foar ien pear ferklearret in soad stille mislearrings.

Beide kanten diele in geheim, en dat is gjin brûkersgegevens. It ûndertekenet de útwikseling, en elk antwurd wurdt dêr tsjin ferifiearre. Stel it geheim oan beide kanten oars yn en de tsjinner antwurdet net mei in ferkeard geheim — hy smyt it fersyk fuort of it antwurd falt troch de ferifikaasje, sadat de poarte in time-out meldt. In ferkeard geheim en in deade tsjinner sjogge der fan 'e poarte itselde út, dêrom test ik de sprong mei in klientark foardat ik de map de skuld jou.

It protokol is lyts en âld — RFC 2865 definiearret de autentikaasje-útwikseling — mar de attributen dy't it draacht, binne wêr't it measte VPN-belied op boud is.

# 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'

De RADIUS-tsjinner stiet miskien allinnich foar de identiteitsprovider

Minsken prate oer RADIUS en identiteitsprovider as wiene it deselde doaze. Faak is dat net sa. De RADIUS-tsjinner ûntfangt it Access-Request en freget dan ear't er antwurdet wat oars — Active Directory fia LDAP of Kerberos, in lokaal brûkersbestân of in eksterne tsjinst. FreeRADIUS mei de LDAP- of krb5-module, Windows NPS en Cisco ISE steane allegear op dit plak.

It ûnderskied bepaalt wêr't jo sjogge. In wegere wachtwurd is in antwurd fan 'e identiteitsprovider dat RADIUS trochjout. In time-out is meastentiids it stik fan RADIUS nei de map: in ferrûn bind-akkount, in net berikbere map of in fersyk dat nei de ferkearde backend stjoerd is. As de brûkersnamme in domein-suffiks hat, kin de tsjinner dêrop routearje, en itselde akkount stjoerd as CORP\alice en [email protected] kin op ferskate plakken telâne komme. Op Windows NPS registrearret it Security-loch 6272 foar in talitting en 6273 foar in wegering, wat jo fertelt oft it beslút uberhaupt fan NPS kaam.

Lês de mislearring by de sprong dy't him makke hat

Ien kin-net-ferbine-berjocht dekt fjouwer ferskate mislearrings. Foardat jo wat feroarje, keppelje it symptoom oan 'e sprong dy't it makke hat.

De lêste rige is dejinge dy't minsken nei it ferkearde team stjoert. Access-Accept betsjut dat de oanmeldgegevens akseptearre binne; it betsjut net dat de poarte de brûker yn 'e goede pool set hat of rûtes skood hat. Groepattributen telle allinnich as it poartebelied se lêst. Ik haw sjoen dat in korrekte oanmelding yn in gastpool telâne kaam om't de groepsmap op 'e RADIUS-kant ynsteld wie foar in oar attribút as dat de poarte ûndersiket.

Folgje ien oanmelding fan begjin oant ein

Kies ien testakkount en ien poarte, en besjoch dan deselde poging op alle fjouwer punten. Start in debug-run oan 'e RADIUS-kant — freeradius -X prints it fersyk en elke module dy't er oanreitset — folgje it autentikaasjeloch fan 'e poarte, en rin tcpdump foar de UDP-útwikseling. Ferbyn ien kear en lês de fjouwer spoaren yn folchoarder.

Wat jo sjen wolle, is oerienstimming: de poarte frege nei de brûker dy't jo ferwachten, de RADIUS-tsjinner keas de backend dy't jo ferwachten, dy backend joech in beslút werom, en de attributen yn it antwurd passe by it belied dat de poarte tapast. It earste plak dêr't de spoaren net oerienkomme, is jo flatergrins. As it antwurd gjin groepattribút draacht, is it probleem oan 'e RADIUS-kant, net yn it VPN-profyl; as it attribút der is en de poarte negearret it, is it poartebelied it probleem.

Ien feiligensnotyske wylst jo dêr binne. It dielde geheim beskermet de útwikseling, mar it fersifert de measte attributen net. As de poarte en de RADIUS-tsjinner op ferskate segminten sitte, set dy sprong dan op RADIUS oer TLS of in priveepaad. In fersifere brûkerstunnel seit neat oer de backend-ferbining.

Foardat jo it ticket slute, befestigje fjouwer dingen. De poarte kin de RADIUS-tsjinner berikke op 'e poarte dêr't er echt foar ynsteld is. It dielde geheim komt oan beide kanten oerien. De RADIUS-tsjinner lost de krekte foarm fan 'e brûkersnamme op dy't de poarte stjoert. De akseptaasje draacht de attributen dy't it poartebelied nedich hat. As alle fjouwer jilde, is in oanmelding dy't noch mislearret in poartebeliedsprobleem, net in autentikaasjeprobleem.