PowerShell Server: Isolated Sessions, User Accounts, and Impersonation
Isolated Sessions
When PowerShell Server is configured to run as a Windows Service, a new process is launched to host the PowerShell Runspace as the logged in user. This causes any processes created from PowerShell to also run from this same user account.
When running PowerShell Server in-process, isolated sessions are not utilized, and impersonation is used (if the Enable Impersonation setting is selected) as described in the Impersonation section below.
Note: Isolated Sessions are not supported on Windows XP or Windows Server 2003.
Turning off Isolated Sessions
To turn off Isolated Sessions, navigate to the Other tab and uncheck the “Isolate Sessions” checkbox. Restart the server for the change to take effect.
This will cause impersonation to be used (if enabled) as described in the Impersonation section below.
Impersonation
When running PowerShell Server in-process, or as a service with Isolated Sessions disabled, the PowerShell Server will impersonate the specified user when connecting to the server by default. Therefore the PowerShell Runspace will be created using the specified credentials and thus will have the access rights of that user. Note that some services (such as working with Microsoft Exchange) do not allow for impersonated users and will return errors when making connections. In these cases, you will need to disable impersonation.
For more information about using the Microsoft Exchange cmdlets with PowerShell Server please see this article.
Disabling Impersonation
To turn off Impersonation, navigate to the Other tab and uncheck the “Enable Impersonation” checkbox. Restart the server for the change to take effect.
When impersonation is disabled, the user account used to create the PowerShell Runspace will vary depending on whether the PowerShell Server is configured to run as a Windows Service or In-Process. This option is configurable via the checkbox labeled “Run as a Windows Service” on the “Service” tab of the PowerShell Server GUI. When this option is checked it will run as a Windows Service. If this option is unchecked it will run In-Process.
Running the PowerShell Server as a Windows Service Without Impersonation
If you have the PowerShell Server configured to run as a Windows Service and both Isolated Sessions and Impersonation are disabled using the methods mentioned above, the PowerShell Runspace will be created using the account specified for the “Log On As” option for the service. By default, the “Local System” account will be used.
If the commands you are running require additional access rights, you will need to change the “Log On As” user to an account that has the needed permissions. This is accomplished by opening up the Services window from the Administrative Tools section of the Control Panel. You can then edit the properties of the PowerShell Server service (right-click -> Properties), open the “Log On” tab, and enter the needed credentials under the “This account” option. You should then be able to restart the service and all PowerShell runspaces will now be created using the specified user account.
Running the PowerShell Server In-Process Without Impersonation
If you have disabled impersonation using the method above, and you do not have the PowerShell Server configured to run as a Windows Service (i.e. it will be running In-Process), the PowerShell Runspace will be created using the account that the executable was started under. Therefore if you wish to use a different account, you will need to logon to your machine using the desired account and start the PowerShell Server. All connections made will have the same access rights of this account when the PowerShell Runspace is created.
Access to Remote Network Resources
For information on accessing remote network resources from PowerShell Server, please see this article.
We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at kb@nsoftware.com.