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"
Nic
  • 13,425
  • 17
  • 61
  • 104
growse
  • 8,020
  • 13
  • 74
  • 115
  • Could it be UAC? – HopelessN00b Mar 28 '13 at 12:16
  • Even though the account is a domain admin? – growse Mar 28 '13 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. – HopelessN00b Mar 28 '13 at 12:53
  • 1
    Did you enabled: winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"} – timmeyh Mar 28 '13 at 13:01
  • I've enabled `RemoteShellAccess` via GPO, and I still see the same result. – growse Mar 28 '13 at 13:20
  • @HopelessN00b: Just to clarify for future reference, UAC does not effect a domain user's access to remote resources (however it may for a local user). The token used remotely is the "full" token. See http://support.microsoft.com/kb/951016 for more information. So in a domain, the simple answer is UAC does not apply to remote use. – charleswj81 Apr 04 '13 at 03:36

4 Answers4

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.

Edwin Young
  • 56
  • 1
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!
argonym
  • 113
  • 4
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.

Cory Plastek
  • 979
  • 2
  • 8
  • 14
  • *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 04 '13 at 09:52
-1

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

womble
  • 96,255
  • 29
  • 175
  • 230
user370867
  • 1