اختبار Intune عبر Microsoft Graph: حسابك محدود، لكن هل تطبيق التكامل محدود بعد؟

طلب قراءة الأجهزة ينجح من خدمة الجرد، ويرفض من حساب الدعم. نفس المستأجر ونفس المسار، لكن النتيجة مختلفة. قبل ما تبحث عن حيلة تغيّر بها الطلب، اسأل السؤال الأهم: هل الخدمة تستخدم هوية تطبيق مستقلة، بينما حساب الدعم يعمل بصلاحيات مستخدم؟

في اختبار إنتيون، هذا الفرق قد يفسر وصولًا واسعًا ما يظهر في أدوار حسابات الموظفين. بنراجع طريقة فهم الصلاحيات والمنح ونتائج القراءة داخل بيئة تدريبية، ونستخدم طلبًا موثقًا لا يغيّر الأجهزة. هدف المقال أن تميز الهوية التي اتخذت بها الخدمة قرارها، وتعرف متى يكون الوصول مشروعًا ومتى يمثل منحًا زائدًا يحتاج نتيجة في التقرير.

نفس اسم الإذن لا يجعل السياق واحدًا

هناك وصول ينفذه التطبيق نيابة عن مستخدم مسجل الدخول، ووصول ينفذه التطبيق بهويته بدون مستخدم حاضر. في الحالة الأولى، تقرأ صلاحية التطبيق مع صلاحية المستخدم على المورد. وفي الثانية، تراجع منح التطبيق نفسه والطريقة التي يثبت بها هويته.

اكتب الاسمين الأصليين في ملاحظاتك حتى ما تختلط الأنواع:
Delegated permissions
Application permissions

لو رأيت إذن قراءة الجرد بالاسم نفسه في النوعين، لا تعتبرهما متطابقين في حدود الأثر. المستخدم المحدود قد يرى جزءًا من البيئة، بينما تطبيق خلفي يحتاج قراءة أوسع حسب منح الخدمة. القياس الصحيح يذكر النوع، وليس الاسم فقط.

خلنا نفترض أن خدمة تقارير تقرأ أجهزة قسم صغير. وجود وصول واسع على التطبيق قد يكون قرارًا إداريًا موثقًا، أو توسعًا ما عاد له حاجة بعد تغير المشروع. ما نثبت سوء الإعداد من وجود الخدمة؛ نقارن حاجتها الحالية بالمنح الفعلية ثم نجري قراءة محدودة على عينة يعرفها الفريق.

راجع المنح الفعلية قبل شاشة الطلبات

صفحة الصلاحيات المطلوبة تصف ما يطلبه تسجيل التطبيق، لكنها لا تكفي وحدها لمعرفة كل ما أصبح نافذًا على مثيله المحلي في المستأجر. افحص الموافقات والمنح المرتبطة بالهوية التي يستخدمها التكامل، وسجل المورد المستفيد من كل منح.

السؤال العملي هو: هذه الخدمة تحتاج قراءة أجهزة، فلماذا تملك تعديل سياسات أو سكربتات؟ لا تفترض أن الصلاحية الزائدة استُخدمت فعلًا. اثبت وجودها أولًا، وراجع مع مالك الخدمة الوظيفة التي تعتمد عليها. بعض التكاملات القديمة تحمل أذونات بقيت من اختبار سابق أو مثال إعداد واسع.

يفيدك سجل بسيط لكل منح: الاسم، والنوع، والمورد، ومبرر الحاجة، ومالك التكامل، وتاريخ آخر مراجعة إن توفر. الحقول الأخيرة ليست خصائص مضمونة في كل واجهة؛ قد تجمعها من سجل الفريق. هذا السجل يربط التفاصيل التقنية بوظيفة العمل، فلا تنتهي المراجعة بقائمة أسماء لا يعرف أحد لماذا بقيت.

عينة قراءة أفضل من جرد المستأجر كاملًا

قبل الطلب الأول، يحدد المسؤول أجهزة تدريبية ومعرفاتها، ويجهز هوية قراءة مناسبة للنطاق. اختر أقل حقول تكفي لمقارنة الهوية والملكية وآخر تزامن. لا تجمع تفاصيل تطبيقات كل موظف أو معلومات شخصية لأن واجهة القراءة تتيحها.

واجهة تعداد الأجهزة المُدارة لها طلب موثق، ويظهر إذن القراءة في جدولها:
GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices
DeviceManagementManagedDevices.Read.All

هذا مثال لفهم المورد وليس تصريحًا لقراءة مستأجر لا تملكه. في لابك، ينفذ الفريق الطلب بأداة المصادقة المعتمدة وبالهوية المخصصة، ثم يحفظ جزءًا من الرد على الأجهزة التجريبية. إذا كنت تحتاج طلبًا على مورد محدد، راجع وثيقة ذلك الطلب بدل تركيب مسار من تخمين.

