Viscosity a reținut parola: ce a făcut acea casetă de bifare
Caseta de reținere stochează o singură acreditare în brelocul macOS. Nu poate ocoli o politică gestionată, un al doilea factor sau un server care respinge parola.
Acea casetă de bifare de la promptul de autentificare pare o preferință a clientului, dar pe un calculator gestionat este adesea o decizie de politică. Controlul de reținere al Viscosity stochează acreditarea în brelocul macOS atunci când implementarea permite stocarea. Mitul este că caseta este întotdeauna a dumneavoastră de setat. În practică, trei lucruri separate o pot bloca, și doar unul dintre ele privește parola.
Ce stochează de fapt caseta
Selectarea opțiunii de reținere cere clientului să păstreze valoarea pentru acea singură conexiune și cont. Elementul ajunge în breloc, iar autentificările ulterioare îl refolosesc prin promptul acceptat, nu printr-o preferință ascunsă. Nimic nu este scris în fișierul de conexiune propriu-zis. Această separare explică și de ce eliminarea ulterioară a elementului produce un prompt în loc de un profil stricat.
Valoarea stocată este o intrare pentru autentificarea pe care serverul oricum avea să o efectueze. Nu schimbă ce cere gatewayul, nu ocolește un al doilea factor și nu transformă un cod de unică folosință într-un secret refolosibil. Ce scurtează este tastarea, nu politica pe care implementarea o aplică acelui cont.
De ce poate lipsi controlul
Un administrator poate dezactiva stocarea acreditărilor pentru o instalare gestionată, iar SparkLabs documentează controlul de reținere împreună cu comportamentul său în breloc în ghidul de stocare a acreditărilor. Când caseta lipsește, nu este defectă, iar căutarea unei comenzi de preferințe care o ocolește este reacția greșită.
Întrebați proprietarul ce flux de lucru acceptat se aplică în schimb. O implementare care interzice stocarea are de obicei un motiv, iar motivul este adesea că contul este partajat, dispozitivul nu este de încredere sau acreditarea trebuie să expire conform unui calendar. Ocolirea setării transformă un control intenționat într-un incident, iar incidentul vine de obicei cu auditul altcuiva atașat.
Pe o instalare negestionată, un control lipsă este o întrebare de suport cu un număr de versiune atașat. Trimiteți versiunea instalată a clientului și ce arată de fapt promptul, în loc să ghiciți valori implicite ascunse.
Trei prompturi care nu sunt același prompt
Un cod de unică folosință nu este o parolă, o parolă nu este o autorizare a brelocului, iar o respingere a serverului nu este niciuna dintre cele trei. Amestecarea lor produce eșecuri care se citesc ca acreditări greșite atunci când problema reală este un câmp, un dialog sau o rută.
Dialogul brelocului este local prin proiectare. Întreabă dacă această aplicație poate citi acest element pe acest calculator, iar aprobarea lui nu spune nimic serverului VPN.
De aceea, refuzarea dialogului produce un eșec pe partea clientului pe care serverul nu îl vede niciodată, în timp ce o parolă greșită produce o respingere pe partea serverului pe care clientul o poate doar raporta. Citiți dialogul înainte de a răspunde și verificați dacă aplicația care cere este clientul pe care îl așteptați, nu un program de instalare sau un proces auxiliar. Distincția contează cel mai mult pe calculatoarele partajate, unde elementul poate fi accesibil pentru mai mult de un cont.
Un al doilea factor stă în afara tuturor acestora. Stocarea unei parole nu stochează codul, iar o implementare care cere codul îl cere în continuare la fiecare conexiune. Păstrați acel pas vizibil în timpul testării, deoarece un flux care îl sare în tăcere nu este fluxul pe care l-ați configurat.
Recuperarea unei acreditări fără a reseta restul
Dacă autentificarea eșuează după o schimbare de parolă, folosiți calea documentată a clientului pentru re-prompt și actualizare pentru acea singură conexiune, în loc să editați brelocul manual. Citiți mesajul înainte de a înlocui ceva, deoarece un timeout, o respingere de certificat sau o rută lipsă nu se repară prin suprascrierea unei parole stocate. Repetarea acestui lucru vă învață mai ales să ignorați eroarea pe care o afișează clientul. Actualizați acreditarea afectată, apoi reconectați-vă și urmăriți ce prompt apare.
Resetarea completă a brelocului pe care o sugerează forumurile de suport este o schimbare mult mai mare decât problema. Parola stocată a unei conexiuni nu are nimic de-a face cu certificatul altei conexiuni, iar ștergerea tuturor transformă un singur element învechit într-o după-amiază întreagă de reînregistrare.
Încheiați deconectându-vă și reconectându-vă prin controalele obișnuite, confirmând că este folosit contul dorit și că eliminarea elementului stocat produce un prompt în loc de un eșec. Reutilizarea previzibilă cu o singură modalitate clară de a actualiza sau elimina acreditarea este rezultatul care merită testat.