האם הוצאת NTLM משימוש תעצור את אפליקציות העסק? — איך לאסוף לוגי ביקורת ובאיזה סדר לחסל תלויות

“שמעתי ש-NTLM יוצא משימוש. נהיה בסדר?” כדי לענות על זה, הדבר הראשון שצריך לעשות אינו לחסום אותו בכל החברה אלא לבצע ביקורת על האימות שפועל כרגע. כל גרסאות NTLM הוכרזו כ-deprecated ביוני 2024, אבל ההכרזה הזאת לבדה לא עוצרת שום עסק.¹

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

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

המכניקה של הפרוטוקול עצמו (למה NTLM מסוכן, ולמה אימות נופל חזרה ל-NTLM במקום ל-Kerberos) מופרדת למאמר הנלווה “NTLM ו-Kerberos מוסברים באיורים — למה אימות נופל חזרה ל-NTLM”.

מפת הדרכים של ההוצאה משימוש וזמינות התכונות מובאות נכון ליולי 2026, אותו בסיס תאריך כמו המאמר המקורי ביפנית. יש להפריד את זה מהתאריך שבו עודכן לאחרונה המבנה של המאמר הזה. בדקו את הזמינות של IAKerb, של ה-KDC המקומי ושל השאר ב-release notes של הגרסה שאליה אתם מכוונים, כשתבואו לקבל בפועל את החלטת המיגרציה.²

להתחיל מהבעיה שיש לכם

אם אתם קוראים ברצף, התחילו בפרק 1; כשאתם מתחילים בעבודה בפועל, חזרו לביקורת בפרק 4.

1. קודם המסקנות

להבחין איפה השינוי באמת עומד

NTLM הוצאה משימוש ביוני 2024. זה כולל כל גרסה, כולל LANMAN, NTLMv1 ו-NTLMv2, וזו הצהרה שפיתוח תכונות פעיל הופסק. באותה הכרזה נאמר גם ששימוש ב-NTLM ימשיך לעבוד במהדורה הבאה של Windows Server ובמהדורה השנתית הבאה של Windows.¹

חלקים ממנו כבר הוסרו. NTLMv1 הוסר ב-Windows 11 גרסה 24H2 וב-Windows Server 2025.¹

ההוצאה משימוש מתקדמת בשלושה שלבים. שלב 1 הוא הפיכת השימוש לגלוי וביקורת עליו, שלב 2 (המחצית השנייה של 2026) הוא התכונות שמסירות את המצבים שבהם אי אפשר להימנע מ-NTLM (IAKerb וה-KDC המקומי), ושלב 3 הוא השבתת אימות NTLM ברשת כברירת מחדל במהדורה הגדולה הבאה.²

לזהות את התלויות לפני שחוסמים משהו

יש דבר אחד בדיוק שצריך לעשות עכשיו. להפעיל מצב ביקורת ולבנות רשימה של “איזה מחשב, איזו אפליקציה, מול איזה שרת” משתמשים ב-NTLM (פרק 4).

עבור חשבונות דומיין, החקירה מתחילה בבקר הדומיין. מעקב אחרי אירוע 8004, ואז 8003 בשרת החבר, ואז 8001 בלקוח, מביא אתכם עד לשם האפליקציה (סעיף 4.2). שימו לב עם זאת שאימות עם חשבונות מקומיים לא עובר דרך בקר דומיין, ולכן לא מופיע 8004. את המסלול הזה צריך לתפוס מ-8003 בשרת ומ-8001 בלקוח.³

רוב הסיבות הן שמות. כתובות IP מקודדות ו-SPN-ים שלא נרשמו הם השניים הגדולים, ואף אחד מהם לא דורש בנייה מחדש של האפליקציה (פרק 5).³²

לנסות בקטן, ולתקן גם את צד האפליקציה

יש דרך בטוחה לבדוק על מחשב בודד. ב-Windows 11 24H2 או ב-Windows Server 2025, NET USE \\server\share /BLOCKNTLM מאפשר לבדוק “האם זה מתחבר בלי NTLM?” בלי לשנות אף מדיניות (פרק 7).⁴

באפליקציות שלכם, החליפו את המקומות שמציינים NTLM ב-Negotiate. Microsoft עצמה כותבת “אל תגשו ישירות ל-NTLM security package” (פרק 8).⁵

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 29, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. מה המשמעות בפועל של “הוצאה משימוש”

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

להפריד בין הכרזת ההוצאה משימוש לבין ההסרה שכבר קרתה

בקיצור, הרשומה של NTLM ברשימת התכונות שהוצאו משימוש של Microsoft אומרת שלושה דברים.¹

1. כל גרסה של NTLM, כולל LANMAN, NTLMv1 ו-NTLMv2, מחוץ לפיתוח תכונות פעיל והוצאה משימוש.
2. שימוש ב-NTLM ימשיך לעבוד במהדורה הבאה של Windows Server ובמהדורה השנתית הבאה של Windows.
3. יש להחליף קריאות ל-NTLM בקריאות ל-Negotiate. Negotiate מנסה לאמת עם Kerberos ונופל חזרה ל-NTLM רק כשצריך.

עדכון מאוחר יותר מוסיף שNTLMv1 הוסר מ-Windows 11 גרסה 24H2 ומ-Windows Server 2025.¹

אז המצב שבו אנחנו נמצאים הוא “הוצאה משימוש”, לא “הוסר”. רק NTLMv1 עבר מעבר להוצאה משימוש ונמצא כבר בשלב ההסרה. אם מדפסת רב-תכליתית ישנה או NAS יודעים לאמת רק עם NTLMv1, העדכון ל-Windows 11 24H2 הוא עצמו התקלה. זו לא בעיה של העתיד; היא קורית עכשיו.

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

הדבר הנוסף שכדאי להחזיק הוא של-NTLM עדיין יש שימושים שאין להם חלופה. Microsoft מציינת במפורש ש-NTLM עדיין בשימוש, וחייב להיות בשימוש, עבור אימות Windows במערכות שמוגדרות כחברות ב-Workgroup ועבור אימות התחברות מקומי במערכות שאינן בקרי דומיין.⁶ ה-KDC המקומי שמתוכנן לשלב 2 הוא בדיוק התכונה שאמורה למלא את הפער של “חשבונות מקומיים דורשים NTLM”.²

