5

I'm trying to administer a Windows 7 machine remotely. I've enabled WinRM and can use Enter-PsSession to connect to the remote machine.

However, I'm noticing a difference between running a particular command locally, vs running it remotely, even though I'm connecting with the same user account (which is a Domain Admin).

The output from the remote session is:

> enter-pssession -computername  REMOTEHOST
[REMOTEHOST} > Get-WURebootStatus
New-Object : Creating an instance of the COM component with CLSID {C01B9BA0-BEA7-41BA-B604-D0A36F469133} from the IClassFactory failed due to the following error: 80070005.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\pswindowsupdate\Get-WURebootStatus.ps1:52 char:33
+             $objSystemInfo= New-Object <<<<  -ComObject "Microsoft.Update.SystemInfo"
+ CategoryInfo          : NotSpecified: (:) [New-Object], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand

ExecutionPolicy is set to 'Unrestricted', and this command works great when I'm using a local powershell session on the remote machine.

Is there a different security context for remote powershell sessions?

edit: the specific line it's failing on is this one:

$objSystemInfo= New-Object -ComObject "Microsoft.Update.SystemInfo"
6
  • Could it be UAC? Mar 28, 2013 at 12:16
  • Even though the account is a domain admin?
    – growse
    Mar 28, 2013 at 12:26
  • Yes, the UAC prompt (well, the way Windows Vista and up use split-token authentication for administrator accounts, to be technical) interferes with domain admins just like it does with local admins. Mar 28, 2013 at 12:53
  • 1
    Did you enabled: winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"}
    – timmeyh
    Mar 28, 2013 at 13:01
  • I've enabled RemoteShellAccess via GPO, and I still see the same result.
    – growse
    Mar 28, 2013 at 13:20

4 Answers 4

4

The Windows Update API is special. It specifically checks for and disallows remote access by checking if your token is marked as remote. I don't know why it was written this way.

I ended up creating a scheduled task and invoking the windows update API inside that - quite a nuisance.

1
  • I think this might have to be the way forward.
    – growse
    Apr 3, 2013 at 8:52
1

Depending on exactly how Get-WURebootStatus cmdlet accesses it's information, I think it might be related to the "second-hop" problem in PowerShell.

When you enter a remote PowerShell session, you're asking WinRM to create a session on the remote host using your credentials. If, from that same session, you attempt to access another (remote) system or service that requires those credentials, the request will fail because the remote machine isn't authorized to use your credentials for authentication to anything else. A 'Hey, Scripting Guy!' blog explains this well:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/11/14/enable-powershell-quot-second-hop-quot-functionality-with-credssp.aspx

You would see this same (or similar) issue when, after remoting into a machine and then attempting to access another remote machine share path with Test-Path, for the same reason.

The solution (as is presented in the blog article) is to enable and use CredSSP as the authentication mechanism when creating the PSSession.

You can also wrap the command in a scheduled task and have that run immediately as well, but that is a lot of extra work that could be unnecessary.

1
  • edit spoke too soon. Get-WUList gives a sane result, but running Get-WUInstall or Get-WURebootStatus still throw a 0x80070005 'access denied' error.
    – growse
    Apr 4, 2013 at 9:52
1

Copy from Stack Overflow: Powershell Remote: Microsoft.Update.Session, Access Denied: 0x80070005:

When you are in a remote PowerShell session your logon session on this remote computer is flagged as a "network" logon (Logon Type: 3). For some obscure (security? sell SCCM?) reason, part of the Windows Update Agent COM APIs are restricted to only be usable by locally logged on Administrators.

Using PsExec and Scheduled Tasks have been suggested as workarounds.

IMO, the most seamless (and still secureable) solution is to facilitate the RunAs-style "Local Virtual Account" feature of PowerShell Session Configurations / JEA. Usually, JEA is used to "restrict" what a user can do on a remote computer PowerShell-wise, but we are (ab-)using it here to gain full access as if we were a locally logged on Administrator.

(1.) Create a new unrestricted (and persistent!) session configuration on ComputerB (remote server):

New-PSSessionConfigurationFile -RunAsVirtualAccount -Path .\VirtualAccount.pssc
# Note this will restart the WinRM service:
Register-PSSessionConfiguration -Name 'VirtualAccount' [-ShowSecurityDescriptorUI] -Path .\VirtualAccount.pssc -Force
# Check the Permission property:
Get-PSSessionConfiguration -Name 'VirtualAccount'
# Those users will have full unrestricted access to the system!

(2.) From ComputerA (local client) connect to our unrestricted session configuration on ComputerB:

New-PSSession -ComputerName 'ComputerB' -ConfigurationName 'VirtualAccount' | Enter-PSSession
[ComputerB]: new-object -com "Microsoft.Update.Downloader" # Yay!
-1

Try using Get-WURebootStatus -ComputerName <your remote computer> -Silent.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .