Delegate a PowerShell task through JEA—not a broad administrator group

Bottom line: PowerShell Just Enough Administration (JEA) can let a nonadministrator perform a defined privileged task through a constrained remoting endpoint. The security boundary is created by the endpoint access list, role capabilities, allowed commands and parameters, and run-as identity. A loosely designed command can return broad administration through another route.

Source fact: what Microsoft documents

Microsoft’s JEA overview describes JEA as delegated administration for PowerShell-managed systems. JEA can use temporary virtual accounts or group-managed service accounts to perform privileged actions for connecting users, limit which cmdlets, functions, external commands, and providers they can use, and create transcripts or logs of commands executed in the session.

Microsoft organizes the implementation around role-capability files and session configurations. Role capabilities define what a role can run. Session configurations define who may use the endpoint, which roles apply, and the run-as behavior. The associated Microsoft security guidance warns that the chosen run-as identity determines what the endpoint can ultimately do and that JEA does not protect a system from users who already have administrator rights outside the endpoint.

What the source does not establish

JEA does not make an unsafe command safe. A permitted script, wildcard parameter, provider, external executable, or command that accepts arbitrary input can become an escape path. Transcription is not guaranteed to capture secrets safely or replace protected event logging. A JEA endpoint does not remove existing direct local, domain, RDP, API, or application privileges unless those are separately revoked.

Applicability questions

• What exact administrative outcome must the operator achieve?
• Which cmdlets, functions, parameter values, providers, files, registry keys, services, and remote systems are truly required?
• Should the run-as identity be a virtual account or gMSA, and what effective privileges does it have locally and remotely?
• Who can connect to the endpoint, edit its files, or register a new endpoint?
• Where are transcripts and events stored, and can operators alter or read sensitive records?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Start with one observable job and write its required commands, parameters, targets, expected outputs, and prohibited actions.
2. Create the least-capable role and run-as identity. Avoid wildcards, arbitrary script blocks, unrestricted paths, and general shells.
3. Test as the delegated user for intended success and escape attempts through parameters, aliases, functions, executables, providers, and remoting.
4. Remove the broader administrator membership that JEA is meant to replace only after the endpoint and recovery path are proven.
5. Review endpoint ACLs, role mappings, files, transcripts, and use on a fixed cadence.

Verification and evidence

• Preserve session configuration, role-capability files, hashes, ACLs, run-as identity, and change approval.
• Record allowed and denied command tests from an actual delegated account.
• Verify transcripts and events reach a protected location and do not routinely expose secrets.
• Reconcile JEA users with local, domain, application, and remote-administration privileges.

Official references

• Just Enough Administration — Microsoft