شرح WinRM وTest-WSMan: المنفذ مفتوح، لكن ليش جلسة PowerShell ترفض الدخول؟

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

في WinRM تحتاج تفصل الوصول إلى الشبكة، واستجابة WS-Management، والمصادقة، وصلاحية الجلسة، وصلاحية الأمر داخلها. بنمشي على جهاز تدريب واحد مصرح، ونستخدم قراءات محددة لفهم أين توقفت العملية. ما نحتاج تعطيل الجدار الناري أو توسيع TrustedHosts أو منح الحساب إدارة كاملة حتى نفسر النتيجة.

WinRM وPowerShell Remoting: مرتبطان، لكنهما مو اسمين للشيء نفسه

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

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

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

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

اعرف الهدف وإعداد الاتصال قبل ما تفسر الرفض

خلنا نفترض جهاز لاب اسمه srv01.lab.test، وحساب تدريب مصرح لاختبار استجابة الخدمة. نعرف من إعداد البيئة أن منفذ HTTP المستخدم هو 5985. في PowerShell Remoting عبر WinRM، 5985 و5986 هما المنفذان المعتادان لـHTTP وHTTPS، لكن الاستماع يمكن أن يكون مخصصًا. لا تختبر رقمًا محفوظًا ثم تعتبر عدم الاستجابة دليلًا أن الخدمة غير موجودة.

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

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

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

فحص TCP يعطيك إجابة صغيرة ومفيدة

على جهاز ويندوز في اللاب، مثال فحص المنفذ المحدد:

Test-NetConnection -ComputerName srv01.lab.test -Port 5985

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

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

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

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

Test-WSMan يفحص استجابة الخدمة، مو صلاحية تنفيذ الأوامر

بعد التحقق من المنفذ المتوقع، استخدم على ويندوز طلب تعريف محدودًا:

Test-WSMan -ComputerName srv01.lab.test -Port 5985

هذا مثال يرسل طلبًا إلى خدمة WS-Management. تعمدنا كتابة المنفذ صراحة حتى يكون هدف الاختبار واضحًا. إذا كانت البيئة تعتمد HTTPS على 5986، استخدم إعدادها الموثق وخيار -UseSSL بدل إرسال طلب HTTP إلى منفذ مختلف ثم تفسير الفشل على أنه رفض حساب.

عندما لا تحدد -Authentication، يوضح توثيق الأداة أن طلب Test-WSMan يرسل دون مصادقة. لذلك نجاح المثال لا يثبت قبول حساب التدريب ولا السماح له بجلسة PowerShell. وقد تظهر معلومات إصدار نظام التشغيل كقيم صفرية في الاستجابة المجهولة؛ لا تحولها إلى اكتشاف «Windows إصدار صفر» أو خلل في الجهاز.

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

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

المصادقة تجاوب من أنت، والتفويض يجاوب وش يسمح لك تسوي

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

إعداد جلسة PowerShell، أو Session Configuration، له حقوق وصول. الجلسات الافتراضية وإعدادات المؤسسة قد تختلف عن جلسة مقيدة أنشئت لفريق دعم. لذلك لا تختصر الأمر في عضوية مجموعة واحدة بدون مراجعة الـendpoint الذي تقصده والحقوق الفعلية التي اعتمدتها البيئة.

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

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

الاسم وKerberos وHTTPS: ثلاثة أسئلة لا تخلطها

في اتصال دومين معتاد بالاسم، يمكن أن يدخل Kerberos في المصادقة. الاتصال بعنوان IP أو من جهاز خارج سياق الدومين يغيّر الشروط، لذلك لا تتوقع أن تكون كل الخيارات متساوية. إذا كانت تعليمات اللاب تعتمد اسمًا مؤهلًا، ابدأ به بدل استبداله بعنوان لمجرد أن العنوان أسهل للنسخ.

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

وجود HTTP في إعداد WinRM لا يسمح لك تختصر النتيجة إلى «كل محتوى PowerShell مكشوف». توثيق أمان PowerShell Remoting يفرق بين النقل وحماية الرسائل بعد المصادقة، ويشرح حماية الجلسة بحسب الآلية. بالمقابل، لا تستخدم هذه المعلومة لتوصية عامة بتفعيل Basic أو قبول محتوى غير مشفر؛ هذه إعدادات لها سياق أمني مختلف.

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

TrustedHosts ما يعطي الحساب صلاحيات على الخادم

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

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

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

كذلك لا تخلط TrustedHosts مع علاقة Trust بين دومينين. تشابه الاسم لا يجعلهما إعدادًا واحدًا. الثقة في Active Directory، وتحقق العميل من جهة WinRM، وتفويض جلسة PowerShell مفاهيم مختلفة. لما تفرقها، تقدر تقرأ رسالة الخطأ وتوجهها للطبقة المناسبة بدل أن تبحث عن كلمة trust وتطبق أول أمر يظهر.

جلسة أولى ناجحة، لكن الوصول لجهاز ثالث يفشل

قد يدخل المستخدم جلسة على srv01، ثم يطلب منها موردًا على files01 فتفشل العملية. هنا عندك اتصال أول نجح، وعملية ثانية إلى وجهة أخرى. لا تصف الحالة بأن «WinRM لا يعمل» بدون الإشارة إلى المرحلة التي فشلت؛ هذا يخفي أن المشكلة تبدأ بعد وصولك إلى الخادم الأول.

مفهوم Second Hop في PowerShell Remoting يتصل باستخدام هوية المستخدم للوصول من الجهاز الوسيط إلى جهة أخرى. المصادقة إلى srv01 لا تعني أنه صار يملك وسيلة يستخدمها في كل اتصال باسمك. هذا الفصل الأمني مهم، وحلول التصميم تختلف حسب التطبيق والهوية المطلوبة.

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

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

سيناريو كامل: ثلاث نتائج، وكل نتيجة لها معنى

ابدأ في لابك بهدف محدد srv01.lab.test ومنفذ معتمد 5985. اختبار TCP يرجع نجاحًا، وTest-WSMan يرجع استجابة تعريف. هاتان النتيجتان تدعمان أن المسار والخدمة يستجيبان للفحص المحدد. إلى الآن لم تختبر حق حسابك في جلسة PowerShell، فلا تضف ذلك إلى الملخص.

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

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

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

اكتب نتيجة يستطيع مسؤول النظام مراجعتها

صياغة مفيدة قد تكون: «من جهاز التدريب المحدد نجح اختبار TCP إلى 5985، وأجاب طلب تعريف WS-Management دون مصادقة. لم تثبت هذه القراءات صلاحية حساب التدريب لتنفيذ جلسة. المحاولة المصرح بها للـendpoint المطلوب رُفضت، وتحتاج مطابقة إعداد الوصول مع الغرض المعتمد للحساب». هذا أدق من اعتبار المنفذ المفتوح دخولًا إداريًا.

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

لفهم أثر اسم الخدمة راجع شرح SPN، وللتفاوت الزمني راجع مقال Clock Skew في المجتمع:
https://courses.cyberpts.com/community/77/shrh-spn-wsetspn-balarby-lysh-alkhdmh-tfth-basm-wtfshl-basm-thany
https://courses.cyberpts.com/community/78/khta-clock-skew-fy-kerberos-afhm-akhtlaf-alwqt-wafhsh-bastkhdam-w32tm

مراجع التحقق: توثيق Test-WSMan، وأمان PowerShell Remoting عبر WinRM، واستكشاف أخطاء الاتصالات البعيدة من مايكروسوفت:
https://learn.microsoft.com/en-us/powershell/module/microsoft.wsman.management/test-wsman
https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/winrm-security
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting

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