Check out the blog post here! PowerShell Universal 2.0
3 Likes
Thank you adam for the release and the fix for the new-psuscript but Get-UAScript still has an issue when no script is there.
so far i had to use a workaround to silence the error using Try/Catch
Ok. Thanks. I’ve opened an issue for this here: Get-PSUScript throws an error when a script isn't found · Issue #201 · ironmansoftware/issues · GitHub
I’m trying to understand the Tag implementation when it comes to roles.
I’ve setup a tag or two, I setup the access control to give specific rights for one of these tags. But how do I make that connection between the tag and a role? I’m not seeing any -tag parameter on the new-psurole function, so I’m a bit lost.
You assign the role to the tag using New-PSUAccessControl: Access Controls - PowerShell Universal
In this example, the ScriptEditor role will have edit and view privileges to anything with the tag HR.
$Type = ([PowerShellUniversal.AccessControlType]::Edit -bor [PowerShellUniversal.AccessControlType]::View)
New-PSUAccessControl -Role 'ScriptEditor' -Tag 'HR' -Type $Type
I see, I misunderstood the role parameter in this case. I’ll adjust and test.
Should the view permission allow access to the details page? My experience is it is not doing that. I end up with the Run button and the Edit button, though because it’s view only rights I can’t actually save or hit ok on the run popup.
An example of what my lab looks like, the tags are fairly self explanatory. This is logged into my test account flagged as an Script Admin
This is the account flagged as Script View
The run and edit buttons being visible is a bug. I’ll get that fixed.
The fact that you can’t see the details page is by design. The idea was that if you assigned View and Execute to a role or tag, then the users would have a really simple view of PSU where they most could just run scripts that were assigned to them without being able to see the details of the script.
I’m certainly open to feedback on this.
From my perspective, I was seeing view permissions as “you can see it all, but you can’t touch”. This likely comes from my experiences in my workplace when Audit folks want to examine code for automated processes we perform from time to time. I usually just hand over the script/code and let them look.
I see where your logic comes from on this, and see it’s a valid way to interpret view permission. Maybe another permission set called Audit? it has the ability to view all data, but no edit/create/delete/run permissions.
Yeah I like that idea. I’ll enhance this a bit so that it’s a bit more granular with an additional permission.