get-process returning one user when packaged

[gkhairallah]

Hi,
I am having an odd issue that I can't figure out.
I have a simple get-process line to get a process for all users that have it running:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.ps1)

1. $QBWUsers = Get-Process -Name QBW32 -IncludeUserName -ErrorAction SilentlyContinue | select -ExpandProperty Username
2. $QBWUsers

It works well when ran directly as a ps1.

However, when I package it as an exe, with another user's credentials (impersonation), this statement always returns one user only, regardless of whether there are more users that should be returned.
If I run the ps1 on the impersonated user, it also returns the correct results, so the issue is only returning a different result when ran as an exe.

Any ideas what I might be doing wrong with the packager that could cause this behavior? As far as I know, the Get-Process command should query all processes regardless of the context of the user running it.

My Packager is set to :
Microsoft Windows (32 bit)
SAPIEN Powershell V5 Host (Silent)
Embed a default manifest
Alternate Credentials Set
Run Mode: Impersonate User

Thanks!

[jvierra]

A normal user can only see that users processes. Only and Admin can see all users.

PS C:\scripts> Get-Process -IncludeUserName
Get-Process : The 'IncludeUserName' parameter requires elevated user rights. Try running the command again in a session that has been opened with elevated user rights
(that is, Run as Administrator).

[gkhairallah]

Thanks for the insight @jvierra.
I have tried removing the impersonation user, and it worked as expected.
I also tried to run the exe (without impersonation), under the intended account under which I want to run the exe and it worked fine.

The account being used is in fact a local administrator on the server (and UAC is off), so I would expect that running the exe under that impersonated user would in fact have the necessary privileges to run correctly?

What you stated is in fact correct, however, as I verified that when I run the command under the impersonated user profile, I do get the message:

Get-Process : The 'IncludeUserName' parameter requires elevated user rights. Try running the command again in a session that has been opened with elevated user rights

Also, running the exe as "Run as Administrator" also does not allow it to run successfully.
Can you shed some light on how I can go about getting that cmdlet with the "IncludeUserName" to work with an impersonated user?
Or ... I'm also open to another method altogether that might work. The important thing is that I can run it under the impersonated user.

Thanks again!

[gkhairallah]

I think I figured out the source of the problem:

User Account Control: Run all administrators in Admin Approval Mode

This was preventing the impersonation user, even as "Local Administrator" from being able to elevate correctly.
Once I resolved this piece, I was able to run the exe elevation as expected.

Thanks for pointing me in the right direction @jvierra!

Cheers!

[jvierra]

WARNING: setting this policy to disabled is a serious security problem is mostly available to allow systems to be run at a lower security level like older windows systems. it is never recommended to disable this setting.

[gkhairallah]

Thanks @jvierra. Agreed. I have researched that specific point and opted to change my method.

Cheers,

[jvierra]

This should always work:

(Get-WmiObject Win32_Process -filter "Name = 'powershell.exe'").GetOwner().User

[gkhairallah]

Yup, indeed it does (on a local admin, regardless of UAC restriction). Very cool. Thanks again @jvierra!

[jvierra]

I suspect that Get-Process should also work as it is built on top of the WMI class but the security restrictions on the Net Framework classes for the CmdLets may be rest6rticting this. When some CmdLet fails then direct access via WMI may help.