למה תיקייה משותפת ב-Windows עובדת לפעמים ונכשלת בפעמים אחרות — troubleshooting של Kerberos, NTLM ו-Credentials

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

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

מדריך האבחון הזה מרכז פקודות להריץ, איך לקרוא את התוצאות שלהן, ואיפה לחקור אחר כך, במקום לקבוע סיבה מהתסמין לבדו. לפרוטוקולים עצמם ראו NTLM ו-Kerberos מוסברים. לתכנון אפליקציה ראו מלכודות של network drives ו-UNC path.

1. מתחילים כאן: המסקנה ומפתח התסמינים

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

flowchart TB
    accTitle: מעבר מתסמינים לראיות
    accDescr: בוחרים מועמדים מהתסמין, משווים ראיות מניסיונות מוצלחים וכושלים, ואז בוחרים תיקון.
    symptom["בוחרים את התסמין"] --> compare["משווים הצלחה וכשל"]
    compare --> evidence["מצמצמים מועמדים עם לוגים"]
    evidence --> fix["משנים דבר אחד ובודקים שוב"]

איור 1: משתמשים בתסמינים כדי להתחיל את החקירה, ובוחרים תיקונים רק אחרי בדיקת הראיות.

ההיקף הוא shares של SMB 2/3 ב-Windows 11 וב-Windows Server על חיבורי TCP 445 רגילים. דוגמאות PowerShell מכוונות ל-Windows PowerShell 5.1. זה מדריך ביניים למנהלים ולמפתחים, אבל קוראים בלי גישת ניהול לשרת עדיין יכולים להתחיל באיסוף מידע בצד הלקוח.

מבחינים בין דומייני AD, shares של Windows ב-workgroup, וחשבונות ספציפיים ל-NAS. המאמר מכסה Kerberos רגיל של AD ותצורות חשבון מקומי קונבנציונליות; SMB over QUIC, אימות ספציפי ל-Azure Files, ותצורות IAKerb או LocalKDC בודדות מחוץ להיקף. עם DFS, רושמים גם את שרת היעד הסופי. הגדרות וברירות מחדל מבוססות על תיעוד רשמי שנבדק ב-8 בספטמבר 2026; התצורה בפועל גוברת על הנחות לפי שם ה-OS.

קודם מאשרים אילו חשבונות ה-share מוגדר לקבל. AD מנהל מרכזית חשבונות לארגון, בעוד חשבונות מקומיים שייכים למחשבים בודדים. NAS יכול להשתמש בחשבונות משלו או להצטרף ל-AD. לא גוזרים Kerberos מ-LAN ארגוני או NTLM מכך שהשרת הוא NAS; שואלים את המנהל על תצורת האימות.¹²³

האם ה-PC שייך לדומיין ואילו credentials החיבור הזה השתמש בהם הן גם שאלות שונות. בדוגמאות למטה, CORP\alice הוא חשבון דומיין, בעוד FILESRV01\alice הוא חשבון מקומי בשרת הקבצים. משתמש באותו שם במחשב שלכם אינו בהכרח נותן למשתמש הזה אותן הרשאות בשרת.⁴⁵

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

2. מפרידים את השלבים שמוסתרים מאחורי “לא מצליחים להתחבר”

פתיחת קובץ כוללת הקמת תקשורת, משא ומתן על דרישות SMB, אימות session, חיבור ל-share, וביצוע פעולת קובץ. אימות מוצלח אינו מעניק גישה ל-share או לקובץ. הודעה שאומרת שנתיב הרשת לא נמצא יכולה אפילו להיות קשורה ל-guest access שנדחה. לא מאבחנים כשל DNS מההודעה הזו לבדה.⁶⁷

flowchart TB
    accTitle: שלבים לפני שקובץ משותף נפתח
    accDescr: קישוריות, משא ומתן SMB, אימות, חיבור ל-share ופעולות קובץ יכולים להיכשל בנפרד.
    net["Name resolution ו-TCP"] --> negotiation["משא ומתן על דרישות SMB"]
    negotiation --> session["SESSION_SETUP: אימות"]
    session --> tree["TREE_CONNECT: share"]
    tree --> file["CREATE ופעולות קובץ אחרות"]

