ה-Mac ממשיך לבקש סיסמת VPN: צרור מפתחות או חשבון?
ה-Mac עשוי לבקש סיסמת צרור מפתחות של הכניסה, סיסמת מנהל או את חשבון ה-VPN עצמו. קראו למי שייך הדיאלוג, ואז תקנו את המאגר הנכון.
אתם פותחים את ה-Mac, פותחים את לקוח ה-VPN, ודף סיסמה מופיע עוד לפני שהמנהרה התחילה. אתם מקלידים את סיסמת השער, והיא נדחית או שהדף חוזר כעבור רגע. אחר כך הוא שואל שוב אחרי התעוררות משינה, התנתקות או עדכון של הלקוח. הדף הזה הוא רק לעתים נדירות שרת ה-VPN שמבקש פרטי התחברות; בדרך כלל macOS מבקש הרשאה לקרוא, לפתוח או לשנות רשומה מקומית, והסיסמה שייכת לבעל הרשומה ההיא, לא לחשבון ה-VPN שלכם.
התאימו את הדף לזהות שמאחוריו
ארבעה חלונות נראים כמעט זהים ורק אחד נוגע בשער. הנוסח, התהליך שמבקש גישה והפריט הנקוב מתחתיו אומרים לכם מול איזה מהם אתם עומדים.
| What the sheet says | Whose password it wants | What it does not do |
|---|---|---|
| Enter the password for the login keychain | The local keychain password, normally your Mac login password | It does not authenticate you to the VPN server |
| An app wants to use confidential information stored in your keychain | Approval for that app to retrieve one item | It does not grant privileges at the gateway |
| macOS wants to make changes, and asks for administrator authorization | An admin account on this Mac, for the named setting | It does not change the VPN account password |
| The client itself asks for a username and password to connect | The remote account, certificate or profile credential | It does not unlock anything local |
דיאלוג על גישה מקומית לא מוכיח דבר על השרת. דחייה מהשער מופיעה בתוך הלקוח עם טקסט השגיאה של הספק, לא כדף מערכת שמציע לפתוח צרור מפתחות. ההפך נפוץ באותה מידה: הקלדת סיסמת השער בדף צרור מפתחות משאירה את הרשומה נעולה ומוסיפה ניסיון כושל.
הדיאלוג נוקב בבעלים, במאגר ובפעולה
בקשות צרור המפתחות עוסקות באחזור, לא באימות מול משהו מרוחק. תיאור Apple של דיאלוג הבקשה צר: אפשר פעם אחת, אפשר תמיד וחסום קובעים אם האפליקציה הזו רשאית לקרוא את הפריט השמור. אף אחד מהשלושה לא מעניק הרשאה בשער ולא משנה מה השרת חושב על הסיסמה שלכם.
כשהמבקש הוא לקוח זה עתה עודכן, אישור מחדש צפוי: הגרסה החדשה כבר לא תואמת את רשימת בקרת הגישה של הפריט, ולכן macOS שואל שוב. ענו אפשר פעם אחת בזמן האבחון. אפשר תמיד הוא הרשאה קבועה לאפליקציה הזו ותשובה שגויה לתהליך עזר שלא ציפיתם לו; חסמו ובדקו אצל הספק אם הקובץ הבינארי אינו הלקוח שהתקנתם.
בקשה לאישור מנהל היא סוג שלישי. היא נוקבת בהגדרת מערכת או במאגר מוגן שמשתנה, והאישור שהיא רוצה הוא חשבון מנהל ב-Mac הזה. לא כל פריט אישי בצרור המפתחות זקוק לכך; אלה שמאחורי תצורת הרשת בדרך כלל כן, כי התצורה שייכת למערכת, לא להפעלה שלכם.
היכן סיסמת VPN יכולה לחיות ב-Mac
צרור המפתחות הוא מאגר אפשרי אחד, לא ההגדרה של מאגר. תצורת VPN מובנית שנוצרה בהגדרות המערכת שומרת את פרטי ההתחברות שלה עם תצורת הרשת, כהגדרת מערכת מנוהלת. לקוח של צד שלישי שומר בדרך כלל פריט בצרור המפתחות של הכניסה שלכם: סיסמה כללית עם מפתח לפי שם שירות, או סיסמת אינטרנט עם מפתח לפי שרת, פרוטוקול וחשבון. אפליקציות חדשות רבות משתמשות במקום זה בצרור המפתחות להגנת נתונים, שפריטיו לעולם אינם מופיעים בגישה לצרור מפתחות.
אנשים מחפשים בגישה לצרור מפתחות את שם ה-VPN, לא מוצאים דבר ומסיקים שהסיסמה לא נשמרה. ההערה TN3137 של Apple אומרת שיש יותר מיישום אחד של צרור מפתחות; היעדרות מהרשימה ההיא היא נורמלית, לא הוכחה לפריט מקולקל.
גם סוגי הרשומות אינם ניתנים להחלפה. סיסמת חשבון, מילת צופן למפתח פרטי, תעודת לקוח וסוד משותף של IPsec נכשלים בדרכים שונות ומתוקנים במקומות שונים; הקלדה מחדש של סיסמה שמורה לא עוזרת לתעודה שנדחתה. אם ה-Mac רשום בניהול, הפרופיל הוא בעלים נוסף: מטען VPN יכול לשאת פרטי התחברות ולהחיל אותם מחדש ברענון, ולכן מחיקת פריט מקומי היא זמנית עד שמנהל משנה אותו.
כשסיסמת הכניסה וסיסמת צרור המפתחות נפרדות
צרור המפתחות של הכניסה משתמש בדרך כלל בסיסמת הכניסה שלכם ל-Mac, ולכן השתיים יכולות להיפרד. איפוס הסיסמה שלכם בידי מנהל מחשבון אחר, תהליך שחזור או שינוי בספרייה יכולים להשאיר את צרור המפתחות נעול לערך הישן, ואז macOS מבקש סיסמה שלא קבעתם זה עתה.
בעת הכניסה ייתכן שתראו אזהרה שהמערכת לא הצליחה לפתוח את צרור המפתחות. עדכונו דורש את הסיסמה הישנה, מה שטוב אם אתם זוכרים אותה וחסר תועלת אם לא. שני התיקונים הכנים הם גישה לצרור מפתחות, עריכה, שינוי סיסמה של צרור המפתחות "login", או צרור מפתחות כניסה חדש עם פרטי ההתחברות הדרושים שהוזנו מחדש. האפשרות השנייה הורסת פריטים שמורים.
אל תאפסו את כל צרור המפתחות מפני ש-VPN אחד דוחה אישור ישן: זה מסיר חשבונות לא קשורים ועדיין לא מזהה את הפריט.
פקודה אחת מכריעה את השאלה מקומי מול מרוחק. בקשו מצרור המפתחות את הפריט ישירות:
security find-internet-password -s vpn.example.com -a [email protected] -g
security find-generic-password -s "Client Name" -a [email protected] -gהשתמשו בשרת ובחשבון מההגדרות של הלקוח שלכם. אם אותו דף אישור מופיע כשאתם עצמכם שואלים את צרור המפתחות, הבקשה מקומית והשרת הוא צופה מהצד. אם פריט כזה אינו קיים, הלקוח לא שומר את הסיסמה היכן שהנחתם. הדגל -g מדפיס את הסוד למסוף, לכן הימנעו משיתוף מסך.
עדכנו את הרשומה שהלקוח באמת קורא
אם החשבון שונה בשער, שנו אותו קודם שם ואז עדכנו את הרשומה השמורה דרך הגדרות הלקוח. עריכה ידנית של פריט בצרור המפתחות אינה אמינה: הלקוח עשוי לקרוא זוג שירות וחשבון אחר, ופרופיל מנוהל ידרוס את העריכה שלכם.
לפריט שנחשד כמיושן, התאימו שירות, חשבון ופרוטוקול לפני שמוחקים משהו:
security delete-generic-password -s "Client Name" -a [email protected]מחיקת פריט בשם דומה מחיבור אחר היא תקלה נפוצה שאתם גורמים לעצמכם. ההסרה מקומית בלבד: היא לא מבטלת הפעלה בשער, לא משחררת תעודת התקן ולא משנה את סיסמת החשבון.
ודאו שהתיקון שורד הפעלה מחדש
התחברו, התעוררו משינה, התנתקו והתחברו שוב ואז הפעילו מחדש פעם אחת. רצף נקי בלי דף ומצב לקוח שמציין את החשבון הצפוי הם הראיה היחידה שנחשבת. המקום שבו הבקשה חוזרת אומר לכם איזה שכבה פספסתם: אחרי עדכון זה אישור, אחרי שינוי רשת הבקשה של הלקוח עצמו, אחרי הפעלה מחדש פרופיל שמחיל מחדש מצב.
בדקו בלקוח הגדרה של זכור סיסמה או שאל תמיד לפני שאתם נוגעים שוב בצרור המפתחות. תצורות מסוימות, במיוחד IKEv2 עם אימות לכל משתמש, שואלות לפי תכנון בכל חיבור; תיקון צרור המפתחות לא יעזור.
רשמו איזה פריט שיניתם, איזה מאגר היה הבעלים שלו ולאיזה חשבון הוא השתייך, כדי שהבקשה הבאה תמוקם בשניות. הדף של Apple בקשות גישה לצרור מפתחות הוא המקור למה ששלושת הכפתורים האלה מאשרים.