LmCompatibilityLevel הוא מדיניות של Windows, לא תיקון ל-VPN
ערך רישום אחד שולט בכניסה לרשת בכל המחשב, לא רק במנהרה. למדו מה כל רמה שולחת ומה היא מסרבת לפני שמתייחסים לזה כתיקון.
מישהו לא מצליח להגיע לשיתוף קובץ דרך ה-VPN, קורא שהורדת LmCompatibilityLevel פותרת בעיות NTLM, ומשנה אותו בשרת משותף. למחרת בבוקר יישומים אחרים נכשלים, והבעיה המקורית עדיין שם. ההגדרה הזאת מעולם לא הייתה מתג לכל מנהרה; היא הצהרה ברמת המחשב כולו לגבי אילו תגובות אימות המערכת הזאת תשלח ותקבל. שינוי שלה כדי לתקן כניסה אחת כותב מחדש את הכללים לכל כניסה שהמחשב מבצע.
קריאת הרמות המתועדות היא הדרך המהירה ביותר להפסיק להתייחס לערך מדיניות כמספר קסם.
שלוש רמות, שלוש הבטחות שונות
רמה 1 גורמת ללקוח לשלוח תגובות LM ו-NTLM, תוך שימוש באבטחת הפעלה של NTLMv2 כאשר המשא ומתן מאפשר זאת. רמה 3 גורמת ללקוח לשלוח רק תגובות NTLMv2, וזה אינו אותו דבר כמו לדחות כל תגובה ישנה בצד המקבל. רמה 5 משאירה את הלקוח ב-NTLMv2 ומוסיפה את הדחייה המתועדת של LM ו-NTLMv1 מצד בקר התחום. שלושה מספרים, והפער ביניהם הוא החלטת מדיניות ולא העדפה.
ההבדלים האלה מסבירים למה העתקת ערך ממקרה שעובד אינה אמינה. העברת לקוח שהוגדר לא נכון מ-1 לקו הבסיס המאושר יכולה להיות נכונה. העברת פריסה מוקשחת מ-5 ל-3 רק משום ששרשור בפורום הזכיר 3 מרפה גבול שמישהו בחר בכוונה, והיא עושה זאת לכל שירות שהמחשב מדבר איתו.
קראו את המדיניות האפקטיבית, לא ערך רישום אחד
מבט לקריאה בלבד בערך המקומי הוא נקודת פתיחה סבירה: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. ערך חסר אינו אומר שהמדיניות האפקטיבית היא אפס, מפני שמדיניות תחום או מדיניות אבטחה מקומית יכולה לקבוע אותו במקום אחר, ותפקיד המחשב משנה מה הוא עושה עם המספר.
בדקו את המדיניות המנוהלת, את תפקיד המערכת ואת הבנייה בפועל לפני שאתם מסיקים דבר. תחנת עבודה ובקר תחום עם אותו ערך מתנהגים אחרת בקצה העליון, וזה החלק שאנשים שוכחים כשהם משווים שני מחשבים.
זהו איזה אימות באמת נכשל
בעיות כרטיסי Kerberos, דחיות NTLM וכשלי קבלה ב-VPN דורשים ראיות שונות. שמרו את שירות היעד, החשבון והשגיאה המדויקת יחד בהערה אחת, ואז הביטו במה שהשירות ביקש ולא במה שהלקוח מעדיף. ההערה האחת הזאת מונעת את הפנייה השגויה הנפוצה ביותר, והיא שינוי ערך בצד הלקוח כדי לענות על דחייה בצד השרת.
הורדה חוזרת של מדיניות עד ששגיאת כניסה כללית נעלמת אינה אבחון; זהו שינוי שמסתיר את הראיה. אם היישום משתמש ב-Kerberos, רמת התאימות של NTLM אינה אפילו הבקרה הרלוונטית, והרפתם גבול לחינם.
יש תמיכת פרוטוקול שאי אפשר להחזיר
Windows 11 24H2 ו-Windows Server 2025 אינם כוללים עוד אימות רשת NTLMv1 כלל. שום מספר תאימות לא מחזיר פרוטוקול שהבנייה כבר אינה מיישמת, ולכן שנמוך שנראה מועיל בגרסה ישנה יותר ייכשל פשוט בגרסה חדשה יותר. מיקרוסופט מתעדת את ההסרה הזו בנפרד מהגדרת המדיניות, וערבוב של השניים מייצר עצה שאינה יכולה לעבוד.
הגבלה קשורה אך נפרדת חלה על פרטי גישה נגזרים מ-NTLMv1 שבהם משתמשת כניסה יחידה המבוססת על MSCHAPv2. זו שאלה של פרטי גישה נגזרים, לא של פרוטוקול הרשת עצמו, ולא של ערך הרישום הזה. התייחסות לשלושתם כאותו נושא היא הדרך שבה ארגונים מחלישים בקרה אחת בזמן שהם מנסים לתקן אחרת.
שנו אותו דרך הבעלים, ואז בדקו את שני הכיוונים
אם באמת נדרש תיקון, עשו אותו דרך בעל המדיניות כדי שקו הבסיס יישאר עקבי, ותעדו למה. אחר כך בדקו יישום מורשה תחת ההגדרה החדשה ומקרה אימות שנאסר בכוונה, מפני ששינוי שמתקן שיתוף אחד ומתיר בשקט תגובות ישנות במקום אחר אינו הצלחה. חיבור VPN שעובד מוכיח שהקבלה הצליחה. הוא אינו מאמת את מדיניות האימות של המחשב, ובוודאי אינו מראה שכל שירות מאחוריו עדיין מתנהג כמתוכנן.
אם השירות הכושל מבוסס על Kerberos, הפסיקו לגמרי להסתכל על ההגדרה הזאת. ואם מדובר במכשיר ישן שבאמת אינו יכול לעשות טוב יותר, תעדו את החריגה הזאת ותחמו אותה, מפני שהחלופה היא קו בסיס שנחלש בשקט שאיש אינו זוכר שאישר אותו.