מי רשאי להתקשר? ביקורת msNPAllowDialin לפני גישה ל-VPN

הסיסמה נכונה, החשבון נמצא בקבוצת ה-VPN, והחיבור עדיין נדחה עם הודעה שאינה מזכירה שום מדיניות. כשזה קורה בשרת גישה מרחוק של Windows, המקום הראשון שאני בודק אינו כלל ה-NPS אלא מאפיין אחד של Active Directory שאיש אינו פותח: msNPAllowDialin, הערך שמאחורי הכרטיסייה Dial-in. יש לו שלושה מצבים, והשלישי מעביר את ההחלטה בשקט למקום אחר. רוב הזמן איש לא שינה אותו בכוונה: החשבון שוכפל מתבנית, או נוצר על ידי סקריפט שכתב סירוב מפורש לפני שנים ומעולם לא נבדק שוב.

הדחייה יכולה להתרחש לפני שהמדיניות נקראת

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

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

שלושה מצבים, והשלישי בלתי נראה

TRUE מתיר חיוג, FALSE מסרב לו, וערך NULL פירושו שהחשבון יורש את תשובתו ממדיניות הגישה המרחוק או מהרשאת NPS. ממשק המשתמש מציג את המצב השלישי כ-"Control access through NPS Network Policy", והוא נקרא כמו תיבת סימון שלא סומנה ולא כמו החלטה.

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

ייצאו את הדגלים בלי לאבד את החשבונות המורשים

הריצו את הייצוא מבקר דומיין, או מתחנת עבודה עם מודול Active Directory, ושמרו את הקובץ הגולמי כראיה במקום להקליד מחדש תקציר:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

מסנן LDAP אחד קל יותר להדביק ברשומת שינוי. זה מחזיר רק את ההיתרים המפורשים:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

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

הפרידו את הדגל מגישת קבוצה ומבריאות החשבון

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

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

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

שנו חשבון אחד והוכיחו שהשינוי הגיע

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

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

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

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

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