المهم أن تقيس القدرة بدون تغيير الحالة. ظهور جهاز خارج النطاق المقصود قد يثبت وصولًا إلى الجرد، لكنه لا يثبت صلاحية التحكم أو النشر. حافظ على هذا الحد في الملاحظات من أول محاولة، حتى ما يتوسع الاستنتاج بسبب كثرة الحقول في الرد.

كيف تثبت أي هوية نفذت الطلب؟

احتفظ بمعرف المستأجر ومعرف التطبيق ونوع الاتصال ومصدر تسجيل الدخول، بدون حفظ السر المستخدم للمصادقة في التقرير. اسم المستخدم الظاهر في نافذة المتصفح لا يثبت هوية خدمة خلفية؛ الأداة قد تستخدم اتصالًا مختلفًا عن اتصالك التفاعلي.

عند فحص رمز تدريبي محليًا، قد تساعدك مطالبة النطاقات ومطالبة الأدوار في فهم النوع. وجود أدوار داخل رمز مفوض لا يعني وحده أنه رمز تطبيق؛ المصدر الرسمي يوضح أن الأدوار قد تظهر للمستخدم أيضًا. لذلك اربط المطالبات بطريقة إصدار الرمز والسياق، ولا تبن حكمك على كلمة واحدة.

scp
roles

لا ترفع رمز وصول حيًا إلى موقع عام لفك محتواه لمجرد أن الشرح يقترح محللًا. احتفظ بالفحص داخل بيئة الفريق أو استخدم عينة منزوعة القيم. كذلك فك الترميز ليس تحققًا من التوقيع ولا دليلًا أن الخدمة ستقبل الرمز. قرار التفويض الفعلي يظهر في الطلب الذي نفذته والسجل المرتبط به.

قارن ثلاث حالات بدل تبديل الحساب عشوائيًا

جهز مستخدم دعم مفوضًا، وتطبيق تقارير للقراءة، وهوية مرجعية يديرها المسؤول. على المورد التدريبي نفسه، قارن القراءة وما تعرضه كل حالة. لا تضف أذونات واسعة إلى المستخدم حتى تجعل النتائج متشابهة؛ الاختلاف قد يكون هو الملاحظة التي تبحث عنها.

في الحالة الأولى، سجل أدوار المستخدم والنطاقات التي مُنحت للتطبيق الذي يعمل نيابة عنه. في الثانية، سجل منح هوية التطبيق. في المرجع، تأكد أن المورد موجود وأن الطلب صحيح. بهذا تمنع تفسير المورد المفقود على أنه عزل، أو تفسير نجاح الحساب الواسع على أنه خلل.

لو فشلت القراءة المفوضة ونجحت قراءة التطبيق، اسأل هل وظيفة التقارير تحتاج ذلك النطاق أصلًا. ولو نجحتا، قارن البيانات التي ظهرت لا رمز النجاح فقط. رد ناجح يحوي عنصرين يختلف عن رد ناجح يكشف أجهزة جميع الأقسام، وكل نتيجة تحتاج وصفًا يناسب ما قسته.

لا تتعامل مع كل رفض باعتباره حماية ناجحة

رد المصادقة والرفض بسبب الأذونات والمورد غير الموجود ليست النتيجة نفسها. احفظ رمز الحالة ورسالة الخطأ ومعرف الطلب والوقت، ثم راجع وثيقة العملية. لا تمسح التفاصيل وتكتفي بعبارة «ما اشتغل».

لو الرمز صادر لمورد آخر، أو البيئة غير صحيحة، أو الترخيص غير متوفر، قد تفشل المحاولة قبل أن تصل إلى الحد الذي تريد اختباره. لهذا نحتاج قراءة مرجعية صحيحة على مورد معروف. الرفض المرجعي بعد طلب صالح يفيدك أكثر من عشر محاولات غير صالحة.

وفي المقابل، لا توسع المنح فور ظهور رفض. اطلب من مالك اللاب تأكيد نوع الاتصال والإذن الضروري، ثم أعد الطلب نفسه. إضافة إذن تعديل شامل لحل مشكلة قراءة تخرب تصميم التجربة، وتخليك تقيس هوية جديدة غير الهوية التي كان السؤال عنها.

الصفحة الأولى ليست قائمة كاملة

قد يرجع تعداد الموارد على صفحات، وتظهر إشارة لصفحة لاحقة. إذا توقفت عند الرد الأول، لا تكتب أن بقية الأجهزة غير مرئية. سجل هل الرد كامل أم جزئي، وما الحدود التي وضعتها على الجمع.

@odata.nextLink

في لاب صغير، الأفضل اختيار موارد معروفة تستطيع مطابقتها. وإذا كان النطاق يسمح باستكمال الصفحات، استخدم الرابط الذي ترده الخدمة حسب وثيقتها، ولا تعيد بناء رموز التصفح يدويًا. اذكر عدد الصفحات التي قرأتها وعدد العناصر التي طابقتها.

