התחקיר של Okta מ־5 בנובמבר על I-11904 מתאר תקלה שנפתרה בניהול Office 365: מ־29 באוקטובר 2026 ב־13:41 UTC עד 30 באוקטובר ב־02:34 UTC. הוספה, הסרה ושמירה חוזרת של דומיינים ב־WS-Federation אוטומטי נכשלו; כניסת SSO קיימת המשיכה לפעול.
Okta מייחסת את דחיית בקשות ההגדרה לעדכון eventual consistency ב־Microsoft Entra. החרגה שביצע הספק למזהי היישום של Okta החזירה את הפעילות. נוספה התראה; טיפול קבוע וניסיונות חוזרים נותרו בדיון.
התאימו את בדיקת הקבלה לשינוי
המסקנה התפעולית שלנו היא להפריד בתוכנית השינוי בין שתי שאלות: האם משתמש יכול להיכנס, והאם מנהל מערכת יכול להשלים את שינוי ההגדרה המתוכנן? תעדו תוצאה לכל שאלה, במקום להתייחס לבדיקה מוצלחת אחת כראיה לכל התהליך.
לשינוי פדרציה מתוכנן, אנו מציעים רישום קבלה קצר:
- לפני: זהו את דומיין היעד ואת הפעולה המתוכננת, הגדירו אחראי לשינוי ותעדו את המצב הסופי המצופה. השתמשו בסביבת בדיקה מאושרת כשאפשר.
- במהלך: תעדו את תוצאת השמירה בפועל ואת השעה. אם התוצאה אינה ודאית, בדקו את ההגדרה שנשמרה לפני חזרה על פעולת כתיבה.
- אחרי: ודאו שההגדרה שהתקבלה תואמת לתוכנית, ואז בדקו בנפרד את מסלול הכניסה הרלוונטי למשתמש. תעדו פערים לפני אישור מעבר לייצור.
- הסלמה לתמיכה: שמרו פרטי שגיאה מועילים בלי להעתיק אסימוני גישה, פרטי התחברות או מידע אישי שאינו נחוץ לפניית התמיכה.
אל תהפכו שגיאה לתיקון מנוחש
ההנחיות הכלליות של Microsoft Graph מבחינות בין תגובות הרשאה, משאב חסר, הגבלת קצב ושירות שאינו זמין. בהגבלת קצב הן ממליצות לכבד את ההשהיה שבכותרת Retry-After. ההנחיות מסייעות לסווג את התגובה בפועל; הן אינן קובעות את הגורם לכשל מסוים.
למנהלים המשתמשים באינטגרציה מנוהלת, שגיאה לא צפויה היא סיבה לאסוף ראיות ולהשתמש בתהליך שחזור נתמך. אל תחלישו אימות, תשנו הרשאות או תסירו דומיין ייצור תקין רק כדי להעלים הודעת שגיאה.
אלה בדיקות מוצעות שלא ביצענו. פרטי האירוע מסתמכים על דוח Okta, ללא שחזור עצמאי.