Kerberos SSO ו-VPN ב-Mac: השוו את שני נתיבי הכניסה

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

שני מנגנונים, מסך כניסה אחד

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

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

מה ההרחבה של Kerberos צריכה ברשת

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

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

klist
sudo sntp -sS time.apple.com

VPN לכל יישום מחליט אם ההרחבה יכולה לעבוד

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

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

סשן זהות בדפדפן הוא חוזה אחר

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

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

עברו על הרצף, לא על החלקים

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

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

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