Miten VPN-kirjautuminen päätyy RADIUS-palvelimelle ja identiteetintarjoajallesi

Viime viikolla käyttäjä pystyi kirjautumaan VPN:ään ja päätyi silti verkkoon, jossa mikään ei ratkennut. Asiakas ilmoitti yhdistetyksi, yhdyskäytävän loki ilmoitti Access-Accept ja identiteettitiimi sanoi, että tili on kunnossa. Kirjautuminen oli onnistunut; sen takana oleva valtuutus ei. Kun VPN-kirjautuminen epäonnistuu, kuljen polun, jonka pyyntö tosiasiassa kulkee — asiakas, yhdyskäytävä, RADIUS-palvelin, identiteetintarjoaja — ja pysähdyn ensimmäiseen hyppyyn, jonka vastaus ei sovi seuraavaan.

Asiakas ei koskaan puhu RADIUS:ta

Mitä tahansa kannettavan sovellus näyttää, sen ensimmäinen hyppy on VPN-protokolla: IKEv2, OpenVPN, WireGuard tai TLS-pohjainen asiakas. RADIUS ei esiinny siinä vaihdossa. Asiakas todennetaan yhdyskäytävälle varmenteella, käyttäjätunnuksella ja salasanalla tai EAP-menetelmällä, jota kuljetetaan tunnelin asetuksissa.

Tällä on väliä lokeja lukiessa, koska yleisen todennusvirheen, jonka käyttäjä näkee, tuottaa yhdyskäytävä vasta juteltuaan jo jotain muuta. Jos asiakas ei koskaan saavuta yhdyskäytävää, virheenkorjattavaa RADIUS-pyyntöä ei ole, ja RADIUS-palvelimella vietetty tunti menee hukkaan. Varmista, että tunneli ylipäätään nousi, ennen kuin kosket taustajärjestelmään.

Yhdyskäytävä on RADIUS-asiakas

Kun tunnelin asetukset etenevät pisteeseen, jossa tunnistetiedot on tarkistettava, yhdyskäytävästä tulee verkon käyttöoikeuspalvelin. Se rakentaa Access-Requestin: User-Name, salasana tai EAP-hyötykuorma, NAS-IP-Address tai NAS-Identifier ja Message-Authenticator, kun menetelmä vaatii sen. Pyyntö menee oletuksena UDP 1812:een ja kirjanpito 1813:een. Vanhemmat asennukset käyttävät yhä portteja 1645 ja 1646, joten yhdelle parille kirjoitettu palomuurisääntö selittää monta hiljaista epäonnistumista.

Molemmat osapuolet jakavat salaisuuden, eikä se ole käyttäjän tunnistetieto. Se allekirjoittaa vaihdon, ja jokainen vastaus varmennetaan sitä vasten. Määritä salaisuus eri tavalla kahdella puolella, niin palvelin ei vastaa huonolla salaisuudella — se pudottaa pyynnön tai vastaus ei läpäise varmennusta, joten yhdyskäytävä ilmoittaa aikakatkaisusta. Väärä salaisuus ja kuollut palvelin näyttävät yhdyskäytävältä samalta, siksi testaan hypyn asiakastyökalulla ennen kuin syytän hakemistoa.

Protokolla on pieni ja vanha — RFC 2865 määrittelee todennusvaihdon — mutta sen kuljettamat attribuutit ovat se, jonka varaan suurin osa VPN-käytännöistä rakentuu.

# 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-palvelin voi olla vain identiteetintarjoajan etuosa

Ihmiset puhuvat RADIUS:sta ja identiteetintarjoajasta ikään kuin ne olisivat sama laatikko. Usein ne eivät ole. RADIUS-palvelin vastaanottaa Access-Requestin ja kysyy sitten ennen vastaamistaan jotain muuta — Active Directoryä LDAP:n tai Kerberoksen kautta, paikallista käyttäjätiedostoa tai ulkoista palvelua. FreeRADIUS LDAP- tai krb5-moduulilla, Windows NPS ja Cisco ISE seisovat kaikki tässä asemassa.

