I installed what was served just by running
Install-PSUServer
and I got 5.0.4
1 Like
I got it with 5.0.4 so there’s still no fix as of 5.0.4 other than what you’re saying with the tokens.
Try this:
$script=Invoke-PSUScript -Script scriptvars.ps1 -Wait -TrustCertificate
1 Like
What is the root context of these scripts? Schedule? App? API?
Are those authenticated? It should be passing authentication context down through those systems. In the case of schedules, it has no authentication context, hence why app tokens work. This was a change to the security model in v5.
That said, I think we need to provide some sort of configuration to reduce how strict this model is because it does add a lot more complexity than was in v4.
The problem in v5 is that, based on your privileges, you could, for example, have access to create or edit scripts but not apps. If you have unfettered access to the cmdlets in your scripts, it doesn’t really matter what your privileges are because you could just elevate past any privileges by adding cmdlet calls to your scripts. We use the user’s current context to determine what they have access to but if there isn’t a user context, then it has no access.
Thank you.That changed the error to:
On my dev server I just have 2 identities,
chief with admin role
and
dexcon with user role
I tried logging in as admin, but the error remains the same.
One of the scripts I had it happen on is this one that runs other scripts to download device configs nightly (partially redacted for privacy/security reasons):
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '20998' -HuduCompanyID '5' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3855' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '20923' -HuduCompanyID '44' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3776' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '13219' -HuduCompanyID '11' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '2848' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '12132' -HuduCompanyID '14' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '2725' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '8159' -HuduCompanyID '14' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '2088' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '12263' -HuduCompanyID '22' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3805' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '14160' -HuduCompanyID '22' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3759' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '48300' -HuduCompanyID '22' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '4018' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '14106' -HuduCompanyID '5' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3896' | Wait-PSUJob -Timeout 60
Invoke-PSUScript -Script "Hudu\DownloadPaloAltoConfig.ps1" -HuduDeviceID '10358' -HuduCompanyID '16' -PaloAltoDeviceIP 'redacted' -HuduCredentialID '3858' | Wait-PSUJob -Timeout 60
The main script is run as a scheduled job every night at midnight, with the following settings:
I’ll give the App Token a shot in a few days when I can attempt the upgrade to 5.0.x again.
I wholeheartedly agree. The new process - while more secure - adds way more complexity and administrative overhead to the process (especially for setups that have loads of scripts that they would now have to modify accordingly, along with creating more App Tokens just for this purpose, etc.).
As for the workaround of using Connect-PSUServer with an App Token, I think official documentation needs to be created explaining the gRPC change with examples of how to get past it rather than just saying “this changed” and wishing people good luck at figuring out how to interpret it.
Sounds good. Thanks for the feedback. We do have documentation about the new authentication and authorization here.
Feel free to provide any feedback on the documentation. We also linked to that documentation in the breaking changes:
That said, I’ll make it more clear in the documentation with the exact error message you may see if you are running into this.
2 Likes
The Module document does have more info about this, as you said - thanks.
I think it would be beneficial to have a way for users to either:
- Disable this new method altogether (i.e., go back to how it worked in v4), but I’m not sure that would be possible or easy to do
- Set the
Connect-PSUServersettings globally rather than having to do it per script (thus potentially requiring multiple scripts to be modified and causing a lot of overhead). If one could just be defined in the customizedappsettings.jsonor something, and then everything can just default to use that unless overridden by the user via a script modification, or something like that, that would solve all of this headache.
It would be pretty easy to disable the enforcement via an appsettings.json change.
2 Likes
Thanks. I got my stuff back working.
1 Like
I may not be understanding the reasons for making this security change, my own assumption would be that it’s mainly to prevent injection-style attacks where user input could potentially be exploited to run cmdlets that affect the management.
From that perspective, I could personally see that:
- Triggers get excluded from the security model. (These scripts are unlikely to be injected as input is known beforehand, except for potential pipeline/host output from the job if retrieved)
- Possibility of configuring the security model on a per-environment basis if that’s feasible in terms of performance (This would allow a clean upgrade without changing scripts as you can simply point the scripts to that environment)
- Maybe the option of defining scripts with a pre-configured list of cmdlets (á la JEA), not sure if that’s feasible or scalable but then you could enforce app/script/api cmdlets that way as well
with that feedback out of the way, I’ve been looking into my scripts again after getting our triggers working, to see why they don’t work, most of our scripts runs as a specific identity/credential, but it seems that none of these work on the new Windows PowerShell and PowerShell environments as they simply time out if I have a credential specified, only the actual executable one (i.e. the one pointing to pwsh.exe), am I correct in assuming that running as a specific windows identity is not supported for these agent environments?
It’s really not about injection and more about different levels of permissions for admins in the console. That said 5.0.5, we added a setting to revert this behavior back to the v4 permissive model.
In terms of the scripts not running as other user’s properly, there shouldn’t be any limitation on the agent environments. I’ll open an issue for this.
Try to upgrade from 4.3.4 to 5.0.4 and got the following issues:
Apps not show’s at all (app tab is empty), in the appdata, I can see my dashboard and the dashboard configuration file is also seems valid.
Scheduled task, Slow responsiveness, after edit any scheduled task it being deleted.
Modules edit from dashboard, I cant edit the modules directly from the psu.
Sorry to poke again on that topic, low priority, I can use scripts with auth tokens.
On my test system running 5.0.5 I have set:
“Api”: {
“Url”: “http://localhost:5000”,
“SecurityModel”: “Permissive”
}
I have 2 users, an admin (adminuistrator role) and a user (user role).
The app is set to administrator and user role.
I have 2 pages, identical code, both calling a script.
Only difference:
One is using a token, the other not.
The one using the token works for the admin and for the user.
The one using
$script=Invoke-PSUScript -Wait -name eav.ps1
works for the admin but gives an 403 error for the user.
(btw, it has to be -name, with -script instead it will fail as well)
When I add the “execute” role the user, logout and back in, the script will run.
This very much looks like the issue I had with 4.3.3, after upgrade from 4.3.2, and then fixed again in 4.3.4.
So the certificate trust that was also an issue in the triggers, is still happening on scripts themselves, even despite going back to the permissive model.
Using “-TrustCertificate” works, but it isn’t actually a self-signed certificate, and it’s not one where the SAN/Subject should be confused, like was happening with triggers.
One of my scripts that use Set-PSUCache has a pretty sizable request (~4500 AD user objects with two supplemental attributes), this is failing, after working around the above, with the following errors:
Failed to connect to server with gRPC. Attempting gRPC-Web.gRPC requires extra configuration on .NET implementations that don't support gRPC over HTTP/2. An HTTP provider must be specified using GrpcChannelOptions.HttpHandler.The configured HTTP provider must either support HTTP/2 or be configured to use gRPC-Web. See https://aka.ms/aspnet/grpc/netstandard for details.
Status(StatusCode="ResourceExhausted", Detail="Received message exceeds the maximum configured message size.")
@adam commented on one of my posts, about Permissive mode not working correctly with APIs and apps, and said it’ll be addressed in PSU 5.0.6, so maybe it’s also not working correctly with scripts.
There is also a fix coming for this size limitation issue as well. It’s currently set at 4MB but will be unlimited in 5.0.6.
We recently updated from v4 to v5 and I’m having an issue with getting the identity of the caller in a script started by an Invoke-PSUScript call in a dashboard.
Currently have the following code to invoke the script which works.
Invoke-PSUScript -Script (Get-PSUScript -Name "Script.ps1") -UserName $SomeInput (and some other script parameters) | Tee-Object -Variable job | Wait-PSUJobThe problem is when trying to get the identity of the caller in “Script.ps1” by calling
$UAJob.Identity.Nameit just returns “System” whereas in v4 I would get the user that triggered the invoke in the dashboard.
Currently have TrustCertificate: true and SecurityModel: Permissive in appsettings.json
I would really prefer to have this information available so I don’t have to pass it to the script manually and this worked in v4.