EAP vai asiakasvarmenteet? IKEv2-todennuksen päättäminen

Yhdyskäytäväsi voi todistaa oman identiteettinsä varmenteella ja sinun identiteettisi EAP:n kautta, ja tämä yhdistelmä on tavallinen eikä ristiriitainen. Kaksi mekanismia vastaavat eri kysymyksiin: onko tämä päätepiste se, jota odotan, ja onko tämä käyttäjä tai laite sallittu. EAP:n näkeminen profiilissa ei kytke palvelimen vahvistusta pois päältä. Profiilin lukeminen yhtenä asetuksena on se, mikä saa ihmiset nollaamaan väärän tunnisteen.

Selvitä, mikä väite epäonnistui, ennen kuin kosket kumpaakaan objektiin. Epäonnistumisen vaihe kertoo sen, jos luet sen järjestyksessä.

Kaksi tunnistetta, kaksi väitettä

Palvelinvarmente sidot nimen avaimeen, ja asiakas tarkistaa tämän sidoksen luottamusvarastostaan. Asiakasvarmenne sitoo identiteetin avaimeen, ja yhdyskäytävä tarkistaa, ketjuuntuuko esitetty varmenne johonkin, johon se luottaa. EAP kuljettaa todennusvaihtoa, jonka sisältö riippuu valitusta menetelmästä. Nämä ovat kolme rakennetta, joilla on eri elinajat, eri omistajat ja eri vikatilat.

Yksityisen avaimen avaava salalause ei ole tilin salasana, vaikka molemmat kehotteet ilmestyvät sekuntien välein. Toinen on paikallinen laitteen avainvarastossa, ja toisen validoi yhdyskäytävän takana oleva todennuspalvelin.

EAP on säiliö, ei menetelmä

EAP on kehys: yhdyskäytävä ja asiakas neuvottelevat menetelmän, ja menetelmä päättää, onko mukana salasana, token, tunnelioitu sisäinen vaihto vai varmenne, kuten strongSwanin IKEv2-dokumentaatio selvittää. Siksi EAP-TLS ei asiakkaan puolelta muistuta lainkaan EAP-MSCHAPv2:ta, vaikka molemmat näkyvät valikossa EAP:na. Profiili, joka nimeää vain EAP:n, ei ole kertonut, mitä käyttäjältä kysytään.

Lue menetelmä ja taustajärjestelmä yhdessä. Taustajärjestelmä määrää tilin muodon, lukituksen käyttäytymisen ja sen, mitä salasanan nollaus todella muuttaa, eikä mikään siitä näy asiakasprofiilissa.

Sekamuotoinen käyttöönotto on normaalia

Palvelinvarmente plus EAP käyttäjälle on muoto, jonka useimmat etäkäyttöyhdyskäytävät ottavat käyttöön, koska se antaa asiakkaalle todennettavan päätepisteen ja operaattorille käyttäjäkohtaisen identiteetin keskitettyyn tilivarastoon. Myös asiakasvarmenteisiin perustuvia käyttöönottoja on, yleensä silloin kun laitteen identiteetti on tärkeämpi kuin salasana. Molemmat ovat päteviä, ja virhe on olettaa, että viime viikolla näkemäsi on se, mikä on edessäsi.

Kysy operaattorilta dokumentoitu menetelmä ja tilin muoto sen sijaan, että päättelet ne asiakkaan kenttänimistä.

Päätös epäonnistumisen vaiheesta

Järjestä havainnot. Luottamusvirhe ennen mitään käyttäjäkehottetta on palvelinvarmenteen ongelma, eikä mikään salasana korjaa sitä. Kehote, jota seuraa hylkäys, on käyttäjän todennuksen ongelma, ja epäiltyinä ovat EAP-menetelmä ja taustajärjestelmä. Onnistunut todennus, jota seuraa child-SA-virhe, ei ole kumpikaan.

Kaksi muuta eroa on tärkeä. Asiakas, joka hylkää palvelinvarmenteen, ilmoittaa yleensä nimien eroavuudesta tai tuntemattomasta myöntäjästä, mikä on luottamusvaraston kysymys. Yhdyskäytävä, joka hylkää käyttäjän, kirjaa usein EAP-menetelmän ja syyluokan, mikä on tilin tai käytännön kysymys.

Kahden mallin käyttö

Varmenteissa työ on myöntäminen, uusiminen, mitätöinti ja kadonneiden laitteiden poisto, ja se tapahtuu aikataululla, jota hallitset. EAP:ssa työ on tilin elinkaari, menetelmätuki jokaisella asiakasalustalla ja se toinen tekijä, jota taustajärjestelmä vaatii. Kumpikaan malli ei ole abstraktisti halvempi; ne kuormittavat eri tiimejä. Kirjoita muistiin, kumpaa käyttöönottoasi todella käyttää, koska tukiskriptit eroavat enemmän kuin kokoonpano.

Pidä ne muistiinpanoissasi erillään. Varmenteen vanheneminen tuottaa virheen tiettynä päivänä, tilin lukitus tuottaa virheen salasanan vaihdon jälkeen ja menetelmän eroavuus tuottaa virheen vain yhdellä alustalla.

Kun identiteetti on hyväksytty

Todennus on yksi portti. Alisteinen suojausyhteys, liikenteen valitsimet, DNS ja sovelluksen omat käyttöoikeudet ovat myöhempiä portteja, ja kukin epäonnistuu omilla ehdoillaan. Hyväksytty identiteetti, joka ei saavuta mitään, ei ole todennuksen ongelma.

Kirjaa menetelmä, käytetty tili tai varmenne ja vaihe, joka epäonnistui. Tämä merkintä tekee seuraavasta tapauksesta haun eikä kokeen.