सर्भर 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 कन्फिगर गर्नुहोस्।

सम्बन्धित लेखहरू