درخواست وبی که به‌صورت تعاملی روی سرور 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 مربوط می‌شوند. وقتی اتصال وب رو به بیرون B است که به پروکسی نیاز دارد، Invoke-WebRequest را داخل بلوک اسکریپت راه‌دور پیکربندی کنید.

مقالات مرتبط