פענוח אפקט הדומינו בין דיירים ב-Microsoft Entra B2B

By Mirko Peters · 2026-08-11

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

Automatically translated with AI from the original post. Read the English original

ברוכים השבים לבלוג הפודקאסט, שבו אנו מעמיקים באתגרים הטכניים שעומדים בפני אנשי IT, אבטחה וארכיטקטים של זהויות. אם הקמתם פעם שיתוף פעולה עם שותפים ב-Microsoft 365, סביר להניח שנתקלתם בתרחיש מתסכל שבו שינוי הגדרה פשוט מפיל הכול, מהצ'אט ב-Microsoft Teams ועד שיתוף קבצים ב-SharePoint. בפרק האחרון שלנו, Fix Microsoft Entra B2B Direct Connect Issues, חשפנו את התלויות הנסתרות שמפתיעות מנהלים. בפוסט המלווה הזה נרחיב את הרעיונות האלה ונספק לכם תוכנית עבודה מלאה להבנה, לאיתור תקלות ולחיזוק התשתית הבין-דיירית שלכם.

סקירה כללית

B2B Direct Connect אינו מתג בודד ומבודד. הוא נשען על רשת מורכבת של מדיניות שמשתרעת על פני Microsoft Entra ID (לשעבר Azure AD), Microsoft Teams, Conditional Access, ספקי זהות חיצוניים וסנכרון ספרייה. כאשר נוכחות, צ'אט, פגישות ושיתוף קבצים נכשלים, הם לרוב נכשלים בשקט. המשתמשים מתקשים להבין מדוע אינם יכולים לשתף פעולה, והמנהלים נאלצים למהר לברר איזו מדיניות שברה את יחסי האמון. הדרך היחידה לפרוס ולתחזק שיתוף פעולה בין-דיירי עמיד, ללא השבתות בלתי צפויות, היא גישה מערכתית.

למי זה עוזר

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

• מנהלי Microsoft 365 או Entra שנדרשים לאפשר שיתוף פעולה מאובטח עם שותפים.
• מנהלי Teams שמנהלים פדרציית דיירים, Direct Connect והגדרות גישת אורחים.
• בעלי תפקידי אבטחה וניהול זהויות וגישה (IAM) שמכווננים מדיניות Conditional Access ודרישות אימות רב-שלבי.

מושגי ליבה (בשפה פשוטה)

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

• B2B Direct Connect: מסגרת אמון שמאפשרת שיתוף פעולה חלק בין דיירים. חשוב מכך, היא אינה עצמאית; היא נשענת במידה רבה על הגדרות מסונכרנות בין שני ארגונים עצמאיים.
• גישת אורח לעומת גישה חיצונית:
  • גישת אורח כוללת יצירת אובייקט משתמש ישירות בתוך הדייר שלכם, ומעניקה לו גישה לקבצים ולערוצים משותפים מסוימים בסביבה שלכם.
  • גישה חיצונית מאפשרת צ'אט, שיחות ופגישות מאוחדים ישירות בין שני דיירים נפרדים, מבלי לדרוש ממשתמשים להחליף הקשר זהות.
  • אלה בקרות עצמאיות. כאשר תרחיש שיתוף פעולה דורש את שתי היכולות, יש להפעיל ולהגדיר במפורש את שתיהן.
• Conditional Access (CA): שומר הסף בכניסה. כלל MFA או תאימות מכשיר נוקשה שנאכף על ידי ארגון שותף עלול לחסום בשוגג את המשתמשים הפנימיים שלכם מגישה למשאבים חיצוניים, ולעתים קרובות בלי להציג הודעת שגיאה ברורה.
• זהות וסנכרון: שינויים בסיסיים בספקי זהות (כמו מעבר מ-ADFS לאימות בענן), כללי claims מותאמים אישית, או אי-התאמות של מאפייני Azure AD Connect עלולים ליצור זהויות "צלליות" ששוברות בשקט חיפושי זמינות ביומן ושיתוף קבצים.

דפוסי הכשל המרכזיים (ומה המשתמשים רואים)

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

1. צ'אט חיצוני ונוכחות חסרים: המשתמשים רואים סטטוס אפור או לא מצליחים להתחיל צ'אט אחד-על-אחד עם שותף.
   • סיבה: גישה חיצונית ל-Teams מושבתת, או שדומיין השותף אינו מותר במפורש בהגדרות של אחד מהדיירים.