איור 2: הצלחה בשלב אחד אינה מוכיחה הצלחה בשלב הבא.

כאן, הצלחה פירושה ביצוע הפעולה המיועדת על הקובץ המיועד. לראות PC בתצוגת Network של File Explorer, לראות רשימת shares, ולקרוא קובץ מסוים אינם שקולים. רושמים את נתיב ה-UNC והפעולה שנכשלים בפועל, ולא רק אם רשימה גלויה.

3. אוספים ראיות לפני restart או שינוי הגדרות

מחיקת חיבורים או כרטיסים בהתחלה מסירה את המצב שרציתם להשוות. קודם רושמים את הזמן, נתיב UNC, משתמש, OS וחיבורים קיימים בלקוח. הפקודות הבאות בודקות מצב. כשחוקרים כשל של service, לא מתייחסים לתוצאות מהטרמינל האינטראקטיבי הזה כתוצאות מה-service עצמו.⁴⁸⁹

Get-Date -Format o
whoami /user
whoami /groups
Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber
net use
cmdkey /list
klist

גם אוספים את הבאים במקום שיש הרשאה לשאול חיבורי SMB. תוצאת access-denied פירושה “לא ניתן לבצע את השאילתה”, לא “אין חיבורים”. מסמנים כל תוצאה שנאספה שוב כמנהל עם הקשר ההרצה הזה. elevation שקט של כל החקירה יכול לשנות את ה-logon session שמשווים.⁴¹⁰

Get-SmbConnection | Format-List *

ב-Get-SmbConnection בודקים Credential וגם UserName. זהות ה-logon המקומית וה-credentials ששימשו לחיבור ה-share יכולים להיות שונים. השוואת ServerName, ShareName, UserName ו-Credential בין ניסיונות מוצלחים וכושלים עוזרת לקבוע אם משווים את אותו חיבור.⁴

flowchart TB
    accTitle: מידע שמור מול מצב פעיל
    accDescr: בודקים בנפרד credentials שמורים, חיבורי SMB וכרטיסי Kerberos.
    snapshot["לוכדים באותו זמן"] --> stored["Credentials שמורים"]
    snapshot --> connection["חיבורי SMB שהוקמו"]
    snapshot --> ticket["Cache של כרטיסים"]
    stored -.-> verify["משווים שימוש בפועל מול לוגים"]
    connection --> verify
    ticket -.-> verify

איור 3: מבחינים בין מה שמור לבין מה שהחיבור הנחקר באמת השתמש בו.

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

4. קודם בודקים name resolution ו-TCP 445

הבאה היא בדיקת קישוריות פעילה שרצה בלקוח. מחליפים את שם השרת בשם החיבור בפועל. רושמים name resolution וקישוריות TCP בנפרד.¹¹

$Server = 'filesrv01.corp.example.com'
Resolve-DnsName -Name $Server
Test-NetConnection -ComputerName $Server -Port 445 -InformationLevel Detailed

אם TcpTestSucceeded הוא False, חוקרים הגעה לפני אימות בנקודה הזו. בודקים את כתובת ה-IP של היעד, VPN וניתוב, firewalls של לקוח ושרת, ואת נקודת ההאזנה של השרת. הצלחה או כשל של ping אינם הצלחה או כשל של חיבור TCP 445. ולהפך, קישוריות TCP מוצלחת משאירה את שם ה-share, האימות, signing וההרשאות לא מאומתים.¹¹

flowchart TB
    accTitle: פרשנות בדיקת חיבור TCP
    accDescr: כשל בבדיקת TCP 445 מוביל לחקירת הגעה; הצלחה מובילה ל-SMB ולשלבים הבאים.
    tcp["בודקים TCP 445"] --> result{"הצליח?"}
    result -->|"לא"| route["בודקים יעד, נתיב, חסימה"]
    result -->|"כן"| smb["בודקים SMB, אימות, גישה"]

איור 4: הצלחת TCP היא ראיה שאפשר להמשיך לשלב הבא, לא שאימות הצליח.

כששם וכתובת IP מתנהגים אחרת, משווים RemoteAddress ואת תוצאות name resolution. שם קצר, FQDN ו-alias אינם בהכרח מגיעים לאותה IP. גם כשהם מגיעים, דרישות האימות בסעיף הבא נשארות נפרדות. אם שינוי השם נראה כמתקן את הבעיה, רושמים מה השתנה.

