EAP sau certificate de client? Deciderea autentificării IKEv2

Gateway-ul dumneavoastră poate dovedi propria identitate cu un certificat în timp ce o dovedește pe a dumneavoastră prin EAP, iar această combinație este obișnuită, nu contradictorie. Cele două mecanisme răspund la întrebări diferite: este acest punct final cel pe care îl aștept, și este acest utilizator sau dispozitiv permis. Vederea EAP într-un profil nu dezactivează validarea serverului. Tocmai citirea profilului ca o singură setare îi trimite pe oameni să reseteze acreditarea greșită.

Stabiliți care afirmație a eșuat înainte de a atinge oricare dintre cele două obiecte. Etapa eșecului vă spune, dacă o citiți în ordine.

Două acreditări, două afirmații

Un certificat de server leagă un nume de o cheie, iar clientul verifică acea legătură față de depozitul său de încredere. Un certificat de client leagă o identitate de o cheie, iar gateway-ul verifică dacă certificatul prezentat se înlănțuie la ceva în care are încredere. EAP transportă un schimb de autentificare al cărui conținut depinde de metoda aleasă. Acestea sunt trei structuri cu durate de viață, proprietari și moduri de eșec diferite.

O frază de acces care deblochează o cheie privată nu este o parolă de cont, chiar și atunci când ambele solicitări apar la câteva secunde una de alta. Una este locală în depozitul de chei al dispozitivului, iar cealaltă este validată de un server de autentificare din spatele gateway-ului.

EAP este un container, nu o metodă

EAP este un cadru: gateway-ul și clientul negociază o metodă, iar metoda decide dacă sunt implicate o parolă, un token, un schimb intern tunelat sau un certificat, după cum arată documentația strongSwan despre IKEv2. De aceea EAP-TLS nu seamănă deloc cu EAP-MSCHAPv2 din partea clientului, deși ambele apar ca EAP într-un meniu. Un profil care numește doar EAP nu v-a spus ce i se va cere utilizatorului.

Citiți metoda și backend-ul împreună. Backend-ul determină formatul contului, comportamentul de blocare și ce schimbă de fapt o resetare de parolă, iar nimic din toate acestea nu este vizibil în profilul clientului.

Implementarea mixtă este normală

Certificat de server plus EAP pentru utilizator este forma pe care o implementează majoritatea gateway-urilor de acces la distanță, pentru că îi dă clientului un punct final verificabil și operatorului o identitate per utilizator într-un depozit central de conturi. Există și implementări cu certificate de client, de obicei acolo unde identitatea dispozitivului contează mai mult decât o parolă. Ambele sunt legitime, iar greșeala este să presupuneți că ceea ce ați văzut săptămâna trecută este ceea ce aveți în față.

Cereți operatorului metoda și formatul contului documentate, în loc să le deduceți din numele câmpurilor dintr-un client.

Decizia după etapa eșecului

Ordonați observațiile. O eroare de încredere înainte de orice solicitare a utilizatorului este o problemă de certificat de server și nicio parolă nu o rezolvă. O solicitare urmată de un refuz este o problemă de autentificare a utilizatorului, cu metoda EAP și backend-ul ca suspecți. O autentificare reușită urmată de un eșec child-SA nu este nici una, nici alta.

Mai contează două distincții. Un client care refuză certificatul de server raportează de obicei o nepotrivire de nume sau o autoritate necunoscută, ceea ce este o chestiune de depozit de încredere. Un gateway care refuză utilizatorul înregistrează adesea metoda EAP și o categorie de motiv, ceea ce este o chestiune de cont sau de politică.

Operarea celor două modele

La certificate, munca este emiterea, reînnoirea, revocarea și eliminarea dispozitivelor pierdute, și se întâmplă după un calendar pe care îl controlați. La EAP, munca este ciclul de viață al contului, suportul metodelor pe fiecare platformă client și orice al doilea factor cerut de backend. Niciun model nu este mai ieftin în abstract; ele încarcă echipe diferite. Notați pe care îl folosește de fapt implementarea dumneavoastră, pentru că scripturile de suport diferă mai mult decât configurația.

Țineți-le separate în notele dumneavoastră. Expirarea unui certificat produce un eșec la o dată, blocarea unui cont produce un eșec după o schimbare de parolă, iar o nepotrivire de metodă produce un eșec doar pe o platformă.

După ce identitatea este acceptată

Autentificarea este o poartă. Asocierea de securitate copil, selectorii de trafic, DNS și permisiunile aplicației înseși sunt porți ulterioare, iar fiecare eșuează în propriii termeni. O identitate acceptată care nu ajunge nicăieri nu este o problemă de autentificare.

Notați metoda, contul sau certificatul folosit și etapa care a eșuat. Acea notă transformă următorul incident într-o căutare în loc de un experiment.