Restricting Multi-Tenant App Registrations to Specific Tenants in Entra ID | مش كل Tenant يعدي: إزاي تقيّد تطبيقك الـ Multi-Tenant في Entra ID

مش كل Tenant يعدي: إزاي تقيّد تطبيقك الـ Multi-Tenant في Entra ID

إزاي تتحكم في مين يستخدم App Registration بتاعك من بره تنانتك، من غير ما تكسر الفكرة الأساسية اللي هي إنه Multi-Tenant.

المقدمة



حصل معايا الموضوع ده وأنا بشتغل على App Registration داخلي، اتعمل Multi-Tenant من الأول عشان استخدام مؤقت مع شركة تانية بعد Merger، وبعد ما خلصنا الغرض، لقيت إن Service Principal بتاع التطبيق ده لسه موجود في تنانتات تانية معملهاش أي Review. المشكلة إن Entra ID مش بيعطيك زرار جاهز اسمه "اسمح للـ Tenants دول بس"، وده بيخلي كتير من المهندسين يفترضوا إن الموضوع مقفول تلقائي بمجرد ما الاستخدام يخلص. الموضوع ده مهم جداً لو عندك SaaS App أو حتى Internal Tool بيتشارك بين شركات فرعية، لأن أي Tenant تاني ممكن يعمل Consent عليه لو الـ Publisher settings مش مضبوطة صح.

💡 المتطلبات:
  • صلاحية Application Administrator أو Cloud Application Administrator على الـ App Registration
  • Permission اسمه Application.ReadWrite.All على Microsoft Graph
  • Microsoft Graph PowerShell SDK أو الوصول لـ Graph Explorer
  • لو عايز Logging على مستوى الكود، محتاج Access Level على الـ Application Insights أو أي Logging Sink بتاع التطبيق نفسه

الفكرة الأساسية: signInAudience مش أداة تقييد حقيقية

أول حاجة لازم تفهمها إن property اسمها signInAudience في الـ App Registration بتحدد نوع الـ Tenants اللي أصلاً مسموح لهم يعملوا Consent، لكنها مش أداة تقييد على مستوى Tenant بعينه، هي بس تحدد الفئة العامة.

القيمة المعنى الاستخدام المناسب
AzureADMyOrg Single Tenant بس، حسابات تنانتك أنت تطبيقات داخلية خالص
AzureADMultipleOrgs أي Entra Tenant يقدر يعمل Consent SaaS تجاري أو استخدام بين شركات فرعية
AzureADandPersonalMicrosoftAccount Multi-Tenant + حسابات Microsoft الشخصية تطبيقات Consumer

⚠️ لو حاولت ترجع من AzureADMultipleOrgs لـ AzureADMyOrg وفيه Service Principals متعملة أصلاً في Tenants تانية، Graph هيرفض العملية. لازم تشيل الـ Service Principals من الـ Tenants دي الأول، ولو مش قادر توصلهم، الحل الوحيد هو التواصل مع Microsoft Support.

التقييد الحقيقي بيحصل في الكود، مش في الـ Portal

الحقيقة اللي محدش بيقولها بصوت عالي: Entra ID مفيهاش Setting اسمه "Restrict this app to these Tenant IDs" جوه الـ App Registration بتاعك. التقييد الفعلي بيتم عن طريق فحص Claim اسمه tid جوه الـ Token نفسه وقت ما التطبيق يستقبله.

1. تحقق من الـ tid Claim قبل ما تكمل أي Logic

أول حاجة لو حابب تتأكد من شكل الـ Claim ده وقت الـ Testing، تقدر تعمل Decode سريع لـ Token عن طريق PowerShell:

