Eelmisel nädalal sai kasutaja VPN-i sisse logida ja maandus ikkagi võrgus, kus midagi ei lahendatud. Klient teatas ühendatud, lüüsi logi teatas Access-Accept ja identiteeditiim ütles, et konto on korras. Sisselogimine oli õnnestunud; selle taga olev autoriseerimine mitte. Kui VPN-i sisselogimine ebaõnnestub, käin läbi tee, mille päring tegelikult läbib — klient, lüüs, RADIUS-server, identiteedipakkuja — ja peatun esimese hüppe juures, mille vastus ei ühti järgmisega.

Klient ei räägi kunagi RADIUSit

Mida iganes sülearvuti rakendus näitab, on selle esimene hüpe VPN-protokoll: IKEv2, OpenVPN, WireGuard või TLS-põhine klient. RADIUS selles vahetuses ei esine. Klient autendib end lüüsi juures sertifikaadi, kasutajanime ja parooli või tunneliseadistuses kantava EAP-meetodiga.

See loeb logisid lugedes, sest üldise autentimisvea, mida kasutaja näeb, toodab lüüs pärast seda, kui on juba millegi muuga rääkinud. Kui klient ei jõua kunagi lüüsini, ei ole RADIUS-päringut, mida siluda, ja RADIUS-serveril veedetud tund on raisatud. Kinnitage, et tunnel üldse püsti tuli, enne kui backendile lähenete.

Lüüs on RADIUS-klient

Kui tunneliseadistus jõuab punkti, kus tuleb mandaate kontrollida, saab lüüsist võrgu juurdepääsu server. See koostab Access-Requesti: User-Name, parool või EAP kasulik koormus, NAS-IP-Address või NAS-Identifier ja Message-Authenticator, kui meetod seda nõuab. Päring läheb vaikimisi UDP 1812-le ja arvestus 1813-le. Vanemad paigaldused kasutavad endiselt 1645 ja 1646, nii et ühe paari jaoks kirjutatud tulemüürireegel seletab paljusid vaikseid tõrkeid.

Mõlemad pooled jagavad saladust ja see ei ole kasutaja mandaat. See allkirjastab vahetuse ja iga vastust kontrollitakse selle vastu. Seadistage saladus kahel poolel erinevalt ja server ei vasta halva saladusega — see viskab päringu ära või vastus ei läbi kontrolli, mistõttu lüüs teatab ajalõpust. Vale saladus ja surnud server näevad lüüsist ühesugused välja, seetõttu testin hüpet klienditööriistaga enne, kui kataloogi süüdistama hakkan.

Protokoll on väike ja vana — RFC 2865 määratleb autentimisvahetuse —, kuid atribuudid, mida see kannab, on alus, millele suurem osa VPN-poliitikast on ehitatud.

# 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-server võib olla ainult identiteedipakkuja esikülg

Inimesed räägivad RADIUSest ja identiteedipakkujast nii, nagu oleksid need sama kast. Tihti ei ole. RADIUS-server saab Access-Requesti ja küsib seejärel enne vastamist midagi muud — Active Directoryt LDAP-i või Kerberose kaudu, kohalikku kasutajafaili või välist teenust. FreeRADIUS LDAP- või krb5-mooduliga, Windows NPS ja Cisco ISE seisavad kõik selles positsioonis.

Erinevus otsustab, kuhu vaadata. Tagasilükatud parool on identiteedipakkuja vastus, mille RADIUS edasi annab. Ajalõpp on tavaliselt lõik RADIUSest kataloogini: aegunud sidumiskonto, kättesaamatu kataloog või valele backendile suunatud päring. Kui kasutajanimes on domeeni järelliide, võib server selle järgi marsruutida, ja sama konto CORP\alice ning [email protected] kujul saadetuna võib sattuda erinevatesse kohtadesse. Windows NPS-is kirjutab Security-logi lubamise korral 6272 ja keeldumise korral 6273, mis ütleb, kas otsus tuli üldse NPS-ist.

Lugege tõrget selle hüppe juures, mis selle tekitas

Üks mitte-ühenda-teade katab nelja erinevat tõrget. Enne millegi muutmist sobitage sümptom hüppega, mis selle tekitas.

What you seeWhere it comes fromFirst check
Gateway timeout, no replyShared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server addresstcpdump at the gateway; radtest from the gateway host
Immediate rejectCredentials, account state, domain suffix, RADIUS policyNPS 6273 or the FreeRADIUS auth log; test the account directly
Repeated challenge or MFA loopAccess-Challenge state not returned, or a token that expired mid-flowClient prompt timing and the State attribute in debug output
Accept, then no accessAuthorization attributes unmapped, wrong pool, route or ACL policyGateway policy and the attributes in the Access-Accept

Viimane rida on see, mis saadab inimesed vale meeskonna juurde. Access-Accept tähendab, et mandaadid võeti vastu; see ei tähenda, et lüüs paigutas kasutaja õigesse pooli või lükkas marsruudid. Grupi atribuudid loevad ainult siis, kui lüüsi poliitika neid loeb. Olen näinud korrektset sisselogimist maandumas külaliste pooli, sest grupimappimine oli RADIUSi poolel seadistatud teise atribuudi jaoks kui see, mida lüüs uurib.

Jälgige üht sisselogimist algusest lõpuni

Valige üks testkonto ja üks lüüs, seejärel jälgige sama katset kõigis neljas punktis. Käivitage silumine RADIUSi poolel — freeradius -X prindib päringu ja iga mooduli, mida see puudutab — jälgige lüüsi autentimislogi ja käivitage tcpdump UDP-vahetuse jaoks. Ühenduge üks kord ja lugege neli jälge järjekorras.

Mida te näha tahate, on üksmeel: lüüs küsis kasutaja kohta, keda ootasite, RADIUS-server valis backendi, mida ootasite, see backend tagastas otsuse ja vastuses olevad atribuudid vastavad poliitikale, mida lüüs rakendab. Esimene koht, kus jäljed lahknevad, on teie rikkejoon. Kui vastus ei kanna grupi atribuuti, on probleem RADIUSi poolel, mitte VPN-profiilis; kui atribuut on olemas ja lüüs eirab seda, on probleem lüüsi poliitikas.

Üks turvamärkus, kuni te seal olete. Jagatud saladus kaitseb vahetust, kuid ei krüpteeri enamikku atribuute. Kui lüüs ja RADIUS-server asuvad erinevates segmentides, pange see hüpe RADIUSele üle TLS-i või privaatse tee. Krüpteeritud kasutajatunnel ei ütle midagi backendi lingi kohta.

Enne pileti sulgemist kinnitage nelja asja. Lüüs pääseb RADIUS-serverile porti, mille jaoks see tegelikult seadistatud on. Jagatud saladus klapib mõlemal poolel. RADIUS-server lahendab täpselt selle kasutajanime kuju, mille lüüs saadab. Vastuvõtt kannab atribuute, mida lüüsi poliitika vajab. Kui kõik neli kehtivad, on ikka veel ebaõnnestuv sisselogimine lüüsi poliitika, mitte autentimise probleem.

Seotud artiklid