5. בודקים תנאי Kerberos כששמות ו-IP שונים

5.1. אותה IP אינה אומרת אותו אימות

כברירת מחדל, Windows אינו מנסה Kerberos כששם היעד הוא כתובת IP. אפשר להגדיר חריגים עם TryIPSPN ו-SPNs מבוססי IP, אבל הגישה התקנית במדריך הזה היא לקבע את שם ה-DNS הנכון ואת זהות השירות. הצלחה עם כתובת IP היא ראיה להשוואת name resolution, אימות וחיבורים קיימים; היא אינה מדגימה תיקון קבוע.¹²

flowchart TB
    accTitle: דרישות האימות תלויות בשם החיבור
    accDescr: בודקים דרישות Kerberos לפי שם ליעדי hostname, ומתחשבים בהתנהגות ברירת המחדל של אי-ניסיון Kerberos ליעדי כתובת IP.
    unc["סימון היעד בנתיב UNC"] --> name["Hostname או FQDN"]
    unc --> ip["כתובת IP"]
    name --> spn["בודקים את ה-SPN לשם הזה"]
    ip --> fallback["אין ניסיון Kerberos כברירת מחדל"]

איור 5: גם כששני שמות מזהים את אותו התקן, שינוי שם החיבור משנה תנאי אימות.

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

5.2. מפרידים בין רכישת כרטיס לקבלה בשרת

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

setspn -Q cifs/filesrv01.corp.example.com
setspn -Q HOST/filesrv01.corp.example.com

היעדר רישום מפורש של cifs/... אינו מוכיח לבדו שחסר SPN. לחשבונות מחשב, SPN מסוג HOST יכול להחליף מחלקות שירות כמו cifs. ולהפך, מציאת רישום אינה שוללת בעיות כמו בעלות של חשבון שאינו חשבון השירות בפועל, או רישומים כפולים. מנהלי AD צריכים לאמת בעלות לפני שינוי רישומים; לא מוסיפים SPN מכנית רק כי שאילתה החזירה אין התאמה.¹⁴

flowchart TB
    accTitle: מה בדיקות SPN וכרטיס קובעות
    accDescr: פענוח SPN, רכישת כרטיס וקבלה בשרת הקבצים הן בדיקות נפרדות.
    lookup["בעלים של SPN והחלפת HOST"] --> issue["אפשר לרכוש כרטיס?"]
    issue --> accept["הוא מתקבל לאימות SMB בפועל?"]
    accept --> logs["משווים מול לוגים בצד השרת"]

איור 6: רכישת כרטיס אינה מבטיחה ששרת הקבצים יקבל אותו.

אחרי שמירת המצב המקורי, ייתכן שתצטרכו לנסות klist get cifs/filesrv01.corp.example.com. זו בדיקה פעילה שמבקשת כרטיס ומשנה את ה-cache. אם היא נכשלת, חוקרים הגעה ל-DC, סנכרון זמן, שמות ו-SPNs. אם היא מצליחה, גישת SMB עדיין אינה מובטחת. לא מיישמים תוצאות כרטיס של משתמש אינטראקטיבי על בעיה שמתרחשת ב-service.⁸¹

ל-NAS בלי דומיין או לאימות עם חשבונות מקומיים, קודם בודקים את שיטות האימות והגדרות החשבון שה-share תומך בהן במקום להתחיל בתיקוני SPN של AD. גם בסביבות עם יכולות אימות חדשות יותר, מעדיפים רישומי חיבור על הנחות לפי שמות מוצרים.

6. File Explorer מצליח, אבל האפליקציה נכשלת

6.1. שם משתמש תואם אינו מספיק

משווים את חשבון ההרצה, logon session, elevation, נתיב UNC והפעולה. Service רץ ב-session אחר מ-logon אינטראקטיבי גם כשהוא מוגדר עם אותו חשבון משתמש. מיפויי אות כונן גם הם מוגבלים ל-logon sessions, לכן קודם מבחינים בין Z:\data לבין \\server\share\data. מעבר לנתיב UNC מטפל בבעיית אות הכונן; הוא אינו מעניק גם אימות או הרשאות.¹⁰

