PowerShell secure remoting with Just‑Enough‑Administration (JEA)

The use of PowerShell remoting has become almost indispensable in any environment Windows Modern, but granting remote access without control is like leaving the data center keys on the table. This is where the game comes in. Just‑Enough‑Administration (JEA), a layer of security that allows you to delegate tasks without giving away administrator rights left and right.

With JEA you can set up very limited remote access points where specific users only run the commands that you have authorized, under accounts with more privileges, but without knowing the real credentials or being able to deviate from the scriptAnd all of this was recorded in transcripts and logs detailed that then allow you to audit who has done what, when and from where.

What is Just-Enough-Administration (JEA) and why does it matter?

Just-Enough-Administration is a PowerShell-based security technology which implements a delegated administration model with the least privilege necessary. In practice, JEA lets you expose remote endpoints where only a closed set of cmdlets, functions, scripts, and external commands defined by you are available.

Thanks to this approach, you can drastically reduce the number of accounts with elevated privileges On your servers, you can use virtual accounts or group-managed service accounts (gMSAs) that execute privileged actions on behalf of standard users. The user logs in with their normal credentials and, through the JEA session, launches commands that are executed behind the scenes with higher privileges.

Another key pillar of JEA is the ability to to precisely define what each role can doRole capability files define which cmdlets, custom functions, external commands, or PowerShell providers are visible. The rest simply doesn't exist for the user: they can't improvise scripts, freely navigate the file system, or access services or processes you haven't specified.

Furthermore, all JEA sessions can be configured to generate full transcripts and audit eventsCapturing commands, parameters, output, errors, user identity, and execution times not only helps meet regulatory requirements but is also invaluable when investigating a security incident or operational failure.

Risks of privileged accounts and how JEA mitigates them

Local, domain, or application administrator accounts with elevated permissions imply one of the most serious risk vectors in any organizationIf an attacker obtains one of these credentials, they can move laterally through the network, escalate privileges, and gain access to critical data, key services, or even take down entire systems.

Removing privileges is not always trivial. A classic example is that of a server that hosts both DNS and an Active Directory domain controllerThe DNS team needs local administrator privileges to troubleshoot DNS service issues, but adding them to the Domain Admins group effectively grants them control over the entire forest and access to any resource on that machine. This is a classic example of sacrificing security for operational convenience.

JEA resolves this dilemma by strictly applying the principle of least privilegeInstead of making DNS administrators domain administrators, you can create a dedicated DNS JEA endpoint that only exposes the cmdlets needed for clearing the cache, restarting the service, reviewing logs, or similar tasks. This allows the operator to perform their job without having to examine Active Directory, navigate the file system, run random scripts, or execute potentially dangerous utilities.

When you configure JEA sessions to use virtual accounts with temporary permissionsThe move is even more interesting: the user connects with unprivileged credentials and, from that session, can execute tasks that normally require administrator rights. This allows many users to be removed from local or domain administrator groups, maintaining operations while significantly hardening the attack surface.

Security concepts that underpin JEA

JEA did not emerge from nothing: It is based on several well-established security principles and models. which give it coherence and robustness. The first is the aforementioned principle of least privilege, which dictates that both users and processes should only have the permissions essential for their functions.

The second major pillar is the model of Role-Based Access Control (RBAC)JEA implements RBAC through role capability files, where you define what a specific role can do within a remote session. For example, a helpdesk role can list services, view events, and restart a specific service, while a SQL Server administration role can only execute cmdlets related to... databases and a little more.

La JEA's technical foundation is PowerShell and its remoting infrastructurePowerShell provides the language, cmdlets, and remote communication layer (WinRM/WS-Management), and JEA adds on top a system of restricted endpoints, virtual accounts, and granular control over which commands are available.

Another important concept is the restricted administration, similar to a assigned access in Windows 11 kiosk modeInstead of giving an operator a full shell, JEA constructs a session where the scripting language is restricted (by default, NoLanguage), the creation of new functions or variables is blocked, loops and conditionals are banned, and only the approved set of cmdlets is allowed to be executed. This severely limits the ability of an attacker who manages to gain access to that session.

