Script Running As Credential Behaving Strangely

PowerShell Universal
1

I’m attempting to run a simple script with a stored credential. I’ve created the secret variable for my AD-based service account, domain\service with the password and set the script to run as this account. The script is set to run in the Windows PowerShell 5.1 environment. The service account is granted log on as a batch job, log on as a service, replace a process level token, and adjust memory quotas for a process. PSUniversal itself is running as Local System.

The script works fine if I log into the PSUniversal server as the service account and run it from the repository directly. All the script does is import the Posh-SSH module, test for the presence of a file to transfer and if it exists, open an SFTP session, upload the file, and close the SFTP session. However it looks like some or all commands are not imported correctly? The job output produces these errors:

Feb 1, 2022 6:26 PM [warning] Failed to verify module and server version. Call failed. An error occurred while sending the request. GET https://localhost:443/api/v1/version
Feb 1, 2022 6:26 PM Imported module Posh-SSH
Feb 1, 2022 6:26 PM [error] Access to the path ‘C:\Windows\system32\config\systemprofile’ is denied.
Feb 1, 2022 6:26 PM [error] Cannot bind argument to parameter ‘SessionId’ because it is null.

The import message is just the result of the module import being wrapped in a try/catch block, and the “Cannot bind” argument is the result of one of the Posh-SSH commands seemingly not functioning correctly.

Product: PowerShell Universal
Version: 2.5.5
2

I’ll open an issue for this one. I don’t know why it would happen and don’t know enough about the posh-ssh module.

Have you tried running the PSU service as a service account?

3

That’s a viable workaround, it will take a little while to test as I’ll need to update cached credential files in a number of scripts to test. Let me know if I can provide any more info to help troubleshoot!

5

I think this might have something to however runas is implemented in Universal. For reference, Posh-SSH stores its known hosts file in $home\.poshssh\hosts.json.

It looks like when Universal runs a script as another user, the $home variable for the Local System account must still be what the ‘running as’ environment sees, so it’s trying to access the hosts.json file for the Local System account in C:\Windows\System32\config\systemprofile\.poshssh, rather than in its own home directory, which would be C:\users\service\.poshssh.

I granted the service account access to the systemprofile.poshssh directory and things work. I don’t know if this should still be considered a bug, or if this is just a reality of Universal and variable scoping that I was unaware of.