תיבת שמירת הסיסמה ב-FortiClient נעלמה? השער הוא שמחליט
השער מחליט אם FortiClient רשאי לשמור סיסמה. בדקו את הגדרת הפורטל, ואחר כך העדיפו ייצוא ושחזור על פני עריכת הרישום.
אתם מסיימים את התקנת FortiClient, מתחברים לSSL VPN של המשרד ומחפשים פקד שמירת סיסמה שפשוט איננו. התקנה מחדש של הלקוח לא מחזירה אותו, וגם לא מחיקת המנהרה והוספתה מחדש. בפרופיל SSL VPN חומת האש מחליטה אם הלקוח רשאי בכלל לשמור פרטי התחברות. תיבה חסרה משמעה אפוא בדרך כלל שמדיניות הגיעה מהשער, ולא שהמתקין נכשל.
ההבחנה הזאת חשובה לפני שמתחילים לערוך קבצים: אחד מהנתיבים האלה הוא שיחה עם בעל חומת האש, והשני הוא עבודת מעבדה שתידרס.
בדקו את הפורטל לפני שנוגעים בנקודת הקצה
בקשו ממי שמנהל את ה-FortiGate לפתוח את פורטל ה-SSL VPN שאליו מצביעה המנהרה שלכם ולקרוא את הגדרת שמירת הסיסמה שלו. כשהאפשרות מושבתת, מצופה מ-FortiClient להסתיר את הפקד ולסרב לשמור את פרטי ההתחברות. נקודת הקצה מצייתת לכלל ולא מקולקלת.
בדיקה מהירה אחת מפרידה בין מדיניות לפרופיל שבור: התחברו לפורטל שעדיין מתיר שמירה, ואז חזרו לשלכם. אם הפקד מופיע בפורטל המתיר ונעלם בזה הנעול, עצרו כאן ובקשו את השינוי בשער. כל מה שלמטה הוא עבודת שדה לדייר מעבדה או לפרופיל בדיקה, ושום דבר ממנו אינו גובר על החלטת השרת. רענון פרופיל או שדרוג לקוח ידרוס את העריכה המקומית.
Windows שומר את הדגל בתוך מפתח המנהרה
מנהרות שמורות חיות תחת המשתמש הנוכחי, מפתח אחד לכל חיבור, ודגל הנראות יושב לצד פרטי החיבור:
HKEY_CURRENT_USER\SOFTWARE\Fortinet\FortiClient\Sslvpn\Tunnels<tunnel name> show_remember_password = 1
העבירו את הערך ל-1, צאו מהלקוח ממגש המערכת במקום לסגור את חלונו, ופתחו אותו שוב. בגרסאות 5.x אותו דגל יכול היה לשבת תחת ענף Wow6432Node של HKEY_LOCAL_MACHINE, אז חפשו שם כשמפתח המשתמש חסר. בחלק מגרסאות 6.x הערך נכתב מחדש לאחר חיבור מוצלח, מה שמסביר תיבה ששורדת התחברות אחת ונעלמת בזו שאחריה. אם במפתח שלכם אין ערך כזה בכלל, צרו אותו כמחרוזת במקום לנחש שמות אחרים.
התייחסו לרישום כאל שלב ניפוי. מצב הרישום החי בלתי נראה למנהל הבא, ושום רענון מלאי לא ישמר אותו.
ב-macOS עקבו אחרי הלקוח כדי למצוא את הקובץ שלו
לקוח ה-macOS שומר הגדרות לכל חיבור תחת /Library/Application Support/Fortinet/FortiClient/conf, במילון לכל מנהרה. המפתח שצריך לקבוע הוא AllowSavePassword, והוא צריך להיקרא כ-1 בזמן שמפתחות החיבור האוטומטי באותו מילון נשארים שלמים. הפעילו מחדש את הלקוח כשתסיימו.
ניחוש הקובץ המדויק מבזבז זמן בגרסה לא מוכרת. הריצו opensnoop בזמן שאתם מוסיפים את המנהרה, ואז קראו את הנתיבים שהלקוח נגע בהם; הקובץ שהוא כתב הוא זה שנושא את הדגל. ערכו את הקובץ הזה כשהלקוח סגור והעבודה נגמרה. חמש דקות של מעקב מנצחות בכל פעם חיפוש בכל מערכת הקבצים.
העדיפו מחזור של ייצוא, עריכה ושחזור
לקוחות חדשים יותר מאפשרים להעביר את כל התצורה דרך קובץ, מה שקל יותר לחזור עליו ולמסור למכונה אחרת מאשר ניתוח רישום חי:
- ייצאו מהגדרות הלקוח, כללו הגדרות משתמש, והגדירו סיסמת ייצוא.
- פתחו את הקובץ והעבירו את show_remember_password ל-1.
- פתחו את המנעול בלקוח; שחזור לא עושה דבר כל עוד הוא נעול.
- שחזרו את הקובץ שנערך ומסרו את סיסמת הייצוא.
הפקד אמור להופיע בהתחברות הבאה. הרחיקו את הקובץ המיוצא מתיקיות משותפות ומצירופי כרטיסים, כי הוא מתאר את המנהרות שלכם ועלול לשאת סוד מוצפן.
אם השחזור עובד אבל התיבה מתחבאת שוב לאחר התחברות, השער כופה את המדיניות מחדש בכל התחברות ושום קובץ מקומי לא יחזיק את ההגדרה לאורך זמן.
מחקו את הסוד לפני שהוא הופך לנעילת חשבון
ללקוח שורת הפקודה של Linux אין תיבה כלל, ולכן עטיפה שמזינה את הסיסמה ב-stdin היא התשובה הרגילה והיא לא שומרת דבר. בכל פלטפורמה ההסרה האמינה היא להחזיר את החיבור לשאול בהתחברות או למחוק את המנהרה לגמרי.
פרטי התחברות שמורים שורדים את החלפת הסיסמה שמבטלת אותם, והכשלים הנובעים מכך נראים כמו נפילת VPN: דחיות, ניסיונות חוזרים ואז נעילת חשבון. מחקו את הערך השמור לפני שאתם מחליפים סיסמה, ועברו על רשימת המנהרות לחפש רשומות ישנות שעדיין נושאות אחת. הסוד יושב מוצפן במאגר הלקוח, ולכן עריכה ידנית שלו חסרת תועלת. מחיקת המנהרה מהירה יותר ולא משאירה דבר.
עברו על זה לפי הסדר: אשרו את הגדרת הפורטל עם בעל חומת האש, הוכיחו את המקור בפרופיל מתיר, שמרו עריכות רישום או plist בתוך מעבדה, ודעו איזה קובץ מחזיק את הסוד כדי שתוכלו להסיר אותו. תיבה חסרה בפורטל שמתיר שמירה היא בעיית נקודת קצה, ויומני הלקוח הם המקום הבא להסתכל בו.