2.1. איפה שלושת השלבים עומדים

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

מה שהטבלה הזאת אמורה להבהיר הוא ששלב 1 הוא היחיד שאפשר לקדם בידיים שלכם היום. טבלת ההחלטות בפרק 6 אומרת על כמה סעיפים שתכונה משלב 2 “יכולה להיות התשובה”, אבל כל אחד מהם מותנה בבדיקת זמינות. תאריכי אספקה יכולים להשתנות, ולכן תמיד בדקו מחדש את תוכן הטבלה הזאת בנקודה שבה הארגון שלכם מקבל את ההחלטה.

3. למה זה נעלם — שלוש דקות

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

בתיעוד של הגדרות המדיניות, Microsoft קובעת בפשטות שאימות NTLM ו-NTLMv2 פגיע למגוון התקפות זדוניות, כולל SMB relay, man-in-the-middle ותקיפות brute force.⁷ בשורש העניין עומדות התכונות הבאות, שמוסברות בדרך כלל בהשוואה ל-Kerberos.⁸

אין אימות הדדי

ב-NTLM, לקוח לא יכול לאמת את זהותו של שרת, ושרת אחד לא יכול לאמת את זהותו של שרת אחר. NTLM תוכנן לסביבות רשת שבהן אפשר להניח ש”השרת אמיתי”. Kerberos לא מניח הנחה כזאת. ההבדל הזה הוא מה שמאפשר התקפות relay, שבהן קורבן גורם לשלוח את פרטי האימות שלו לשרת מזויף.

באימות דומיין, השרת פונה ל-DC

ב-NTLM, שרת אפליקציות צריך להתחבר לבקר דומיין בכל פעם שהוא מאמת לקוח עם חשבון דומיין (עבור חשבון מקומי של השרת, השרת מתייעץ עם מסד החשבונות שלו ומחליט שם).⁶ ב-Kerberos, כרטיסי session מתחדשים מחליפים את אימות ה-pass-through הזה, והשרת לא צריך לפנות לבקר דומיין אלא כשצריך לאמת את ה-PAC (privilege attribute certificate).

האש שנגנב מנוצל בלי לדעת את הסיסמה

פרטי האימות של NTLM מורכבים משם דומיין, שם משתמש ו-hash חד-כיווני של הסיסמה (רק הסיסמה עוברת hash), והלקוח מצפין את ה-challenge עם ה-hash הזה כדי להפיק את ה-response שלו.⁵ מכאן נובעת התכונה שגניבת ה-hash מספיקה כדי להתחזות למשתמש, בלי לדעת את הסיסמה בטקסט גלוי.

המשמעות המעשית של “אין אימות הדדי” היא שניסיון פשוט להתחבר ל-share של SMB יכול למסור את פרטי האימות שלכם לשרת מזויף. הסיבה ש-Microsoft בנתה חסימת NTLM לתוך לקוח ה-SMB מתוארת באותה צורה: למנוע טכניקות שגורמות לשלוח בקשות NTLM לשרתים זדוניים.⁴

4. ביקורת — בניית רשימה של היכן משתמשים ב-NTLM

זה הלב של המאמר. ההנחיה של Microsoft עצמה קובעת במפורש שגילוי וביקורת של המצב הנוכחי של תעבורת אימות NTLM הכרחיים לפני יישום מדיניות הגבלה.⁹

4.1. הפעלת מצב ביקורת

הערה: מצב ביקורת רק רושם; הוא לא חוסם דבר. מנגד, בסביבה עם מחשבים רבים נפח היומן קופץ מיד. אם אתם לא משתמשים באיסוף אירועים (WEF), עברו על מגבלת גודל היומן ותקופת השמירה לפני שאתם מפעילים. ההנחיה של Microsoft אומרת גם שהניתוח עלול לקחת כמה חודשים בהתאם למורכבות הסביבה.³

את תקופת הביקורת ספרו מרגע שההגדרות הגיעו למחשבי היעד. כדי לא לפספס עיבוד חודשי או מסלולים שמשמשים רק בתקלה, קראו גם את סעיף 9.2 על “מחזור עסקי שלם”.

איפה מגדירים, ושלוש המדיניות

יש שלוש מדיניות להגדיר. כולן נמצאות תחת Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, ולא נדרש restart. בין אם תשמרו אותן מקומית ובין אם תפיצו אותן ב-Group Policy, הן נכנסות לתוקף ברגע שההגדרה מיושמת.⁷

אל תשתמשו בשעה שבה שמרתם את ה-GPO כתחילת הביקורת

“לא נדרש restart” ו”נכנס לתוקף בכל מחשב מיד” הם לעומת זאת שני דברים שונים. כשאתם מפיצים GPO של דומיין, שמירת ה-GPO מעדכנת רק את המדיניות ב-AD וב-SYSVOL; כל מחשב מתחיל לבצע ביקורת בפועל ב-refresh הבא שלו ברקע או אחרי שאתם מריצים gpupdate /force. ספרו את תחילת תקופת הביקורת מהרגע שההגדרות סיימו להגיע למחשבי היעד, ולא מהרגע שמרתם את ה-GPO. אם תטעו בזה, התוצאה תיטה לכיוון מסוים: רק הצבירה הראשונה תכסה פחות מחשבים ממה שאתם חושבים.

לשלישית, “Outgoing NTLM traffic to remote servers”, יש ארבעה ערכים: Allow all, Audit all, Deny all ו-Not Defined, ו-Not Defined מתייחס לאותו דבר כמו Allow all. ההמלצה של Microsoft ברורה באותה מידה: אל תקפצו ישר ל-“Deny all”; הגדירו קודם “Audit all”, עברו על ה-operational log, הבינו אילו שרתים מקבלים בקשות אימות, ורק אז בנו את רשימת החריגים.⁷

מסתכלים על NTLM/Operational, לא על ה-Security log

האירועים נרשמים ב-Event Viewer > Applications and Services Logs > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). אין מדיניות של security audit event שמתאימה לביקורת הזאת, ולכן מסתכלים על ה-channel הזה ולא על ה-Security log.⁷

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

הדבר היחיד שהכי קל לטעות בו בשטח הוא המיפוי של “איזו מדיניות שמים על איזה מחשב, ואיזה אירוע מסתכלים עליו”. אם נקרא לשלוש המדיניות בטבלה שלמעלה (1), (2) ו-(3), הרי זו רשימת הבדיקה.

