Device Compliance and Conditional Access: Closing the Gap Between Intune and Entra | الفجوة بين Intune و Entra: ليه الجهاز Compliant وبرضو بيتمنع من الدخول؟

الفجوة بين Intune و Entra: ليه الجهاز Compliant وبرضو بيتمنع من الدخول؟

حكاية Ticket فضل قاعد يومين، وبعد التحقيق طلع السبب حاجة بسيطة كل واحد فينا ممكن يقع فيها.



المقدمة

لو شغال Identity أو Endpoint Engineer، أكيد قابلت الموقف ده: يوزر بيقولك "الجهاز بتاعي Compliant في Intune، طب ليه Conditional Access رافضه؟". الموضوع مش باج، الموضوع إن Intune و Entra ID عندهم مصدرين مختلفين للحقيقة (source of truth)، والـ sync بينهم مش instant، وفيه شروط تانية غير الـ Compliance نفسها بتتحكم في القرار. في البوست ده هنفكك المشكلة دي من جذورها: إزاي الـ Compliance State بيتحسب، إزاي الـ Conditional Access بيقرأه، وإزاي تقفل الفجوة دي عمليًا بدل ما تفضل بتعمل Troubleshoot كل مرة من الصفر.

💡 المتطلبات:
  • صلاحية Global Administrator أو Intune Administrator + Conditional Access Administrator
  • Microsoft Entra ID P1 على الأقل (للـ Conditional Access)
  • Microsoft Intune Plan 1 (Device Compliance Policies)
  • وصول لـ Microsoft Graph Explorer أو PowerShell مع Microsoft.Graph module
  • وصول لـ Advanced Hunting في Defender XDR (اختياري، للتحقيق في الـ Sign-in Logs المرتبطة بأجهزة)

إزاي Intune و Entra بيتكلموا مع بعض أصلًا

لازم نفهم الميكانيزم قبل ما ندخل في الحلول. الجهاز لما بيتسجل (Enrolled) في Intune، Intune بيعمل Evaluate للـ Compliance Policy بتاعته (Encryption, OS version, Jailbreak/Root detection... إلخ)، وبعدين Intune بيبعت الـ Compliance State ده لـ Entra ID عن طريق Device object في Microsoft Entra ID، مش عن طريق Conditional Access مباشرة.

يعني الـ flow بيبقى كده:

Device Enrollment → Intune Compliance Evaluation → Entra ID Device Object (isCompliant attribute) → Conditional Access Policy Evaluation

المشكلة إن الخطوة التالتة دي مش instant، فيه delay طبيعي بين ما الجهاز يبقى Compliant في Intune وبين ما الـ attribute يتحدث فعليًا في Entra. وده أول حاجة لازم تشرحها للـ end user قبل ما تدخل في تحقيق طويل.

1. تأكد الجهاز فعلًا مسجل كـ Registered/Joined مش بس Enrolled

فيه فرق كبير بين إن الجهاز يبقى Enrolled في Intune وإن يبقى Azure AD Joined أو Hybrid Azure AD Joined أو Registered في Entra. لو الجهاز Enrolled بس مش له Device Object سليم في Entra، الـ Conditional Access مش هيقدر يقرأ الـ Compliance State أصلًا.

# تحقق من حالة الجهاز في Entra ID عبر Microsoft Graph
GET https://graph.microsoft.com/v1.0/devices?$filter=displayName eq 'DEVICE-NAME'
&$select=id,displayName,isCompliant,isManaged,trustType,approximateLastSignInDateTime

لو isCompliant رجعت false أو null رغم إن Intune شكله سليم، يبقى فيه انفصال بين الاتنين، وهنا التحقيق يبدأ من هنا مش من الـ CA Policy.

2. اتأكد من الـ Sync Delay مش Sync Failure

عادة الـ Compliance State بياخد وقت قليل عشان يترحّل (بيعتمد على الـ check-in interval بتاع الجهاز). لو عدّى وقت طويل من غير تحديث، المشكلة مش delay، المشكلة sync عطلان.

