Assigning User context to schedule

PowerShell Universal
1 
Product: PowerShell Universal
Version: 5.3.2

Hello, I am having a problem with scheduled scripts. They don’t have access to secrets in the vault. While trying to find any information on this I found something in the documentation.

The documentation says this about schedules.

“…Schedules do not have a user context so you will need to specify one in order to get them to run properly when using these cmdlets.”
However it does not go into further detail on how to actually achieve this. Do anyone know how to accomplish this? I’ve tried setting my schedules with “run as” credentials and I have tried to adding “-apptoken ” to appropriate line in Schedules.ps1. Neither has made a difference. I am unable to reference a secret store in the database when running via a schedule. This secret is set to only be accessible by the administrator role. The app token is setup to be given the administrator role.

2

Hey @aulucas , I had a similar thing a while ago until I realised I forgot about the -integrated switch on a command - when running inside a script environment i PSU.

I have this in a helper function that I use periodically to see what variables a script, app, etc has visibility of. maybe it will hep you to see what the scheduled script can access

$variables = @(Get-PSUVariable -Integrated)

if($variables.Count -eq 0){
    Write-Warning "No variables found" 
    return
}

$secrets = @($variables.Where({$_.Secret}))
$nonSecrets = @($variables.Where({-not $_.Secret}))

Write-Information "Secrets"
$secrets | format-table -properties Name,Vault,Type,Scope,Description

Write-Information "Variables"
$nonSecrets | format-table -properties Name,Vault,Type,Scope,Description
3

Oddly enough running “Get-PSUVariable” with no -integrated or -apptoken tag runs just fine in a schedule, but I can’t use the $secret scope.

I found the following in documentation (Variables | PowerShell Universal)
“Applying roles to a secret will prevent the secret from being accessible in scheduled jobs because no roles are applied in the scheduler.”

So I may be trying to do something that just doesn’t work, but is there a way to assign roles to my schedule or authenticate within the script?

4

Ah yeah I grasp it better now.

In places where Ive seen User Context in the docs it is talking to the Identity in the runas on the item or on the environment

Things that come to mind - although youve probably done em are:

  • The Identity used in Schedule RunAs has the Administrator Role assigned to it
  • Try using an environment that is running as the identity, and setting the schedules environment, instead of the schedules runas

After that it feels like a documentation gap or a bug for sure

5

In digging today I found this reference: Variables | PowerShell Universal

Applying roles to a secret will prevent the secret from being accessible in scheduled jobs because no roles are applied in the scheduler.

If that one in the variables page is correct then the data in the Module page about Schedules is probs a little misleading. The variables page seems pretty “You shall not pass!” language

6

Scheduled scripts run under a hidden System identity that doesn’t have any roles so it cant look at secrets. Run As credentials aren’t identities in themselves so they don’t provide roles to the schedule. It’s really just a security mechanism to prevent unauthorized folks from accessing the contents of a secret by manually creating and running a script to dump them.

Currently, the only option would be to remove the roles from the variable. We do have an option issue on this but it’s never been fixed because I’m a bit torn on what the solution should be.

This confuses a lot of people so it certainly seems like we may just need to rethink exactly what roles on variables should be used for. For example, job runners like GitHub actions allow you use secrets (albeit they don’t have role configurations) in any script\schedule.

7

@TriggerAu I appreciate you doing some digging on my behalf.

@adam, currently I have just removed the role requirements from my secret, which feels like a security issue itself. Currently its not an issue as I’m one of the only admins using PSU in my environment. If it was possible to lock down schedule creation to a specific role, that could sort of side step this issue. If only my Admins can create schedules and I wouldn’t care If Jobs run as schedules can access all of my secrets.

I think I might be talking in circles, and maybe removing roles from my secrets isn’t really as big of a issue as I think it is. Maybe schedule creation is already locked down to only Admins and I just don’t realize it.

I was going to recommend a documentation change, but as I re-read the Config>Module>Schedule section I realize that it is laid out. I just misunderstood it.

Module | PowerShell Universal
"Schedules do not have a current user. You will need to specify an App Token or Default Credential when using cmdlets within scheduled scripts. Although this is an extra step, it ensures that only the necessary permissions are applied to the schedule script.

Schedules do not have a user context so you will need to specify one in order to get them to run properly when using these cmdlets."

I think I skimmed right over “cmdlets”. If I understand that is referencing a command that I would run within the script I’m scheduling. like invoking another script or another PSU specific command. Meaning I would just need to supply a apptoken to that?

8

You can use permissions to do this. I’ll be the first to admit we need better documentation around this.

We are also working on improving the UI for it in v5.5 so it should be easier to approach. I made an example of how to define a role with permissions for a scheduler.

That’s correct. If you use Permissive or Integrated security mode, you won’t need to specify app tokens if you use the -Integrated switch. If you are using the secure setting, you will need app tokens for schedules scripts.