Viscosity זכר את הסיסמה: מה עשתה תיבת הסימון הזו

תיבת הסימון הזו בהנחיית ההתחברות נראית כמו העדפת לקוח, אך במחשב מנוהל היא לעתים קרובות החלטת מדיניות. בקרת הזכירה של Viscosity שומרת את פרטי ההתחברות במחזיק המפתחות של macOS כאשר הפריסה מאפשרת אחסון. המיתוס הוא שתיבת הסימון תמיד שלכם לקביעה. בפועל, שלושה דברים נפרדים יכולים לחסום אותה, ורק אחד מהם נוגע לסיסמה.

מה תיבת הסימון באמת שומרת

בחירת אפשרות הזכירה מבקשת מהלקוח לשמור את הערך עבור אותה התחברות וחשבון. הפריט מגיע למחזיק המפתחות, והתחברויות מאוחרות יותר משתמשות בו שוב דרך ההנחיה הנתמכת ולא דרך העדפה נסתרת. שום דבר אינו נכתב בקובץ ההתחברות עצמו. ההפרדה הזו היא גם הסיבה לכך שהסרת הפריט מאוחר יותר מייצרת הנחיה ולא פרופיל שבור.

הערך השמור הוא קלט לאימות שהשרת ממילא היה מבצע. הוא אינו משנה את מה שהשער דורש, אינו עוקף גורם שני ואינו הופך קוד חד-פעמי לסוד שניתן לשימוש חוזר. מה שהוא מקצר הוא ההקלדה, לא המדיניות שהפריסה מיישמת על אותו חשבון.

מדוע הבקרה עשויה להיות חסרה

מנהל יכול להשבית שמירת פרטי התחברות בהתקנה מנוהלת, ו-SparkLabs מתעדת את בקרת הזכירה יחד עם התנהגותה במחזיק המפתחות, כמתואר במדריך לאחסון פרטי התחברות. כאשר תיבת הסימון חסרה, היא אינה שבורה, וחיפוש אחר פקודת העדפות שעוקפת אותה הוא התגובה השגויה.

שאלו את הבעלים איזה תהליך עבודה נתמך חל במקום. לפריסה שאוסרת אחסון יש בדרך כלל סיבה, והסיבה היא לעתים קרובות שהחשבון משותף, שהמכשיר אינו מהימן, או שפרטי ההתחברות אמורים לפוג לפי לוח זמנים. עקיפת ההגדרה הופכת בקרה מכוונת לתקרית, והתקרית מגיעה בדרך כלל עם הביקורת של מישהו אחר מצורפת.

בהתקנה לא מנוהלת, בקרה חסרה היא שאלת תמיכה עם מספר גרסה מצורף. שלחו את גרסת הלקוח המותקנת ואת מה שההנחיה מציגה בפועל, ולא ניחוש לגבי ברירות מחדל נסתרות.

שלוש הנחיות שאינן אותה הנחיה

קוד חד-פעמי אינו סיסמה, סיסמה אינה הרשאה של מחזיק המפתחות, ודחייה של שרת אינה אף אחד מהשלושה. ערבוב ביניהם מייצר כשלים שנקראים כפרטי התחברות שגויים כאשר הבעיה האמיתית היא שדה, דיאלוג או מסלול.

הדיאלוג של מחזיק המפתחות הוא מקומי מעצם התכנון. הוא שואל אם היישום הזה רשאי לקרוא את הפריט הזה במחשב הזה, ואישורו אינו אומר דבר לשרת ה-VPN.

לכן דחיית הדיאלוג מייצרת כשל בצד הלקוח שהשרת אינו רואה לעולם, בעוד סיסמה שגויה מייצרת דחייה בצד השרת שהלקוח יכול רק לדווח עליה. קראו את הדיאלוג לפני שמשיבים לו, ובדקו שהיישום המבקש הוא הלקוח שאתם מצפים לו ולא מתקין או תהליך עזר. ההבחנה חשובה ביותר במחשבים משותפים, שבהם הפריט עשוי להיות נגיש ליותר מחשבון אחד.

גורם שני נמצא מחוץ לכל זה. שמירת סיסמה אינה שומרת את הקוד, ופריסה שדורשת את הקוד עדיין דורשת אותו בכל התחברות. שמרו על השלב הזה גלוי במהלך הבדיקות, כי תהליך שמדלג עליו בשקט אינו התהליך שהגדרתם.

שחזור פרטי התחברות אחדים בלי לאפס את השאר

אם האימות נכשל לאחר שינוי סיסמה, השתמשו במסלול המתועד של הלקוח לבקשה חוזרת ולעדכון עבור אותה התחברות, במקום לערוך את מחזיק המפתחות ביד. קראו את ההודעה לפני שמחליפים משהו, כי פסק זמן, דחיית תעודה או מסלול חסר אינם מתוקנים על ידי דריסת סיסמה שמורה. עשיית זה שוב ושוב בעיקר מלמדת אתכם להתעלם מהשגיאה שהלקוח מציג. עדכנו את פרטי ההתחברות שנפגעו, ואז התחברו מחדש וצפו איזו הנחיה מופיעה.

איפוס מחזיק המפתחות כולו שהפורומים לתמיכה מציעים הוא שינוי גדול בהרבה מהבעיה. לסיסמה השמורה של התחברות אחת אין שום קשר לתעודה של התחברות אחרת, ומחיקת הכול הופכת פריט מיושן אחד לצהריים של רישום מחדש.

סיימו בניתוק והתחברות מחדש דרך הבקרות הרגילות, באישור שהחשבון המיועד משמש ושבהוצאת הפריט השמור מופיעה הנחיה ולא כשל. שימוש חוזר צפוי עם דרך ברורה אחת לעדכן או להסיר את פרטי ההתחברות הוא התוצאה ששווה לבדוק.