flowchart TB
    accTitle: File Explorer ו-service משתמשים בהקשרים שונים
    accDescr: גם באותו PC, משווים logon אינטראקטיבי ו-logon של service כ-sessions נפרדים עם credentials משלהם.
    pc["אותו PC"] --> explorer["Logon אינטראקטיבי"]
    pc --> service["Logon של service"]
    explorer --> a["חיבורים וגישה ב-session הזה"]
    service --> b["חיבורים וגישה ב-session אחר"]

איור 7: אותו PC ושם משתמש אינם בהכרח חולקים את אותו מצב חיבור.

מבקשים מהאפליקציה שנכשלת לרשום את מזהה התהליך, זהות ההרצה, מצב elevation, הנתיב בפועל, שם הפעולה, ה-exception המקורי וקוד השגיאה. אם היא משתמשת ב-impersonation, גם לוכדים את הזהות האפקטיבית של ה-thread שמבצע את הפעולה. לא סוגרים חקירת service רק כי session PowerShell של מנהל יכול לפתוח את ה-share.

6.2. חשבונות service וסוגי logon של משימות

כש-service משתמש ב-credentials ברירת המחדל שלו, LocalSystem מציג את credentials של המחשב ברשת, בעוד LocalService מציג credentials אנונימיים. לגישת LocalSystem ל-share של דומיין, ההרשאות הרלוונטיות שייכות לזהות שבשימוש בפועל, כמו חשבון המחשב, ולא למשתמש האינטראקטיבי. מימושים שמשתמשים ב-credentials מפורשים או ב-impersonation דורשים בדיקות משלהם.¹⁵¹⁶

flowchart TB
    accTitle: הרשאות מקומיות מול הזהות המרוחקת
    accDescr: עם credentials רשת ברירת מחדל, LocalSystem ו-LocalService מציגים זהויות שונות.
    service["Credentials ברירת מחדל של service"] --> system["LocalSystem"]
    service --> local["LocalService"]
    system --> machine["Credentials של המחשב"]
    local --> anonymous["Credentials אנונימיים"]

איור 8: הרשאות מקומיות נרחבות אינן הופכות את ה-service למשתמש האינטראקטיבי ב-share המרוחק.

ב-Task Scheduler בודקים את סוג ה-logon וגם את שם החשבון. TASK_LOGON_S4U אינו שומר סיסמה ואינו מספק גישה לרשת או לקבצים מוצפנים. לא מניחים שמשימה שמוגדרת לא לשמור סיסמה יש לה אותם תנאים כמו logon אינטראקטיבי רגיל. מגדירים תהליכים עסקיים עם חשבון service מתאים, סוג logon והרשאות least-privilege במקום להסתמך על כך שמישהו פותח את ה-share ב-File Explorer קודם.¹⁷

7. מבחינים בין ארבעה מובנים של “אין צורך בסיסמה”

היעדר prompt אינו ראיה לגישה לא מאומתת. ייתכן שמשתמשים ב-credentials של ה-logon הנוכחי, ב-credentials שמורים, או ב-SMB session שהוקם. רשומה ב-cmdkey /list לבדה אינה קובעת שהחיבור השתמש בה.⁴⁹

flowchart TB
    accTitle: מה היעדר prompt סיסמה אומר
    accDescr: לא גוזרים גישה לא מאומתת מה-UI; מבחינים בין credentials, session קיים, סיסמה ריקה ו-guest access.
    prompt["אין prompt סיסמה"] --> identity["בודקים את הזהות שהתקבלה בפועל"]
    identity --> authenticated["Credentials או session קיים"]
    identity --> blank["חשבון עם סיסמה ריקה"]
    identity --> guest["Guest"]

איור 9: ממשקים שנראים זהים יכולים להסתיר מנגנוני אימות שונים.

כששרת הקבצים רץ Windows והמדיניות שמגבילה חשבונות מקומיים עם סיסמאות ריקות ל-logon במסוף מופעלת, logon-ים רשת רגילים עם החשבונות האלה מוגבלים. זה נפרד מההגדרה שמתירה guest access. אם מישהו אומר שמשתמש עם סיסמה ריקה התחבר קודם, קודם מאמתים בשרת אם החשבון הזה באמת אימת את החיבור הקודם. במקום לכבות את המגבלה כתגובה ראשונה, שוקלים חשבון מתאים עם סיסמה לגישת share.²³

