חסרה מדיניות קבוצה ב-VPN? בדקו את ההיקף לפני המנהרה

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

התחילו בהגדרה, לא במנהרה

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

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

קראו את הדוח עם החשבון שההגדרה שייכת לו

בהפעלה של המשתמש שנפגע עצמו, הריצו whoami /user ואחר כך gpresult /scope user /r. החשבון שאימת את ה-VPN אינו אוטומטית חשבון ה-Windows שאת המדיניות שלו אתם קוראים, ובדיקה מחשבון מנהל עונה על שאלה אחרת. שמרו את קו הבסיס בשם קובץ חדש, כגון %TEMP%\vpn-policy-user-before.html. ההפנייה של gpresult מתעדת את מתגי ההיקף והפלט, וכדאי לדעת שיצירת דוח אינה מרעננת דבר.

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

גילוי אינו גישה: תחילה רשומות SRV, ואחר כך SMB

כשה-VPN המאושר מחובר, אשרו שהלקוח מפענח בקרי תחום דרך נתיב ה-DNS המיועד; אתר ציבורי שנטען אינו אומר דבר על גילוי בקרים. עבור התחום להמחשה corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example עונה על השאלה שבאמת יש לכם. רשומת שירות שמוחזרת היא רק ראיה לגילוי, מפני שכתובת הבקר שנבחר עדיין צריכה להיות נגישה עם האימות הנדרש ושרותי המדריך המאושרים. חומר המדיניות מגיע אחר כך מ-SYSVOL, כלומר קריאת SMB מול אותו בקר ספציפי ולא מבחן ICMP.

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

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

רענון אחד, שני דוחות, השוואה אחת

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

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

קשרו את הכשל לפעילות אחת בלבד

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

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

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