מיפוי שיתוף קבצים ב-VPN עם חשבון Samba שהשרת מכיר

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

הפתרון אינו איפוס חשבון ה-VPN. הפתרון הוא לנקוב בזהות שהשרת Samba אכן מכיר, ואז לבדוק שלאותה זהות יש זכויות על השיתוף והתיקייה.

כניסת VPN וכניסת SMB הן זהויות שונות

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

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

שרת Samba המשולב בדומיין משנה את התמונה: הזהות מגיעה מהמדריך ומ-Kerberos, לא מרשימת חשבונות מקומית. במקרה כזה השתמשו בזהות מהמדריך ובתצורת SMB הנתמכת במקום ליצור כפילויות מקומיות כדי לחקות חברות בדומיין. בדקו באיזה מודל משתמש השרת לפני יצירת חשבון כלשהו.

בדקו באיזו זהות Windows משתמש בפועל

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

net use
cmdkey /list
klist

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

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

מפו את השיתוף עם החשבון שהשרת מזהה

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

net use Z: \\files.corp.example\team * /user:FILESERVER\alice /persistent:no

רכיב השרת שלפני הקו הנטוי ההפוך הוא הקשר הזהות של שרת Samba, לא שער ה-VPN. הכוכבית מבקשת בקשה אינטראקטיבית לסיסמה, ו-/persistent:no משאיר את המיפוי מחוץ לכניסה הבאה. בחרו אות כונן פנויה.

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

תוקף החשבון, הגישה לשיתוף והרשאות מערכת הקבצים הם שלוש בדיקות

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

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

בצד מערכת הקבצים חשובים גם תהליך Samba וגם הזהות הממופה. תיקייה בבעלות root עם מצב 700 לא תקבל כתיבה מחשבון רגיל גם כאשר הגדרת השיתוף מתירה זאת. נסו בקריאה ואחר כך בכתיבה בתיקייה שהחשבון אמור להשתמש בה.

פנו הפעלה מתנגשת בלי לשבור את המדיניות

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

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

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