אם אתם מנהלים את שרת הקבצים של Windows, מריצים את הבאה ב-session PowerShell של מנהל באותו שרת בזמן שהגישה עובדת. לא מבלבלים בין Get-SmbConnection, שרץ בלקוח, לבין Get-SmbSession, שרץ בשרת שמקבל את החיבור.¹⁸

Get-SmbSession |
    Select-Object SessionId, ClientComputerName, ClientUserName, NumOpens

משתמשים ב-ClientComputerName ובזמן הניסיון כדי לאתר את ה-session הרלוונטי, ואז בודקים ClientUserName. זה מתאר SMB sessions שכבר הוקמו; הוא אינו מסביר חיבור שנכשל קודם או קובע אם השתמשו ב-Kerberos או ב-NTLM. אם לאותו לקוח יש כמה sessions, גם משווים זמני פעולת האפליקציה ורישומים ספציפיים ל-SMB. אם החיבור כבר נסגר, ממשיכים ללוגים בפרק 12.¹⁸

8. שגיאה 1219 וכשלים בהחלפת משתמשים

שגיאה 1219 מצביעה על התנגשות שכוללת כמה חיבורים לאותו שרת תחת שמות משתמש שונים. חיבורים קיימים לשרת הזה חשובים גם כששמות ה-share שונים. קודם משתמשים ב-net use וב-Get-SmbConnection כדי לבדוק חיבורים לשרת היעד. לפני שינוי credentials, מזהים קבצים פתוחים ואפליקציות שמשתמשות בחיבורים האלה.¹⁹²⁰

flowchart TB
    accTitle: Credentials יכולים להתנגש בין shares שונים
    accDescr: הוספת חיבור תחת משתמש אחר מאותו הקשר חיבור לאותו שרת יכולה להתנגש גם אם שם ה-share שונה.
    existing["כבר מחוברים לשרת כמשתמש A"] --> new["מתחברים ל-share אחר כמשתמש B"]
    new --> conflict["התנגשות credentials: 1219"]
    conflict --> inspect["בודקים חיבורים קיימים לפי שרת"]

איור 10: בודקים את השרת ואת ה-credentials יחד, לא רק את שם ה-share.

הבאה משנה מצב חיבור. רק אחרי עצירת השימוש ביעד וקבלת אישור להשפעה מנתקים ומתחברים מחדש לחיבור הספציפי שזיהיתם. מחליפים את שמות השרת, ה-share והחשבון בדוגמה. * מבקש prompt סיסמה אינטראקטיבי; לא שמים את הסיסמה ישירות בשורת הפקודה.⁵

net use "\\filesrv01.corp.example.com\data" /delete
net use "\\filesrv01.corp.example.com\data" /user:CORP\alice * /persistent:no

ניתוק share אחד יכול להשאיר חיבורים ל-shares אחרים או שימושים באותו שרת. בודקים את הרשימה שוב ומנקים רק את החיבורים הנחוצים לשרת היעד. לא הופכים net use * /delete או הימנעות בלתי מוגבלת מהתנגשויות עם aliases וכתובות IP לתיקון התקני. אחר כך מאמתים שהאפליקציה בפועל מתחברת עם ה-credentials המיועדים שלה.

9. כש-restart מתקן, שואלים מה השתנה

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

flowchart TB
    accTitle: פרשנות workaround מוצלח של restart
    accDescr: Restart משנה כמה תנאים, כך ששיפור לבדו אינו יכול לזהות סיבה אחת.
    reboot["Restart החזיר גישה"] --> app["מצב האפליקציה"]
    reboot --> session["מצב חיבור ו-logon"]
    reboot --> network["רשת ומצב אחר"]
    app --> evidence["צריך ראיות לפני ואחרי"]
    session --> evidence
    network --> evidence

איור 11: Restart עשוי להחזיר שירות בלי להוכיח את הסיבה.

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

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

klist purge משנה מצב על ידי מחיקת כרטיסים. הוא אינו מכוון לחיבור שאינו משתמש ב-Kerberos ויכול להשפיע על שירותים אחרים באותו logon session. נמנעים מ”פשוט לנקות” לפני שמירת ראיות.⁸

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