היומן הוא אותו Microsoft-Windows-NTLM/Operational בכל מחשב. מדיניות (1) משפיעה רק על בקרי דומיין, ומחשב ששכחתם בו את (2) ו-(3) אינו “מחשב שלא משתמש ב-NTLM” אלא “מחשב שלא רושם”. ההבדל הזה הוא מקור ההטיה הגדול ביותר בצבירות.

4.2. לעקוב “מבקר הדומיין והלאה במורד הזרם”

מתחילים מלהפריד בין החשבונות שמשמשים לאימות. עבור חשבונות דומיין, עוקבים מבקר הדומיין והלאה; עבור חשבונות מקומיים, עוקבים מהשרת ומה-לקוח.³

שימו לב גם שיש מקרים שבהם לא מופיע 8004 בבקר הדומיין, כי כשמשתמש מקומי מתחבר לשרת קבצים, האימות הזה לא עובר דרך בקר דומיין.³ אל תסיקו “יומני ה-DC היו דלילים, אז אנחנו בסדר”.

חשבונות דומיין: עוקבים 8004 → 8003 → 8001

מסלול המעקב לחשבונות דומיין שנותנת ההנחיה של Microsoft הוא כזה.³

flowchart TD
    DC["בקר דומיין<br/>אירוע 8004"]
    MS["שרת חבר<br/>אירוע 8003"]
    CL["לקוח<br/>אירוע 8001"]
    APP["האפליקציה האשמה"]

    DC -->|"Secure Channel Name =<br/>השרת לבדיקה"| MS
    MS -->|"Workstation Name =<br/>הלקוח לבדיקה"| CL
    CL -->|"Client Process Name"| APP
    MS -.->|"PID 4 (SYSTEM) אומר<br/>שזה הגיע דרך SMB"| CL

איור 1: הסדר שבו עוקבים אחרי אירועי הביקורת של NTLM

השדות שמסתכלים עליהם בכל אירוע הם אלה.³

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

מה שהופך את המסלול הזה לבעל ערך במיוחד הוא “Target Server” ו-“Client Process Name” באירוע 8001. הראשון אומר לכם ישירות למה זה לא הפך ל-Kerberos, והשני אומר לכם ישירות מי אשם. ההנחיה של Microsoft מתארת את אותו דבר: מהמידע הזה אפשר לקבוע שמשתמש מתחבר לכתובת ה-IP של שרת אינטרנט ולא לשם NetBIOS או ל-FQDN שהיו מאפשרים Kerberos.³

4.3. צבירה עם PowerShell

שלב 1: לספור את מזהי האירועים שנרשמו במחשב

להסתכל על אלפי רשומות בממשק של Event Viewer זה לא ריאלי, ולכן מסכמים אותן עם Get-WinEvent. קודם בודקים אילו אירועים מופיעים במחשב וכמה מכל אחד.

# צבירת אירועי NTLM/Operational לפי ID (להריץ כמנהל)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

שלב 2: לפתוח אירוע 8001 אחד ולבדוק את שמות השדות בפועל

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

# קודם בודקים אירוע אחד
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# כדי לראות את השדות המובנים
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

שלב 3: לצבור לפי יעד כפול תהליך קורא

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

# צבירת 8001 של 7 הימים האחרונים לפי "יעד × תהליך קורא"
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # לאסוף רק את שמות השדות שקיימים בפועל, לפי סדר עדיפות
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

שלב 4: להסתכל על היעד ועל האפליקציה שאחראית, לא על מספר המופעים

הצבירה הסופית מחזירה שתי עמודות: Count ו-Name (היעד והתהליך הקורא מחוברים בפסיק). כלומר, הפלט נראה כך (הערכים להמחשה בלבד).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

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

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

אם הצבירה מחזירה ריקים או PIDs, לחזור לשמות השדות

כיוון ששמות השדות שונים בין גרסאות מערכת הפעלה, הקוד מפרט מועמדים במערך לפי סדר עדיפות ולוקח רק את אלה שקיימים. אם תשתמשו כאן בהתאמה חלקית כמו -match 'Process', גם שדות PID כמו ClientProcessId ייתפסו, ותיגמרו בצבירה לפי PID שמשתנה בכל פעם במקום לפי שם קובץ ההרצה (סדר המפתחות בטבלת hash אינו מוגדר, ולכן גם לא מובטח מה תקבלו). אם עמודת ה-Process יוצאת ריקה בכל השורות, זה הסימן ששמות המועמדים שלכם לא תואמים לסכימה בפועל, ולכן הוסיפו את השם שאימתתם בשלב הקודם למערך.

לפני שמתרחבים, לוודא שמחשב אחד נקרא באותה צורה

אם אתם אוספים מכמה מחשבים, הרצה במקביל עם PowerShell Remoting היא הדרך המהירה (“מבוא ל-PowerShell Remoting (WinRM) — ניהול כמה מחשבי Windows בבת אחת”). השאלה אם אתם משתמשים ב--FilterHashtable עושה הבדל של סדר גודל בזמן שסינון Get-WinEvent לוקח; העיקר של זה מרוכז ב-“חקירת יומני אירועים בפועל עם Get-WinEvent — מהירות הסינון קובעת כמה זמן החקירה תיקח”.

4.4. להסתכל מהצד של ה-Security log — האם NTLMv1 עוד בשימוש?

בנפרד מ-NTLM/Operational, יש גם דרך לבדוק את גרסת ה-NTLM מאירועי ההתחברות ב-Security log. הנוהל הוא לחפש ב-Security log את “Authentication Package” ולהסתכל על “Detailed Authentication Information” בכל אירוע.³

Detailed Authentication Information:
    Logon Process:              NtLmSsp
    Authentication Package:     NTLM
    Transited Services:         -
    Package Name (NTLM only):   NTLM V1
    Key Length:                 128

רשומות NTLM V1 מטופלות בנפרד ובעדיפות גבוהה יותר

ה-“Package Name (NTLM only)” הזה מראה איזה תת-פרוטוקול ממשפחת NTLM שימש.³ מארח שמציג NTLM V1 הוא מועמד לכשלי אימות ברגע שתשדרגו אותו ל-Windows 11 24H2 או ל-Windows Server 2025, כי NTLMv1 הוסר בגרסאות האלה.¹ כשאתם מריצים את הביקורת, העלו את העדיפות של ההיבט הזה במיוחד.