Ero ratkaisee, mihin katsot. Hylätty salasana on identiteetintarjoajan vastaus, jonka RADIUS välittää. Aikakatkaisu on yleensä RADIUS–hakemisto-osuus: vanhentunut bind-tili, tavoittamaton hakemisto tai väärään taustajärjestelmään ohjattu pyyntö. Jos käyttäjätunnuksessa on toimialueen jälkiliite, palvelin voi reitittää sen perusteella, ja sama tili muodossa CORP\alice ja [email protected] lähetettynä voi päätyä eri paikkoihin. Windows NPS:ssä Security-loki kirjaa 6272 myönnytyksestä ja 6273 hylkäyksestä, mikä kertoo, tuliko päätös ylipäätään NPS:stä.

Lue epäonnistuminen siltä hypyltä, joka sen tuotti

Yksi ei-voi-yhdistää-viesti kattaa neljä eri epäonnistumista. Ennen kuin muutat mitään, sovita oire siihen hyppyyn, joka sen tuotti.

Viimeinen rivi on se, joka lähettää ihmiset väärälle tiimille. Access-Accept tarkoittaa, että tunnistetiedot hyväksyttiin; se ei tarkoita, että yhdyskäytävä on sijoittanut käyttäjän oikeaan pooliin tai työntänyt reittejä. Ryhmäattribuutit merkitsevät vain, jos yhdyskäytävän käytäntö lukee ne. Olen nähnyt oikean kirjautumisen päätyvän vieraspooliin, koska ryhmien kartoitus oli RADIUS-puolella määritetty eri attribuutille kuin mille yhdyskäytävä tarkistaa.

Seuraa yksi kirjautuminen alusta loppuun

Valitse yksi testitili ja yksi yhdyskäytävä ja seuraa sitten samaa yritystä kaikissa neljässä pisteessä. Käynnistä virheenkorjaus RADIUS-puolella — freeradius -X tulostaa pyynnön ja jokaisen moduulin, johon se koskee — seuraa yhdyskäytävän todennuslokia ja aja tcpdump UDP-vaihtoa varten. Yhdistä kerran ja lue neljä jälkeä järjestyksessä.

Haluat nähdä yhteisymmärryksen: yhdyskäytävä kysyi käyttäjää, jota odotit, RADIUS-palvelin valitsi taustajärjestelmän, jota odotit, se palautti päätöksen ja vastauksen attribuutit vastaavat käytäntöä, jota yhdyskäytävä soveltaa. Ensimmäinen kohta, jossa jäljet eroavat, on vikarajasi. Jos vastaus ei kanna ryhmäattribuuttia, ongelma on RADIUS-puolella, ei VPN-profiilissa; jos attribuutti on siellä ja yhdyskäytävä jättää sen huomiotta, ongelma on yhdyskäytävän käytäntö.

Yksi turvahuomio, kun olet siellä. Jaettu salaisuus suojaa vaihdon, mutta se ei salaa useimpia attribuutteja. Jos yhdyskäytävä ja RADIUS-palvelin ovat eri segmenteissä, laita tämä hyppy RADIUS:lle TLS:n tai yksityisen polun yli. Salattu käyttäjätunneli ei kerro mitään taustajärjestelmän yhteydestä.

Ennen kuin suljet tiketin, varmista neljä asiaa. Yhdyskäytävä tavoittaa RADIUS-palvelimen portilla, jolle se on tosiasiassa määritetty. Jaettu salaisuus täsmää molemmilla puolilla. RADIUS-palvelin ratkaisee sen käyttäjätunnuksen muodon, jonka yhdyskäytävä lähettää. Hyväksyntä kuljettaa attribuutit, jotka yhdyskäytävän käytäntö tarvitsee. Kun kaikki neljä pitävät, kirjautuminen, joka yhä epäonnistuu, on yhdyskäytävän käytäntöongelma, ei todennusongelma.