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

התחילו בשגיאה שהלקוח באמת הציג

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

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

What you observeWhere the decision was madeWho owns the fix
The prompt returns before the tunnel formsLocal credential handling on the clientDevice policy or the installed build
Authentication succeeds, no internal site loadsRouting or access control after loginThe gateway or network owner
Fails only when the logged-on account is reusedSSO credential generationThe policy boundary this page covers
Every user on one build failsUpdate level or vendor regressionPatch management

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

קראו את המדיניות האפקטיבית, לא את הערך החסר

קבעו קודם את רמת הגרסה והעדכון, משום שברירת המחדל ליצירת פרטי גישה הנגזרים מ-NTLMv1 השתנתה במהדורות הרשומות של Windows 11 ו-Windows Server 2025. כשמגן ה-Credential Guard כבוי ו-BlockNtlmv1SSO אינו מוגדר, עדכון שפורסם ב-13 באוקטובר 2026 או אחריו מעביר את ההתנהגות מביקורת לאכיפה בלי ליצור אי פעם את הערך הזה. ברישום לא מופיע דבר, והמכשיר נעשה מחמיר ממה שהתכוון המנהל האחרון. זו כל הסיבה לכך שחיפוש ברישום מוכיח כאן כל כך מעט.

הפרידו בין הגבולות בזמן קריאת הפלט. LmCompatibilityLevel הוא רמת תגובת אימות הרשת, שקובעת איזו אתגר ותגובה ישלח המחשב לשרת; הוא אינו הבקרה שמסדירה יצירת פרטי גישה לכניסה יחידה, ולכן הורדתו אינה משחזרת את הכניסה. האם המכשיר ידבר בכלל NTLMv1 כפרוטוקול רשת הוא הגבול השלישי, ומהדורות Windows 11 ו-Server 2025 הנוכחיות כבר נטשו אותו. ה-Credential Guard, הרביעי, מגן על סודות במכשיר.

קשרו ניסיון אחד לאירוע אחד

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

Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, Message

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

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

עברו לשיטת כניסה נתמכת

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

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

מאמרים קשורים