10.1. לא מערבבים signing, guest access וחסימת NTLM

SMB signing מגן מפני שיבוש הודעות; זו הגדרה נפרדת מכך אם האימות משתמש ב-Kerberos או ב-NTLM. מדריך SMB signing הייעודי של Microsoft מציין ש-Windows 11 24H2 Pro, Enterprise ו-Education דורשים signing נכנס ויוצא כברירת מחדל, בעוד Windows Server 2025 דורש signing יוצא. בודקים את המהדורה ואת התצורה האפקטיבית, לא רק את שם ה-OS.⁷

ל-Home, המדריך הזה אומר ש-signing אינו נדרש, בעוד רשימת השינויים של Windows 11 24H2 כוללת את Home בין המהדורות שדורשות signing כברירת מחדל. לכן המסמכים נבדלים. במקום לדחות signing כלא רלוונטי ב-Home, משתמשים בפקודות למטה כדי לבדוק את המחשב הנחקר.⁷²¹

flowchart TB
    accTitle: דרישות הגנת SMB לבדיקה בנפרד
    accDescr: פרוטוקולי אימות, SMB signing ו-guest access הן הגדרות שונות שכל אחת צריכה בדיקה.
    policy["בודקים policy אפקטיבי"] --> auth["הרשאות Kerberos ו-NTLM"]
    policy --> signing["דרישת SMB signing"]
    policy --> guest["הרשאת guest access"]

איור 12: בדיקת הגדרה אחת אינה קובעת ששאר הדרישות מתקיימות.

Guest access אינו תומך ב-SMB signing או בהצפנה רגילים. לכן, התרת guests לבדה עשויה לא לפתור את הבעיה אם signing עדיין נדרש. מעדיפים להגדיר חשבונות מאומתים ו-signing ב-NAS. לא מתייחסים לכיבוי signing או להתקנת SMB1 כ-workaround קל.³

10.2. קוראים את התצורה בפועל, לא רק את ברירות המחדל

אוספים את הבאה ב-session PowerShell של מנהל בלקוח. זה קורא תצורה; מבחינים בינה לבין לכידת מצב חיבור של משתמש אינטראקטיבי.⁷²²

$config = Get-SmbClientConfiguration
$config | Format-List RequireSecuritySignature, EnableInsecureGuestLogons
if ($config.PSObject.Properties['BlockNTLM']) {
    $config | Format-List BlockNTLM
} else {
    'המאפיין BlockNTLM אינו זמין במערכת הזו.'
}

RequireSecuritySignature: False פירושו ש-signing אינו נדרש; הוא אינו מוכיח שכל חיבור אינו חתום. אם BlockNTLM חסר במערכת ישנה יותר, זה אינו מוכיח שמדיניות מגבלת NTLM אחרות חסרות. חסימת NTLM של לקוח SMB זמינה החל מ-Windows 11 24H2 ומ-Windows Server 2025, ואפשר גם לציין אותה לחיבורי share בודדים. בודקים גם את אפשרויות החיבור של האפליקציה ואת מדיניות הארגון, לא רק הגדרות גלובליות.⁷²²

flowchart TB
    accTitle: הגדרות גלובליות אינן קובעות את כל החיבור
    accDescr: בודקים מדיניות ארגון, אפשרויות חיבור ודרישות שרת בנוסף לברירות המחדל של ה-OS.
    defaults["ברירות מחדל של OS ומהדורה"] --> effective["דרישות החיבור בפועל"]
    organization["מדיניות ארגון ואפשרויות חיבור"] --> effective
    server["יכולות ודרישות השרת"] --> effective
    effective --> log["בודקים לוגים לסיבת הדחייה"]

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

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

11. האימות מצליח, אבל פתיחה או שמירה נכשלות

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

flowchart TB
    accTitle: אימות שונה מ-authorization
    accDescr: גם אחרי שאימות מצליח, גם הרשאות share וגם הרשאות קובץ חייבות לאפשר את הפעולה המבוקשת.
    identity["זהות מאומתת"] --> share["הרשאות share"]
    share --> file["הרשאות הקובץ שמתחת"]
    file --> operation["מבצעים את הפעולה המיועדת"]

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

