Invoke-PSUScript in 4.3.3 gets "not authorized", worked in 4.3.2

PowerShell Universal
1 
Product: PowerShell Universal
Version: 4.3.2
Version: 4.3.3

I have a simple page that asks for an account name, a button click will call a script that calls get-aduser, and display the output in a textbox.
This worked in 4.3.2 and causes an “not authorized” error upon Invoke-PSUScript after update to 4.3.3. It works again after a downgrade to 4.3.2.

All I found in the logs is:
[01:18:21 ERR][App][AD] Failed to execute script. NotAuthorized

Details:
Host: Windows Server 2016 on VMware
Powershell: 7.4.2
PSU installed via: install-module universal, install-psuserver
added a self-signed certificate and https on 443.
PSU runs as service / local system

The script getaduser.ps1 is listed in Automation/Scripts.
Environment is set to Windows PowerShell 5.1
It resides in the Repository folder.
It works nicely when called directly from the scripts page in both PSU versions

It loads the credentials needed to access AD from an xml file.

param($sam="xuser",$two)

Import-Module -Name ActiveDirectory

$identity="zzz"
$creds=$null
$credfile=("$([System.Environment]::MachineName)_$identity.xml")
$creds=Import-Clixml "$credfile"

if ($sam) {
    $out=get-aduser $sam  -credential $creds -server "zzz.no.net"
} else {
    $out="no account name"
}

return $out

The app that calls the script uses the Integrated Environment.

New-UDGrid -Container -Content {
    New-UDGrid  -Item -ExtraSmallSize 12 -Content {
        New-UDTextbox -id "sam" -Label "sam accountname" -Value "xxx"
    }
    New-UDGrid  -Item -ExtraSmallSize 12 -Content {
        New-UDButton -id "search" -text "Search ZZZ"  -showloading -onclick {
            
            $sam=(Get-UDElement -id "sam").value
            Show-UDToast -Message "$($sam)" -BackgroundColor "gold"
            if ($sam) {

                $Job=Invoke-PSUScript -Name getaduser.ps1
                while ($Job.status -notmatch "Completed|Error") {
                    Show-UDToast -Message "$($Job.status)" -BackgroundColor "gold"
                    start-sleep 1
                    $job=Get-PSUJob -id $job.id
                }
                Show-UDToast -Message "$($Job.id)" -BackgroundColor "gold"
                $out=Get-PSUJobOutput -JobId $job.id 
                $out=$out -replace "\s+"," "
                Set-UDElement -id "result" -Properties @{value=$out|out-string -Width 160}
            }
        }
    }
    New-UDGrid  -Item -ExtraSmallSize 12 -Content {
        New-UDTextbox -id "result" -Label "Result" -Multiline -Disabled -Variant filled -FullWidth 
    }
}
2

If you use the -Credential parameter in your Invoke-PSUScript command, does it work? Just wondering if it’s an issue of credentials not being passed.

3

which credentials?
It does not need that in 4.3.2.

PSU runs under system, so it cannot access AD.
I know I could probably launch the script with credentials.
But theoretically it should just run anyway.
The error tells me that PSU is not allowed to start the script at all.

And if there would be issues with the credentials for get-aduser, I would get a nice error message.

4

I would try to include the -Integrated parameter.

      $Job=Invoke-PSUScript -Name getaduser.ps1 -Integrated
                while ($Job.status -notmatch "Completed|Error") {
                    Show-UDToast -Message "$($Job.status)" -BackgroundColor "gold"
                    start-sleep 1
                    $job=Get-PSUJob -id $job.id -Integrated
                }

This is the default mode when running PSU cmdlets in PSU but it uses a couple things, like Connect-PSUServer state, and some built in variables, to determine if that’s the case. -Integrated forces it.

I’m unaware of changes between .2 and .3 in this regard but we could open an issue to investigate.

2 Likes
5

We don’t have ours tied to AD, and ours was installed via MSI, but I modified your example App to essentially just launch one of our scripts via the button, and it executed without any error about permissions. There are some other differences with our setup to how you have yours (such as both the App and script are set to use Agent for their environment), so I’m going to make some more samples to test with that better reflect your scenario as close as I can.

For reference, the App code I ran is:

New-UDApp -Title 'PowerShell Universal' -Content {
    New-UDGrid -Container -Content {
        New-UDGrid  -Item -ExtraSmallSize 12 -Content {
            New-UDButton -id "search" -text "Run"  -showloading -onclick {
                $job = Invoke-PSUScript -Script "Mist\PLC - Get Mist Clients.ps1"
                    while ($Job.status -notmatch "Completed|Error") {
                        Show-UDToast -Message "$($Job.status)" -BackgroundColor "gold"
                        start-sleep 1
                        $job = Get-PSUJob -id $job.id
                    }
                    Show-UDToast -Message "$($Job.id)" -BackgroundColor "gold"
                    $out = Get-PSUJobOutput -JobId $job.id
                    $out = $out -replace "\s+", " "
                    Set-UDElement -id "result" -Properties @{value = $out | out-string -Width 160
                }
            }
        }
        New-UDGrid  -Item -ExtraSmallSize 12 -Content {
            New-UDTextbox -id "result" -Label "Result" -Multiline -Disabled -Variant filled -FullWidth
        }
    }
}
1 Like
6