# فرض Sync يدوي على الجهاز من PowerShell (لو عندك Intune module)
Sync-IntuneDevice -DeviceId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# أو من Microsoft Graph
POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/syncDevice

3. راجع الـ Conditional Access Policy نفسها، مش بس الـ Compliance

حاجة كتير بينسوها: لو الـ Policy فيها شرط "Require multiple controls" (زي Compliant Device AND MFA)، الجهاز ممكن يبقى Compliant فعلًا لكن الشرط التاني (MFA أو Approved App) هو اللي بيرجّع الـ Block. لازم تشوف الـ Sign-in log بالتفصيل مش تفترض إن السبب هو الـ Compliance بس.

// KQL في Defender XDR / Sentinel للتحقيق في Sign-ins اللي اتمنعت بسبب Device State
SigninLogs
| where ResultType != "0"
| where ConditionalAccessStatus == "failure"
| extend DeviceCompliance = tostring(DeviceDetail.isCompliant)
| project TimeGenerated, UserPrincipalName, AppDisplayName, DeviceDetail, DeviceCompliance, ConditionalAccessPolicies
| order by TimeGenerated desc

مقارنة سريعة: Compliance Policy مقابل Conditional Access Policy

العنصر Intune Compliance Policy Entra Conditional Access
بيحدد إيه؟ هل الجهاز مطابق للمعايير الأمنية (encryption, OS, password) هل مسموح بالوصول للـ resource ولا لأ
مكان التطبيق Intune (Endpoint Manager) Entra ID
النتيجة اللي بتترحّل isCompliant attribute Grant/Block Decision
التحديث دوري حسب check-in interval Real-time evaluation وقت الـ sign-in

⚠️ لاحظ إن Conditional Access بيعمل Evaluate وقت الـ Sign-in فعليًا، لكن هو بيقرأ آخر قيمة متسجلة لـ isCompliant، مش بيسأل Intune live. يعني لو القيمة القديمة متخزنة، الـ CA هيتصرف على أساسها لحد ما الـ sync يحصل.

قفل الفجوة عمليًا: Automation بدل الانتظار

بدل ما تسيب المستخدمين يفتحوا Ticket كل مرة، فيه خطوات وقائية بتقلل المشكلة دي بشكل كبير:

1. فعّل Automatic Enrollment صح من البداية

تأكد إن الـ MDM User Scope في Entra ID (Mobility (MDM and MAM) settings) متظبط على الـ Group الصح، عشان الجهاز يتسجل تلقائي في Intune ساعة الـ Azure AD Join، مش يستنى enrollment يدوي.

2. راقب الـ Compliance بشكل استباقي مش بعد الشكوى

# استعلام Graph لعرض كل الأجهزة غير المتوافقة
GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices
?$filter=complianceState eq 'noncompliant'
&$select=deviceName,userPrincipalName,complianceState,lastSyncDateTime

حط الاستعلام ده في Scheduled Script أو Logic App يبعتلك تنبيه لو عدد الأجهزة الـ noncompliant زاد فجأة، ده بيديك إشارة مبكرة قبل ما تتحول لموجة Tickets.

3. استخدم Report-only Mode قبل أي تعديل على Policy حساسة

قبل ما تشدد شرط "Require device to be marked as compliant" على تطبيق مهم، شغّل الـ Policy في Report-only mode كام يوم وشوف مين هيتأثر فعليًا. ده بيوفر عليك مفاجآت الصبح بدري.

✅ لو الأمور تمام، المفروض تلاقي إن نسبة الأجهزة الـ compliant ثابتة نسبيًا، وإن أي Block بيحصل بيكون له سبب واضح في الـ Sign-in log (Device state أو شرط تاني)، مش "غير معروف".

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

