0

Der folgende Code funktioniert gut, wenn ich es in der Powershell ISE als Administrator ausführen (dh ich die PS ISE als Admin starten)Invoke-Command läuft OK als Administrator, aber nicht als aktuelle Benutzer

Invoke-Command -ScriptBlock {[IntPtr]::Size} 

Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential 

Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential -ConfigurationName Microsoft.PowerShell32 

ich die erwarteten Antworten von

8 
8 
4 

Das sagt mir, dass WinRM richtig konfiguriert ist und läuft, und dass mein $ Credential richtig eingestellt ist. Allerdings, wenn ich versuchen, das gleiche in der PS ISE als Benutzer ausgeführt wird (mit oder ohne Administratorrechte) ich die folgenden Fehler für den zweiten und dritten Befehle erhalten

[<ComputerName>] Connecting to remote server <ComputerName> failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic. 
    + CategoryInfo   : OpenError: (<ComputerName>:String) [], PSRemotingTransportException 
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken 

Ich werde den Scriptcode mit etwas mehr werden ersetzt Substantiv, das aufgrund von Abhängigkeiten von 32-Bit-DLLs im 32-Bit-Modus ausgeführt werden muss, und die Möglichkeit für Benutzer, einen Teil des Codes im 64-Bit-Modus und andere Teile im 32-Bit-Modus auszuführen, ist wichtig.

Irgendwelche Gedanken?

+0

Ist der Berechtigungsnachweis der gleiche wie Ihr Login? – Jimbo

+0

@ Jimbo - Ja ist es, deshalb ist das so verwirrend. Auch das gleiche Zertifikat im Admin- oder Benutzer-Modus, und es funktioniert gut im Admin-Modus. – hsbatra

Antwort

2

PSRemoting verwendet einen Endpunkt oder eine Sitzungskonfiguration auf dem Remotecomputer. Sie sind sich dessen natürlich bewusst, da Ihr dritter Befehl den Parameter ConfigurationName enthält. Diese Endpunkte - Microsoft.PowerShell, Microsoft.PowerShell32 usw. - enthalten Berechtigungen für sie, die angeben, wer eine Verbindung zu ihnen herstellen kann.

Wechseln Sie zu Ihrem Remotecomputer (in diesem Fall Ihr lokaler Computer), führen Sie Get-PSSessionConfiguration aus, und sehen Sie sich die Permission-Eigenschaft an. Sie werden schnell erkennen, dass Ihr Administratorzugriff Voraussetzung ist. Dies ist beabsichtigt; Es ist eine gute Sache!

Ihre Optionen sind eins, bearbeiten Sie den/die Endpunkt (e) und fügen Sie Ihren Benutzer (n) hinzu, gewähren Sie Ihrem Benutzer Zugriff (entweder Admin- oder möglicherweise Remote-Management-Benutzerzugriff), drei, verwenden Sie einen Berechtigungsnachweis Objekt, wenn Sie Invoke-Command ausführen, übergeben Sie die Anmeldeinformationen oder vier, Erstellen Sie Ihren eigenen Endpunkt mit den erforderlichen Berechtigungen.

+0

Dank @TommyMaynard - Da die $ credential ist die gleiche, ob das Skript in der Admin oder der Benutzer ISE ausgeführt wird, und es funktioniert in der Admin-ISE - ich nehme an (a) der Benutzer wurde hinzugefügt (Using the derzeit angemeldet (b) Der Benutzer hat den erforderlichen Zugriff, da er im Admin-ISE ausgeführt wird. (c) Der Parameter -Credential wird in den Befehlen 2 und 3 verwendet. Die Verwirrung bleibt bestehen! Wie geht man mit Vorschlag Nr. 4 vor? btw - Get-PSSessionConfig funktioniert nur in der Admin-ISE - wie oder im User-Modus zu laufen? – hsbatra

+0

Für Vorschlag # 4 meinst du: Set-PSSessionConfiguration Microsoft.Powershell32 -ShowSecurityDescriptorUI. Ich habe das getan, aber die Wirkung scheint nicht hartnäckig zu sein !? Wenn ich zu der Konfiguration zurückkehre, scheint meine Execute-Berechtigung verschwunden zu sein. – hsbatra

+0

Bitte ignorieren Sie den vorherigen Kommentar zur Persistenz. Für Vorschlag # 4 wollten Sie folgendes verwenden: Set-PSSessionConfiguration Microsoft.Powershell32 -ShowSecurityDescriptorUI. Ich habe das auch getan, und alle Benutzer haben FullControl. – hsbatra

Verwandte Themen