JEA, Constrained Language, Application Control, and Least-Privilege Automation

1. Least privilege is an architecture rule

If a deployment task only needs to restart one service and read one log, giving its automation identity unrestricted administrator rights creates unnecessary blast radius. Least privilege means granting only the capabilities required, for only the required scope and duration.

PowerShell can participate in this design through constrained remoting endpoints, JEA role capabilities, operating-system/application-control policy, service/workload identities, and explicit command interfaces.

2. JEA exposes an administrative API instead of an admin desktop

Just Enough Administration (JEA) is a PowerShell remoting technology for Windows that lets administrators publish constrained endpoints. A caller connects to the endpoint and receives only the commands/resources defined for that role instead of general administrative PowerShell.

flowchart TD
    U["Operator / automation identity"] --> E["JEA endpoint"]
    E --> R["Role capability"]
    R --> C["Explicit commands"]
    C --> S["Privileged system action"]
    E --> T["Transcripts / audit"]
  

Current Microsoft documentation also makes the platform boundary explicit: Linux/macOS PowerShell cannot create constrained JEA remoting endpoints.

3. Role capabilities define what a JEA user can run

A role capability is a .psrc PowerShell data file that lists visible cmdlets, functions, providers, and external commands. Security depends on being specific: broad wildcards or helpers that themselves expose arbitrary execution can defeat the purpose.

# Windows/JEA design example — inspect the command if available.
if ($IsWindows -and (Get-Command New-PSRoleCapabilityFile -ErrorAction SilentlyContinue)) {
    Get-Command New-PSRoleCapabilityFile |
        Select-Object Name,Source,Version,Parameters
}

# Production design principle:
# VisibleCmdlets = @('Get-Service')
# Add only the exact commands/parameters required for the role.

4. Session configurations bind identities to roles and run-as behavior

A JEA endpoint is registered from a .pssc session configuration. It determines who can connect, which roles are assigned, what identity performs the underlying work, transcript settings, and other endpoint restrictions. Registration is an administrative operation and can affect remoting services, so this lesson stays inspect-only unless you have an isolated Windows lab.

if ($IsWindows -and (Get-Command Get-PSSessionConfiguration -ErrorAction SilentlyContinue)) {
    Get-PSSessionConfiguration |
        Select-Object Name,Permission,RunAsUser,PSVersion
} else {
    [pscustomobject]@{ JEAEndpointCreation='Windows-only'; LabMode='Concept/inspection' }
}

5. Run-as identity determines the real privilege behind the endpoint

JEA separates the caller identity from the identity used to perform allowed actions. Microsoft recommends virtual accounts for many JEA scenarios because they are temporary accounts created for the session and can receive carefully scoped local privileges. The endpoint is only as safe as its role definitions and run-as privilege.

$jeaDesign = [pscustomobject]@{
    Caller              = 'HelpDesk-Operator'
    Endpoint            = 'ServiceMaintenance'
    VisibleCapabilities = @('Read service state','Restart approved service')
    RunAsModel          = 'Virtual account / approved managed identity pattern'
    Forbidden           = @('Arbitrary shell','Filesystem-wide write','Credential export')
}
$jeaDesign

6. Constrained Language is a language restriction, not a role definition

PowerShell supports language modes including FullLanguage, RestrictedLanguage, ConstrainedLanguage, and NoLanguage. ConstrainedLanguage limits access to sensitive .NET/COM APIs and certain language capabilities. Under system application control on Windows, PowerShell automatically enters ConstrainedLanguage for untrusted code.

Do not confuse this with JEA. JEA is an endpoint/role capability model; JEA sessions commonly restrict direct language use (for example through NoLanguage) while exposing selected commands. Manually setting $ExecutionContext.SessionState.LanguageMode is useful for experimentation, but it is not a durable security boundary by itself.

[pscustomobject]@{
    CurrentLanguageMode = $ExecutionContext.SessionState.LanguageMode
    IsWindows           = $IsWindows
}

# Do not treat this experimental assignment as a security deployment:
# $ExecutionContext.SessionState.LanguageMode = 'ConstrainedLanguage' 

7. Application control gives Constrained Language a system trust anchor

Current PowerShell documentation states that ConstrainedLanguage should be used with a system application-control policy to provide a meaningful lockdown boundary. On Windows, PowerShell detects AppLocker and App Control for Business (historically known as Windows Defender Application Control/WDAC) and applies additional restrictions to untrusted code.

Application control decides which code is trusted to run. PowerShell then adjusts language behavior according to that system policy. This is stronger than asking a script to restrict itself.

$controlLayers = @(
    [pscustomobject]@{ Layer='Identity'; Question='Who is running the automation?' },
    [pscustomobject]@{ Layer='Application control'; Question='Which code is trusted to run?' },
    [pscustomobject]@{ Layer='PowerShell language mode'; Question='Which language capabilities are available?' },
    [pscustomobject]@{ Layer='JEA role'; Question='Which administrative commands are exposed?' }
)
$controlLayers

8. Service accounts and managed identities reduce human-secret reuse