4.5. כשהכול מציג PID 4 (SYSTEM) ואי אפשר להתקדם

תתחילו לבצע ביקורת וכמעט בטוח תיתקלו בקיר הזה. באפליקציות שמתקשרות דרך ה-redirector, כמו SMB (תיקיות משותפות), הגורם שמבקש אימות הוא ה-redirector במצב kernel, ולכן ה-PID שנרשם באירוע הוא תמיד 4 (SYSTEM).³

לצמצם למחשב אחד בעזרת היומנים, ואז לרדוף אחרי המחשב הזה עם ProcMon

התרופה שנותנת ההנחיה של Microsoft היא כזאת.³

1. להתקין כלי לניטור תהליכים בלקוח ששולח את פרטי האימות של NTLM (ה-“Computer” באירוע 8001).
2. לסנן נתיבים לפי גם שם המחשב של שרת העמית וגם כתובת ה-IP שלו. אם צריך לתעד לאורך זמן, להריץ במצב background.
3. להצליב את התיעוד עם חותמות הזמן של אירוע 8003 בצד השרת. המשתמש, הנתיב ומזהה האימות מסתדרים, ומשם אפשר לזהות את האפליקציה הקוראת.

הכלי הוא Process Monitor (ProcMon). איך מחילים סינון ואיך קוראים את הפלט מרוכזים ב-“מדריך מעשי ל-Process Monitor (ProcMon) — לאתר בזמן של 10 דקות הגדרה שלא הוחלה ו-ACCESS DENIED”.

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

5. תבניות אופייניות שנופלות חזרה ל-NTLM

אחרי שהביקורת אמרה לכם איפה, השלב הבא הוא לסווג את הסיבות. ההנחיה של Microsoft מפרטת את ארבעת אלה כאפליקציות שמשתמשות ב-NTLM למרות שהן תומכות תאורטית ב-Kerberos.³

• אפליקציות שמאפשרות לבחור בין תצורות אבטחה ו-providers שונים
• אפליקציות שה-SPN (service principal name) שלהן לא מוגדר נכון
• אפליקציות שמשתמשות בכתובת IP ולא בשם DNS בגלל תצורה שגויה או תיעוד של הספק
• אפליקציות עם קוד בסיס ישן שעדיין יש בהן חלקים שתומכים רק ב-NTLM

הבלוג של התמיכה הטכנית של Microsoft Japan מונה את הסיבות האופייניות לשימוש ב-NTLM: גישה לשרת שצוינה לפי כתובת IP, הגבלות firewall על הפורטים ש-Kerberos צריך, SPN-ים שלא נרשמו, אימות מול שותף מהימן, ואימות בסביבת Workgroup.²

לרשום את הסיבה ואת עדיפות התיקון באותה טבלה

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

לתת ל-NTLMv1 עדיפות ראשונה, ולהתחיל במקביל תיאומים עם זמן אספקה ארוך

סדר העבודה נובע מכנית משתי העמודות האלה.

1. בלי קשר לרדיוס ההשפעה, העדיפות העליונה היא ציוד שיודע לדבר רק NTLMv1 ומארחים שבהם נרשם NTLM V1 (סעיף 4.4). זה יוצא מחוץ לחישוב העדיפות, כי המועד שלו כבר הגיע.¹
2. אחר כך באים רדיוס השפעה גדול וקלות תיקון גבוהה, כלומר כתובות IP מקודדות. מספר המופעים גבוה ואפשר לתקן לפי החלטה שלכם בלבד. להתרכז בהם בחודש הראשון.
3. אחרי זה סעיפי קלות התיקון הבינונית סביב SPN-ים. לעבור עליהם יחד עם האחידות של שמות.
4. סעיפי קלות התיקון הנמוכה (תלוי בהתקן, נתיב רשת, המתנה לשלב 2) לא מאחרים להתחיל; פשוט יש להם זמן אספקה ארוך, ולכן מתחילים את הפניות לספקים ואת בקשות התקציב במקביל לסעיפים 1 עד 3.

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

6. טבלת החלטות לתיקונים

בוחרים את התיקון לפי הסיווג שקבעתם בפרק 5. קודם עושים את המעבר ל-FQDN ואת בדיקת ה-SPN, ומתייחסים ל-TryIPSPN כמוצא האחרון למקרה שאי אפשר להשתמש בשם. יש חריג לגבי היכן נרשמים SPN-ים עבור IIS, ולכן קראו את סעיף 8.3 על “הזהות שמפענחת את הכרטיס” לפני שמתחילים.

7. חסימת NTLM ב-SMB — הדרך הקצרה לבדיקה אמיתית

לוגי הביקורת אומרים לכם שמשהו נמצא בשימוש, אבל לא מה יקרה אם תעצרו אותו. כאן עוזרת חסימת ה-NTLM בצד לקוח ה-SMB שנוספה ב-Windows Server 2025 וב-Windows 11 גרסה 24H2.⁴

התכונה חוסמת את לקוח ה-SMB מלהשתמש באימות NTLM בחיבורים יוצאים למחשבים מרוחקים. Microsoft קובעת שזה מונע טכניקות שגורמות לשלוח בקשות NTLM לשרתים זדוניים ומתמודד עם תקיפות brute force, cracking ו-Pass-the-Hash, וממקמת את חסימת NTLM כמה שהכרחי למעבר של פרוטוקול האימות של הארגון ל-Kerberos. במקביל היא כותבת שאפשר להפעיל את שכבת ההגנה הזאת לבדה, בלי להשבית את NTLM לגמרי.⁴

הערה: זו תכונה של לקוח ה-SMB.⁴ NTLM במסלולים שאינם SMB (תעבורת HTTP מהאפליקציות שלכם, חיבורים ל-SQL Server, WinRM וכדומה) לא נעצר על ידה. את אלה צריך לחסל בנפרד, לפי הסיווג בפרק 5.

יש שני תנאים מוקדמים.⁴

• לקוח ה-SMB הוא Windows Server 2025 ואילך, או Windows 11 גרסה 24H2 ואילך
• שרת ה-SMB ביעד יכול להשתמש ב-Kerberos (מערכת ההפעלה בצד שרת ה-SMB יכולה להיות כל דבר שתומך ב-PKU2U או ב-Kerberos)