רישום תיקייה, קריאת קובץ, יצירה, overwrite, שינוי שם ומחיקה הן פעולות שונות. לאפליקציה ששומרת על ידי יצירת קובץ זמני והחלפת המקורי, קריאה מוצלחת אינה מספיקה. מעבר לאימות ולהרשאות, חוקרים sharing violations, קיבולת, נתיבים או קבצים שנעלמו באמצעות השגיאה המקורית.²⁴

גם File.Exists של .NET מחזיר false לתנאים כמו הרשאות לא מספיקות. בודקים אם הודעת “הקובץ אינו קיים” של האפליקציה מבוססת רק על ערך ההחזרה הזה. קוד אבחון צריך לרשום exceptions מהפעולה שבאמת צריך לבצע.²⁵

$Path = '\\filesrv01.corp.example.com\data\sample.txt'
try {
    Get-Item -LiteralPath $Path -ErrorAction Stop |
        Select-Object FullName, Length, LastWriteTime
} catch {
    $_.Exception.GetType().FullName
    'HRESULT=0x{0:X8}' -f $_.Exception.HResult
    $_.Exception.Message
}

זה בודק שליפת metadata, לא קריאה או כתיבה מוצלחת של התוכן. כדי לבדוק I/O בפועל, משחזרים את הפעולה המיועדת על קובץ בדיקה אחרי אימות authorization והשפעה. שמירת שגיאות במקום להמיר את כולן ל-“הקובץ לא נמצא” גם מקלה על החקירה הבאה.

12. משווים לוגים כדי לצמצם את הסיבה

12.1. מבחינים בין לקוח, שרת קבצים ו-DC

בלקוח בודקים Microsoft-Windows-SMBClient/Connectivity ו-Microsoft-Windows-SMBClient/Security ב-Event Viewer. בשרת קבצים של Windows, אירועי Security 4624 ל-logon מוצלח ו-4625 ל-logon שנכשל יכולים לעזור כש-auditing מופעל. ל-logon-ים רשת של SMB בודקים logon type 3. ב-NAS משתמשים בלוגי האימות וה-share הספציפיים למוצר.²⁶²⁷²⁸

Logon type 3 באירוע 4624 אינו ספציפי ל-SMB. גם כשהזמן, המקור והחשבון תואמים, האירוע לבדו אינו מזהה share או SMB session. משווים אותו עם Get-SmbConnection, לוגים ספציפיים ל-SMB, ו-trace במקום שנחוץ.²⁷⁴²⁶

flowchart TB
    accTitle: השוואת לוגים משלושה מקומות
    accDescr: משווים לוגים של לקוח, שרת קבצים, ובמקום שנחוץ DC באמצעות זמן ומידע חיבור.
    client["לקוח: לוגי SMBClient"] --> match["מתאימים זמן, מקור וחשבון"]
    server["שרת קבצים: לוגי אימות"] --> match
    dc["DC: כרטיסים ואימות credentials"] --> match
    match --> result["קוראים כראיה לאותו ניסיון"]

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

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

$Start = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'; Id = 4624, 4625; StartTime = $Start
} -ErrorAction Stop | ForEach-Object {
    $event = $_
    $xml = [xml]$event.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = [string]$item.'#text'
    }
    if ($fields['LogonType'] -eq '3') {
        [pscustomobject]@{
            Time = $event.TimeCreated
            EventId = $event.Id
            User = $fields['TargetUserName']
            Domain = $fields['TargetDomainName']
            SourceIp = $fields['IpAddress']
            Authentication = $fields['AuthenticationPackageName']
            Status = $fields['Status']
            SubStatus = $fields['SubStatus']
            LogonId = $fields['TargetLogonId']
        }
    }
} | Format-List

ל-4624 קוראים את חשבון היעד של ה-logon החדש, לא את ה-Subject שדיווח על האירוע. ב-4625, שם המשתמש היעד הוא השם שניסו, לא זהות שהתקבלה. קוראים Status ו-SubStatus יחד לסיבת הכשל. אם AuthenticationPackageName אומר רק Negotiate, זה לבדו אינו קובע אם השתמשו ב-Kerberos או ב-NTLM.²⁷²⁸

