Just Enough Administration (JEA) is a new extension in the Windows Management Framework that allows you to restrict the rights of IT admins in remote PowerShell sessions. In this first part of my JEA series, I will give an overview of the basic concepts.
Follow me:
Latest posts by Anil Erduran (see all)

Jeffrey Snover used the Snowden case to explain the main point about JEA.

Image Credit Jeffrey Snover

Image Credit Jeffrey Snover

Michael Hayden (left) was the director of the National Security Agency (NSA) from 1999 to 2005 when Edward Snowden, a simple admin, revealed thousands of classified NSA documents to the public. Admins have full permissions to all data. Thus, they have all of the keys to the kingdom.

To date, Microsoft has provided many different ways to help organizations have delegated administration for different tasks. The role-based access control (RBAC) model used in a couple of different Microsoft products provides granular level control over resources. Using the RBAC model, we were able to define roles, specify tasks for each role, and assign users to these roles, but even the RBAC has some limitations when it comes to defining only the required tasks for users without giving them administrator rights. The RBAC process usually results in providing more access than is required.

JEA is a new way for organizations to create secured PowerShell remote endpoints to restrict IT admins’ rights as much as possible. Using JEA, admins can only perform required tasks without being given unnecessary administrator rights.

Use cases for JEA ^

I can think of many use cases for JEA:

  • In a service provider scenario, you can delegate restricted rights or limited Hyper-V PowerShell cmdlets to your virtualization admins to manage their tenants. You can also delegate limited access to admins to implement changes or operational tasks on behalf of tenants without exposing sensitive tenant data or requiring them to sign in to the tenant’s environment.
  • It’s a common practice to install DNS server role on the Active Directory server, but that practice also brings some challenges when it comes to the delegation of DNS server operations. If one of your admins needs to run some basic DNS server commands, say Clear-DNSServerCache, you need to grant this user Domain Admin access. Giving full administrative privileges to a user just to clear DNS cache doesn’t sound like a good plan. This user now can create group policies, copy NTDS.dit files, or change the group memberships. Alternatively, you can use JEA and make available only the set of required DNS server PowerShell commands to this particular admin.
  • Front-line support usually needs to access servers for some first-level troubleshooting tasks. JEA is a good way to give them access to particular resources or cmdlets on the target server via PowerShell remote.
  • Instead of giving full Hyper-V administrative privileges to virtualization admins, you can limit the available Hyper-V cmdlets for a custom JEA session to grant privileges only when they really need it.
  • JEA allows you to limit administrative rights for server operators who are responsible for applying critical updates to the servers or doing maintenance work. You can grant specific permissions and also limit the available cmdlets to start or stop services or restart physical servers.
  • You may have a specialized technician group who provides support for executives. To resolve problems on an executive’s computer, these technicians may need to have full PowerShell access to run commands. The main concern here is that they may also run additional unnecessary PowerShell commands to do more on the remote laptop or to access sensitive data. JEA is the answer to this problem.

As JEA is based on PowerShell remoting technologies, let’s have a quick look at the current available PowerShell remote feature.

PowerShell Remoting ^

PowerShell remoting was introduced with PowerShell 2.0. With Windows Server 2012, PowerShell remoting is now enabled by default. This feature configures target computers to receive remote PowerShell commands for local execution. Once your target computers have the configured listeners, you can use the New-PSSession cmdlet with the ComputerName parameter to connect remote endpoints. After that, any command you execute will be run on the target computer.

Enable PS Remote

Enable PS Remote

When you start a session using default Enter-PSSession / New-PSSession commands and execute command blocks using the Invoke-Command cmdlet, you are actually connecting to an endpoint which uses a Session Configuration. You can list all registered Session Configurations in a default Windows installation:

Default Session Configurations

Default Session Configurations

This is where you can have more granular control on PowerShell remote sessions.

Session Configuration is a file that defines local environments for Windows PowerShell sessions that are used by remote users to connect to this computer. You can create custom environments and determine the permissions for remote users on local resources. For instance, you can limit the size of the objects in a session, change the language mode, or specify a set of cmdlets that can be used in that session.

Session Configuration files are used in session configurations to define the environment. They have the file extension .pssc and include all properties of the existing session in a hash table.

Session Configuration File Content

Session Configuration File Content

To learn more about constrained endpoints and configuration files, you can read this article at 4sysops.

How JEA works ^

JEA is an addition to constrained endpoints which adds additional capabilities, like role definitions, and makes it a lot easier to restrict your target session endpoints in PowerShell remote sessions. In short, JEA allows admins to perform administrative tasks without giving them unnecessary administrator rights. JEA started as a bolt-on feature in Desired State Configuration (DSC), but now it’s a separate feature available in Windows Management Framework (WMF) 5.0.

It’s the latest update in Windows Management Framework 5.0 to enable extended role-based control through widely used PowerShell remoting technology. JEA is based on the PowerShell constrained session I mentioned before. It’s fully integrated with PowerShell, which means anything you are currently managing with PowerShell can be managed with JEA as well.

JEA is actually implemented as a PowerShell session endpoint, and this endpoint consists of a Session Configuration file and Role Capability files.

The Session Configuration is a file with a .pssc extension which defines who can connect to an endpoint. Within the .pssc file, you can configure users, groups, virtual accounts (one-time privileged accounts), and general high-level settings.

On the other side, the Role Capability file (.psrc) defines actual responsibilities for each defined user, including which cmdlets or functions can be run or, in short, what an admin can do in a session.

Think of .pssc files as a place where you can define general settings and plus role definitions. You can use the role definition line to associate user roles (security groups) with role capabilities. The example below assigns the security group JEA_CustomGroup to the HyperVOperators RoleCapability.

{'Domain\JEA_CustomGroup' = @{ RoleCapabilities =  'HyperVOperators' }}

Once you have defined who can connect to a PowerShell endpoint with a .pssc file, you have to determine what these users can do. This is where Role Capability files (.psrc) come into play. You then need to define what the HyperVOperators can do in the HyperVOperators.psrc capability file. In that file, you have a bunch of options regarding the restrictions you want to apply.

Native PowerShell commands are more than enough to create JEA endpoints which include Session Configurations and Role Capability files. We will cover the session file and role capability file creation process in the next part of the JEA series.

Getting JEA ^

JEA comes as an update in Windows Management Framework 5.0, and it’s also available in previous Windows Server versions:

  • Windows Server 2016 Technical Preview 5
  • Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2

WMF 5.0 is also available on the following client operating systems:

  • Windows 10 with the November update (1511) installed
  • Windows 8.1, Windows 8, and Windows 7

For more information on WMF 5.0 RTM and download details, please check out the WMF 5.0 release notes overview.

In the next part of this JEA series, we will have a look at creating your first JEA endpoint by following one of the use cases: Assigning appropriate rights to DNS admins.

1 Comment
  1. Jay Adams 5 years ago

    JEA will be handy for situations where sysadmins need delegated cmdlet access, like the use cases mentioned above, but for level 1 help desk, customer support and other non-admin staff, would an automatically generated GUI make more sense? System Frontier does this and works for way more than just PowerShell, as in any command-line scripts or executables that can run on Windows Server. Like CMD scripts, VBScripts, Python, .NET CLI, etc...

    The RBAC granularity is very flexible and can all be configured through the web GUI. You could even put an "easy button" in front of your JEA endpoints to make it dead simple for the areas of your support hierarchy that need that simplicity.

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2022


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account