IKEv1 XAuthin ja OTP:n kanssa: mitä kukin kenttä kysyy

IKEv1 PSK:n, XAuthin ja OTP:n kanssa ei kysy yhtä monimutkaista salasanaa. Se kerrostaa vertaisten välisen jaetun avaimen, käyttäjävaihdon ja toisen tekijän, jonka kysymistavan backend päättää. Jokaisella kerroksella on oma omistajansa ja oma virheilmoituksensa. Niiden sekoittaminen saa ihmiset kirjoittamaan kertakäyttökoodin uudelleen kenttään, joka tallentaa ryhmäsalaisuuden.

Yhdistä jokainen kenttä siihen kerrokseen, joka sitä kysyy, ennen kuin asennat toisen asiakkaan tai nollaat tunnistetiedon.

Kolme salaisuutta, kolme omistajaa

Jaettu avain kuuluu vertaissuhteeseen ja sen määrittää kerran se, joka omistaa molemmat päät. Käyttäjän tunnistetieto kuuluu todennuksen backendille ja se tarkistetaan joka kirjautumisella. Toinen tekijä kuuluu token-järjestelmälle, jonka vastaus muuttuu joka yrityksellä. Mikään ei korvaa toista, ja käyttöönotto, joka kohtelee niitä yhtenä salasanana, epäonnistuu kerroksessa, jota kukaan ei dokumentoinut.

Kirjoita kolme saraketta: omistaja, elinikä ja virheilmoitus, jonka kukin tuottaa. Se taulukko on diagnostiikkatyökalu, asiakkaan kenttänimet eivät.

PSK: vastapuoli, ei henkilö

Jaettu avain todentaa yhdyskäytäväparin tässä vanhassa järjestelyssä, joten käyttäjän kirjautuminen ei koskaan korvaa sitä. Se on myös arvo, joka todennäköisimmin on väärin niin, että syntyy yleinen neuvotteluvirhe kentän sijaan. Kun tunneli epäonnistuu ennen kuin yhtään käyttäjäkenttää ilmestyy, epäillyt ovat avain tai ehdotukset.

Käyttäjän tunnistetieto ei voi korjata ensimmäisen vaiheen vikaa. Sen vaihtaminen tuhlaa ainoan tunnistetiedon, jonka voit turvallisesti vaihtaa, ja vahvistaa väärää teoriaa.

XAuth: vanha käyttäjävaihto

XAuth lisää käyttäjän todennusvaihdon IKEv1:n vertaistodennuksen päälle, ja yhdyskäytävä päättää, mikä backend sen vahvistaa. Tästä backendista riippuen vaihto voi hyväksyä hakemistosalasanan, RADIUS-tunnistetiedon tai token-vastauksen. Sana XAuth nimeää vaihdon kuljetuksen, ei tunnistetiedon tyyppiä.

Tarkista, mihin backendiin yhdyskäytäväprofiili osoittaa. Se kertoo, mitä käyttäjältä kysytään ja mitä salasanan nollaus todella muuttaa, eikä kumpikaan näy asiakasprofiilissa.

OTP: mitä backend pyytää

Jotkin käyttöönotot pyytävät salasanan jälkeen erillisen kertakäyttökoodin, ja toiset määrittelevät yhdistetyn syöttömuodon, jossa on dokumentoitu erotin. Molempia on, ja edessäsi oleva profiili päättää kumman. Yhdistämisen keksiminen siksi, että se toimi muualla, on yleisin tapa polttaa rekisteröintitoken. Yhdyskäytävän oma dokumentaatio on ainoa lähde, joka ratkaisee asian.

Käytä dokumentoitua muotoa asiakkaan kanssa, joka pystyy suorittamaan yhdyskäytävän tarjoaman vaihdon.

Missä asiakkaan raja puree

Fortinet dokumentoi, että FortiClient 7.4.4 ja uudemmat eivät enää tue IKEv1:tä IPsec VPN:ille, mikä on tuote- ja versioraja eikä yleinen poisto, kuten FortiClient-yhteensopivuushuomautus kirjaa. Muutkaan asiakkaat eivät ole vaihdettavissa: OpenConnect ja openfortivpn puhuvat tiettyjä yhdyskäytäväprotokollia, eivät mielivaltaisia IKEv1-profiileja. Tarkista asennetun asiakkaan IKE-versio, PSK-tila, XAuth-tuki ja vuorovaikutusmalli erikseen. Asiakas, joka yhdistää toisella menetelmällä, ei ole todistanut alkuperäistä vaatimusta.

IKEv1 on vanhentunut, joten uusi käyttöönotto tukemattomalla vanhalla asiakkaalla on lyhytikäinen ratkaisu. Pyydä yhdyskäytävän omistajalta tuettu siirtymäpolku, mukaan lukien miten toinen tekijä siellä hoidetaan.

Diagnosointi kytkemättä tekijää pois

Erottele lokissa vaiheet: vertaisneuvottelu, käyttäjävaihto, toisen tekijän tulos, sitten osoitteen ja reitin jako. Kirjaa komponentti ja vaihe sen sijaan, että kokeilisit koodia jokaisessa kentässä. Tekijän kytkeminen pois, jotta testi menee läpi, tuottaa tunnelin, joka ei todista käyttöönotosta mitään.

Säilytä rekisteröintisalaisuudet ja jaettu avain suojatussa tallennuksessa organisaation prosessin mukaan. Pysyvässä tiedostossa oleva kertakäyttökoodi on tekijä, joka on lakannut olemasta sellainen.