7.1. לבדוק קודם מחשב אחד וחיבור אחד

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

# לנסות להתחבר עם איסור NTLM בחיבור הזה בלבד (אם זה מתחבר, ה-share הזה לא צריך NTLM)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# אותו דבר אפשר לעשות עם מיפוי ב-PowerShell
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

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

בודקים את התוצאה בשלושה שלבים. אל תסיקו על תלות ב-NTLM מהניסוח של הודעת שגיאה בלבד.

ארבעה שלבים כדי להימנע מפסק דין שגוי

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

$server = 'fileserver.corp.example.com'

# 1. להסיר כל מיפוי אחרון לשרת הזה
#    אם נשאר אפילו share אחד אחר, ה-session לשרת נשאר בחיים
net use | Select-String $server              # קודם לראות מה מחובר
net use \\$server\share  /delete
net use \\$server\other  /delete             # וגם כל share אחר על אותו שרת

# 2. לאמת שה-session באמת נעלם (לא להמשיך עד שזה ריק)
Get-SmbConnection -ServerName $server

# 3. קודם לאמת שזה מתחבר בלי הדגל (כשל כאן אינו בעיית NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # גם כאן לחזור לריק

# 4. ורק אז לנסות עם /BLOCKNTLM
net use \\$server\share /BLOCKNTLM

שלבים 1 ו-2: לפרק את ה-session לשרת, לא רק ל-share

session-ים של SMB הם לפי שרת, לא לפי share. אם נשאר session מאומת לשרת הזה, ה-redirector עושה בו שימוש חוזר במקום לאמת שוב. /BLOCKNTLM משפיע רק על האימות שמבוצע עבור המיפוי הזה; הוא לא מאמת בדיעבד session שכבר הוקם (ושאולי הוקם עם NTLM).

במילים אחרות, /delete על ה-share הנבדק לבדו אינו מספיק. אם share אחר על אותו שרת עוד מחובר, זה יצליח למרות שקיימת תלות ב-NTLM. להביא את זה עד ש-Get-SmbConnection לא מחזיר דבר. מלבד המיפויים שלכם, גם אפליקציות שפועלות ברקע ומשימות גיבוי יכולות להחזיק session. הגישה האמינה והמהירה ביותר היא לבדוק ממחשב שמעולם לא התחבר לשרת הזה.

שלב 3: להשתמש בהצלחה בלי הדגל כבסיס להשוואה

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

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

שימו לב שכל מה שאפשר לומר כאן הוא “זה לא היה צריך את NTLM”, ולא “זה אומת עם Kerberos”. התנאי המוקדם של התכונה הזאת הוא “שרת SMB שיכול להשתמש ב-Kerberos”, אבל היעד רשאי להיות מערכת הפעלה שתומכת ב-PKU2U.⁴ זה משאיר אפשרות שהסיבה להצלחה הייתה PKU2U ולא Kerberos. כשהעמית הוא שרת קבצים שהצטרף לדומיין זה כנראה לא ישנה, אבל כשרוצים לקבוע בדיוק מה אומת, מריצים klist בלקוח אחרי ההתחברות ורואים אם התקבל כרטיס cifs/ לשרת הזה, או בודקים את חבילת האימות של אירוע ההתחברות ב-Security log בצד השרת (סעיף 4.4).

7.2. הפעלה לפי מחשב

אחרי שהאימות הושלם, עוברים לחסימה בכל המחשב במחשבי ה-pilot.⁴

# לחסום NTLM בכל לקוח ה-SMB (להריץ כמנהל)
Set-SmbClientConfiguration -BlockNTLM $true

ב-Group Policy מפעילים את “Block NTLM (LM, NTLM, NTLMv2)” תחת Computer Configuration > Administrative Templates > Network > Lanman Workstation.⁴

7.3. עמיתים שאי אפשר לשנות נכנסים לרשימת החריגים

עמיתים שבאמת צריכים NTLM, כמו שרתי SMB שלא הצטרפו לדומיין, יכולים להיות חריגים. מפעילים ב-Group Policy את Lanman Workstation > Block NTLM Server Exception List ורושמים את כתובות ה-IP, שמות ה-NetBIOS וה-FQDN-ים שרוצים לאפשר.⁴

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

אין cmdlet של PowerShell ליצירת רשימת החריגים עצמה, ולכן את התצורה הראשונה חייבים לעשות ב-Group Policy Editor; אחרי שהיא קיימת, אפשר להוסיף רשומות בודדות בעריכת registry.⁴

# להוסיף רשומות לרשימת חריגים קיימת
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

הערה: בדוגמה שמפורסמת בתיעוד של Microsoft, הענף של “הערך עוד לא קיים” מגדיר רק @(""), ולכן הרשומות שרציתם להוסיף נזרקות לפח.⁴ ההתנהגות היא שהרצה ראשונה לא מוסיפה אף חריג ורק ההרצה השנייה מוסיפה, ולכן הקוד שלמעלה כותב את הרשומות כפי שהן גם במקרה שהערך עוד לא נוצר. עם זאת, ערך ה-registry הזה הוא טריטוריה שמנוהלת על ידי Group Policy. נהלו חריגים קבועים בצד ה-Group Policy והגבילו את הפעולה הזאת לשימוש של חירום וזמני. יישום המדיניות הבא ידרוס אותה.

8. NTLM מנקודת המבט של המפתח — להשתמש ב-Negotiate

אם אתם בונים אפליקציות Windows בעצמכם, מה שצריך לתקן ברור. Microsoft קובעת את הדבר הבא במפורש.⁵

אפליקציות לא אמורות לגשת ישירות ל-NTLM security package; במקום זאת הן אמורות להשתמש ב-Negotiate security package. Negotiate מאפשר לאפליקציות ליהנות מפרוטוקולי אבטחה מתקדמים יותר אם המערכות שמשתתפות באימות תומכות בהם. נכון להיום, חבילת האבטחה Negotiate בוחרת בין Kerberos ל-NTLM. Negotiate בוחר Kerberos אלא אם אחת המערכות שמשתתפות באימות לא יכולה להשתמש בו.

