הצטרפות לתחום דרך VPN של משתמש, ושרידה מהאתחול מחדש

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

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

לפני שמתחברים: מהדורה, מנהל מקומי, DNS

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

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

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

ודאו שהתחום ניתן לגילוי, לא רק לפינג

פתרו את רשומת LDAP SRV של התחום לפני ניסיון ההצטרפות. עבור סביבה לדוגמה עם תחום יחיד בשם ad.corp.example, השאילתה היא:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

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

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

בצעו את ההצטרפות וקראו את השגיאה

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

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

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

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

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

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

החלפת משתמשים והתמדה של VPN משתנות לפי לקוח. אל תניחו שחיבור שהתחיל כמנהל מקומי ישרוד לסשן של משתמש אחר.

שמרו על גישת שחזור מקומית

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

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