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

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)
  • لو هتستخدم KQL، محتاج Log Analytics Workspace متوصل بـ Entra Sign-in Logs

الفرق الأساسي: App Registration مش Enterprise Application

الفكرة الأساسية إن أي تطبيق ليه وشين في نفس الـ tenant (أو في tenants مختلفة لو multi-tenant):

  • App Registration: ده الـ "blueprint" أو التعريف الأساسي للتطبيق. هنا بتحدد الـ API Permissions المطلوبة، الـ redirect URIs، الـ certificates/secrets، وهل التطبيق single-tenant ولا multi-tenant. الـ object بتاعه اسمه Application object.
  • Enterprise Application: ده الـ instance الفعلي اللي بيتربط بالـ tenant بتاعك، واللي بيحصل عليه الـ Consent فعليًا، وبيتحكم فيه الـ Conditional Access و الـ user assignment. الـ object بتاعه اسمه Service Principal.

لما تعمل App Registration جديد، Entra بتنشئ تلقائيًا Service Principal مقابل ليه في نفس الـ tenant، وده اللي بتشوفه كـ Enterprise Application. لو التطبيق جاي من tenant تاني (multi-tenant app) أو من Azure Marketplace، هتلاقي Enterprise Application من غير App Registration ظاهر عندك أصلًا، لأن الـ registration نفسه موجود في tenant المطور.

المقارنة App Registration Enterprise Application
الـ Object Type Application object Service Principal object
فين بتتعرف الـ Permissions API permissions requested الـ permissions اللي فعلًا اتعمللها Grant
Conditional Access مش متاح هنا بيتحدد على مستوى الـ Service Principal
User assignment / SSO config لا نعم
موجود لكل tenant؟ مرة واحدة في tenant الـ home نسخة مختلفة في كل tenant بيتم فيه consent

إزاي الـ Permissions بتتحدد فعليًا

لما تروح على App Registration وتفتح "API Permissions"، إنت هنا بتطلب صلاحيات (Delegated أو Application). دول لسه requested مش فعالين. الجزء اللي بيخليهم فعالين هو الـ Consent، واللي بيحصل على مستوى الـ Service Principal (يعني الـ Enterprise Application).

1. Delegated Permissions

بتشتغل نيابة عن المستخدم اللي عمل login، وبتحمل نفس صلاحياته. مثال: User.Read.

2. Application Permissions

بتشتغل من غير ما يكون فيه مستخدم مسجل دخول (زي الـ daemon apps أو الـ background jobs)، ودايمًا محتاجة Admin Consent مهما كانت بسيطة.

# جيب كل الـ permissions اللي طالبها App Registration معين
Connect-MgGraph -Scopes "Application.Read.All"

$app = Get-MgApplication -Filter "displayName eq 'Contoso Reporting App'"
$app.RequiredResourceAccess | ConvertTo-Json -Depth 5

إزاي الـ Consent بيشتغل عمليًا (Admin vs User)

1. User Consent

لو الـ tenant مفعّل فيه "Users can consent to apps"، أي مستخدم عادي ممكن يوافق بنفسه على Delegated permissions اللي مش حساسة، وده بيولّد Service Principal (Enterprise Application) تلقائيًا لو مكانش موجود.

2. Admin Consent

لازم لأي Application permission، أو لو الـ tenant عامل تقييد على الـ user consent. بيتعمل من هنا:

# Grant admin consent لكل الـ permissions المطلوبة لـ Service Principal معين
Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All"

$sp = Get-MgServicePrincipal -Filter "displayName eq 'Contoso Reporting App'"