בקיצור, הכלל הוא להחליף את המקומות שכתוב בהם “NTLM” ב-“Negotiate”. גם רשימת התכונות שהוצאו משימוש אומרת את אותו דבר: יש להחליף קריאות ל-NTLM בקריאות ל-Negotiate.¹

8.1. ה-“ציון NTLM” הנפוץ ב-.NET

להחליף רק את סוג האימות, לא את החשבון שמאמת

// רע: מציין NTLM כסוג האימות
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// טוב: רק סוג האימות משתנה. פרטי האימות מועברים כמו קודם
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

מה שמשתנה כאן הוא רק המחרוזת של סוג האימות. אם תחליפו את credential ב-CredentialCache.DefaultNetworkCredentials, תשנו לא רק את פרוטוקול האימות אלא את הזהות שמאמתת. האימות ייצא אז כחשבון שמריץ את התהליך (חשבון שירות או המשתמש המחובר) ולא כחשבון שציינתם, ובהתאם להרשאות ביעד זה יכול להפסיק לעבוד. החזיקו את החלפת הפרוטוקול ואת כל בחינה מחדש של פרטי האימות כשינויים נפרדים.

מעבר לאימות כהמשתמש הנוכחי הוא החלטה נפרדת

אם לעומת זאת מה שאתם רוצים מלכתחילה הוא לאמת עם פרטי האימות של המשתמש המחובר (אימות Windows משולב), אפשר לכתוב את זה הרבה יותר פשוט. כך כותבים את זה כשאתם משנים בכוונה את “מי שאתם מאמתים בתורו”.

// אימות Windows משולב (אימות כהמשתמש המחובר כרגע)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

הטיפול ב-HttpClient עצמו (לא לעטוף אותו ב-using, תבניות יצירה, תכנון timeouts) מכוסה ב-“אל תעטפו את HttpClient ב-using — תקשורת HTTP מעשית באפליקציות עסקיות ב-C# (תבניות יצירה, timeouts, retries)”.

כשעובדים ישירות עם SSPI, גם שם מציינים Negotiate

אם אתם חייבים לעבוד ישירות עם SSPI, System.Net.Security.NegotiateAuthentication, שנוסף ב-.NET 7, מאפשר לטפל באימות מעל Negotiate מקוד מנוהל. גם כאן הנקודה המרכזית היא לא לציין NTLM כשם החבילה.

8.2. “איך כתוב היעד” בא לפני הקוד

גם אם תתקנו את הקוד, אם היעד עוד כתוב ככתובת IP זה יגיע בכל זאת ל-NTLM. כברירת מחדל, כששם המארח הוא כתובת IP, Windows לא מנסה אימות Kerberos מול המארח הזה ונופל חזרה לפרוטוקול תקף אחר, כמו NTLM.¹⁰ באופן קונקרטי, עברו על הדברים הבאים.

• שמות שרתים שכתובים בקבצי תצורה (appsettings.json, App.config, קבצי ini)
• ציון השרת במחרוזות חיבור של SQL Server (Data Source)
• מקומות שבהם מרכיבים נתיבי UNC. לחפש כתובות IP מקודדות
• ערכי ברירת מחדל במתקינים ובנהלי התקנה של מחשבים
• מקומות שנכתבו מחדש ככתובת IP בתקלה קודמת “כי פתרון השמות היה לא יציב” ומעולם לא הוחזרו

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

8.3. אם אתם בונים את צד השירות

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

ב-IIS, זהות ה-App Pool והזהות שמפענחת אינן בהכרח אותו דבר

אם תחשיבו את יעד הרישום בפשטות כ”החשבון שמריץ את השירות”, תיתקלו ב-IIS. אימות Windows ב-IIS פועל כברירת מחדל עם אימות במצב kernel, ובמקרה הזה מי שמפענח את כרטיס ה-Kerberos הוא לא זהות ה-application pool אלא חשבון המחשב שבו משתמש HTTP.sys. הרצה של ה-application pool תחת חשבון דומיין ייעודי ורישום ה-SPN של ה-HTTP של האתר בחשבון הזה מותירה את בעל ה-SPN ואת החשבון שמפענח בפועל לא מסכימים, והאימות עצמו נכשל עם KRB_AP_ERR_MODIFIED במקום ליפול חזרה ל-NTLM.

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

מה לבחור תלוי בשאלה אם אותו חשבון שירות משותף לכמה שרתים (אם כן, איחוד על זהות ה-pool קל יותר לניהול). שימו לב שSPN יכול להיות רשום רק בחשבון אחד, ולכן כשאתם מחליפים, אל תשכחו להסיר את הרישום הישן. רישומים כפולים שוברים את אימות Kerberos עצמו.

לבדוק גם את ההאצלה לשרתים אחרים יחד עם שינוי הפרוטוקול

אם התכנון שלכם מתחזה ללקוח כדי לגשת לשרת אחר (delegation), NTLM ו-Kerberos שונים באופן שבו הם מטפלים בזה. Kerberos תומך במנגנון האצלה שבו שירות מתחבר לשירותים אחרים בשם הלקוח, ואילו מה ש-NTLM מספק מגיע רק עד למידע ההרשאה שנדרש כדי להתחזות באופן מקומי.⁸ הצד המימושי של ההתחזות מכוסה ב-“טיפול נכון ב-impersonation token של Windows — השאלת הרשאות לכל thread וחזרה בטוחה”.

9. מפת דרכים להידוק מדורג

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

9.1. עצירת SMB היא רק חצי מהטיפול ב-NTLM

שלבים 4 עד 6 מטפלים ב-SMB בלבד. כפי שמוסבר בפרק 7, חסימת NTLM בצד לקוח SMB היא תכונה של לקוח ה-SMB,⁴ ואין לה שום השפעה על מסלול אחר. כל מה שסיווגתם בשלב 2 כ”מאמת מעל HTTP”, “SQL Server משתמש ב-NTLM” או “WinRM משתמש ב-NTLM” נשאר לא נגוע כשתסיימו את שלב 6. וכיוון שזה גם לא מופיע ברשימת החריגים של SMB, ספירה של הרשימה הזאת לא תגלה אותו.

עבור כל מה שאינו SMB, להתקדם בביקורת, חריגים וחסימה עם Restrict NTLM

שלב 6b הוא מה שסוגר את הפער הזה. הוא משתמש בדיוק בשלוש המדיניות שהעברתם למצב ביקורת בפרק 4. הנוהל עוקב אחרי אותה צורה.¹¹

