Automation job - Certificate issuess and azure connection

Product: PowerShell Universal
Version: 1.5.0

I’m looking to utilize an Azure keyvault for some automation job testing. I’m having an issue utilizing commands and information inside the Automation scripts. Even after setting up the azure connection from a powershell session under the same service account running the Universal service, it behaved like I wasn’t connected to azure.

To fix this, I added in connect-azaccount into the script just to see if i could get the commands to work. Unfortunately, I was met with an error with it finding my certificate with the thumbprint i specified, even though it is in the localmachine\my location on the same box. What’s more, if I run the identical dir cert:\localmachine\my command in a pwsh session and as the script in automation, i get two different sets of results. The one in automation seems to have less certificates. If I specify a path to the cert to import it at the start, it says it can’t find the .cer file, even though its there.

So, I guess what I’m coming to ask is if there is a difference in the powershell driven sessions via Automation causing this issue?

Are you running PSU as a service? It kind of sounds like a permission issue with PSU. I know you said you are running with the same account but could it be some kind of elevation issue?

You can check like this:

(New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

Another thing you can check is differences in privileges. We have seen IIS do some weird stuff with worker processes in certain environments so if you are running in IIS it’s another thing to check. Even when running as the same account, IIS will assign limited privileges to the worker process which can cause unexpected permission issues.

PSU starts PowerShell using standard Process.Start calls in C#. The only time it does something kind of weird is when running as a service account and then running a job as another user. In this scenario, it uses some P\Invoke calls to login as the target user. This is why we have to set a bunch of interesting privileges when doing so: About - PowerShell Universal (ironmansoftware.com)

Yep, PSU is running as a service, under a domain service account.

I took your code snippet and added it to my test script in automation. It’s returning True, so it seems it is running as Administrator.

EDIT: Looked over the page you linked, didn’t have all of those set for the service account. Once I did, that fixed my problem! Thanks for the help Adam

1 Like