صلاحية نشر سكربت في Intune: متى تصير طريقًا إلى SYSTEM، وكيف تثبت الأثر بدون ضرر؟

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

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

ارسم المسار قبل أن ترفع ملفًا

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

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

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

سياق المستخدم وسياق النظام ليسا نفس الأثر

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

SYSTEM
User context

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

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

حدد جهازًا واحدًا ومجموعة لا تتوسع بالصدفة

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

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

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

إثبات حميد لسياق التنفيذ

بدل تنفيذ تغيير حساس، يمكن لمسؤول اللاب تجهيز سكربت يطبع علامة التجربة وهوية العملية. هذا مثال تعليمي محلي لا يجمع أسرارًا ولا يغير أذونات:

Write-Output "Lab script identity check"
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

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

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

التوقيع طبقة مهمة، لكنه لا يراجع نية المحتوى

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

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

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

افحص الموافقة على المورد الذي يهمك

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

Multi Admin Approval

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

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

القراءة والإنشاء والتعديل تحتاج جداول مختلفة

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

DeviceManagementScripts.Read.All
DeviceManagementScripts.ReadWrite.All

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

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

افصل أربع لحظات في سجل النشر

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

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

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

سجلات العميل تربط السياسة بالعملية

على جهاز ويندوز التدريبي، توجد سجلات لامتداد الإدارة تساعد في متابعة الطلب والمعالجة والتنفيذ. من الأسماء التي تحتاج تميزها:
IntuneManagementExtension.log
AgentExecutor.log

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

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

العمارة وسلوك التطبيق قد يغيران النتيجة

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

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

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

المسار قد يبدأ بملكية مجموعة لا بدور النشر

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

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

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

اكتب الخطورة من النطاق والسياق

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

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

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

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

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

اختبار الإغلاق يحافظ على وظيفة النشر المشروعة

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

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

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

المراجع

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

Use PowerShell scripts on Windows devices in Intune
https://learn.microsoft.com/en-us/intune/device-management/tools/run-powershell-scripts-windows

Intune Management Extension
https://learn.microsoft.com/en-us/intune/device-management/tools/management-extension-windows

Use Multi Admin Approval with Microsoft Graph
https://learn.microsoft.com/en-us/intune/fundamentals/role-based-access-control/multi-admin-approval-graph-api

List deviceManagementScripts
https://learn.microsoft.com/en-us/graph/api/intune-devices-devicemanagementscript-list?view=graph-rest-beta