2. שגיאות "הקובץ לא נפתח" מצ'אט של Teams: שותף מנסה לפתוח מסמך משותף ישירות בתוך חלון הצ'אט, ומקבל הודעת גישה נדחתה.
   • סיבה: מדיניות שיתוף מגבילה ב-SharePoint, כלל של Conditional Access החוסם הקשרי הפעלה חיצוניים, או תכונת זהות חסרה.
3. לולאות כניסה ו-MFA אינסופיות בהצטרפות לפגישות: משתמשים נתקעים בלולאות אימות כשהם מנסים להצטרף לפגישה עם שותף חיצוני.
   • סיבה: מדיניות Conditional Access של השותף דורשת בקרות שהדייר הביתי של המשתמשים שלכם אינו יכול לספק, או שיש סטייה באמון בספק הזהויות.
4. מידע זמינות (free/busy) ביומן ריק או מציג רשומות כפולות: תיאום פגישה עם עמיתים חיצוניים הופך לניחוש, מכיוון שנתוני הזמינות מסרבים להסתנכרן.
   • סיבה: אי-התאמות של מאפייני Azure AD Connect (כמו הבדלים ב-User Principal Name) או חשבונות צל כפולים בספריה.
5. שגיאות בהזמנת אורחים או ערוצים חסרים: משתמשים מקבלים הזמנה, אבל אינם רואים ערוצים משותפים או משאבים משותפים.
   • סיבה: גישת אורחים מותרת, אך בסיסי Conditional Access או תוויות רגישות שבבסיס מונעים גישה למשאבים.

מטריצת החלטות מהירה

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

• צריכים שיתוף פעולה מעמיק בערוצים ועריכה משותפת של קבצים בתוך הדייר שלכם? הטמיעו גישת אורחים, יחד עם חריגים מתאימים ב-Conditional Access במידת הצורך.
• צריכים צ'אט מהיר, נוכחות ושיחות בין ארגונים נפרדים בלי להחליף הקשרי דייר? הטמיעו גישה חיצונית (פדרציה) שמוגדרת בשני הדיירים המשתתפים.
• צריכים את שני תהליכי העבודה? הפעילו גישת אורחים וגישה חיצונית במקביל, ודאו שמדיניות Conditional Access והשיתוף מיושרות היטב בשני הצדדים.

רשימת בדיקות לפני הפעלה (שני הדיירים)

לפני שתפתחו יכולות בין-דיירים בפני המשתמשים, עברו על רשימת הבדיקות המקיפה הזו בשתי הסביבות:

• גישה חיצונית ב-Teams
  • דומיין השותף היעד מותר (ולא חסום) בשני הדיירים המשתתפים.
  • הפדרציה מופעלת ברמת הארגון, ללא עקיפות מדיניות סותרות.
• גישת אורחים ושיתוף
  • גישת אורחים מופעלת במלואה הן ב-Entra ID והן במרכזי הניהול של Teams.
  • רמות השיתוף החיצוני ב-SharePoint וב-OneDrive תומכות בפעולות השיתוף הנדרשות.
  • תוויות רגישות מוגדרות כך שאינן חוסמות שיתוף פעולה חיצוני.
• Conditional Access
  • מדיניות נכנסת ויוצאת של חיצוניים/B2B נבדקו לעומק.
  • דרישות אימות רב-שלבי וציות מכשירים ריאליסטיות עבור משתמשי השותף (והחריגים מתועדים).
  • קיים נתיב חירום (break-glass) לפגישות ולגישה לקבצים באמצעות מיקומים מוגדרים או קבוצות חריגים ייעודיות.
• זהות וסנכרון
  • אשרו את מצב ספק הזהויות של השותף (ADFS לעומת אימות בענן) ובדקו את מטא-נתוני הפדרציה התקפים.
  • Azure AD Connect תקין ללא שגיאות סנכרון, וייחודיות UPN/דוא"ל אומתה.
  • אין אובייקטי אורחים כפולים או צל עבור אנשי מפתח.
• ניטור
  • קורלציית יומנים להחלטות Conditional Access פעילה כדי לתעד מזהי בקשות ותוצאות מדיניות.
  • בוצעו בדיקות קצה-לקצה לנוכחות, לצ'אט, לפתיחת קבצים, להצטרפות לפגישות ולזמינות ביומן (free/busy).

הפצה מינימלית בת-קיימא (רצף בטוח)

הפעלת יכולות בין-דיירים בבטחה דורשת מתודולוגיה משמעתית, שלב אחר שלב:

