Eine Webanforderung, die auf Server B interaktiv funktioniert, kann 407 erhalten, wenn derselbe Befehl dort über PowerShell-Remoting ausgeführt wird. Die Anmeldung von A nach B delegiert diese Identität nicht automatisch für den nächsten Authentifizierungsaustausch von B.

A → remoting session on B → HTTP proxy → website

Ein unterstütztes Vorgehen ist es, das Proxykonto explizit bereitzustellen für die ausgehende Anforderung. Mit einer bestehenden PSSession und einem ordnungsgemäß beschafften PSCredential-Objekt:

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
}

Das Anmeldeinformationsobjekt gehört zum vorgesehenen Konto des Proxys. Die Sitzung verwendet weiterhin ihre normale Remoting-Authentifizierung, und eine Website-Anmeldung bleibt Teil der Anforderung an diese Website.

Damit wird die Abhängigkeit von einer automatischen Delegierung der ersten Anmeldung vermieden. Es setzt jedoch voraus, dass der Remotehost das übergebene Kontomaterial im Rahmen des vorgesehenen Administrationsdesigns behandelt. Andere Architekturen, etwa ein verwalteter RunAs-Endpunkt oder ein eingeschränkter Dienstzugriff, haben eigene Konfigurationsanforderungen.

Wenn die Standard-Proxyanmeldeinformationen die fehlerhafte Annahme waren, halten Sie das Konto, unter dem der Remotebefehl läuft, und die vom Proxy angeforderte Authentifizierung fest. Ein längeres Timeout für die Webanforderung kann fehlende Anmeldeinformationen nicht ersetzen.

Die Proxyoptionen von New-PSSessionOption betreffen die Remoting-Verbindung selbst. Konfigurieren Sie Invoke-WebRequest im Remote-Skriptblock, wenn die ausgehende Webverbindung von B den Proxy benötigt.

Ähnliche Artikel