قد يتلقى طلب ويب يعمل تفاعليًا على الخادم B الرمز 407 عندما يُنفَّذ الأمر نفسه هناك عبر PowerShell remoting. تسجيل الدخول من A إلى B لا يفوّض تلك الهوية تلقائيًا لتبادل المصادقة التالي على B.

A → remoting session on B → HTTP proxy → website

أحد التصاميم المدعومة هو تمرير حساب الوكيل صراحةً للطلب الصادر. مع PSSession قائمة وكائن PSCredential مُحصَّل بالطريقة المناسبة:

Invoke-Command -Session $session -ArgumentList $proxyCredential -ScriptBlock {
    param([pscredential]$outboundProxyCredential)

    $requestOptions = @{
        Uri = 'https://api.example/'
        Proxy = 'http://proxy.example:8080'
        ProxyCredential = $outboundProxyCredential
    }
    Invoke-WebRequest @requestOptions
}

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

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

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

تخصّ خيارات الوكيل على New-PSSessionOption اتصال remoting نفسه. اضبط Invoke-WebRequest داخل كتلة النص البرمجي البعيدة عندما يكون اتصال B الخارجي بالويب هو ما يحتاج إلى الوكيل.

مقالات ذات صلة