Cross-Tenant Access Settings and B2B Collaboration for Consultants Managing Multiple Clients | بتدير أكتر من Tenant لعملاءك؟ لازم تتقن Cross-tenant Access Settings في Entra ID

بتدير أكتر من Tenant لعملاءك؟ لازم تتقن Cross-tenant Access Settings في Entra ID

دليل عملي لأي Consultant أو MSP شغال على كذا Entra ID Tenant في نفس الوقت، من الدعوة كـ Guest لحد التحكم في الـ Trust بين التينانتات.

---

المقدمة

لو إنت Consultant أو شغال في MSP، غالبا إنت مش عندك تينانت واحد بتتعامل معاه، إنت عندك 5 أو 10 أو حتى 20 عميل، كل واحد فيهم Entra ID Tenant منفصل تماما، وإنت بتدخل كـ Guest في كل واحد منهم. المشكلة إن الإعدادات الافتراضية لـ Cross-tenant Access في Entra ID مبنية على فرضية إن كل تينانت مستقل وحذر من التينانتات التانية، فلو مسكتهاش بإيدك هتلاقي نفسك بتعمل MFA كل شوية، أو هتلاقي حسابك كـ Guest معلق ومش قادر يوصل لحاجة، أو الأسوأ، تينانت عميل مسيب Default settings مفتوحة لأي تينانت في العالم من غير ما يحس. المقال ده هيشرح إزاي تتحكم في الموضوع ده صحيح، من ناحيتك كـ Consultant ومن ناحية العميل كـ Tenant Admin.

💡 المتطلبات:

• صلاحيات Global Administrator أو Security Administrator على التينانت اللي هتظبط فيه الإعدادات (بتاعك أو بتاع العميل)
• Microsoft Graph PowerShell SDK متركب (Install-Module Microsoft.Graph)
• معرفة Tenant ID بتاع كل عميل هتتعامل معاه
• لو هتستخدم Cross-tenant synchronization: لازم Entra ID P1 على الأقل في التينانت المصدر

إزاي الـ Default Settings شغالة أصلا

أول حاجة لازم تفهمها إن Entra ID فيها مستويين من Cross-tenant Access Settings: Default Settings اللي تنطبق على أي تينانت خارجي مش متعامل معاه بشكل خاص، وOrganizational Settings اللي تسمحلك تخصص إعدادات مختلفة لتينانت معين (زي تينانت عميل بعينه).

الافتراضي في Entra ID إن:

• Outbound B2B Collaboration: مسموح لكل التينانتات الخارجية
• Inbound B2B Collaboration: مسموح من كل التينانتات الخارجية
• Inbound/Outbound Trust settings (MFA, Compliant Device, Hybrid Join): كلها Not Trusted بشكل افتراضي

يعني عمليا، إنت كـ Guest في تينانت عميل، حتى لو عملت MFA في تينانتك الأساسي، تينانت العميل مش هيصدق الـ Claim ده، وهيطلب منك MFA تاني عنده. ده اللي بيخلق "MFA Fatigue" عند الاستشاريين اللي بيتنقلوا بين تينانتات كتير في اليوم.

تظبيط Cross-tenant Access Settings بـ PowerShell وGraph

1. شوف الـ Default Policy الحالية

Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.CrossTenantAccessPolicy"

Get-MgPolicyCrossTenantAccessPolicyDefault | ConvertTo-Json -Depth 5

2. أضف Organizational Setting لتينانت عميل معين

ده بيسمحلك إنك تخصص إعدادات Trust مختلفة تماما عن الـ Default، بس للتينانت ده بالذات.

$clientTenantId = "11111111-2222-3333-4444-555555555555"

New-MgPolicyCrossTenantAccessPolicyPartner -TenantId $clientTenantId `
  -B2bCollaborationInbound @{
    UsersAndGroups = @{ AccessType = "allowed"; Targets = @(@{ Target = "AllUsers"; TargetType = "user" }) }
  } `
  -InboundTrust @{
    IsMfaAccepted = $true
    IsCompliantDeviceAccepted = $true
    IsHybridAzureADJoinedDeviceAccepted = $false
  }

⚠️ لاحظ إن InboundTrust هنا معناها "التينانت اللي إنت شغال عليه دلوقتي هيصدق MFA/Device claims الجاية من التينانت التاني (تينانتك الأساسي)". يعني ده بيتظبط من جوه تينانت العميل، مش من تينانتك، لأن العميل هو اللي بيقرر يوثق فيك أو لأ.

3. عبر Graph API مباشرة (لو مش عايز PowerShell)

PATCH https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/{clientTenantId}
Content-Type: application/json

{
  "inboundTrust": {
    "isMfaAccepted": true,
    "isCompliantDeviceAccepted": true,
    "isHybridAzureADJoinedDeviceAccepted": false
  }
}

✅ لو الإعدادات صحيحة، هتلاحظ إن الـ Guest بتاعك (يعني إنت كـ Consultant) بقى يدخل التطبيقات في تينانت العميل من غير ما يطلب MFA تاني، طول ما عملها في تينانتك الأساسي.

B2B Collaboration ولا B2B Direct Connect؟

كتير بيلخبطوا بين الاتنين، والفرق مهم لأي Consultant بيقرر إزاي يتعامل مع كل عميل.

الخاصية	B2B Collaboration	B2B Direct Connect
نوع الحساب	Guest User Object بيتنشئ في تينانت العميل	مفيش حساب Guest أصلا, هوية فيدرالية بس
نطاق الاستخدام	أي Resource: Apps, SharePoint, Teams, إلخ	Teams Shared Channels بس حاليا
تجربة الدخول	دعوة، قبول، Redemption	مباشر من غير Invitation Flow
إدارة الوصول	Access Reviews, Groups, Conditional Access	Cross-tenant Access Settings مباشرة

عمليا، أغلب سيناريوهات الاستشاريين بتستخدم B2B Collaboration لأنك محتاج توصل لـ Resources متنوعة زي Portal العميل أو Azure Resources، وB2B Direct Connect بيفضل أكتر للتعاون على Teams بس بين شركتين.

مراقبة الوصول بـ KQL

لو عندك Log Analytics أو Sentinel متوصل بـ Sign-in Logs، ممكن تتابع فعليا مين بيدخل من تينانتات خارجية على تينانتك، وده مفيد جدا لو إنت التينانت المضيف وعندك استشاريين خارجيين بيدخلوا عليك.

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(CrossTenantAccessType) and CrossTenantAccessType != "none"
| summarize SignInCount = count() by UserPrincipalName, CrossTenantAccessType, ResourceTenantId
| order by SignInCount desc

لو لاحظت CrossTenantAccessType بقيمة غير متوقعة أو تينانتات مش عارف مين هي، ده إشارة إن الـ Default settings عندك لسه مفتوحة أكتر من اللزوم.

مشاكل شائعة وحلولها

المشكلة	الحل
الـ Guest بيتطلب منه MFA كل مرة يدخل تينانت العميل، حتى إنه عمل MFA في تينانته الأساسي	فعّل isMfaAccepted في Inbound Trust Settings في Organizational Settings بتاعة تينانت العميل لصالح تينانتك
حساب Guest تم إنشاؤه بس المستخدم مش شايف أي Resource	راجع External Collaboration Settings وتأكد إن B2B Collaboration Inbound مش على Block، وكذلك صلاحيات المستخدم على التطبيقات نفسها
الاستشاري عنده حسابات Guest متكررة في تينانتات كتير وب