Automation often runs without a human present. A dedicated service account gives ownership and permissions to the workload rather than sharing an administrator's credential. Cloud/workload managed identities go further: the platform can issue short-lived tokens to an authenticated workload, reducing long-lived secrets.

The design questions are the same across implementations: what is the identity, where can it authenticate, what actions can it perform, how are credentials/tokens rotated, and who can change the policy?

$identityChecklist = [ordered]@{
    DedicatedIdentity     = $true
    InteractiveLogon      = 'Disabled unless explicitly required'
    Privileges            = 'Only deployment-specific permissions'
    CredentialLifetime    = 'Prefer short-lived / managed where available'
    SecretInSource        = $false
    AuditIdentityIncluded = $true
}
[pscustomobject]$identityChecklist

9. Separation of duties limits unilateral high-impact change

Least privilege is stronger when paired with separation of duties. The person who writes deployment code need not be the person who approves production release; the CI identity that builds artifacts need not be allowed to alter production policy; the JEA role administrator should be tightly controlled because editing a role capability can effectively expand privilege.

$duties = @(
    [pscustomobject]@{ Duty='Author'; Capability='Propose automation code'; ProductionAdmin=$false },
    [pscustomobject]@{ Duty='Reviewer'; Capability='Approve change'; ProductionAdmin=$false },
    [pscustomobject]@{ Duty='Release identity'; Capability='Execute approved deployment API'; ProductionAdmin=$false },
    [pscustomobject]@{ Duty='Security admin'; Capability='Manage endpoint/application-control policy'; ProductionAdmin=$true }
)
$duties

10. Threat modeling turns security features into design decisions

A threat model identifies assets, trust boundaries, threat actors/inputs, privileges, abuse paths, detections, and mitigations. It prevents the “security checklist” mistake where controls are enabled without knowing which failure they are supposed to prevent.

11. Design a narrow deployment capability contract

Instead of giving the caller “PowerShell admin,” expose a small operation such as Invoke-ApprovedDeployment. The public contract validates environment/version, verifies artifact provenance, uses an injected identity, writes audit records, and internally calls only approved state-changing primitives.

function New-DeploymentThreatModel {
    param(
        [ValidateSet('test','stage','prod')][string]$Environment,
        [ValidatePattern('^v\d+\.\d+\.\d+$')][string]$Version
    )

    [pscustomobject]@{
        Environment       = $Environment
        Version           = $Version
        RequiredPrivilege = 'Deploy application + restart approved service only'
        Secrets           = 'Injected at runtime; never logged'
        Inputs            = @('Environment','Version','Approved artifact')
        Evidence          = @('CorrelationId','ArtifactHash','CallerIdentity','Outcome')
        DeniedCapability  = @('Arbitrary command','Policy modification','Credential export')
    }
}
New-DeploymentThreatModel -Environment prod -Version v2.4.1

12. Know when PowerShell should not be the policy engine

PowerShell is excellent for implementing a narrow automation command, but fleet-wide policy may belong in application control, IAM, configuration management, cloud role assignments, endpoint-management policy, CI environment protections, or a secrets platform. Put policy where the authoritative system can enforce it consistently.

13. Capstone exercise — review a deployment threat model

No elevated configuration is changed. Use the object below as a review artifact and deliberately identify what must be enforced outside the script.

$model = New-DeploymentThreatModel -Environment prod -Version v2.4.1
$model | Format-List

$review = [pscustomobject]@{
    ScriptCanEnforce = @('Input shape','Artifact hash check','Redacted logging','Fail-closed error handling')
    HostMustEnforce  = @('Filesystem ACLs','Service permissions','Application control','JEA endpoint registration')
    PlatformMustEnforce = @('CI approvals','Workload identity','Secret rotation','Audit retention')
}
$review

14. Common least-privilege mistakes

15. Verification checklist

• You can explain least privilege as capability design.
• You understand JEA role capabilities, session configurations, endpoints, and run-as identity at a conceptual level.
• You know JEA constrained endpoint creation is Windows-specific.
• You distinguish JEA from ConstrainedLanguage and understand the role of application control.
• You can explain service/workload identities and separation of duties.
• You can build a threat model covering assets, inputs, privileges, secrets, logs, and failure behavior.

16. Knowledge check

17. Chapter summary and next bridge

Chapter 16 treated PowerShell security as trust-boundary engineering. Execution policy and signatures provide Windows script-loading and publisher/integrity signals. Credentials and secrets require lifecycle controls and explicit injection. Untrusted inputs must remain data. Logs must preserve evidence without leaking secrets. Least privilege then constrains the capabilities available to identities and code through JEA, OS permissions, application control, and platform IAM.

Chapter 17 moves from privilege boundaries to execution scale: jobs, parallelism, runspaces, cancellation, synchronization, partial failure, and performance measurement.

18. Authoritative references

• Microsoft Learn — Just Enough Administration overview
• Microsoft Learn — JEA role capabilities
• Microsoft Learn — about_Language_Modes
• Microsoft Learn — PowerShell security features
• Microsoft Learn — PowerShell differences on non-Windows platforms