למה Windows מציע את סיסמת ה-VPN לשרת קבצים

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

זהו איזה חשבון נדחה

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

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

הגדירו UseRasCredentials בפרופיל אחד

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

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

ערכו את ספר הטלפונים שמחזיק בחיבור

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

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

Get-ChildItem "$env:APPDATA\Microsoft\Network\Connections\Pbk"
Get-ChildItem "$env:PROGRAMDATA\Microsoft\Network\Connections\Pbk"
Copy-Item "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk.bak"
Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials"

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

UseRasCredentials=1   becomes   UseRasCredentials=0

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

אמתו בניסיון חדש

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

Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials=0" -Context 4,0

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