Key components: .psrc and .pssc files

At the heart of any JEA deployment are two types of files: role capability files (.psrc) and session configuration files (.pssc)Together they transform a general-purpose shell into a perfectly tailored endpoint for specific users.

In a role capability file you define exactly which commands are available to the roleAmong the most important elements are:

• VisibleCmdlets: list of allowed cmdlets, even being able to restrict parameters.
• VisibleFunctions: custom functions that are loaded in the session.
• VisibleExternalCommands: specific external executables that are accessed.
• VisibleProviders: PowerShell providers (for example, FileSystem or Registry) visible in the session.

The .pssc session configuration files, on the other hand, They describe the JEA endpoint as such and link it to the roles.Elements such as the following are declared here:

• Role Definitions: mapping users or security groups to role capabilities.
• SessionType: where 'RestrictedRemoteServer' is usually set to harden the session.
• Transcript Directory: folder where the transcripts of each session are stored.
• RunAsVirtualAccount and related options, such as whether the virtual account is added to specific groups.

JEA materializes in the form of PowerShell remoting endpoints registered in the systemThese endpoints are created and enabled with cmdlets such as New‑PSSessionConfigurationFile, Register‑PSSessionConfiguration or graphical tools like the JEA Helper Tool, which makes it easier to generate .pssc and .psrc files without struggling so much with the syntax.

JEA session lifecycle

When setting up a complete JEA environment, the process usually follows a series of logical steps that They transform an open remoting system into a strictly governed one.The typical sequence is:

First, you create a security group or several groups that represent the roles you want to delegate (for example, HelpdeskDNS, Web Operators, SQL Operators). Using groups isn't mandatory, but it makes administration much simpler as the environment grows.

Then, one or more are prepared role capability files .psrc These list the allowed actions: cmdlets, functions, scripts, external commands, aliases, providers, and additional restrictions (specific parameters, allowed paths, etc.). Here, for example, you can allow all cmdlets that begin with Get-, restrict Restart-Service to the Spooler service, and authorize only the FileSystem provider.

The following is generated session configuration file .pssc using New-PSSessionConfigurationFile. It defines options such as SessionType = RestrictedRemoteServer, the TranscriptDirectory path, whether virtual accounts are used, and the RoleDefinitions block that links groups to role capabilities, for example, 'DOMAIN\HelpdeskDNS' = @{ RoleCapabilities = 'HelpdeskDNSRole' }.

With the .pssc file already prepared, the endpoint is registered using Register‑PSSessionConfiguration -Name JEASession Name -Path Path\File.psscFrom that moment on, if the available configurations are listed with Get-PSSessionConfiguration, the new connection point will appear ready to receive connections.

Users connect to this endpoint from their computers with Enter‑PSSession -ComputerName Server -ConfigurationName JEASession Name or with New-PSSession and then Invoke-Command. Upon entering, the session automatically applies the restrictions defined in the user's associated role capability.

During the session, PowerShell remoting uses WinRM with encrypted channelsIntegrated authentication (typically Kerberos in the domain) and the firewall rules defined for the service. Underlying this, if RunAsVirtualAccount is enabled, a temporary virtual account is created, added to the necessary groups, and destroyed when the session ends.

Finally, upon closing the JEA session, The audit transcripts and events are saved These logs leave a clear trail of executed commands, results, and user context. They can then be sent to or correlated within a SIEM system for alerts and further analysis.

PowerShell remoting, access control, and hardening

PowerShell Remoting, supported by the service Windows Remote Management (WinRM) The WS-Management protocol allows for the centralized execution of commands and scripts on remote computers. It is a powerful tool for automation, mass server management, debugging, and remote support.

Default, local administrators and members of the Remote Management Users group They can use standard PowerShell endpoints. In many environments, this capability has been used to allow non-administrator users to run remote tasks, which is not inherently dangerous, but if not properly controlled, it opens a significant avenue for abuse.

To strengthen the security posture, a common strategy involves Restrict remote PowerShell access to administrator accounts only. Or, even better, combine that limitation with JEA endpoints that give certain users only the strictly necessary access. This can be achieved through:

