VPN a l'iPad sense demanar contrasenya: certificats o inici de sessió desat
Una contrasenya desada i un certificat de dispositiu eliminen la petició de maneres diferents. Compareu-los i després decidiu per separat què obre el túnel.
«Deixa de demanar-me una contrasenya» en realitat agrupa tres requisits en una sola queixa, i una implementació a l'iPad els respon en llocs diferents. La petició ve de l'autenticació, el moment ve de l'activació i la cobertura ve de l'aplicació de les regles. Trieu primer la credencial que elimina la petició i després decidiu per separat què determina quan s'obre el túnel. Barrejar les dues decisions és exactament el que fa que una contrasenya desada acabi en un perfil que encara espera un toc.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
Dos problemes en una sola queixa
Una configuració IKEv2 nativa a l'iPad pot fer referència a una contrasenya o a un certificat, i la clau AuthenticationMethod decideix quin s'aplica, mentre que PayloadCertificateUUID nomena la credencial que proporciona la identitat. Quina de les dues acceptarà la passarel·la és una qüestió de política del servidor, no una preferència del client. Per tant, primer cal establir què permet el servei VPN, perquè un iPad no pot negociar fins a un mètode que l'altre extrem rebutja.
Només després té sentit parlar de quan s'activa el túnel, que és un conjunt de claus de perfil completament diferent.
Primera opció: una credencial que l'iPad pot reutilitzar
Una contrasenya de compte desada o un secret compartit satisfan una passarel·la que autentica l'usuari o el grup, i eliminen la petició mentre el secret sigui vàlid. La seva feblesa és el cicle de vida: el secret és al perfil, diversos dispositius poden compartir-lo i rotar-lo obliga a tocar cada perfil que el porta. Si el servei també exigeix un factor d'un sol ús o una aprovació interactiva, cap paràmetre local converteix aquesta política en un inici de sessió sense supervisió.
Una contrasenya desada per una aplicació tampoc no està disponible automàticament per a una altra implementació de VPN, i per això el mateix compte pot deixar de demanar-la en un client i demanar-la sempre en un altre.
Segona opció: un certificat de dispositiu amb la seva pròpia clau
Un certificat elimina la petició d'una manera més ferma, perquè l'iPad demostra la possessió d'una clau privada en lloc de reproduir un secret. Això exigeix que el certificat fulla i la seva clau arribin pel camí de registre aprovat, i que la passarel·la accepti l'autenticació per certificat per a aquesta connexió. Importar només un certificat de CA dona al dispositiu material de confiança i res més, cosa que és una fallada habitual i silenciosa.
El preu és treball de cicle de vida. Cada iPad rep la seva pròpia identitat perquè un dispositiu perdut es pugui revocar sense reemetre tot el parc, i les dates de caducitat esdevenen esdeveniments operatius reals. Un certificat que caduca en silenci sembla exactament una caiguda de VPN el matí que passa.
Trieu segons el que accepta la passarel·la, no segons la preferència
Pregunteu a l'administrador de VPN dues coses: quins mètodes d'autenticació accepta el servei per a aquest tipus de client, i si algun d'ells requereix entrada interactiva. Si la resposta és només certificat, planifiqueu el registre i la renovació. Si la resposta és contrasenya més un segon factor, accepteu que la petició és política i deixeu de tractar-la com una fallada del dispositiu. Si s'accepten tots dos, el certificat guanya en cicle de vida per a un parc supervisat i la contrasenya guanya en esforç de configuració per a uns quants dispositius.
Escriviu el mètode triat al registre de desplegament al costat de l'identificador del perfil, perquè si no la propera persona que toqui el perfil triarà l'altre.
Després separeu l'activació de l'autenticació
El VPN On Demand obre el túnel quan coincideix una condició configurada, ja sigui un domini DNS, un tipus d'interfície o una xarxa unida, i Apple el documenta com a quelcom que no requereix interacció de l'usuari. Això encaixa bé amb recursos privats que només han de ser accessibles quan alguna cosa els demana. No és el mateix que l'Always On gestionat, que manté la cobertura aplicada i porta els seus propis requisits de supervisió i de perfil.
Una credencial que funciona no fa res per a cap dels dos casos. Molts iPads tenen un certificat perfectament vàlid i tot i així esperen un toc manual perquè cap regla a demanda no s'ha activat mai.
Lliureu el requisit en una forma sobre la qual un administrador pugui actuar: aquest iPad ha d'arribar a aquests recursos sense entrada recurrent de l'usuari, amb aquest tipus de credencial i sota aquestes regles d'activació i d'incidència. Si el servei actual no pot complir aquestes condicions, les peticions repetides són la política que funciona tal com es va dissenyar.