סובבו חשבון VPN מקומי בלי לאבד את ההרשאות שלו

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

גלו איזה מאגר באמת מאמת את ההפעלה

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

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

עדכון במקום לעומת מחיקה ויצירה מחדש

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

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

למה ה-hash שיש לכם אולי אינו הסוד שהוא צריך

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

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

הפעלות ששורדות את האישור

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

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

הוכיחו שההרשאות שרדו

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

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