Thank you.
I have “fumbled” so much meanwhile…
I will update to 4.3.3 again and test again.

7

Thank you.
I will try that as well, just need to understand first what “agent” means. :wink:
I am still new.

AD does not like Agent:

[error] The running command stopped because the preference variable “ErrorActionPreference” or common parameter is set to Stop: Module ‘C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ActiveDirectory\ActiveDirectory.psd1’ supports PowerShell edition ‘Desktop’ and cannot be loaded implicitly using the Windows Compatibility feature because it is disabled in the settings file. Use ‘Import-Module -UseWindowsPowerShell’ to load this module with Windows PowerShell or ‘Import-Module -SkipEditionCheck’ to try to load the module with the current PowerShell.

8

You can read about the environments at Environments | PowerShell Universal if you’d like (assuming you haven’t already found that page).

You will probably have to set your environment to PowerShell 7 or WIndows PowerShell 5.1 for the ActiveDirectory module to work. I haven’t tested, but that seems likely.

1 Like
9

with 4.3.2 I can set the app to Integrated ore Agent and the script to PS5.1, both works.
Tomorrow I will test with 4.3.3 again.

1 Like
10

I did Update-PSUServer -LatestVersion
No other changes.

The AD script throws a red error toast “Failed to execute script. Not authorized”

The AD script still runs nicely from automation/scripts.

I switched between several environment options - no change in behavior.

I created another script that just does “ls”.
Same error.

Added a new app, one page, just to call the script, still same error.

1 Like
11

So weird.

12

Can you double check that the files were all unblocked properly?

Get-ChildContent C:\ProgramData\PowerShellUniversal -Recurse | Unblock-File

Ensure you run it from an elevated prompt.

1 Like
13

Wait,
I just found the cause.

Since this is a POC, I have no license yet.
I only have 2 users (identities) created.
One with Administrator role,
one with User role.

4.3.2
The script launch works with Administrator role.
And it does work with just User role.

4.3.3
The script will not launch with just User role.
The Execute role needs to be set as well.

Yes, confirmed.
Adding the Execute role to a user (identity) and logging out and back in solves the issue.
It seems 4.3.3 behaves here different than 4.3.2, where 4.3.2 did not need the Execute role on identities to run a script.

14

Mmh.
Maybe that is not yet it.
It seems that the identity with the User and Execute role can access the admin pages.
That was not possible without the Execute role.
I still think something broke in 4.3.3

15

We faced the same issue after upgrading to 4.3.3. To assign less permissions we use accesscontrols for our dashboard role:

$Type = ([PowerShellUniversal.AccessControlType]::Execute)
New-PSUAccessControl -Role 'DashboardRole' -ObjectType 'Script' -Type $Type

With this permission the user can still access the admin console, but can see almost nothing:

image
image2031×1057 70.2 KB

1 Like
16

The user role should never be able to access the admin console by default.

image
image1102×105 2.56 KB

1 Like
17

I’ve opened an issue to track this. I haven’t been able to reproduce the NotAuthorized error so I will need some system logs from someone, if possible.

2 Likes
18

How I experienced the issue:

4.3.2
2 identities set up.
One with Administrator role.
Another with User role.
Behavior:
Administrator can get into admin pages and do all.
User can’t get into admin pages, but can have scripts executed by app web pages.
(invoke-psuscript)

Then update to 4.3.3 via Update-PSUServer -LatestVersion.
Behavior:
Administrator can get into admin pages and do all. (no change)
User can’t get into admin pages.
User CANNOT have scripts executed by app web pages anymore.

Change to fix this:
Added Execute role to User.
User can have scripts executed by app web pages again.

New issue:
NOW User can access admin pages as well, what should not be possible.

adam: what logs do you need_

19

If you provided the execute role to the user, then they will be able to access the admin console.

I realize now why this is happening and should be able to work around this in v4.3.4. I may ask for you to test a nightly build just to verify my assumption is correct.

We have some new controls in v5 that will make this much simpler to configure because scripts just have a role property you can set.

1 Like
20

running the nightly build 4.3.4 and removing the “execute” role from the user, shows the same result as before: “Failed to execute script. Not authorized”

There must be a code change between 4.3.2 and 4.3.3, because this worked in 4.3.2 and still does when I downgrade.