Enforcing Least-Privilege Remote Administration with PowerShell JEA

Just Enough Administration (JEA) lets you grant someone the ability to perform a specific, defined set of administrative actions remotely via PowerShell, without granting them full administrative rights on the target machine at all — a meaningfully different security posture than the common alternative of simply adding a support account to the local Administrators group because it’s the path of least resistance.

The problem JEA specifically solves

A common, risky pattern in many environments: a support team needs to perform a small number of specific tasks (restarting a particular service, clearing a specific log, checking disk space) on production servers, and the practical shortcut is granting that team full local administrator rights so they can do whatever’s needed without friction. This grants vastly more privilege than the actual task requires, and if that support account’s credentials are ever compromised, the blast radius is full administrative control rather than the narrow set of actions actually needed.

What a JEA session actually restricts

A JEA endpoint defines a specific, constrained PowerShell session: only explicitly whitelisted cmdlets, functions, and parameters are available inside it, and the session can run using a temporary, auto-elevated virtual account (or a specific configured identity) rather than the connecting user’s own account — meaning the connecting user never needs standing administrative rights of their own at all, since the actual elevated actions happen through the tightly scoped JEA session’s own identity, not theirs.

Defining a role capability file

A role capability file (.psrc) defines exactly what’s permitted inside a JEA session:

# RestartWebService.psrc
@{
    Author = 'IT Security'
    Description = 'Allows restarting the web application service only'
    VisibleCmdlets = 'Restart-Service'
    VisibleFunctions = 'Get-WebServiceStatus'
}

This specific role capability permits exactly one cmdlet (Restart-Service) and one custom function — nothing else is available inside a session using this role, regardless of what the connecting user might otherwise want to run.

Constraining even the permitted cmdlet’s actual scope

A blanket Restart-Service permission would still let someone restart any service on the machine, which is broader than intended. Parameter constraints narrow this further:

VisibleCmdlets = @{
    Name = 'Restart-Service'
    Parameters = @{ Name = 'Name'; ValidateSet = 'WebAppService' }
}

This restricts the permitted Restart-Service calls to only the specific named service, closing off the ability to use the same broadly-useful cmdlet against anything else on the system — the actual granular restriction that makes JEA meaningfully different from just granting a broad, unrestricted cmdlet.

Defining the session configuration

The session configuration file (.pssc) ties role capabilities to specific users or groups, and specifies the account context the session actually runs under:

# WebSupport.pssc
@{
    SessionType = 'RestrictedRemoteServer'
    RunAsVirtualAccount = $true
    RoleDefinitions = @{
        'DOMAIN\WebSupportTeam' = @{ RoleCapabilities = 'RestartWebService' }
    }
}

RunAsVirtualAccount = $true is a key detail — the session runs using a temporary virtual administrative account created just for this session’s lifetime, rather than either the connecting user’s own credentials or a real, standing service account whose credentials would otherwise need to be separately protected and rotated.

Registering the JEA endpoint

Register-PSSessionConfiguration -Name 'WebSupport' -Path .\WebSupport.pssc -Force

This registers the endpoint on the target server, making it available for members of DOMAIN\WebSupportTeam to connect to specifically — not as a general-purpose remote session, but constrained to exactly the role capabilities defined.

Connecting to and using the constrained session

Enter-PSSession -ComputerName webserver01 -ConfigurationName WebSupport

A member of the authorized group connecting this way gets a PowerShell session where only Restart-Service (restricted to the one named service) and the specific custom function are available — attempting anything else results in the command simply not being recognized, since it was never exposed in this constrained session at all, not merely blocked after being attempted.

Auditing what actually happened in a JEA session

JEA sessions log which specific actions were taken, by which connecting identity, even though the actions themselves executed under the shared virtual account — this combination (broad account sharing at the execution layer, but precise per-user audit logging of what was actually requested) is what makes JEA practical for real support team scenarios without sacrificing accountability for what each individual team member actually did.

Why this is worth the setup effort over just granting admin rights

The setup and maintenance overhead of defining role capabilities and session configurations is real, and meaningfully more effort than adding an account to a local Administrators group — but the security benefit (a compromised support account can only perform the specific narrow actions defined, not arbitrary administrative actions) is exactly the kind of blast-radius reduction that matters most for exactly the accounts most likely to be targeted, since support and help-desk credentials are frequently among the first targets in a real intrusion specifically because they’re expected to have broad access under the common, less careful alternative approach.