PowerGUI Admin Console has the ability to lock down the user interface so you can create custom management consoles specific to job roles (e.g. helpdesk), get these pushed to the corresponding users, and hide from them the functionality which might hurt them (e.g. ability to see the PowerShell code behind the functionality or change anything in the tool.)
See a quick video on the feature here and a related one here.
We want to make it easier to use in the future. So the question is: how granular you want lockdown to be? It can be all the way from item-level (let this user change this node but not the other one) to PowerPack-level to user-level.
I personally like the user-level approach – some people get more functional PowerGUI than others more read-only ones. E.g. if according to your job role you are supposed to be only using PowerPacks from others – you get a locked down version of PowerGUI – regardless of the PowerPacks assigned to you. On the other hand, if you are allowed to change PowerPacks – you can do this. Of course, you might not be able to post your changes to a central distribution point (file share or SharePoint site) but this is a whole different story.
Does this make sense?
Please put your comments to this blog entry and respond to the survey here.
Subscribe by email
Dmitry's Blog: Cloud, PowerShell and beyond 
I’ve already given you my most of my wishlist for lockdown, and I’m sure you already knew how I would vote in the poll, but here’s another feature that would enhance a roll-based security/access lockdown model.
Now that I’m locking PowerGUI down so that it can only do the things that I want to allow the least trustworthy members of my organization or clients to do, it’s likely that those same users won’t have the rights necessary to perform certain actions. Therefore, I would like to see a feature that would allow me to use my non-locked PowerGUI to easily store and manage credentials that I can reference from within my PowerPacks. This would be very helpful to elevate user’s rights, or provide them permissions on systems or in databases that are located in domains which do not trust the user’s domain.
Cheers,
Chris
I’m going with granular. It does not have to be super-granular, but some flexibility is nice (allow Get actions, deny Delete actions for instance).
What is a definite requirement for me is AD integration. I want to be able to define Active Directory groups for specific roles and add people to them. And then use the groups to set the permissions within PowerGUI. Copying around lockdown files is not an “Enterprise Solution” as we’d call it.
Hugo
+1 on the AD integration. Great idea Hugo!
That would go a long way towards making the lockdown much more manageable.
-Chris
Guys,
Please help me understand something:
Why wouldn’t I just assign the actions to different PowerPacks (e.g. “Delete” goes to “Advanced” PowerPack, and “Get” goes into “Advanced” and “Helpdesk”)? Then export both PowerPacks and use GPO to assign “Advanced” to one group of people and “Helpdesk” to another?
Dmitry
The challenge there in my mind is having multiple sets of “source code”, or in this case, multiple PowerPacks.
With your approach, like most people I’m going to start of with a single PowerPack and keep it that way until I need to implement role-specific functionality (e.g. “Delete”). In order to provide that functionality to the Admin role, but not the Helpdesk role I need to fork my code and create a second PowerPack. Now any time I want to add common functionality or fix a common bug I need to update the code in two places rather than just one and I have to test and release two updates instead of just one. This adds time, complexity, and opportunity for error.
In order to avoid forking the code, I could have one source PowerPack and export the role-specific PowerPacks. This approach would probably be preferred, but imagine having 10 or 20 role-specific actions in the Active Directory PowerPack… The export process would be time-consuming and error-prone. While I would have just a single code branch to maintain I still have to test and release two updates because of the opportunity for user error during the export process.
Don’t get me wrong – for a lot of small PowerPacks I don’t see that there is a strong need for role-based security; it’s just that I’m always looking for ways to minimize the amount of time I have to spend maintaining something after I “ship” it.
-Chris
Chris, why would you need to fork the code though? Have a single super-pack, and parts of it would be in one powerpack or another?
This is basically the standard Windows local/global groups model:
1. You have a bunch of PowerPacks you define in PowerGUI and treat these effectively as local groups/roles. You assign them element by element in PowerGUI.
2. Then you export the PowerPacks and use GPO to assign them to end-users (e.g. by groups or OUs)?
Won’t this give you what you need without making you fork the code?
Dmitry
As I’m doing some digging I obviously haven’t wrapped my head fully around the new PowerPack management capabilities.
Let’s take the Active Directory PowerPack as an example and I’m going to walk through what I believe you are saying.
If I want to create a new PowerPack for the Helpdesk role that does not have the “Delete” action for user objects, I do the following:
– select the AD pack in the navigation pane
– right-click and choose Create New PowerPack…
– give the new pack a name of “Active Directory – Helpdesk”
– click Advanced button
– expand Quest…ArsDirectoryObject\Actions
– uncheck “Delete…”
– click OK
Now, each time I export this new PowerPack it will grab all of the current code from the AD pack with the exception of the “Delete” action. Is this correct?
If this is how it works, then I definitely think it’s a workable solution and allows me to focus most/all of my testing on the “super pack” rather than the child packs.
One question – if I add a new action to the “super pack” will it automatically be included in the child packs without having to go back in and add it explicitly?
I currently see one minor drawback to this approach in terms of flexibility – if I need to give a Helpdesk user access to the full AD PowerPack I can change their group membership, but have to wait for group policy (or other config management tool like SCCM) to push down the new version of the pack before the user can delete an object. On the other hand, if I had a single powerpack with role-based security tied to AD groups, once I change the users group membership they might need to exit and restart PowerGUI, but they would have nearly instantaneous access to the delete action.
Given the current capabilities and the scenarios I’m envisioning, I would personally rank role-based security as a P3 (nice to have).
-Chris
Chris,
I actually think we provide the features you just mentioned, maybe apart from that kind of global inheritance…
And maybe we need to make SCCM/GPO deployments easier by accepting powerpack links set in registry…
Dmitry