პროქსის სერტიფიკატები მეორე PowerShell ნახტომზე

მიაწოდეთ განკუთვნილი პროქსის ანგარიში დისტანციურ სერვერზე მომუშავე Invoke-WebRequest-ს, ნაცვლად იმისა, რომ ჩათვალოთ remoting-შესვლა დელეგირებულად.

ვებ-მოთხოვნამ, რომელიც 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-ის გარე ვებ-კავშირს სჭირდება პროქსი.

დაკავშირებული სტატიები