كذلك الحقول المختارة ومرشحات الطلب تؤثر على النتيجة. خاصية غير موجودة في الرد قد تكون مستبعدة من الاستعلام، لا محجوبة أمنيًا. احتفظ بنسخة من طريقة الطلب بعد إزالة المصادقة، حتى يستطيع الفريق معرفة إن كان الفرق من التفويض أم من الاستعلام الذي كتبته.

القراءة قد تكون حساسة حتى بدون تعديل

قائمة الأجهزة قد تكشف أسماء أصول أو أنواع أنظمة أو معلومات عن تبعية المستخدمين. هذه البيانات لا تساوي اختراق الأجهزة، لكنها قد تساعد في فهم بيئة الشركة أكثر مما يحتاجه تكامل صغير. لذلك قيّم حاجة الخدمة إلى النطاق ونوع البيانات معًا.

خلنا نفترض أن تقريرًا أسبوعيًا يحتاج عدد الأجهزة المطابقة فقط. ربما يستطيع تصميمه تقليل الحقول المخزنة والاحتفاظ بالتجميع بدل كل تفاصيل الجرد. هذا قرار معماري يراجعه مالك الخدمة، وليس وعدًا أن كل واجهة تدعم عزلًا على قسم واحد بالطريقة نفسها.

في التقرير، وضح البيانات التي ظهرت فعليًا لعينة الاختبار، والبيانات التي لم تفحصها. لا تقول إن أسرار الأجهزة مكشوفة لأن الرد يحوي اسم الجهاز. وفي الوقت نفسه، لا تقلل الملاحظة لمجرد أنها قراءة؛ قيمة الجرد تعتمد على حساسية البيئة والمستفيد من المنح ونقطة دخوله.

حدود الأدوار البشرية لا تغلق هوية التطبيق

إخراج موظف من مجموعة إدارة قد يغلق طريقه التفاعلي، لكنه لا يعني أن كل تطبيق كان يديره فقد صلاحياته. هوية الخدمة لها دورة حياة تحتاج مراجعة مستقلة: من يملكها؟ من يغير إعداداتها؟ من يدير اعتمادها؟ وما المنح التي بقيت لها؟

راجع كذلك المهمة المجدولة أو الخدمة التي تستعمل التطبيق. لا تحتاج استخراج سرها حتى تحدد المسؤولية؛ يستطيع مالك النظام تقديم وصف لطريقة حفظ الاعتماد ومن يملك الوصول إليه. الاختبار يربط قدرة إدارة الهوية بأثر المنح، ويحدد أين ينبغي أن يكون الفصل بين الفرق.

مثال نتيجة واضحة: «تكامل قديم ما زال يملك قراءة جرد المستأجر بعد توقف المشروع، ولا يوجد مالك حالي للمراجعة». هذه تختلف عن «تطبيق نشط يحتاج جردًا واسعًا لكنه يخزن أكثر من الحاجة». الأولى تعالج البقاء والملكية، والثانية تعالج تصميم الوظيفة وحفظ البيانات.

متى تنتقل من القراءة إلى إثبات أثر أكبر؟

إذا ظهرت صلاحية كتابة غير مبررة، لا يعني ذلك أنك تحتاج استخدامها على مورد إنتاج. ناقش مع الفريق موردًا تدريبيًا وإجراءً محدودًا، مثل تعديل وصف عنصر غير معين. اختر تجربة تختبر الإذن الذي وثقته دون تنفيذ مسح أو نشر واسع.

اكتب شرط الانتقال قبل التنفيذ: المصدر أكد المنح، والهوية معروفة، والمورد تجريبي، والأثر قابل للاستعادة. إن لم تتوفر الشروط، تبقى النتيجة مراجعة منح مع أثر محتمل موضح. هذا يكفي لكثير من المشاريع ولا يجعل التقرير ناقصًا إذا كان نطاق العمل لا يسمح بتغييرات.

بعد التجربة، طابق نتيجة الخدمة مع سجل العنصر. طلب نجح لكنه ما غير الخاصية المتوقعة يحتاج مراجعة، وطلب تأخر لا يبرر إعادة الإرسال المتكررة. تعامل مع الكتابة بحذر تشغيلي عادي، لأن بعض الأوامر الإدارية تصل آثارها إلى أجهزة ليست أمامك على الشاشة.

تمرين الأرقام يكشف الفرق بين النطاق والفلاتر

جهز مسؤول اللاب ستة أجهزة تدريبية: ثلاثة للقسم أ وثلاثة للقسم ب. هذه أرقام للمثال فقط، وليست حدودًا للمنصة. المستخدم المحدود يتوقع قراءة أجهزة القسم أ، وخدمة التقارير يتوقع أن تجمع عدد الأجهزة في القسمين. احتفظ بمعرفات الستة في ورقة مرجعية قبل الطلب.

