„Nu-mi mai cere parola” reunește de fapt trei cerințe într-o singură plângere, iar o implementare pe iPad le răspunde în locuri diferite. Solicitarea vine din autentificare, momentul din activare și acoperirea din aplicarea forțată. Alegeți mai întâi acreditarea care elimină solicitarea, apoi decideți separat ce determină când se deschide tunelul. Amestecarea celor două decizii este exact motivul pentru care o parolă salvată ajunge pe un profil care încă așteaptă o atingere.

Saved or shared secretDevice certificate
What the user seesno prompt while the credential stays validno prompt, no password to rotate
What the admin managesthe secret in the profile and its distributionenrollment, expiry and revocation per device
Typical failuregateway demands a second factorexpired or revoked certificate

Două probleme într-o singură plângere

O configurație IKEv2 nativă pe iPad poate face referire la o parolă sau la un certificat, iar cheia AuthenticationMethod decide care se aplică, în timp ce PayloadCertificateUUID numește acreditarea care furnizează identitatea. Care dintre ele va fi acceptată de poartă este o chestiune de politică a serverului, nu o preferință a clientului. Așadar primul lucru de stabilit este ce permite serviciul VPN, pentru că iPad-ul nu poate negocia până la o metodă pe care celălalt capăt o refuză.

Abia după aceea are sens să vorbim despre când se activează tunelul, care este un set complet diferit de chei de profil.

Prima opțiune: o acreditare pe care iPad-ul o poate refolosi

O parolă de cont salvată sau un secret partajat satisfac o poartă care autentifică utilizatorul sau grupul și elimină solicitarea atât timp cât secretul rămâne valid. Slăbiciunea ei este ciclul de viață: secretul stă în profil, mai multe dispozitive îl pot partaja, iar rotirea lui înseamnă să atingeți fiecare profil care îl poartă. Dacă serviciul cere suplimentar un factor de unică folosință sau o aprobare interactivă, nicio setare locală nu transformă acea politică într-o autentificare nesupravegheată.

O parolă salvată de o aplicație nu este nici ea disponibilă automat pentru o altă implementare VPN, motiv pentru care același cont poate înceta să mai ceară într-un client și poate cere de fiecare dată în altul.

A doua opțiune: un certificat de dispozitiv cu propria cheie

Un certificat elimină solicitarea într-un mod mai puternic, pentru că iPad-ul dovedește deținerea unei chei private în loc să reproducă un secret. Asta cere ca certificatul frunză și cheia lui să ajungă pe calea de înrolare aprobată și ca poarta să accepte autentificarea prin certificat pentru acea conexiune. Importarea doar a unui certificat CA îi dă dispozitivului material de încredere și nimic altceva, ceea ce este o defecțiune comună și silențioasă.

Prețul este munca de ciclu de viață. Fiecare iPad primește propria identitate, astfel încât un dispozitiv pierdut să poată fi revocat fără a reemite întreaga flotă, iar datele de expirare devin evenimente operaționale reale. Un certificat care expiră în tăcere arată exact ca o pană VPN în dimineața în care se întâmplă.

Alegeți după ce acceptă poarta, nu după preferință

Întrebați administratorul VPN două lucruri: ce metode de autentificare acceptă serviciul pentru acest tip de client și dacă vreuna dintre ele cere introducere interactivă. Dacă răspunsul este doar certificat, planificați înrolarea și reînnoirea. Dacă răspunsul este parolă plus un al doilea factor, acceptați că solicitarea este politică și nu o mai tratați ca pe o defecțiune a dispozitivului. Dacă ambele sunt acceptate, certificatul câștigă la ciclul de viață pentru o flotă supravegheată, iar parola la efortul de instalare pentru câteva dispozitive.

Scrieți metoda aleasă în evidența de implementare lângă identificatorul profilului, altfel următoarea persoană care atinge profilul o va alege pe cealaltă.

Apoi separați activarea de autentificare

VPN On Demand deschide tunelul când o condiție configurată se potrivește, fie că este un domeniu DNS, un tip de interfață sau o rețea alăturată, iar Apple o documentează ca neavând nevoie de interacțiunea utilizatorului. Asta se potrivește resurselor private care ar trebui să devină accesibile doar când ceva le cere. Nu este același lucru cu Always On gestionat, care menține acoperirea impusă și vine cu propriile cerințe de supraveghere și de profil.

O acreditare funcțională nu face nimic pentru niciuna dintre ele. Multe iPad-uri au un certificat perfect valid și tot așteaptă o atingere manuală pentru că nicio regulă la cerere nu s-a declanșat vreodată.

Predați cerința într-o formă pe care administratorul poate acționa: acest iPad trebuie să ajungă la aceste resurse fără introducere repetată din partea utilizatorului, cu acest tip de acreditare și sub aceste reguli de activare și de defecțiune. Dacă serviciul actual nu poate îndeplini acele condiții, solicitările repetate sunt politica funcționând conform proiectării.

Articole similare