# لو Application permission (App Role)
New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $sp.Id `
  -PrincipalId $sp.Id `
  -ResourceId "00000003-0000-0000-c000-000000000000" `
  -AppRoleId "df021288-bdef-4463-88db-98f22de89214"

لو حابب تعمل الطريقة الأسرع من الـ Portal مباشرة عبر رابط، ده الـ endpoint الكلاسيكي:

https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={app-client-id}

⚠️ الرابط ده بيحتاج تكون Global Administrator أو Privileged Role Administrator، وبيعمل consent لكل الـ permissions المطلوبة في الـ manifest دفعة واحدة، فلازم تتأكد إنك مراجع الـ permissions قبل ما تفتحه، خصوصًا لو التطبيق multi-tenant من جهة خارجية.

تتبع الـ Consent Grants بالـ KQL

لو عندك Sign-in logs متوصلة بـ Log Analytics، ده استعلام بسيط يوريك أي consent events حصلت مؤخرًا من خلال الـ Audit Logs:

AuditLogs
| where OperationName in ("Consent to application", "Add app role assignment to service principal")
| extend AppName = tostring(TargetResources[0].displayName)
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, AppName, Initiator, Result
| order by TimeGenerated desc

✅ لو شفت "Consent to application" جاي من مستخدم عادي مش admin، وده لتطبيق طالب Application permissions، ده علامة إنه في حاجة غلط لازم تتراجع فيها، لأن ده لازم يكون Admin Consent بس.

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

المشكلة الحل
مش لاقي الـ Enterprise Application في الـ list رغم إنه App Registration موجود تأكد إن حد أصلًا عمل sign-in أو consent ولو مرة، لأن الـ Service Principal ممكن ميتنشئش تلقائيًا لحد ما يحصل أول استخدام فعلي
Conditional Access policy مش شغالة على تطبيق معين تأكد إنك اخترت الـ Enterprise Application الصح (الـ Service Principal) مش الـ App Registration، والـ CA بيتطبق على الأول بس
Admin Consent متعمل بس التطبيق لسه بياخد error 403 افحص إن الـ token اللي بيتعمله request فعلًا شامل الـ scope الصح، وإن الـ permission اتعمل لها consent على الـ Resource الصح (Graph مش حاجة تانية بالغلط)
تطبيق واحد ظاهر مرتين في Enterprise Applications عادي في حالة multi-tenant apps لو اتعمل consent من ناس مختلفة بـ tenants مختلفة، كل واحد بياخد Service Principal منفصل

نصائح الأمان 🔐

  • قفل خاصية "Users can consent to apps" واخليها بس على "Users can consent for permissions classified as low risk" على الأقل، وده بيقلل احتمال إن حد يوافق بالغلط على تطبيق phishing.
  • راجع الـ Enterprise Applications بشكل دوري (كل ربع سنة مثلًا) وشوف أي app عليه permissions أعلى من احتياجه الفعلي.
  • استخدم Admin Consent Workflow بدل ما تدي المستخدمين access مباشر لطلب consent، ده بيدي لك تتبع وموافقة مركزية.
  • خلي Application permissions دايمًا تتراجع مرتين، لأنها بتشتغل بدون سياق مستخدم وممكن تكون خطر أكبر من Delegated لو اتسرقت الـ credentials.
  • استخدم PIM لو ممكن على أدوار زي Cloud Application Administrator، عشان محدش يقدر يعمل Grant Consent بشكل دائم من غير Justification.

الخلاصة

لما تفهم إن App Registration هو التعريف والـ blueprint، والـ Enterprise Application هو الـ instance اللي بيحصل عليه الـ consent الفعلي والـ policies، هتوقف تتلخبط في كل مرة تحاول تتبع مين له access على إيه. الموضوع مش معقد لما تشوفه من الزاوية دي، بس التصميم نفسه بيحتاج انتباه خصوصًا وقت الـ Admin Consent.

  1. App Registration بيحدد الـ permissions المطلوبة (Application object)
  2. Enterprise Application (Service Principal) هو اللي بيتحكم في الـ consent الفعلي والـ Conditional Access
  3. Application permissions دايمًا محتاجة Admin Consent، والـ Delegated ممكن تتفعل بـ user consent لو مسموح
  4. راقب الـ Audit Logs بالـ KQL عشان تمسك أي consent مشبوه بدري

إنت جربت موقف مشابه فين الـ Consent كان مربك أو حصل فيه ثغرة أمنية؟ شاركنا تجربتك في الكومنتات.


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