إذا رجع للمستخدم ثلاثة عناصر، لا تعتبر العزل ثابتًا حتى تفحص الطلب: ربما كتب مرشحًا على القسم أ، وربما أخذ صفحة صغيرة، وربما حسابه بالفعل محدود. أعد المقارنة بطلب موثق مطابق للتوقع، بدون تغيير الهوية. عدد النتائج لا يشرح سبب العدد وحده.

إذا رجعت للتطبيق الستة، اسأل هل التقرير يحتاج بياناتها التفصيلية أم أعدادًا مجمعة. ثم قارن ما يحفظه التطبيق بعد القراءة بما يحتاجه المنتج. القدرة على القراءة موضوع، والاحتفاظ بالمخرجات موضوع آخر. قد تكون المنح مناسبة بينما التخزين أوسع من الحاجة.

وفي تقرير التجربة، اكتب معرفات العينة التي ظهرت وما تمثله من أقسام تدريبية. لا تحول المثال إلى تقدير بعدد الأجهزة المتأثرة في الإنتاج دون جرد موثق داخل النطاق. هذه المقارنة الصغيرة تعطيك طريقة تفسير يمكن توسيعها لاحقًا بدون تضخيم الاستنتاج.

رد التقييد ليس نتيجة عن صلاحية الحساب

إذا أعادت الخدمة ردًا يفيد بأن معدل الطلبات تجاوز الحد، فهذا لا يخبرك أن الحساب ممنوع من المورد. أوقف التوازي غير الضروري، والتزم بزمن الانتظار الذي تطلبه الخدمة عند توفره، ثم واصل وفق خطة الجمع المحدودة. لا تغير الحساب أو المسار لمحاولة تجاوز التقييد.

في سجل الاختبار، ضع علامة أن الحالة لم تُقَس بسبب حد الطلبات، بدل تسجيلها كرفض تفويض. هذا مهم لأن مقارنة هوية مرجعية هادئة بهوية أرسلت عشرات الطلبات قد تعطي نتيجة تبدو أمنية وهي اختلاف في طريقة التشغيل.

خلي حجم العينة مناسبًا للسؤال. إذا تريد إثبات ظهور جهاز تدريبي خارج النطاق، ما تحتاج تعداد كل المستأجر كل دقيقة. الطلب الأقل يجمع دليلًا أوضح ويقلل الضوضاء، ويسهل على الفريق مطابقة سجل المحاولة بنتيجتها.

اختبار الإغلاق يحتاج المهمة المشروعة أيضًا

بعد تقليل المنح، أعد القراءة المسموحة للتقرير وتأكد أن الخدمة تؤدي مهمتها. ثم أعد الحالة التي كشفت الوصول الزائد وفق تصميم الفريق. لو توقفت خدمة التقارير كلها، فهذا لا يثبت أن العزل صار مناسبًا؛ قد يعني أن التصحيح منع الوظيفة المطلوبة.

سجل السياق الجديد والتوقيت، ولا تفترض أن رمزًا سبق إصداره يعكس كل تغيير فورًا. يراجع مالك الهوية دورة الرمز وآلية الاتصال، وتستخدم أنت سياق اختبار واضحًا تقارنه بالحالة السابقة. القياس يحتاج فصلًا بين تغير المنح وتأخر أثرها على اتصال قائم.

الخلاصة العملية: عند اختلاف نتائج القراءة، لا تبدأ بتغيير الأداة. ابدأ بالهوية ونوع الوصول والمنح الفعلية والمورد المقصود. هذه الأربع تفسر أغلب الالتباس، وتكشف مسارات إدارة قد لا تظهر في مراجعة حسابات الموظفين وحدها.

المراجع وقراءة مرتبطة

راجع جدول الأذونات الخاص بكل عملية؛ أذونات السكربتات وبعض الواجهات تطورت مع الوقت، وما ينفع تعميم أمثلة قديمة على كل مورد. السيناريو في المقال تعليمي مستقل داخل مستأجر مصرح.

Authentication and authorization basics
https://learn.microsoft.com/en-us/graph/auth/auth-concepts

Application and delegated permissions for access tokens
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/application-delegated-permission-access-tokens-identity-platform

List managedDevices
https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0

Paging Microsoft Graph data
https://learn.microsoft.com/en-us/graph/paging

ولمراجعة أدوار المستخدمين ونطاق الإدارة داخل إنتيون:
https://courses.cyberpts.com/community/145/scope-tags-fy-intune-lysh-dwr-alqrah-qd-ytla-awsa-mn-almtwqa-and-jma-aladwar

Microsoft Graph throttling guidance
https://learn.microsoft.com/en-us/graph/throttling