1. להשאיר את “Outgoing NTLM traffic to remote servers” על Audit all ולמנות את היעדים שנשארו
2. לרשום את העמיתים שבאמת צריך ב-“Add remote server exceptions”
3. להעביר מחשבי pilot ל-Deny all ולהמתין שהעסק יעבור מחזור שלם
4. אם אין בעיות, לפרוס

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

עבור הדומיין בכללותו, להעביר את “NTLM authentication in this domain” באותו סדר: ביקורת, חריגים (“Add server exceptions in this domain”), ואז חסימה.¹² Microsoft אומרת באותה מידה שלפני שבוחרים באפשרות חסימה יש להגדיר את מדיניות הביקורת המתאימה לאותה אפשרות ולהעריך את ההשפעה.¹²

“חסמנו את SMB, אז הטיפול ב-NTLM הושלם” אינו נכון. אם רוצים מדד להשלמה, ספרו גם את רשימת החריגים של SMB וגם את רשימת החריגים של Restrict NTLM.

9.2. לקבוע את תקופת הביקורת לפי “מחזור עסקי שלם”, לא לפי ימים

הדבר שהכי קל לטעות בו בשלב 1 הוא איך מחליטים על התקופה. תכריזו שזה הושלם כי “אספנו שבועיים” וכל מה שלא רץ בשבועיים האלה לא נמצא ברשימה. ומה שלא נמצא ברשימה יישבר בפעם הראשונה אחרי שתפיצו את החסימה בשלב 6.

למפות גם מסלולי שחזור ומחשבים לא מקוונים, לא רק עיבוד חודשי

באופן קונקרטי, הדברים שהכי קל לפספס הם אלה.

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

אם אי אפשר לחכות, להריץ את העיבוד בתדירות הנמוכה בכוונה

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

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

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

9.3. לא להעביר ישר לחסימה

המפתח כאן הוא לא להעביר את “Outgoing NTLM traffic = Deny all” בתנועה אחת. Microsoft אומרת באותה מידה שהגדרה של המדיניות הזאת לחסימה עלולה לגרום לכשל של בקשות אימות NTLM רבות ולפגוע בפרודוקטיביות, ולכן לפני יישום יש לעבור על היומן עם “Audit all”, לנתח את השרתים ולבנות רשימת חריגים של אלה שיש להוציא.⁷ אותה אזהרה כתובה גם לגבי המדיניות “NTLM authentication in this domain” שמכוונת לדומיין כולו.¹²

10. סיכום

• כל גרסאות NTLM הוצאו משימוש ביוני 2024. זה לא שינוי שעוצר משהו מיד; נאמר שזה ימשיך לעבוד במהדורה הבאה של Windows Server ובמהדורה השנתית הבאה של Windows.¹
• מנגד, NTLMv1 כבר הוסר (Windows 11 24H2 ו-Windows Server 2025). ציוד שיודע לדבר רק NTLMv1, ומארחים שבהם נרשם NTLM V1, הם המועד הקרוב ביותר.¹
• להוצאה משימוש יש שלושה שלבים: שלב 1 הוא ביקורת, שלב 2 (המחצית השנייה של 2026) הוא IAKerb וה-KDC המקומי, ושלב 3 הוא כיבוי ברירת המחדל.²
• ביקורת פירושה העברה של שלוש המדיניות למצב ביקורת ואיסוף Microsoft-Windows-NTLM/Operational. עבור חשבונות דומיין, עוברים 8004 ב-DC, 8003 בשרת החבר, ואז 8001 בלקוח, ומגיעים בסוף לשם האפליקציה. אימות עם חשבונות מקומיים לא מייצר 8004, ולכן תופסים אותו מאירועי השרת והלקוח.³⁷
• תעבורה דרך SMB מציגה תמיד PID 4 (SYSTEM). לצמצם למחשב בעזרת יומני האירועים, ואז לרדוף אחרי המחשב הזה עם ProcMon.³
• רוב הסיבות הן שמות. רק טיפול בכתובות IP מקודדות וב-SPN-ים שלא נרשמו מקטין מאוד את החריגים שנשארים.³²
• NET USE \\server\share /BLOCKNTLM הוא הדרך הבטוחה ביותר לאמת, חיבור אחד בכל פעם, בלי לשנות מדיניות.⁴
• באפליקציות פנימיות, להחליף NTLM בשם ב-Negotiate ולאחד את כתיבת היעדים על FQDN-ים.⁵
• רשימת חריגים היא תקופת חסד, לא פתרון. להשתמש בשאלה אם המספר יורד בכל שנה כמדד.

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

• NTLM ו-Kerberos מוסברים באיורים — למה אימות נופל חזרה ל-NTLM
• מלכודות בכונני רשת ובנתיבי UNC — עבודה עם שרתי קבצים (תיקיות משותפות) מאפליקציה עסקית
• חקירת יומני אירועים בפועל עם Get-WinEvent — מהירות הסינון קובעת כמה זמן החקירה תיקח
• מדריך מעשי ל-Process Monitor (ProcMon) — לאתר בזמן של 10 דקות הגדרה שלא הוחלה ו-ACCESS DENIED
• מבוא ל-PowerShell Remoting (WinRM) — ניהול כמה מחשבי Windows בבת אחת
• טיפול בטוח בפרטי אימות ב-PowerShell — הרחקת סיסמאות בטקסט גלוי מהסקריפטים שלכם
• שילוב אימות Entra ID באפליקציות WinForms/WPF — ארכיטקטורה מעשית עם MSAL.NET ו-WAM Broker
• מהו ה-TPM ב-Windows? — מדריך מאויר ל”כספת שלעולם לא מוציאה מפתחות החוצה” ולמדידה של אתחול

תחומי ייעוץ קשורים

KomuraSoft LLC מבצעת מיפוי של תלויות NTLM, התאמת אפליקציות עסקיות למעבר לסביבה מבוססת Kerberos, וחקירת תקלות שקשורות לאימות.

• פיתוח אפליקציות Windows
• חקירת תקלות וניתוח שורש הבעיה
• שימוש חוזר בנכסי legacy ותמיכה במיגרציה
• יצירת קשר

מקורות

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

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

כשה-NTLM יוצא משימוש, מתי העסק שלנו ייעצר?