1. מיפוי תלויות: הבינו איך Direct Connect, Teams, Conditional Access, ספקי זהויות ו-SharePoint פועלים יחד בסביבה שלכם.
2. פתחו זוג דומיינים לפיילוט: חברו בין yourtenant.com לבין partner.com בגישה חיצונית ב-Teams בשני הצדדים.
3. יישרו את Conditional Access: הוסיפו חריג מדיניות זמני לתעבורת השותף, מוגבל למשתמשי הבדיקה בלבד.
4. אמתו זהות: אשרו תביעות UPN וודאו שלא נוצרים אובייקטי אורחים כפולים.
5. הריצו בדיקות קצה-לקצה: אמתו נוכחות, צ'אט 1:1, הצטרפות ספונטנית לפגישות, גישת אורחים לערוצים, פתיחת קבצים בתוך הצ'אט וזמינות ביומן (free/busy).
6. הדקו את Conditional Access: חדדו כללים לפי יומני הכניסה והסירו חריגים זמניים שכבר אינם נחוצים.
7. תיעוד והרחבה: אִרזו את הממצאים שלכם והרחיבו את ההגדרות לדומיינים נוספים של שותפים.

מדריך פתרון תקלות מהיר

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

• אין נוכחות או צ'אט: בדקו את רשימות ההיתר והחסימה החיצוניות של Teams בשני הדיירים.
• לולאות בהצטרפות לפגישה: בדקו את יומני הכניסה של Conditional Access עבור המשתמש החיצוני, והשוו את הבקרות הנדרשות ליכולות של השותף.
• קבצים לא נפתחים: בדקו את הגדרות השיתוף החיצוני של SharePoint ואת בקרות הסשן של Conditional Access; ודאו שתביעות הזהות הנדרשות קיימות.
• יומן ריק או שמופיעות כפילויות: בדקו ב-Azure AD Connect אי-התאמות של UPN, הסירו אובייקטים כפולים, ובצעו סנכרון מחדש בכוח.
• אורח לא רואה ערוצים: ודאו את מדיניות האורחים ב-Teams לצד היקפי מדיניות הרגישות והתוויות של הצוות.

מעקות בטיחות ופרקטיקות טובות

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

• נהלו רישום שותפים מקיף שעוקב אחר שמות דומיינים, מצבי IdP, מצבי CA ואנשי קשר מנהליים מרכזיים.
• השתמשו במיקומים בעלי שם או בהגדרות גישה בין-דיירים כדי למקד מדיניות Conditional Access בדיוק כירורגי.
• נהלו יומן שינויים מדויק שמתעד מעברי IdP, עדכוני CA ושינויים במדיניות Teams, וקשרו כל שינוי ישירות לתוצאות עסקיות.
• בצעו בדיקת תקינות רבעונית הכוללת בדיקות פדרציה, סקירות שגיאות סנכרון וביקורות CA.
• ספקו למשתמשים שלכם מדריך של עמוד אחד ברור לצ'אט ולפגישות בין-דיירים, שמדגיש את התנהגות החלפת החשבונות ואת מגבלות הפלטפורמה הידועות.

מדדי ביצוע לתשומת לב

עקבו אחר מדדי הביצוע המרכזיים הבאים כדי למדוד את תקינות התשתית לשיתוף פעולה בין-דיירים:

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

ניצחונות מהירים (השבוע)

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

• הפעילו ואמתו את רשימת ההיתר החיצונית של Teams עבור שלושת דומייני השותפים המובילים בשני הארגונים המשתתפים.
• צרו מדיניות בדיקה של Conditional Access עם קבוצת פיילוט ייעודית כדי לאמת דרישות MFA חיצוני וציות מכשירים.
• הריצו סריקה של כפילויות ושל סטיית UPN ב-Azure AD Connect, וטפלו מיד בחשבונות בעלי השפעה גבוהה.
• כתבו סקריפט לבדיקת נוכחות, צ'אט ופתיחת קבצים שניתן להריץ שוב ושוב לאחר כל שינוי במדיניות.

סיכום

שיתוף פעולה בין-דיירים נכשל בהכרח כאשר מנהלים מתייחסים להגדרות בודדות כאל איים מבודדים. כדי לבנות סביבה חזקה, יש לראות בתשתית הזהות שלכם מערכת אחת מגובשת, למפות כל תלות, ולתזמן בקפידה שינויים בין Conditional Access, פדרציית Teams, ספקי זהות וסנכרון ספריות. כשנוקטים בגישה הוליסטית זו, שינוי מדיניות בודד כבר לא יפיל את כל חוויית שיתוף הפעולה עם השותפים. כדי להעמיק עוד יותר במלכודות תצורה נסתרות ובאסטרטגיות תיקון מומחיות, הקשיבו בהחלט לדיון המלא שלנו בפודקאסט בפרק Fix Microsoft Entra B2B Direct Connect Issues!