איזה ספר טלפונים מחפשת משימת SYSTEM עבור פרופילי VPN?

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

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

שני מאגרים מחזיקים באותו שם פרופיל

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

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

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

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

קראו את ה-principal של המשימה לפני האישורים שלה

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

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

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

מציאת הפרופיל אינה התחברות

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

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

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

ארבעה שדות שהתיעוד של המשימה צריך

שמרו את הערכים שקובעים את התוצאה יחד במקום אחד, משום ששלושה מהם נשארים בדרך כלל מרומזים. התיעוד צריך ארבע שורות:

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

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

אתרו את השלב שאליו הגיעה המשימה

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

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

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

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

מאמרים קשורים