אמון הדומיין נכשל אחרי חודש לא מקוון? בדקו קודם

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

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

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

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

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

סמל VPN אינו מוכיח דבר על הערוץ המאובטח

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

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

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

רשמו את שרת ה‑DNS, את הבקר שאותר ואת נוסח השגיאה המדויק. לקוח VPN שמדווח שהוא מחובר אומר שהמנהרה קיימת, לא שנתיב הדומיין עובד. בקר שעונה בפורט Kerberos אך לא בפורט הספרייה הוא ממצא חומת אש, לא ממצא אמון.

בדקו את החברה לפני שמתקנים אותה

בחבר דומיין Windows מורשה, Test-ComputerSecureChannel -Verbose הוא בדיקה לקריאה בלבד של הערוץ בין המחשב לדומיין. הריצו אותה בהקשר של המחשב שאתם חוקרים, לא מבקר דומיין, שיש לו תפקיד אחר וכללי שחזור אחרים. תעדו את הפלט ואת קוד היציאה ולא את המילה עבר או נכשל. אם ה‑cmdlet חסר בגרסה הזו, המודול הוא בעיה נפרדת.

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

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

תקנו רק את היחסים שהוכחתם

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

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

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

מה לבדוק כשהכשל חוזר

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

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

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