אינטגרציה של Microsoft Entra External Authentication עם ניתוב IDP של Okta
פורסם ב-19 באוגוסט 2025
אינטגרציה של Microsoft Entra External Authentication עם ניתוב IDP של Okta
Microsoft הציגה לאחרונה ב-Entra ID יכולת חדשה וחזקה שנקראת External Authentication Methods (EAM).
עבור ארגונים רבים, זה פותר בעיה ותיקה: איך מפעילים את יכולות האבטחה המתקדמות של Microsoft בלי לחייב משתמשים לוותר על פתרונות ה-MFA של צד שלישי שהם כבר מכירים ובוטחים בהם.
במשך שנים, ארגונים שהשתמשו ב-Okta, ב-Duo או בספקי MFA אחרים עמדו מול פשרה כואבת. או שהם נשארו עם הגדרת ה-MFA הנוכחית שלהם, ופספסו את אוטומציית האבטחה המובנית של Microsoft, או שהם עברו ל-Microsoft Authenticator, פגעו בחוויית המשתמש והיו צריכים להכשיר מחדש את כל העובדים.
הבעיה המרכזית ארגונים שמריצים MFA / IDP של צד שלישי היו מנועים מחלק מתרחישי תזמור האבטחה (security orchestration) היקרים ביותר של Microsoft. הנה רצף נפוץ כדוגמה (אינטגרציה של Defender > Intune > Entra):
-
Defender מזהה סיכון במכשיר
-
Intune מסמן את המכשיר כלא תואם (non-compliant)
-
Entra Conditional Access חוסם גישה למשאבי ענן
-
Defender חוקר ומתקן אוטומטית את האיום
-
Defender מנקה את סיכון המכשיר
-
Intune משחזר את התאימות
-
Entra ID מאפשר שוב גישה אוטומטית
אוטומציית האבטחה במעגל סגור הזו אפשרית רק כש-Microsoft Entra ID הוא הסמכות הראשית לאימות והרשאה.
כשיש MFA של צד שלישי, ארגונים לא יכלו לנצל את היכולת הזו בלי לפגוע בחוויית המשתמש.
דרישות טכניות
כדי ליישם External Authentication Methods, ארגונים צריכים:
-
רישיונות Microsoft Entra ID P1 או P2
-
זהויות משתמשים ראשיות שמאוחסנות ב-Entra ID (לא federated)
-
ספק MFA נתמך, כמו Okta, Duo או Akamai MFA
-
אינטגרציה תואמת OIDC בין Entra ID לספק ה-MFA
איך External Authentication Methods עובדים
EAM יוצר הפרדה בין מי שמנהל זהות והרשאה (Entra ID) לבין האופן שבו מתבצע ה-MFA (ספק צד שלישי).
כך זה עובד בפועל:
דרישות הגדרה:
-
זהויות המשתמשים חייבות להיות מנוהלות ישירות ב-Microsoft Entra ID (Cloud Apps נשאר מחובר ל-OKTA)
-
ספק ה-MFA של צד שלישי/OKTA רשום כ-External Authentication Method
-
מדיניות Conditional Access מוגדרת ב-Entra ID
זרימת האימות:
-
משתמש ניגש לאפליקציה ← מופנה ל-Entra ID (למשל מ-OKTA ל-Entra)
-
Entra ID מאמת את פרטי ההתחברות הראשיים (סיסמה או passwordless)
-
Conditional Access מעריך תאימות מכשיר, אותות סיכון ומדיניות
-
נדרש MFA ← Entra ID מפנה לספק הצד השלישי (למשל Okta Verify, Duo)
-
המשתמש משלים MFA עם האפליקציה הקיימת שלו
-
Entra ID מקבל את התוצאה ומקבל את החלטת ההרשאה הסופית
-
הגישה ניתנת כשכל מערך האבטחה של Microsoft פעיל
העיצוב הזה משאיר את Microsoft בשליטה בתהליך הזהות וההרשאה, ובמקביל מאפשר למשתמשי הקצה להמשיך עם כלי ה-MFA המוכרים להם.
היתרונות המרכזיים:
הערך של EAM ברור גם ל-IT וגם למשתמשי הקצה:
שמירה על חוויית המשתמש
-
אין צורך בהכשרה מחדש
-
אין מעבר כפוי ל-Microsoft Authenticator
-
העובדים ממשיכים להשתמש באפליקציית ה-MFA שהם כבר מכירים
מימוש מערך האבטחה המשולב של Microsoft
-
Conditional Access שקשור לתאימות המכשיר
-
תגובה אוטומטית לאיומים עם Microsoft Defender
-
הגנת זהויות מבוססת סיכון
-
ניהול מכשירים חלק עם Intune
אפשרות לאימוץ הדרגתי
-
מתחילים עם קבוצות פיילוט
-
בודקים מדיניות בבטחה לפני פריסה בכל הארגון
-
שומרים על רציפות עסקית תוך מודרניזציה של האבטחה
שורה תחתונה
עם External Authentication Methods, Microsoft מסירה את הבחירה המזויפת בין חדשנות באבטחה לחוויית משתמש.
ארגונים יכולים עכשיו להפעיל את אוטומציית האבטחה המתקדמת של Microsoft ובמקביל לשמור על השקעות ה-MFA, ועל היכרות המשתמשים איתן, שנבנו לאורך זמן.
לצוותי אבטחה, זו התפתחות חשובה. המשמעות היא שאפשר לנצל במלואם את Conditional Access, Defender ו-Intune בלי לעקור ולהחליף את פתרון ה-MFA הקיים.
EAM מספק את הגשר לאוטומציית האבטחה של הדור הבא, ומאפשר לארגונים להתחדש בקצב שלהם תוך שמירה על חוויית המשתמש.
Microsoft Entra External Authentication Methods נמצא כרגע ב-public preview. דורש רישוי Entra ID P1/P2. פנו לנציג Microsoft שלכם לקבלת הנחיות הטמעה.