EAP ar kliento sertifikatai? IKEv2 autentifikavimo sprendimas
Du prisijungimo duomenys, du darbai: vienas įrodo galinį tašką, kitas – naudotoją. Nustatykite, kuris etapas nepavyko, prieš iš naujo nustatydami slaptažodį ar išduodami sertifikatą.
Jūsų tinklo vartai gali įrodyti savo tapatybę sertifikatu ir jūsų – per EAP, ir šis derinys yra įprastas, o ne prieštaringas. Du mechanizmai atsako į skirtingus klausimus: ar šis galinis taškas yra tas, kurio tikiuosi, ir ar šiam naudotojui ar įrenginiui leidžiama. EAP matymas profilyje neišjungia serverio patikros. Būtent profilio skaitymas kaip vieno nustatymo skatina žmones iš naujo nustatyti ne tuos prisijungimo duomenis.
Nustatykite, kuris teiginys nepavyko, prieš liesdami bet kurį iš dviejų objektų. Nesėkmės etapas tai pasakys, jei skaitysite iš eilės.
Du prisijungimo duomenys, du teiginiai
Serverio sertifikatas susieja vardą su raktu, o klientas tikrina tą ryšį savo patikimumo saugykloje. Kliento sertifikatas susieja tapatybę su raktu, o vartai tikrina, ar pateiktas sertifikatas susijęs grandine su tuo, kuo jie pasitiki. EAP perduoda autentifikavimo mainus, kurių turinys priklauso nuo pasirinkto metodo. Tai trys struktūros su skirtingu galiojimo laiku, skirtingais savininkais ir skirtingais gedimo būdais.
Privataus rakto užraktą atverianti slaptafrazė nėra paskyros slaptažodis, net kai abu raginimai pasirodo per kelias sekundes vienas nuo kito. Vienas yra vietinis įrenginio raktų saugykloje, o kitą tikrina autentifikavimo serveris už vartų.
EAP yra talpykla, o ne metodas
EAP yra sistema: vartai ir klientas derasi dėl metodo, o metodas nusprendžia, ar dalyvauja slaptažodis, žetonas, tuneliuotas vidinis mainas ar sertifikatas, kaip nurodo strongSwan IKEv2 dokumentacija. Štai kodėl EAP-TLS iš kliento pusės visai neprimena EAP-MSCHAPv2, nors abu meniu rodomi kaip EAP. Profilis, kuriame nurodytas tik EAP, nepasakė, ko naudotojo bus klausiama.
Skaitykite metodą ir backend kartu. Backend nustato paskyros formatą, užrakinimo elgesį ir tai, ką iš tikrųjų pakeičia slaptažodžio nustatymas iš naujo, ir nieko iš to nesimato kliento profilyje.
Mišrus diegimas yra normalus
Serverio sertifikatas ir EAP naudotojui yra forma, kurią diegia dauguma nuotolinės prieigos vartų, nes ji klientui suteikia patikrinamą galinį tašką, o operatoriui – kiekvieno naudotojo tapatybę centrinėje paskyrų saugykloje. Yra ir diegimų su kliento sertifikatais, paprastai ten, kur įrenginio tapatybė svarbesnė už slaptažodį. Abu teisėti, o klaida yra manyti, kad tai, ką matėte praėjusią savaitę, yra tai, kas priešais jus.
Klauskite operatoriaus dokumentuoto metodo ir paskyros formato, o ne spėkite juos iš laukų pavadinimų kliente.
Sprendimas pagal nesėkmės etapą
Sudėliokite stebėjimus iš eilės. Pasitikėjimo klaida prieš bet kokį naudotojo raginimą yra serverio sertifikato problema, ir joks slaptažodis jos neištaisys. Raginimas, po kurio ateina atmetimas, yra naudotojo autentifikavimo problema, o įtariamieji yra EAP metodas ir backend. Sėkmingas autentifikavimas, po kurio nepavyksta child-SA, nėra nė vienas iš jų.
Svarbūs dar du skirtumai. Klientas, atmetantis serverio sertifikatą, paprastai praneša apie vardo neatitikimą ar nežinomą instituciją, o tai yra patikimumo saugyklos klausimas. Vartai, atmetantys naudotoją, dažnai registruoja EAP metodą ir priežasties kategoriją, o tai yra paskyros ar politikos klausimas.
Abiejų modelių valdymas
Sertifikatų atveju darbas yra išdavimas, atnaujinimas, panaikinimas ir pamestų įrenginių pašalinimas, ir jis vyksta pagal jūsų kontroliuojamą grafiką. EAP atveju darbas yra paskyros gyvavimo ciklas, metodų palaikymas kiekvienoje kliento platformoje ir bet koks antrasis veiksnys, kurio reikalauja backend. Nė vienas modelis nėra abstrakčiai pigesnis; jie apkrauna skirtingas komandas. Užsirašykite, kurį jūsų diegimas iš tikrųjų naudoja, nes palaikymo scenarijai skiriasi labiau nei konfigūracija.
Laikykite juos atskirai savo užrašuose. Sertifikato galiojimo pabaiga sukelia gedimą konkrečią datą, paskyros užrakinimas sukelia gedimą po slaptažodžio pakeitimo, o metodo neatitikimas sukelia gedimą tik vienoje platformoje.
Kai tapatybė priimta
Autentifikavimas yra vieni vartai. Dukterinė saugos asociacija, srauto parinkikliai, DNS ir pačios programos leidimai yra vėlesni vartai, ir kiekvieni nepavyksta savo sąlygomis. Priimta tapatybė, kuri nieko nepasiekia, nėra autentifikavimo problema.
Užrašykite metodą, naudotą paskyrą ar sertifikatą ir etapą, kuris nepavyko. Šis užrašas paverčia kitą incidentą paieška, o ne eksperimentu.