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

מדוע המנהרה אינה יכולה להחליף זהות SMB

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

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

קראו את מדיניות הלקוח ואת אירוע הדחייה

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

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

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

השתמשו בחשבון בעל שם ושמרו על החתימה

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

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

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

כאשר המכשיר מכיר רק אורח

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

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

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