सर्व्हर B वर परस्परसंवादी पद्धतीने काम करणारी वेब विनंती 407 मिळवू शकते जेव्हा तीच आज्ञा तिथे PowerShell रिमोटिंगद्वारे चालवली जाते. 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
}

क्रेडेन्शियल ऑब्जेक्ट प्रॉक्सीच्या इच्छित खात्यासाठी आहे. सत्र अजूनही त्याचे नेहमीचे रिमोटिंग प्रमाणीकरण वापरते, आणि कोणतेही वेबसाइट लॉगिन त्या वेबसाइट विनंतीचा भाग राहते.

यामुळे पहिल्या लॉगिनच्या स्वयंचलित डेलिगेशनवर अवलंबून राहणे टळते. तथापि रिमोट होस्टने दिलेली खाते सामग्री इच्छित प्रशासन रचनेचा भाग म्हणून हाताळणे आवश्यक आहे. इतर आर्किटेक्चर, जसे की व्यवस्थापित RunAs एंडपॉइंट किंवा मर्यादित सेवा प्रवेश, यांना त्यांच्या स्वतःच्या कॉन्फिगरेशन आवश्यकता असतात.

जर डीफॉल्ट प्रॉक्सी क्रेडेन्शियल्स हे चुकीचे गृहीतक होते, तर रिमोट आज्ञा कोणत्या खात्याखाली चालते आणि प्रॉक्सी कोणते प्रमाणीकरण मागते ते नोंदवा. जास्त वेळाची वेब-विनंती मुदत गहाळ क्रेडेन्शियल्स देऊ शकत नाही.

New-PSSessionOption वरील प्रॉक्सी पर्याय रिमोटिंग कनेक्शनशीच संबंधित आहेत. जेव्हा B चे बाह्य वेब कनेक्शन प्रॉक्सीची गरज असते तेव्हा रिमोट स्क्रिप्ट ब्लॉकमध्ये Invoke-WebRequest कॉन्फिगर करा.

संबंधित लेख