ה-Mac שלך שולח את חשבון ה-Windows הלא נכון דרך RDP

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

עבור על הרשומה לפני שתיגע בצרור המפתחות.

חשבון ה-VPN וחשבון ה-Windows הם שני דברים שונים

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

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

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

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

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

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

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

השתמש בצורת החשבון שהמנהל סיפק

הקלד את החשבון בדיוק כפי שהונפק, בצורה שהסביבה מצפה לה: DOMAIN\user לדומיין בסגנון NetBIOS, או user principal name אם זה מה שהספרייה משתמשת בו. לאחר מכן שמור אותו עבור המחשב הזה ובצע ניסיון חיבור מכוון אחד.

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

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

חיבור כושל לפני הכניסה הוא תקלה אחרת

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

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

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

הנח לחיבור החוזר האוטומטי

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

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