הכרזה על "הוצאה משימוש" כשלעצמה לא עוצרת דבר. Microsoft הוציאה משימוש את כל גרסאות NTLM ביוני 2024, אבל בהנחיות הנלוות נאמר ששימוש ב-NTLM ימשיך לעבוד במהדורה הבאה של Windows Server ובמהדורה השנתית הבאה של Windows. השינוי הקונקרטי שכבר גרם לשבירות הוא הסרת NTLMv1 ב-Windows 11 גרסה 24H2 וב-Windows Server 2025. יש תוכנית מפורסמת להשבית אימות NTLM ברשת כברירת מחדל במהדורה עתידית, אבל גם אז נאמר שאפשר להחזיר אותו לפעולה באמצעות מדיניות. במילים אחרות, זה לא שינוי שבו החברה כולה נעצרת ביום אחד; זה שינוי שהולך ומתהדק עם כל גרסת מערכת הפעלה חדשה. בדיוק בגלל זה ההכנה הריאלית היחידה היא למפות את התלויות עם לוגי ביקורת בזמן ש-NTLM עוד עובד, ולא לחקור אחרי שמשהו כבר נשבר.

איך מפיקים רשימה של המקומות שבהם משתמשים ב-NTLM?

מעבירים את משפחת הגדרות ה-Group Policy של "Network security: Restrict NTLM" למצב ביקורת ואוספים את יומן NTLM/Operational. מגדירים "Audit NTLM authentication in this domain" בבקרי דומיין, ואת "Audit Incoming NTLM Traffic" יחד עם "Outgoing NTLM traffic to remote servers = Audit all" בשרתים ובלקוחות, והאירועים נרשמים תחת Applications and Services Logs > Microsoft > Windows > NTLM ב-Event Viewer. עבור אימות עם חשבון דומיין, הסדר הוא: מזהים את המשתמש ואת שרת היעד (Secure Channel Name) מאירוע 8004 בבקר הדומיין, מסתכלים על ה-PID באירוע 8003 בשרת הזה, ולבסוף מזהים "איזו אפליקציה, מול איזה שם שרת" בעזרת אירוע 8001 בלקוח. אירוע 8001 נושא את שם שרת היעד ואת שם תהליך הלקוח, כך שברגע שמגיעים לשם יודעים איזו אפליקציה אשמה. שימו לב שאימות עם חשבונות מקומיים לא עובר דרך בקר דומיין, ולכן לא יופיע 8004. מסלולים שבהם מחשב ב-Workgroup או חשבון מקומי על שרת קבצים מתחבר ל-share צריכים להיתפס מ-8003 בשרת ומ-8001 בלקוח. אל תסתכלו רק על יומני בקר הדומיין ותסיקו "כמעט לא משתמשים בזה".

הפעלתי ביקורת וכל האירועים מציגים PID 4 (SYSTEM). אני לא מצליח לדעת איזו אפליקציה זו.

זה קורה כי התעבורה עוברת דרך SMB (תיקיות משותפות). אימות SMB מתבצע על ידי ה-redirector במצב kernel, ולכן האפליקציה הקוראת מוסתרת מאחורי חבילות ה-SMB וה-PID שנרשם באירוע הוא תמיד 4 (SYSTEM). ההנחיה של Microsoft מתייחסת למקרה הזה במפורש וממליצה להריץ Process Monitor (ProcMon) בלקוח שבו מופיעים האירועים, לסנן נתיבים לפי שם המחשב וכתובת ה-IP של שרת העמית, ולהצליב עם חותמות הזמן של אירוע 8003 בצד השרת כדי לזהות את התהליך הקורא. בפועל המסלול המהיר הוא לצמצם קודם "איזה מחשב" בעזרת יומני האירועים, ואז לרדוף רק אחרי המחשב הזה עם ProcMon.

למה אפליקציה שאמורה לתמוך ב-Kerberos נופלת חזרה ל-NTLM?

כמעט תמיד זו בעיה של שמות. ההנחיה של Microsoft מפרטת ארבעה סוגי אפליקציות שמשתמשות ב-NTLM למרות שהן תומכות תאורטית ב-Kerberos: אפליקציות שמאפשרות לבחור את תצורת האבטחה או את ה-provider; אפליקציות שה-SPN (service principal name) שלהן לא נרשם כראוי; אפליקציות שמתחברות לפי כתובת IP במקום לפי שם DNS בגלל תצורה שגויה או תיעוד של הספק; ואפליקציות עם קוד בסיס ישן שעדיין מכיל חלקים שתומכים רק ב-NTLM. אם "Target Server" באירוע 8001 אינו בצורת NetBIOS ולא בצורת FQDN (כלומר כתובת IP), Kerberos לא ישמש בתצורת ברירת המחדל. שתי הפעולות הראשונות הן להחליף כתובות IP מקודדות ב-FQDN, ולרשום SPN עבור ה-alias אם הגישה משתמשת בו. יש גם דרך להגדיר TryIPSPN בלקוחות ולרשום ידנית SPN עבור כתובת ה-IP, למקרים שבהם באמת אי אפשר לשנות את השם, אבל Microsoft עצמה אומרת שיש להגביל את זה למצבים שבהם המעבר לשם DNS בלתי אפשרי, ולכן יש להתייחס לזה אך ורק כמוצא אחרון.

מה עלינו לתקן באפליקציות Windows שאנחנו מפתחים בעצמנו?

מחליפים כל מקום שמציין NTLM כ-authentication package ב-Negotiate. Microsoft קובעת במפורש שאפליקציות לא אמורות לגשת ישירות ל-NTLM security package אלא להשתמש ב-Negotiate package. Negotiate בוחר בין Kerberos ל-NTLM, ובוחר Kerberos אלא אם אחת המערכות שמשתתפות באימות לא יכולה להשתמש בו. ב-.NET התיקון האופייני הוא לשנות את סוג האימות שמועבר ל-CredentialCache.Add מ-"NTLM" ל-"Negotiate" (סוג האימות מצוין ב-CredentialCache.Add, לא בבנאי של NetworkCredential). לצד זה צריך גם לציין יעדים לפי FQDN ולא לפי כתובת IP או alias שכתוב ב-hosts, ואם רוצים שהשירות שלכם יקבל Kerberos — לרשום SPN על חשבון השירות הזה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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