none
is there a built-in powershell runspace property telling which the user created the remote runspace?

    Question

  • Suppose user A creates a remote powershell runspace using credential B. I can use RunSpace.ConnectionInfo.Credential.UserName to get B’s information. Is there any built-in properties in this runspace where I can know that this runspace is ultimately created by A? I can pass A’s username using a session state in this runspace, however such session state can be easily tempered. Appreciate your help!

    Thursday, March 01, 2012 4:52 PM

Answers

  • If you are concerned about being able to reliably establish the identity of the user connection to the system, User A and User C should not be using a set of shared credentials for User B in the first place.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Saturday, March 03, 2012 12:42 AM
    Moderator

All replies

  • Suppose user A creates a remote powershell runspace using credential B. I can use RunSpace.ConnectionInfo.Credential.UserName to get B’s information. Is there any built-in properties in this runspace where I can know that this runspace is ultimately created by A? I can pass A’s username using a session state in this runspace, however such session state can be easily tempered. Appreciate your help!

    No.  You cannot know that from the runspace.

    The runspace state cannot be easily tampered with.  It is managed by the system and not by the user.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 5:30 PM
  • Thanks for reply.

    I hope we are talking about the same thing - "runspace state" and "session state". The session state can be easily set by SessionStateProxy API. Say user A creates a remote session/runspace using credential B. To let the function called in the runspace know that this call is initialized by A instead of B, the only way is set A's user name in the session state. Then the remote runspace can extract A's name from the session state. However, user C can also creates a remote session/runspace using credential B, setting A's user name in the session state, resulting that we cannot trust the user name set in the session state. This may clarifies why session state is not safe to be used for authentication.

    Friday, March 02, 2012 11:58 PM
  • If you are concerned about being able to reliably establish the identity of the user connection to the system, User A and User C should not be using a set of shared credentials for User B in the first place.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Saturday, March 03, 2012 12:42 AM
    Moderator