يعتبر التحكم عن بُعد في PowerShell (PSRemoting) أحد أكثر الميزات استخداماً في PowerShell بشكل عام. لماذا؟ لأنه مفيد للغاية! باستخدام أمر واحد فقط، يمكنك الاتصال بسلاسة بكمبيوتر واحد أو الآلاف من الأجهزة البعيدة وتنفيذ الأوامر.
في هذا الدليل النهائي، ستتعمق في PSRemoting. ستتعرف على ما هو وكيف يعمل، وعلى كل التقنيات المختلفة التي تجعل PSRemoting يعمل. لن يتطرق هذا الدليل إلى كيفية استخدام PSRemoting. ستجد العديد من الإشارات إلى دلائلنا التعليمية في جميع أنحاء الدليل.
كيف يعمل PSRemoting
بشكل مبسط، يتيح لك PSRemoting تشغيل الأوامر على أجهزة الكمبيوتر البعيدة تماماً كما لو كنت جالساً أمامها. يوفر PSRemoting مجموعة من الميزات التي تتيح الاتصال والمصادقة للمستخدم، وتشغيل الأوامر البعيدة وإرجاع أي ناتج من تلك الأوامر إلى الكمبيوتر المحلي.
فكر في PSRemoting مثل بروتوكولات telnet أو SSH أو حتى psexec. إنها مجرد طريقة لتشغيل الأوامر على أجهزة الكمبيوتر باستخدام PowerShell.
يعتمد PSRemoting بشكل كبير على مفهوم يسمى “جلسة”. الجلسة هي مصطلح يستخدم لوصف قذيفة بعيدة تشغل الأوامر بداخلها. يتم إنشاء إحدى هذه الجلسات عبر عدة خطوات في الخلفية.
عندما تبدأ جلسة PSRemoting، يتم تنفيذ الخطوات العامة التالية:
- يحاول العميل الاتصال بخادم الوجهة على استمعة WinRM (لمزيد من المعلومات حول استمعات WinRM أدناه). استمعة WinRM هي خدمة ويب صغيرة تعمل على الخادم الوجهة. WinRM هو تنفيذ Microsoft لمعيار يسمى WSMan. WSMan هو معيار مفتوح تم إنشاؤه مع العديد من الشركات التكنولوجية الكبيرة الأخرى في ذلك الوقت مثل Dell و Intel و Sun Microsystems.
- عندما يتصل العميل بالاستمعة عبر بروتوكول HTTP أو HTTPS ، يبدأ عملية المصادقة. سيتم تغطية تفاصيل كل طريقة للمصادقة في وقت لاحق ، ولكن في الوقت الحالي ، يجب على العميل تمرير بيانات الاعتماد إلى الخادم بطريقة ما.
- بعد أن يتصل العميل ويتم مصادقته على الخادم ، ينشئ PSRemoting جلسة.
- بمجرد أن ينشئ PSRemoting الجلسة ، فإنه يكون مفتوحًا للعمل. في هذه النقطة ، يمكن للعميل أن يبدأ في إرسال المعلومات إلى الخادم مع إرجاع الخادم لأي إخراج ضروري يعرف بـ serialization. يتم تشفير هذه الاتصالات عادة.
استمعات WinRM: متاحة للاتصال
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
يمكنك اكتشاف جميع استمعات WinRm التي تعمل على أي كمبيوتر يعمل بنظام التشغيل Windows باستخدام الأمر winrm أدناه.
تحتوي استمعات WinRm على بعض المكونات المهمة. لديها:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- نوع النقل – يحتاج كل مستمع WinRM إلى وسيلة للتواصل مع العميل ، ويتم ذلك عبر نقل باستخدام HTTP أو HTTPS.
- بصمة شهادة اختيارية – عندما يستخدم مستمع WinRM HTTPS للنقل ، يجب أن يعرف ما هي المفتاح الخاص للمصادقة على العميل ؛ يتم العثور على هذا المفتاح باستخدام بصمة الشهادة.
استخدم مستمع HTTPS عند الإمكان. يزيد إعداد نقل HTTPS من الأمان عن طريق ضمان صحة الخادم وتشفير كل من المصادقة وحركة المرور. عند إصدار شهادة ، استخدم شهادة موثوقة من سلطة الاعتماد ، إذا كان ذلك ممكنًا بدلاً من شهادة ذاتية التوقيع.
المضيفون الموثوق بهم: التحقق من الخادم
كيفية عمل المصادقة عبر PSRemoting عبر WinRM
كما ذكر أعلاه ، أحد أولى الخطوات التي يتخذها PSRemoting هي المصادقة. المصادقة هي واحدة من أكثر الأجزاء تعقيدًا وأساسية في PSRemoting.
عندما تم تقديم PSRemoting لأول مرة ، كان لديه آلية مصادقة واحدة فقط ، وهي إدارة Windows عن بُعد (WinRM) ولكن في الوقت الحاضر ، يمكنك أيضًا المصادقة باستخدام SSH كما سترى لاحقًا.
يدعم WinRM نوعين متميزين من المصادقة ؛ اسم المستخدم وكلمة المرور أو شهادة مع أنواع مختلفة من المصادقة للتوصل إلى توازن بين اسم المستخدم وكلمة المرور.
المصادقة الأساسية
ابتداءً من أسهل طريقة للمصادقة، ولكنها غير آمنة، هي المصادقة الأساسية. هذا النوع من المصادقة هو معيار مدمج في بروتوكول HTTP. ترسل المصادقة الأساسية نسخة مشفرة بترميز base64 من اسم المستخدم وكلمة المرور في رأس الطلب HTTP من العميل إلى المستقبل.
نظرًا لأن المصادقة الأساسية تقوم بتشفير اسم المستخدم وكلمة المرور فقط ولا تقوم بتشفيرها، فإنه من السهل جدًا اعتراض بيانات الاعتماد عبر الشبكة.
لا تستخدم المصادقة الأساسية إلا إذا كنت مضطرًا لذلك. هناك العديد من الطرق الأخرى الأكثر أمانًا التي يمكن لـ WinRM أن تستخدمها للمصادقة!
مصادقة Kerberos
هل كل من العميل والخادم الخاص بك في بيئة Active Directory؟ إذا كنت كذلك، فأنت تستخدم بالفعل مصادقة Kerberos في العديد من خدمات الشبكة الخاصة بك.
عندما يحاول عميل WinRM الاتصال بمستقبل WinRM عبر بروتوكول Kerberos:
- يحاول المستقبل أولاً الحصول على مفتاح الجلسة أو تذكرة منح التذاكر للعميل من خادم تحكم النطاق.
- يقوم خادم تحكم النطاق بالبحث عن العميل والخادم، وإذا كان كلاهما صالحًا وموثوقًا، فإنه يصدر الرمز.
- ثم يقوم المستقبل بالتحقق من اتصال العميل باستخدام الرمز الموثوق به بدلاً من اسم المستخدم وكلمة المرور.
أثناء مصادقة كيربيروس، يقوم مركز النطاق بالتحقق من صحة كل من العميل والخادم أثناء خطوات استرداد التذكرة مما يمنع أي شخص خبيث من انتحال صفة الخادم.
كيربيروس هو طريقة مصادقة ناضجة وآمنة وهي النوع الافتراضي للمصادقة عندما يكون العميل والخادم عضوين في نطاق Active Directory. ولكن، يتطلب كلا من العميل والخادم أن يكونا متصلين بنفس غابة Active Directory أو بوجود ثقة معمول بها بين الغابات.
المصادقة التفاوضية
يمكن أيضًا لـ WinRm أن يحاول استخدام كيربيروس وإذا لم يكن متاحًا، فيمكنه الاستخدام البديل ومحاولة استخدام بروتوكول مصادقة يسمى مدير NT Lan (NTLM).
عند استخدام NTLM:
- يقوم الخادم بإرسال سلسلة نصية للعميل.
- يقوم العميل بتشفير السلسلة النصية باستخدام تجزئة كلمة مرور المستخدم.
- يتم إرسال السلسلة المشفرة ثم إعادتها إلى الخادم الذي يرسل اسم المستخدم والسلسلة الأصلية والسلسلة المشفرة إلى مركز النطاق.
- ثم يقوم مركز النطاق بالبحث عن تجزئة كلمة المرور لتلك المستخدمة ويكرر نفس عملية التشفير على السلسلة للتحقق من تطابقها.
يعتبر NTLM جيدًا للتحقق من العميل ، ولكن على عكس Kerberos ، فإنه لا يتحقق من صحة الخادم. يفتح ذلك الباب أمام هجمات متعددة حيث يمكن للمهاجم أن يتنكر في الخادم.
يمكنك تعزيز أمان NTLM عن طريق التحقق من صحة الخادم أيضًا باستخدام شهادة مصادقة الخادم وتعيينها للمستمع HTTPS WinRM. في هذا الإعداد ، يتم التحقق من صحة العميل باستخدام NTLM ضد مراقب المجال ، ويتم التحقق من صحة الخادم باستخدام شهادة موثوقة. على الرغم من أن هذا الإعداد يوفر كل من مصادقة العميل والخادم ، إلا أن بروتوكول NLTM يستخدم تشفيرًا قديمًا مع حجم مفتاح قديم.
لهذه الأسباب ، يمكن استخدام NLTM فقط إذا قمت بإضافة الخادم إلى قائمة المضيفين الموثوق بهم أو استخدام مستمع HTTPS.
مصادقة الهضم
واحدة من أكثر أساليب المصادقة غير المعتادة للاستخدام في WinRM هي مصادقة الهضم. NTLM والهضم هما أساليب مصادقة مماثلة. مثل NTLM ، يولد الهضم سلسلة فريدة تتم تشفيرها بواسطة هاش كلمة مرور المستخدم. بعد ذلك ، لا يحتاج إرسال كلمة المرور إلى الخادم.
يستخدم الهضم خوارزمية تجزئة MD5 لتشفير كلمة المرور. بسبب اختيار هذا الخوارزمية ، يعتبر الهضم عمومًا قديمًا ويجب عدم استخدامه. يحتوي MD5 على ثغرات معروفة مختلفة تجعله غير مناسب للاستخدام الهجائي.
موفر دعم أمان الاعتمادات (CredSSP)
على الرغم من أننا يمكن أن نتعمق في تفاصيل CredSSP، إلا أن ذلك غير ضروري. لماذا؟ لأنه عندما يتعلق الأمر بـ PSRemoting و WinRM ، يتم تنفيذ CredSSP عادةً لسبب واحد فقط ، وهو “مشكلة القفزة الثانية” التي ستتعرف عليها أدناه.
عند تكوين المصادقة باستخدام CredSSP ، يستخدم كل من عميل WinRM والخادم المصادقة الاعتراضية للمصادقة للمستخدم والعميل. ولكن بمجرد الانتهاء من ذلك ، يتم إرسال كلمة مرور المستخدم إلى الخادم.
نظرًا لأن كلمة المرور يتم إرسالها بعد اكتمال عملية المصادقة ، فإنها مشفرة الآن. يقوم CredSSP أيضًا بتشفير كلمة المرور باستخدام مفاتيح جلسة TLS بحيث يكون السلسلة المشفرة فريدة بين الجلسات.
يكون CredSSP مفيدًا لأنه بعد المصادقة ، يمكن للخادم الاتصال بأي شيء آخر نيابة عنك. ومع ذلك ، عند حدوث ذلك ، فأنت تثق تمامًا في الخادم الذي قمت بالاتصال به بكلمة مرور المستخدم.
المصادقة بواسطة الشهادة
ربما يكون أكثر طريقة آمنة للمصادقة لاستخدام PSRemoting هي المصادقة بواسطة الشهادة. في هذه الطريقة للمصادقة ، يحدث تبادل مفتاح نموذجي بين المفتاح الخاص والمفتاح العام على العميل وتحقق الخادم من الشهادة.
يقوم WinRM بمصادقة المستخدم عن طريق تعيين مستخدم على الخادم داخل WinRM. الشيء الوحيد الذي يتم تمريره أثناء عملية المصادقة هو المفتاح العمومي، لذا فإنه يعتبر طريقة آمنة جدًا للمصادقة.
على الرغم من أن مصادقة الشهادة هي الأكثر أمانًا، إلا أنها غير شائعة جدًا. هذا ببساطة بسبب الجهد اللازم لإعدادها. يجب عليك:
- بناء سلطة الشهادات
- إنشاء شهادة مصادقة مستخدم
- مشاركة المفتاح العمومي
- استخدام حساب مستخدم محلي بالصلاحيات المناسبة (ربما مجموعة المسؤولين)
- إعداد استماع HTTPS
- …وخطوات أخرى.
لا يمكنك استخدام مستخدم مجال للمصادقة باستخدام الشهادات حتى لو كان العميل والخادم على حد سواء جزءًا من Active Directory.
القيم الافتراضية للمصادقة في نظام التشغيل Windows
الآن بعد أن رأيت أن هناك العديد من خيارات المصادقة المختلفة المتاحة، كيف تعرف أي منها متاحة مسبقًا؟ في الجدول أدناه ستجد عمودين يشيران إذا كان عميل WinRM ممكّنًا افتراضيًا وإذا كان هذا النوع المحدد من المصادقة ممكّنًا افتراضيًا.
يمكن تكوين جميع أنواع المصادقة المذكورة سابقًا ولكن استخدام الجدول أدناه سيعطيك فكرة جيدة عن ما ستحتاج إلى تكوينه بنفسك.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
المشكلة الثانية أو مشكلة القفزة المزدوجة
واحدة من أكبر المشكلات في PSRemoting هي ما يعرف بـ “مشكلة القفزة الثانية” أو “القفزة المزدوجة”. يحدث هذا الوضع عندما تتصل بنظام بعيد عبر PSRemoting وتحتاج بعد ذلك للاتصال بجهاز كمبيوتر بعيد آخر.
يعد هذا الوضع مشكلة لأنه عندما يقوم عميل WinRm بالمصادقة على الكمبيوتر البعيد الأول ، يقوم الخادم فقط بالتحقق من هوية العميل الأصلي دون إرسال كلمة المرور إلى الخادم. عند محاولتك الاتصال بالكمبيوتر الثاني من خادم الاتصال الأول ، لا يكون لدى الخادم النهائي أي طريقة للتحقق من هوية المستخدم.
يمكنك حل مشكلة القفزة المزدوجة بعدة طرق مختلفة سواء عن طريق استخدام CredSSP أو تفويض Kerberos.
استخدام CredSSP
أكثر الطرق شيوعًا للتعامل مع مشكلة القفزة المزدوجة هو استخدام CredSSP. يتجاوز المصادقة بواسطة CredSSP هذا الوضع عن طريق تخزين بيانات اعتماد المستخدم على الخادم البعيد الأول الذي يمكن للخادم المحول أن يمرها إلى الخادم البعيد الثاني.
لكن هناك مشكلة واحدة في استخدام CredSSP. يمكن تخزين بيانات اعتماد المستخدم على الخادم البعيد الأول على شكل نص نقي، مما يشكل مصدر قلق أمني واضح. في أنظمة التشغيل الأحدث ، يتم استخدام التجزئة لكلمة المرور وتذكرة Kerberos لمنح التصريح. يمكن استخدام هذه المعلومات معًا للمصادقة باسم المستخدم في أي مكان على الشبكة تمامًا مثل كلمة المرور النصية العادية ، ولكن يقلل من المخاطر قليلاً.
مع عملية التفاوض، يتم تبادل المعلومات بين العميل والخادم للتحقق من هويتهما، ولكن لا يمكن الوصول إلى كلمة مرور المستخدم. نظرًا لهذه الميزة الأمنية، لا يوجد طريقة يمكن للخادم الأول أن يوثق هويتك عند الاتصال بالخادم الثاني.
باستخدام تفويض كيربروس
كما ذكر في وقت سابق، يُعتبر كيربروس وسيلة شائعة لإعداد PSRemoting. يعتبر جزءًا من Active Directory المنتشر على نطاق واسع ومعد مسبقًا، وبشكل افتراضي، فإنه شائع جدًا. على الرغم من أن كيربروس بمفرده يعتبر طريقة جيدة للمصادقة على WinRM، إلا أنه لا يتجاوز مشكلة القفزة المزدوجة.
للتغلب على سيناريو القفزة المزدوجة، يمكنك استخدام نوع ثانٍ من المصادقة يُعرف بـ
على الرغم من وجود العديد من أنواع تفويض كيربروس، فإن النوع الوحيد القادر على (ويعتبر آمنًا بما فيه الكفاية) أن يكون بديلاً لـ CredSSP يُعرف بـ
تفويض كيربروس المقيد Delegation
وتحديدًا تفويض كيربروس المقيد المستند إلى الموارد.
تعد تفويض كيربروس المقيد المستند إلى الموارد شكلًا لتفويض رموز مصادقة كيربروس استنادًا إلى موارد المجال، مثل الكمبيوترات في هذه الحالة، والتي تكون مقيدة بقائمة محددة من كائنات كيربروس (Active Directory).
لتكوين تفويض Kerberos هذا ، تحتاج إلى تعديل كائن ADComputer للكمبيوتر الثالث في السلسلة. على سبيل المثال ، إذا كنت ستقوم بالاتصال عن بُعد من العميلA إلى الخادمB إلى الخادمC ، يجب عليك تعديل كائن ADComputer للخادمC ، ولكنك أيضًا بحاجة إلى معرفة ما سيكون الخادمB. لهذا المثال ، قم بتشغيل الأمر التالي في PowerShell:
استخدام تفويض Kerberos المعتمد على الموارد يعمل للاتصالات عن بُعد مثل …. أو … ولكنه لن يعمل مع PSRemoting. لن تتمكن من الاتصال بكمبيوتر ثالث عند الاتصال بكمبيوتر عبر WinRM باستخدام PSRemoting.
إعداد تفويض Kerberos المعتمد على الموارد هو أمر PowerShell مكون من سطر واحد باستخدام cmdlet Set-ADComputer. على سبيل المثال ، إذا كنت متصلاً بـ الخادمB من العميلA عبر PSRemoting وترغب في الاتصال بـ الخادمC باستخدام …. ، يمكنك ذلك من خلال تشغيل الأمر التالي في PowerShell.
يخزن WinRm الاتصالات الفاشلة لمدة 15 دقيقة. بسبب هذه الميزة ، قد لا تتمكن من الاتصال بالكمبيوتر الثالث حتى بعد إعداد تفويض Kerberos المعتمد على الموارد. لحل هذه المشكلة ، انتظر أو قم بتشغيل الأمر
klist purge -LI 0x3e7على الكمبيوتر الثالث لتطهير رموز Kerberos الفاشلة.
كيفية عمل المصادقة عبر SSH لـ PSRemoting.
على الرغم من أن مصادقة WinRm هي الطريقة الأكثر شيوعًا لمصادقة PSRemoting ، إلا أنه اعتبارًا من PowerShell v6 ، لديك طريقة أخرى ؛ SSH. باستخدام SSH كطريقة مصادقة يمكنك استخدام PSRemoting مع Linux.
يتطلب SSH ، على عكس WinRm ، بعض التكوينات الإضافية على كلا العميل والخادم مثل إعداد عميل SSH على عميل Windows و…
استخدام SSH للتعامل مع المصادقة يعني أنك محدود بأنواع المصادقة التي يدعمها SSH. يقتصر هذا على القائمة مع وجود نوعين رئيسيين وهما المصادقة بناءً على كلمة المرور والمصادقة بناءً على المفتاح العام.
هناك أنواع أخرى من المصادقة المدعومة بواسطة SSH ، ولكن عادة ما يتم اعتبارها أقل أمانًا من الخيارات المعتمدة على كلمة المرور والمفتاح العام ، لذلك سنركز فقط على هاتين الخيارين.
مصادقة كلمة المرور
أسهل طريقة لإعداد مصادقة SSH مع PSRemoting هي باستخدام مصادقة كلمة المرور. تسمح لك مصادقة كلمة المرور بتقديم كلمة مرور للتحقق من هويتك.
في عملية المصادقة بواسطة SSH، يتم تبادل كلمة المرور بعد إجراء اتصال SSH ويتم تشفير كلمة المرور أثناء النقل. على عكس بعض طرق المصادقة المستخدمة بواسطة WinRM، مثل Kerberos، فإن هذه الطريقة للمصادقة لا ترسل كلمة المرور بأكملها إلى الخادم.
يمكنك بعض الشيء مقارنة مصادقة كلمة المرور في SSH بطريقة المصادقة Basic المستخدمة في WinRM باستخدام مستمع HTTPS. فعملية حماية كلمة المرور ذاتها ليست ذات صلة بأي طريقة، ولكن الاتصال بأكمله، بما في ذلك كلمة المرور، يتم تشفيره استنادًا إلى شهادة ويتم التحقق من صحة الخادم استنادًا إلى شهادة.
المصادقة بناءً على الشهادة
على الرغم من أن المصادقة بناءً على كلمة المرور سهلة الإعداد ومباشرة الاستخدام، إلا أنها تعاني من مشكلتين.
- المشكلة الأولى هي أنه لا يوجد وسيلة للمصادقة بشكل آمن بتنسيق غير مراقب.
- ما زالت مصادقة كلمة المرور ترسل كلمة المرور عبر الشبكة. على الرغم من أن كلمة المرور مشفرة داخل اتصال SSH، إلا أن الخادم يستلم كلمة المرور بالكامل. إذا تم اختراق الخادم بأي طريقة ما، فقد يتحول ذلك إلى قضية أمان.
من ناحية أخرى، لا يتم إرسال أي بيانات حساسة عبر الشبكة في حالة المصادقة بناءً على الشهادة مثل كلمة المرور. بدلاً من ذلك، يحتوي الخادم على نسخة من المفتاح العمومي، ويحتوي العميل على نسخة من المفتاح الخاص، وتتم المفاوضات على الخادم.
A rough workflow goes as follows:
- عندما يحاول العميل المصادقة، يرسل معرف أو بصمة المفتاح العمومي إلى الخادم.
- إذا كان لدى الخادم المفتاح العمومي المسجل كمفوض له، فإنه يرد بسلسلة مشفرة باستخدام المفتاح العمومي.
- ثم يقوم العميل بفك تشفير السلسلة باستخدام المفتاح الخاص.
- ثم يتم تجزئة المفتاح الخاص باستخدام معرف الجلسة.
- يتم إرسال معرف الجلسة إلى الخادم، الذي يقارنه بالتجزئة التي تم إنشاؤها باستخدام السلسلة الأصلية ومعرف الجلسة.
- إذا تطابقت تجزئة معرف الجلسة من العميل مع معرف الجلسة على الخادم، يتم توثيق العميل ويسمح له بالاتصال.
أي شيء يتم تشفيره باستخدام المفتاح العام يمكن فقط فك تشفيره بواسطة المفتاح الخاص المرتبط. أي شيء يتم تشفيره باستخدام المفتاح الخاص يمكن فقط فك تشفيره بواسطة المفتاح العام. يتم أيضًا إدخال معرف الجلسة لتوفير ما يسمى بـسرية التقدم الأمثل (PFS).
توفر PFS الأمان إذا تم اختراق المفتاح الخاص، حيث لن يكون الهاكر قادرًا على فك تشفير جميع الرسائل التي تمت المراسلة فيها. معرف الجلسة الفريد يعني أن السر المشترك المستخدم لتشفير الاتصال مختلف لكل جلسة.
يتطلب المصادقة القائمة على الشهادة باستخدام SSH، مثل WinRm، جهودًا إضافية لإعدادها مثل إنشاء المفتاح الخاص/العام وتفويض المفتاح العام على الخادم البعيد.
الحقوق المطلوبة للاتصال
بشكل افتراضي، يمكن لمجموعتين محليتين من المستخدمين الاتصال بخادم عن بُعد باستخدام PSRemoting؛ المسؤولون و مستخدمو الإدارة عن بُعد.
على الرغم من أنه يمكنك فقط إضافة حسابات المستخدمين إلى مجموعة المسؤولين المحليين على الخادم البعيد ، يجب عليك دائمًا توفير أقل قدر من الوصول. إذا كان المستخدم يحتاج فقط إلى الاتصال بـ PSRemoting بجهاز كمبيوتر بعيد ، فيمكنك إضافة حساب المستخدم إلى مجموعة مستخدمي الإدارة البعيدة ؛ وليس المسؤولين.
لمزيد من التحكم في الوصول إلى PSRemoting ، يمكنك أيضًا استخدام ميزة تسمى الإدارة بالقدر الكافي (JEA). تتيح JEA للمستخدمين غير المسؤولين تشغيل أوامر محددة فقط كمسؤولين في وضع اللغة المحدودة لـ PowerShell.
التراسل الضمني مقابل التراسل “الصريح”
إذا كنت قد استخدمت PSRemoting من قبل ، فربما تكون معتادًا على الأوامر مثل Invoke-Command ، New-PSSession ، Enter-PSSession ، الخ. عند تشغيل هذه الأوامر ، من الواضح أنك تقوم بالاتصال بجهاز كمبيوتر بعيد بطريقة ما. أنت تستخدم PSRemoting بشكل صريح.
عند تشغيل الأوامر الخاصة بـ PSRemoting ، فأنت تقوم بتشغيل تلك الأوامر بشكل صريح ولكن هل تعلم أن هناك طريقة أخرى؟ بدلاً من استدعاء Invoke-Command وغيرها من cmdlets مباشرةً ، يمكنك الاستفادة من PSRemoting عن طريق استخدام التراسل الضمني الضمني.
قد يبدو استخدام PSRemoting الضمني كما لو أنك تقوم بتشغيل الأوامر محلياً داخل جلسة PowerShell الخاصة بك، ولكنها في الواقع تعمل على جهاز بعيد. مثال جيد على ذلك هو استخدام وحدة ليست مثبتة على نظامك. بدلاً من تثبيتها محلياً، يمكنك تصدير الأوامر من PSSession والسماح لك بتشغيلها كما لو كانت مثبتة محلياً.
في الصورة أدناه يمكنك رؤية أنني لا أملك الأمر Test-PendingReboot. ثم قمت بالاتصال بجهاز بعيد وتصدير هذا الأمر.
ثم إذا تم استيراد تلك الوحدة، يمكنني بعد ذلك تنفيذ الأمر Test-PendingReboot. يتم عرض ذلك في الأدنى، ولكن ستلاحظ أنه يظهر اسم الكمبيوتر في الناتج ليس اسم الجهاز الذي تعمل فيه PowerShell، ولكن اسم الجهاز الذي تم استيراد الأمر منه.