• GPOs that define which groups can use WinRM and the default endpoints.
• Firewall rules that allow WinRM only from subnets or management computers.
• Removing the Remote Management Users group from the ACLs of standard endpoints.

Additionally, you can choose to Completely block PowerShell for non-administrator users using solutions like AppLocker. This way, you prevent a standard user from running malicious scripts locally, but still allow privileged accounts to use PowerShell for management and automation tasks.

JEA versus other PowerShell restriction methods

There are several ways to limit what users can do with PowerShell remoting, and JEA fits as a thinner and more flexible option within a range that includes broader approaches such as:

On the one hand, the use of GPO to control who enters the default PowerShell endpointsMicrosoft PowerShell can be restricted to administrators, or even unregistered for everyone, forcing the use of specific endpoints. This is useful for restricting access in a "brute force" manner, but it doesn't solve the granularity problem: whoever gains access can do virtually anything.

On the other hand, there are application control tools such as AppLocker or Software Restriction PoliciesThese methods allow you to deny the execution of PowerShell.exe or pwsh.exe to standard users, either by path, publisher, or hash. This approach is useful for hardening workstations and preventing any user from launching PowerShell, but it presents limitations when you want someone to perform limited administrative tasks from their user account.

Another option is the Constrained endpoints without reaching full JEAYou can create custom session configurations that restrict cmdlets, functions, and modules, but without relying as heavily on the role model, virtual accounts, or structured RBAC that JEA provides. It's a sort of middle ground suitable for simple scenarios, but less scalable in large environments.

JEA combines the best of several worlds: strict command limitation, RBAC, controlled elevated privilege execution, and comprehensive loggingThis makes it the recommended solution when you need to enable PowerShell remoting for non-administrators, but without giving them a complete management environment.

Advanced features: run as another account and log

One of JEA's most powerful capabilities is the execute commands as another, more privileged account without exposing your credentialsThis solves the typical problem of "I'll give you the password for this service so you can do X", which is then never changed and ends up being a huge risk.

Domain scenarios are commonly used Group Managed Service Accounts (gMSA) This allows JEA endpoints to execute actions under a centrally managed service identity, with automatic password rotation and without any operator ever knowing the secret. In other cases, temporary virtual accounts local to the machine are used, created ad hoc when a user connects and destroyed at the end of the session.

From an audit perspective, each JEA session can be configured to generate both PowerShell transcripts and rich event log entriesThe information that is typically collected includes:

• Complete history of commands and parameters entered.
• Output generated and error messages.
• Timestamp of the start and end of the session, as well as its duration.
• Identity of the logged-in user and assigned role/capacity.

If you combine these traces with functionalities of PowerShell Module Logging and Script Block logging via GPOAnd by sending the logs to a SIEM, you gain robust visibility into what's happening on your management endpoints. This is critical for both compliance (SOX audits, ISO 27001, etc.) and incident detection and response.

Typical JEA use cases in real-world environments

JEA shines especially when you need Delegating very specific tasks to teams that shouldn't be administratorsSome very common examples in practice are:

In the technical support area, you can give top-level technicians JEA access to restart services, view event logs, and check process status on servers, but without the ability to install software, modify critical configurations, or access Active Directory. A typical helpdesk role might include cmdlets such as Get-Service, Restart-Service for specific services, Get-EventLog in read-only mode, and some network diagnostic cmdlets.

In operations or development teams, you can configure roles focused on specific tasks such as IIS administration or website maintenanceFor example, allowing access to Application Pool management cmdlets, website restarts, querying logs from a limited directory, and certificate management for specific services, while excluding any ability to restart the entire server or modify security policies.

In hybrid and cloud environments, JEA is frequently used for limit what each team can do about Virtual machines, storage or networksYou can expose endpoints that allow you to manage only the VMs of a department, modify the firewall rules of a specific segment, or manage a specific set of service accounts, keeping access separate from the rest of the infrastructure.

At the same time, JEA fits very well with Privileged Access Management (PAM) strategieswhere privileged sessions are granted temporarily, logged, and attributed to personal identities, avoiding shared accounts and minimizing the risk associated with each privileged action.