$token = "<paste access token here>"
$payload = $token.Split('.')[1].Replace('-','+

Comments

Post a Comment

Popular posts from this blog

Entra ID Free vs P1 vs P2: What You Actually Get at Each License Tier | Entra ID Free ولا P1 ولا P2: الفرق الحقيقي بين الباقات

Image
Entra ID Free ولا P1 ولا P2: الفرق الحقيقي بين الباقات دليل عملي لأي حد بيحاول يقنع الإدارة يدفع فلوس زيادة، أو بيحاول يفهم ليه الميزة اللي شافها في الدوكيومنتيشن مش شغالة عنده. المقدمة كل شوية بيجيلي سؤال من حد بيقولي "عملت Conditional Access policy بالظبط زي اللي في الفيديو بس مش لاقيها في التينانت بتاعي"، وبعد شوية بحث بيطلع إن التينانت شغال على Entra ID Free أو إن المستخدم نفسه مش معاه P1 أصلا. الموضوع ده بيسبب لخبطة كبيرة لأن Microsoft بتدي نفس الـ Portal تقريبا لكل الباقات، بس الميزات اللي بتظهر جوه بتختلف بشكل جوهري حسب الـ license اللي أنت أو المستخدم معاك. في البوست ده هوضحلك بالظبط إيه اللي بتاخده في كل tier، وإزاي تتأكد من الـ licensing الفعلي عندك بدل ما تعتمد على الحظ. 💡 المتطلبات: صلاحية Global Reader أو Global Administrator عشان تشوف الـ licenses المفعلة في التينانت وصول لـ Microsoft Entra admin center أو Microsoft Graph PowerShell SDK فكرة مبدئية عن الفرق بين Assigned license للمستخدم والـ features المتاحة في التينانت الفرق الأساسي بين الب...
Read more

Conditional Access Design Mistakes That Lock Admins Out of Microsoft Entra ID | لما الـ Conditional Access يقفل عليك الباب وأنت جوه Tenant

Image
لما الـ Conditional Access يقفل عليك الباب وأنت جوه Tenant قصة واقعية عن Policy واحدة تعبانة قدرت تقفل كل الأدمنز بره التينانت في نص ساعة المقدمة  لو شغال Identity Engineer من فترة، أكيد سمعت أو عملت بنفسك موقف إن حد عمل Conditional Access Policy جديدة الصبح، ضغط Enable على طول من غير Report-only، وبعد شوية بدأ يوصله شكاوى إن الأدمنز مش عارفين يدخلوا الـ Portal. المشكلة إن ده مش سيناريو نظري، ده حاصل فعلاً في شركات كبيرة لدرجة إن Microsoft نفسها عاملة Policy جاهزة اسمها "Emergency access" recommendation بس لسه كتير مش مطبقينها. النهاردة هنتكلم عن أكتر الأغلاط اللي بتحصل في تصميم CA وبتخلي الأدمن نفسه Locked out من غير قصد، وإزاي تتجنبها من الأول. 💡 المتطلبات: صلاحية Conditional Access Administrator أو Security Administrator في Entra ID، Entra ID P1 على الأقل (P2 لو هتستخدم PIM وRisk-based policies)، Access إلى Microsoft Graph PowerShell SDK، وحساب Break-glass جاهز ومُستبعد من كل الـ Policies. 1. الغلطة الأشهر: مفيش Break-Glass Account من الأساس لو مفيش عندك E...
Read more

App Registrations vs Enterprise Applications in Entra ID: Permissions and Consent Explained | App Registration و Enterprise Application: مين بيعمل إيه في الـ Permissions والـ Consent؟

Image
App Registration و Enterprise Application: مين بيعمل إيه في الـ Permissions والـ Consent؟ دليل عملي يفكك اللخبطة اللي بتحصل لكل مهندس Identity أول ما يفتح Entra Portal ويلاقي التطبيق الواحد ظاهر في مكانين مختلفين. المقدمة لو اشتغلت على Entra ID شهر واحد، أكيد قابلت الموقف ده: بتدور على تطبيق معين عشان تدي له permission جديد، تلاقيه موجود في App Registrations، تفتحه، تضيف الـ permission، تحس إنك خلصت... وبعدين تكتشف إن الـ Consent لسه محتاج approval من مكان تاني خالص اسمه Enterprise Applications. الحيرة دي مش غلطة منك، ده أساسًا التصميم اللي بنى عليه Microsoft الموضوع كله، وفهمه صح بيفرق كتير في تصميم الـ Conditional Access policies، وفي تتبع أي تطبيق شرير أو مشبوه عمل Consent من غير ما حد يعرف. 💡 المتطلبات: صلاحية Application Administrator أو Cloud Application Administrator على الأقل (أو Global Administrator للتجربة الكاملة) Microsoft Graph PowerShell SDK متثبت ( Install-Module Microsoft.Graph ) وصول لـ Entra Portal (portal.azure.com > Microsoft Entra ID) لو هتستخ...
Read more