Just Enough Administration (JEA) is the answer to the "give them local admin so the script works" anti-pattern. A JEA endpoint is a PowerShell session configuration with a role capability file that explicitly lists which cmdlets, parameters and values a connecting user can use. The user runs as a temporary virtual account with the privileges they need, and a transcript of every command lands on disk.
Table of Contents
Why JEA
Three classes of accounts benefit immediately:
- Helpdesk — needs to restart a print spooler or unlock an AD account, never needs to be a Domain Admin.
- Service accounts — most automation needs three cmdlets, not unrestricted shell access.
- Vendors — third-party support that needs to read logs and restart a service.
JEA enforces this in the engine itself, not via "training". The user cannot escape the role even if they try.
The two files: PSSC and PSRC
JEA has two file types:
- .pssc — Session Configuration. Defines the endpoint name, language mode (NoLanguage), run-as account (a virtual account or a group-managed service account) and which roles map to which AD groups.
- .psrc — Role Capability. Lists the cmdlets, functions, scripts and parameters the role can use, and any visible aliases.
A working role capability
A helpdesk role that can restart the print spooler and re-enable AD users:
New-PSRoleCapabilityFile -Path C:\JEA\Roles\Helpdesk.psrc `
-VisibleCmdlets @{
Name='Restart-Service';
Parameters=@(@{Name='Name';ValidateSet='Spooler'})
}, @{
Name='Enable-ADAccount';
Parameters=@(@{Name='Identity'})
} `
-VisibleProviders FileSystem `
-VisibleAliases 'gci','dir','ls'Note the parameter constraint: the role cannot restart any service other than Spooler. That is the entire point.
A working session configuration
New-PSSessionConfigurationFile -Path C:\JEA\Endpoints\HelpdeskEndpoint.pssc `
-SessionType RestrictedRemoteServer `
-RunAsVirtualAccount `
-TranscriptDirectory C:\JEA\Transcripts `
-RoleDefinitions @{ 'CONTOSO\Helpdesk' = @{ RoleCapabilities = 'Helpdesk' } } `
-LanguageMode NoLanguageRegister and connect
Register-PSSessionConfiguration -Name Helpdesk -Path C:\JEA\Endpoints\HelpdeskEndpoint.pssc -Force
# From the helpdesk workstation:
Enter-PSSession -ComputerName srv01 -ConfigurationName HelpdeskInside the session, Get-Command shows only the allowed cmdlets. Restart-Service Spooler works. Restart-Service WinDefend fails with a parameter validation error.
Logging and audit
The Session Configuration's TranscriptDirectory writes a transcript per connection — input, output, and the virtual account name. Combine with ScriptBlock logging for the second source of truth. The two together are evidentiary: you can show exactly what each helpdesk session ran.
Common patterns
One endpoint per persona. Helpdesk, BackupOperator, SqlOperator. Resist the urge to merge them.
Run as gMSA for service automation. Use -RunAsVirtualAccount for interactive helpdesk; for unattended scripts, bind to a Group Managed Service Account so the audit trail is meaningful.
Source-control the PSRC and PSSC. They are text files. Treat them like infrastructure code.
Designing role capabilities for real teams
The example role capability file in the introduction is the bare minimum. A production JEA endpoint typically serves three to five distinct roles, each scoped to a single team's job-to-be-done. The trick is to think in verbs, not modules.
Map a helpdesk role from real tickets
Pull the last 90 days of tier-1 tickets, group them by action ("reset password", "unlock account", "restart print spooler"), and write one allowed cmdlet entry per action. Anything not on the list is denied — including Get-Help, which surprises new operators.
@{
ModulesToImport = 'ActiveDirectory','PrintManagement'
VisibleCmdlets = @(
@{ Name='Unlock-ADAccount'; Parameters=@(@{ Name='Identity' }) },
@{ Name='Set-ADAccountPassword'; Parameters=@(@{ Name='Identity' },
@{ Name='Reset' },
@{ Name='NewPassword' }) },
@{ Name='Restart-Service'; Parameters=@(@{ Name='Name';
ValidateSet='Spooler' }) }
)
VisibleFunctions = 'Get-Help','Get-Command'
VisibleAliases = 'cls'
}
Notice how Restart-Service is locked to a single service name with ValidateSet. The operator cannot accidentally — or deliberately — restart WinDefend.
Virtual accounts vs group-managed service accounts
JEA sessions can run as a virtual account (local admin on the target, exists for the lifetime of the session) or under a group-managed service account (gMSA, domain identity with auto-rotated password). Use virtual accounts for single-host operations and gMSAs when the role needs to talk to other systems with a stable identity.
# Session config that uses a gMSA
New-PSSessionConfigurationFile `
-Path C:\jea\helpdesk.pssc `
-SessionType RestrictedRemoteServer `
-RunAsVirtualAccount $false `
-GroupManagedServiceAccount 'CORP\jea-helpdesk$' `
-RoleDefinitions @{
'CORP\Helpdesk-Tier1' = @{ RoleCapabilities='HelpdeskTier1' }
}
Transcripts and post-hoc auditing
Every JEA session writes a transcript to the path you specify. These are the gold-standard evidence trail: every command, every parameter, every output line, attributed to the calling user even though the action ran as the virtual account. Ship the transcript directory to immutable storage and you have an audit log even an attacker with admin on the host cannot edit.
Common pitfalls
- Allowing wildcards in cmdlet names.
Get-*inVisibleCmdletsopens far more surface than you think — includingGet-Processwith-IncludeUserName, which leaks information. - Forgetting to register on every node.
Register-PSSessionConfigurationis per-host. A new server in the fleet without the JEA endpoint silently falls back to a regular admin session. - Granting role membership to nested groups you do not control. If
Helpdesk-Tier1nestsDomain Users, your JEA endpoint is a privilege escalation path. Audit group membership weekly. - No language mode constraint. A role that allows arbitrary script blocks is not a constrained role. Set
LanguageMode='NoLanguage'in the session configuration unless you have a specific reason not to. - Skipping the dry run. Always test a role with
Test-PSSessionConfigurationFileand a non-admin account before rolling out. Many "it works" tests are run by domain admins, which bypass JEA entirely.
Operator-ready JEA in 60 minutes
The fastest defensible JEA deployment serves one role on one host. Nail that, then expand. Below is a one-hour checklist that produces a working endpoint a tier-1 helpdesk operator can connect to.
- Minute 0–10 — install module. On the target server,
Install-Module Microsoft.PowerShell.JEA -Scope AllUsers. CreateC:\jea\modules\Helpdesk. - Minute 10–25 — role capability file. Run
New-PSRoleCapabilityFile -Path C:\jea\modules\Helpdesk\RoleCapabilities\HelpdeskTier1.psrc. Edit to allow onlyUnlock-ADAccount,Set-ADAccountPasswordwith-Reset, andGet-ADUser. - Minute 25–40 — session configuration. Create
C:\jea\helpdesk.psscwithSessionType=RestrictedRemoteServer,RunAsVirtualAccount=$true,LanguageMode=NoLanguage,TranscriptDirectory='\\logs\jea'. - Minute 40–50 — register.
Register-PSSessionConfiguration -Path .\helpdesk.pssc -Name Helpdesk -Force. Restart WinRM. - Minute 50–60 — verify. From a workstation with a non-admin test account:
Enter-PSSession -ComputerName srv -ConfigurationName Helpdesk. Confirm only the three allowed commands appear inGet-Command, and thatcmd.exereturns "term not recognised".
Once the first endpoint is solid, replicate by GPO startup script that copies the role capability + session configuration files and runs Register-PSSessionConfiguration. Idempotent rollout to 100 servers takes another hour; the role design is the time-consuming part.
Plan a quarterly review of the role capability file against the actual ticket volume. If a command was used twice in 90 days, document the use case; if it was never used, remove it. Roles drift toward over-permissive without that discipline.
Long-term maintenance: keeping JEA honest as your fleet grows
JEA's biggest failure mode is not a bug — it is benign neglect. A role file shipped two years ago accumulates exceptions, the operators who understood the design have moved teams, and the next audit finds a "constrained" endpoint that effectively grants local admin. Three small habits prevent the drift.
The first habit is a quarterly role review. Pull every role capability file, list every command it allows, and cross-reference against the helpdesk ticket queue. A command that has not been used in 90 days has no business being in the role. Removing it is a five-minute change with negligible risk; leaving it in is the seed of every future privilege-escalation story.
The second is transcript sampling. JEA endpoints write a transcript of every session. Sample five sessions per role per week, read them end-to-end, and look for patterns: an operator who repeatedly tries a denied command (the role is too narrow), an operator who never uses three of the allowed commands (the role is too wide), an unexpected source IP (account compromise). The reading takes 20 minutes and replaces a much longer audit cycle.
The third is role-membership reconciliation. The Active Directory group that gates each role drifts as people change teams. Run a weekly script that emails each role owner the current membership list with last-login dates. Owners spot the stale account immediately; without the email, nobody looks until an auditor asks.
For organisations with more than a handful of roles, treat the role capability files as code. Store them in source control, require pull-request review for changes, and run a CI check that fails on any cmdlet allowed without a parameter set. The discipline costs a few minutes per change and eliminates the entire class of "we shipped admin to half the fleet by mistake" incidents.
FAQ
Does JEA work over PowerShell SSH?
The constrained session works once connected, but the endpoint registration is WinRM-only.
Is JEA enough on its own?
No. Combine with WinRM hardening, ScriptBlock logging and AppLocker for the full posture.
Can JEA users escape via .NET?
LanguageMode = NoLanguage blocks [System.IO.File]-style escapes. Always set it.
How do I distribute the PSRC files to a fleet?
Drop them in C:\Program Files\WindowsPowerShell\Modules\<ModuleName>\RoleCapabilities via DSC or GPO file copy.
Can JEA replace LAPS for local admin access?
Different problems. LAPS rotates the local admin password; JEA limits what an admin can do once connected. Use both — LAPS for break-glass, JEA for daily operations.
What happens during a forest functional level upgrade?
Nothing on the JEA side. Role capability and session configuration files live on the target host's filesystem and are unaffected by AD schema changes.
How do I test a role as a non-admin without disturbing production?
Spin up a Windows Sandbox or a throwaway VM, register the same session configuration, and connect with a test account that has the role's group membership. The sandbox approach gives you a clean state in seconds.
Does JEA work over PowerShell-over-SSH?
Partially. The Register-PSSessionConfiguration mechanism is WinRM-specific. SSH-based remoting honours the script execution policies but not the JEA role capability files. For SSH, achieve a similar effect with sudoers and constrained shells.
