> hey, this was a pretty good try! But here's what else you need to do:
No I don't. To open up a machine for remote administration, all I have to do is run Enable-PSRemoting like so:
Enable-PSRemoting -Force
For domain-joined machines the authentication from there is just automatic, -i.e. when I use Invoke-Command it automatically created an authenticated and encrypted connection for the duration of the script execution.
> you'll quickly find that when you start a program (which you left off) using a script remotely, it doesn't show up anywhere on-screen, despite being authenticated as the logged-in user, but it does show up in the process list. Guess why THAT is.
That has nothing to do with PowerShell and everything to do with your expectation that you have equally poor session separation as with your typical nix.
With sufficient rights you can of course stop any process. But to reach in and control another user session is something else.
On Windows, processes are separated not just by the account they run under, but also by the session* under which they are created. Security barriers prevents a process in one session from interacting with processes in another session, even if they run as the same user.
This security boundary was raised to prevent compromised user processes from reaching into services and vice versa. This is part of the protection against shatter attacks and more.
I know a utility like psexec (sysinternals) may be able to launch a process in a foreign session, but I'm honestly not sure how it achieves this without some kernel support.
> but it does show up in the process list. Guess why THAT is.
That is because when you launch a process is launches in your session. A session is associated with a Windows Desktop (an operating system object type) which is a namespace separation somewhat like cnames in Linux. Windows on your (remote) session lives on the non-visible desktop associated with that session. When you log off it destroys the session and any processes running under the session.
You may not agree with the extra security features built into Windows, but the separation they create has noting to do with PowerShell.
No I don't. To open up a machine for remote administration, all I have to do is run Enable-PSRemoting like so:
For domain-joined machines the authentication from there is just automatic, -i.e. when I use Invoke-Command it automatically created an authenticated and encrypted connection for the duration of the script execution.> you'll quickly find that when you start a program (which you left off) using a script remotely, it doesn't show up anywhere on-screen, despite being authenticated as the logged-in user, but it does show up in the process list. Guess why THAT is.
That has nothing to do with PowerShell and everything to do with your expectation that you have equally poor session separation as with your typical nix.
With sufficient rights you can of course stop any process. But to reach in and control another user session is something else.
On Windows, processes are separated not just by the account they run under, but also by the session* under which they are created. Security barriers prevents a process in one session from interacting with processes in another session, even if they run as the same user.
This security boundary was raised to prevent compromised user processes from reaching into services and vice versa. This is part of the protection against shatter attacks and more.
I know a utility like psexec (sysinternals) may be able to launch a process in a foreign session, but I'm honestly not sure how it achieves this without some kernel support.
> but it does show up in the process list. Guess why THAT is.
That is because when you launch a process is launches in your session. A session is associated with a Windows Desktop (an operating system object type) which is a namespace separation somewhat like cnames in Linux. Windows on your (remote) session lives on the non-visible desktop associated with that session. When you log off it destroys the session and any processes running under the session.
You may not agree with the extra security features built into Windows, but the separation they create has noting to do with PowerShell.