दूसरी PowerShell हॉप पर प्रॉक्सी क्रेडेंशियल

रिमोटिंग लॉगिन को डेलिगेट मानने के बजाय रिमोट सर्वर पर चल रहे Invoke-WebRequest को इच्छित प्रॉक्सी खाता दें।

सर्वर 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 कॉन्फ़िगर करें।

संबंधित लेख