المشكلة الحل
الجهاز Compliant في Intune بس مرفوض في Conditional Access اعمل syncDevice يدوي، وراجع isCompliant attribute في Entra مباشرة عن طريق Graph
جهاز Hybrid Azure AD Joined مش بيظهر Device Object في Entra تأكد من الـ Azure AD Connect sync cycle والـ Device Registration health من Entra Connect Health
مستخدم على جهاز شخصي (BYOD) مش قادر يستوفي شرط Compliant استخدم App Protection Policies (MAM) بدل Device Compliance للسيناريوهات دي
الـ Compliance State بيرجع لـ noncompliant بعد فترة صغيرة من غير سبب واضح راجع الـ Compliance Policy grace period وشوف لو فيه setting اتغير (زي BitLocker أو Firewall) بيتراجع بعد إعادة تشغيل

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

  • متعملش استثناء عام (Exclude) على مستوى Group واسع بس عشان تحل مشكلة مؤقتة، ده بيفتح ثغرة تفضل موجودة
  • استخدم Named Locations مع شرط Compliance، مش بديل عنه، كطبقة إضافية للتحقق
  • راجع الـ Sign-in Logs بشكل دوري في Defender XDR للأنماط الغريبة زي أجهزة Compliant من موقع جغرافي مش متوقع
  • لو بتستخدم PIM مع Conditional Access، خلي شرط الـ Compliant Device شرط أساسي مش اختياري على الـ Privileged Roles
  • وثّق أي Exception بتعملها على Conditional Access Policy، مع تاريخ انتهاء واضح، مش استثناء دايم

الخلاصة

الفجوة بين Intune و Entra مش باج ولا خلل، هي نتيجة طبيعية لمعمارية فيها مصدرين للبيانات بيتزامنوا مع بعض. اللي بيفرق بين إنك تحل المشكلة في دقيقتين وإنك تفضل تايه ساعتين هو إنك تفهم الـ flow صح وتبني عليه مراقبة استباقية بدل ما تستنى الشكوى.

خلاصة الخطوات:

  1. افهم إن Compliance State بينتقل من Intune لـ Entra مش instant، وفيه delay طبيعي
  2. لما تحقق في مشكلة، اتأكد من الـ Device Object في Entra قبل ما تلوم الـ Conditional Access Policy
  3. راقب الأجهزة الـ noncompliant بشكل استباقي عن طريق Graph queries دورية
  4. استخدم Report-only mode قبل أي تعديل حساس على Policies بتخص Compliance

إنت قابلت الموقف ده قبل كده؟ شاركنا في الكومنتات إيه السبب اللي طلع عندك في النهاية.

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

Entra ID Built-in Roles vs Custom Roles for Least Privilege | أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID

Image
أدوار مدمجة ولا Custom Roles؟ إزاي تطبق مبدأ الصلاحية الأقل في Entra ID حكاية عملية عن الفرق بين إنك تدي حد صلاحية "تقريبًا كفاية" وإنك تدي حد الصلاحية "بالظبط اللي محتاجها"، ومتى تستخدم إيه من الاتنين. المقدمة حصلت معايا قبل كده موقف كلاسيكي: عضو في فريق الـ Helpdesk طلب صلاحية يعمل reset password لمستخدمين قسم معين بس. أقرب Built-in Role ليها هو Password Administrator أو Helpdesk Administrator، بس المشكلة إن الدور ده بيدي صلاحية على كل المستخدمين في الـ tenant تقريبًا، مش بس القسم المطلوب. يعني عشان أحل مشكلة صغيرة، أنا فتحت باب كبير قوي. المشكلة دي بتتكرر كتير في الشركات اللي بتكبر وتحتاج تفصيل الصلاحيات على مستوى أدق من اللي الأدوار المدمجة بتقدمه، وهنا بالظبط بييجي دور الـ Custom Roles. 💡 المتطلبات: Microsoft Entra ID P1 على الأقل عشان تقدر تعمل Custom Roles (P2 لو هتستخدم PIM مع الأدوار دي). صلاحية Privileged Role Administrator أو Global Administrator عشان تنشئ وتخصص الأدوار. Microsoft Graph PowerShell SDK مثبت (Install-Module Microsoft.Graph...
Read more