PowerShell is a powerful scripting language that can be used to manage many tasks in an organization. One of the most popular PowerShell cmdlets is the Get-Command. This cmdlet allows you to get information about a specific command or set of commands in your system. You can also use this cmdlet to manage objects and files in your system. One common use for the Get-Command cmdlet is to delegate tasks to other members of your team. For example, you might want to create a script that prints out all the users in your organization and assigns them unique passwords. You could also delegate tasks to other members of your team so that they can do their work without having to know every detail about your system. You can use the Get-Command cmdlet with just enough administration by using aliases. Aliases are special characters that are used instead of the full name of a command or set of commands. Aliases allow you to group related commands together and make them easier to find and use. For example, you might want to create a script that prints out all the users in your organization and assigns them unique passwords. You could also alias this script “passwords”. The alias “passwords” would print out only those users who have unique passwords assigned by you. You can also use aliases when you want to group related commands together so that they are easier to find and use. For example, if you want all the scripts in your project named “scripts”, then you would create an alias for “scripts” called “all”. This alias would include all the scripts in your project, regardless of their namesakes (the scripts named “scripts” in our previous example).
Have you ever wanted to delegate a task, but found that the permissions needed can be too risky to hand out? Or, have you wanted to lock down things like group creation in AD to enforce naming conventions of groups?
JEA can help you with just that and a lot more. In this article, we’re going to walk through how you can delegate your already created scripts with PowerShell 5.1.
What Is JEA?
JEA is a PowerShell solution from Microsoft that can restrict users (and administrators) to only be able to perform specified tasks in a specific PowerShell session, even if they require local admin on the said resource. In addition, you can be extremely specific. Only the commands you specify can be executed, you can enable only specific parameter values and parameter values that match a specific pattern.
For example, you can enable Servicedesk to only restart a specific service with Restart-Service, or only add groups to AD according to a specific naming convention. You can do all of this without giving them explicit permissions on a server or in AD. It’s a tool that can save you a tremendous amount of time and secure your environment. Let’s get started by wrapping our script into a function.
Step 1: Creating a Function Out of Your Script
The first step if you’ve not already done so is to make a function out of your script. This is quite easy, assuming that you already have your parameters set up. Below, I’ve wrapped my simple script “New-FolderAndShare” into a function:
You validate the parameters with ValidatePattern in the function, but if this were a part of a module you could to that in the RoleCapabilities file instead with VisibleFunctions.
Making the script a function gives us greater control of what parameters are allowed in JEA, and makes it easier to export.
Step 2: Creating RoleCapabilities
The RoleCapabilities file decides what a specified role (defined in the next step) is allowed to do. This includes what commands they are allowed to run, what parameters they can use, and what modules to import.
While RoleCapabilities can be created manually, it’s recommended to use the New-PSRoleCapabilityFile command built into PowerShell 5.1. It’s also in this file that you’ll load in the function that we created in the previous step.
The follwing script creates a file called FileShareCreator.psrc and adds the New-FolderAndShare function (that needs to be loaded into the current session):
Utilize Get-Command to fetch the function in the FunctionDefinitions-parameter. You can also add the raw script with parameters.
You also specify how you are allowed to use the function in the VisibleCmdlet parameter. You do this by specifying the name of the function and its parameters together with a regular expression.
With this, you can create an extremely granular control of what a user can and can’t do. But there’s one caveat to making this work—you need to add the psrc-file into a module.
Step 3: Creating a Module for the RoleCapability File
It’s time to create a module that you can put your role capabilities into. JEA finds the RoleCapabilities by the psrc files name without its extension, so avoid duplicates if you’re going to create more role capabilities later on.
The following script is a modified version of what you find in the Official JEA documentation. It creates a new module in the module directory, creates the necessary files and folders needed, and copies the psrc file that you created in Step 2 into it:
You have now created a role capability and a function so that you can use it in JEA. What’s left do now is to create a PowerShell Session Configuration to map AD groups to the roles you just created.
Step 4: Defining Roles
In this step, you’re going to create a PowerShell Session Configuration file that defines what roles are going to be assigned what Capabilities (from the .psrc file we created in Step 2).
You’re going to create the AD group and transcript directory here as well.
Step 5: Creating a PowerShell Session
In this step, you will read in the SessionConfiguration.pssc file that you created in the previous step. This enables the members of JEA_FILESHARE_CREATOR to connect via PowerShell to the server:
You’re done! Add a user to JEA_FILESHARE_CREATOR that does not have access to the server through normal means and try it out as that user by typing:
You can now run the command as a temporary local administrator that’s locked down and only enabled to run a few default commands (visible with Get-Command while in session) and the New-FolderAndShare function that added in the Role Capabilities file.
If you want to see the account that’s created temporarily, add VisibleExternalCommands @(‘c:windowssystem32whoami.exe’) to your RoleCapabilities parameters in Step 2. You can run whoami and see the local administrator name:
Summary
Using JEA can be an awesome and easy way to delegate out tasks and secure your environment. This does not only include your own scripts but built-in modules and installed modules as well. Even though JEA can be a great value-add, be careful! You can create a great risk to your environment if you delegate the wrong commands or specify the wrong parameters to unexpected individuals.
Want to learn more?
Microsoft’s Documentation on JEA Getting started with Just Enough Administration (JEA) by Jason Helmick [YouTube]