12.2. כשאין לוגים, או רק כרטיס

מציאת אין אירוע אינה מוכיחה שאימות לא התרחש. בודקים auditing, הרשאות קריאה, הבדלי שעון, האם בודקים את השרת הנכון, שימוש חוזר ב-session קיים, וכשל לפני אימות. שימוש חוזר בחיבור SMB קיים אינו מייצר 4624 חדש בכל פעם שנפתח קובץ.²⁷⁴

flowchart TB
    accTitle: פרשנות אירועי לוג חסרים
    accDescr: כשאירוע חסר, בודקים תנאי איסוף ו-sessions קיימים במקום להסיק מיד שאימות לא התרחש.
    absent["אין אירוע תואם"] --> collection["Auditing, הרשאות, זמן, יעד"]
    absent --> reuse["שימוש חוזר ב-session קיים"]
    absent --> before["כשל לפני אימות"]

איור 16: רישום חסר אינו שקול לפעולה שמעולם לא התרחשה.

בסביבות AD, אירוע 4769 ב-DC עוזר לזהות בקשות כרטיס שירות של Kerberos, בעוד 4776 עוזר לזהות אימות credentials של NTLM. הנפקת כרטיס לבדה אינה מוכיחה שימוש או קבלה בשרת הקבצים, ו-4776 לבדו אינו מזהה SMB כשירות היעד. משלבים זמן, מקור, חשבון יעד ורישומים בצד השרת. אם נשארת עמימות, מבקשים ממנהל לאסוף trace בהיקף צר.²⁹³⁰

13. מאמתים פעולה אמינה אחרי התיקון

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

flowchart TB
    accTitle: מניסיון מוצלח אחד לבדיקת חזרה
    accDescr: אחרי שינוי אחד, בודקים שוב את תנאי הכשל המקוריים ואת תנאי החיבור מחדש.
    evidence["ראיה שמזהה את הסיבה"] --> change["תיקון ממוקד אחד"]
    change --> original["בודקים את האפליקציה והפעולה המקוריות"]
    original --> reconnect["בודקים שוב אחרי חיבור מחדש או restart"]
    reconnect --> record["רושמים הבדלים ותוצאות"]

איור 17: מאמתים הצלחה בתנאי הכשל המקוריים, לא רק ניסיון מוצלח בודד ב-File Explorer.

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

אם restart מחזיר גישה לתיקייה משותפת, זה מוכיח ש-cache גרם לבעיה?

לא. Restart משנה יחד את האפליקציה, logon sessions, חיבורי SMB, מצב הרשת ותנאים אחרים. לפני restart רושמים את היעד, זהות ההרצה, חיבורים קיימים, כרטיסים ושגיאות, ואז משווים מול ניסיון מוצלח. credentials שמורים וחיבורי SMB שכבר הוקמו הם דברים שונים.

למה אפשר לפתוח share לפי כתובת IP אבל לא לפי שם השרת?

קודם בודקים אם שתי הצורות מגיעות לאותה כתובת IP של היעד. גם כשהן מגיעות, תנאי האימות שונים: Windows כברירת מחדל אינו מנסה Kerberos ליעד שהוא כתובת IP. חוקרים name resolution בנפרד מ-SPNs ומאימות. הצלחה עם כתובת IP לבדה אינה תיקון קבוע.

למה File Explorer יכול לגשת ל-share שהאפליקציה שלי לא יכולה?

חשבון ההרצה, logon session, elevation, credentials או הפעולה המבוקשת עשויים להיות שונים. Service רץ ב-session אחר מ-logon אינטראקטיבי. שמות משתמש תואמים אינם קובעים תנאים שקולים, לכן בודקים את התהליך שנכשל עצמו ואת רישומי האימות בצד השרת.

חיבור בלי בקשת סיסמה אומר שהחיבור משתמש ב-guest access?

היעדר prompt אינו מספיק כדי לדעת. החיבור עשוי להשתמש ב-credentials של ה-logon הנוכחי, ב-credentials שמורים, או בחיבור SMB קיים. חשבון מקומי עם סיסמה ריקה וחיבור guest גם הם שונים. בודקים איזה חשבון השרת באמת קיבל.

אם klist מציג כרטיס cifs, האם SMB מחובר עם Kerberos?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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