Swimming in the Deep End: Taking a Deeper Look at the Use Cases of JEA

Use Cases of JEA

Reintroducing JEA

We are revisiting JEA to take a closer look at some key points of use and to go over areas I feel are disadvantages. You can review my previous post, but here are a few key points:

• Just Enough Administration, part of the Windows Management Framework 5.0—is a technology that helps enforce information security protections by restricting IT administrative rights.
• JEA can be used to allocate Administrative privileges to special users and user groups (via a session) to perform tasks and special commands via PowerShell as specified by an Administrator.

A main issue that JEA usage faces in the workplace is that many administrators are still accustomed to using GUIs rather than the Windows PowerShell command-line shell and scripting environment. PowerShell uses cmdlets to perform common system administration tasks, such as managing the registry, services, processes, and event logs. Learning these commands to run the proper cmdlets may pose a learning challenge.

Deep Dive – Testing and Implementation of JEA

Throughout my testing and implementation of JEA in a private network I was able to discover additional reasons why JEA is such an underused but powerful tool.

My testing was on a very large scale, and a benefit I discovered was that the implementation on a larger environment would still be manageable due to implicit remoting. Implicit Remoting works by importing cmdlets from previous or existing PowerShell sessions. Per Microsoft, “You can optionally choose to prefix the nouns of each proxy cmdlet with a string of your choosing to distinguish which commands are for the remote system. A temporary script module containing all of the proxy commands will be created and can be used for the duration of your local PowerShell session.” So, functions such as Tabbing for completion, variables, manipulation of objects and even use of local scripts can easily be automated with implicit remoting.

An issue I had with JEA is the added work for an admin to specifically manage ongoing sessions and accounts created for JEA use. For limited-time uses I found it annoying to have to keep track of multiple test groups and sessions. If the naming convention was not correctly specified it could be easily confused with an already permanent group being utilized.

Thankfully, I found out that JEA has a complementary technology called JIT – Just In Time. This technology allows you to assign users to privileged groups for a limited duration rather than on a semi-permanent basis. This can help a lot with managing JEA implementation in a very large environment.

JEA can also be used in automation systems and in user applications. By using Invoke-Command for simple one off tasks or for building a C# app for example, you can create a PowerShell runspace that connects to a JEA session by specifying the configuration name in a WSManConnectionInfo object. I plan to test this in the future.

Let’s Talk JEA Security

JEA has a more in-depth capacity regarding security.

At the base level for security with JEA is Virtual Accounts. Virtual accounts are temporary local accounts that are created for the connecting user for the duration of their JEA session. It is destroyed once the session closes. By default, virtual accounts belong to the local administrators group on the machine. This gives them full rights to manage anything on the system, but no rights to manage resources on the network.

Another security method JEA proposes is Group Managed Service Accounts (gMSAs). GMSAs are used when the JEA session requires specified network resources. Per Microsoft, the best example of this use case is “a JEA endpoint that is used to control access to a REST API hosted on a different machine. It is easy to write functions to make the desired invocations on the REST API, but to authenticate with the API you need a network identity. Using a group managed service account makes the “second hop” possible while still having control over which computers can use the account. The effective permissions of the gMSA are defined by the security groups (local or domain) to which the gMSA account belongs.”

Also, when looking at regular PowerShell remoting endpoints, we see that JEA endpoints have separate ACLs (Access Control List) set in WinRM configuration. These WinRM ACLs can be configured to allow all users mapping to one or more roles access or no access to the endpoint.

JEA is Under-Utilized

In conclusion, JEA is highly under-utilized and has the potential to change the way Admin rights are allocated, blanketing a network with some additional security. However, general ease of use and learning curve for those unfamiliar with PowerShell and cmdlets syntax remain a concern. I do hope that the developers continue to add more functionality and documentation to solidify the need for such a tool.

Helpful References

• Just Enough Administration Windows PowerShell security controls help protect enterprise data.
• JEA Github
• JIT & JEA Introduction

VerSprite Security Operations

The focus of SecOps services revolves around security engineering for Cloud and On-Prem environments (which includes Managed Hosting or CoLo environments).

Our group offer a range of managed security services aimed at providing a service that addresses client challenges across vulnerability management, threat analysis, technical remediation, system auditing/ hardening, and more. VerSprite’s SecOps →