התחברות מחדש ל-VPN של Windows בלי לשים את הסיסמה במשימה

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

מה פעולת משימה משאירה קריא

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

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

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

מה מפתח משותף מראש שמור באמת קונה

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

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

פרטי הגישה של Winlogon מסירים את הסוד ומוסיפים תלות

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

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

אימות באישורים מתרחב כי דבר אינו נשמר

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

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

עברו על החפצים לפני הסבב הבא

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

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