How to Configure PowerShell Just Enough Administration (JEA) on Windows Server 2019

What Is Just Enough Administration (JEA)?

Just Enough Administration (JEA) is a PowerShell security technology built into Windows Server 2019 that allows administrators to delegate specific administrative tasks without granting full administrative privileges. With JEA, a help desk operator can restart a service or reset a password through a constrained PowerShell endpoint that exposes only the exact cmdlets and parameters they need—nothing more. This principle of least privilege dramatically reduces the attack surface and limits damage from compromised accounts.

JEA Architecture Overview

JEA works through two configuration files: a Role Capability File (.psrc), which defines what an authorized user can do, and a Session Configuration File (.pssc), which registers the endpoint on the server and maps Active Directory groups to role capabilities. When a user connects, PowerShell creates a constrained runspace running as a virtual account or Group Managed Service Account (gMSA)—the user never gains persistent elevated access to the system.

Prerequisites

JEA requires Windows PowerShell 5.1 (built into Windows Server 2019), WinRM enabled, and the RSAT ActiveDirectory module if AD integration is needed.

# Verify PowerShell version
$PSVersionTable.PSVersion

# Ensure WinRM is running
Get-Service WinRM | Start-Service
Set-Service WinRM -StartupType Automatic

# Confirm JEA cmdlets are available
Get-Command New-PSRoleCapabilityFile, New-PSSessionConfigurationFile

Step 1: Create the Role Capability File

The Role Capability File (.psrc) declares the PowerShell session capabilities for a role. Create a directory for the capabilities—it must be named RoleCapabilities and located inside a valid PowerShell module path:

# Create the module structure
$modulePath = 'C:Program FilesWindowsPowerShellModulesJEACapabilities'
New-Item -Path "$modulePathRoleCapabilities" -ItemType Directory -Force

# Create a role capability for help desk operators
New-PSRoleCapabilityFile -Path "$modulePathRoleCapabilitiesHelpDesk.psrc" `
    -Description 'Allows help desk to manage user accounts and specific services' `
    -VisibleCmdlets @(
        'Get-Command',
        'Get-Help',
        'Get-Service',
        @{Name='Restart-Service'; Parameters=@{Name='Name'; ValidateSet='Spooler','W32Time','WinRM'}},
        'Get-ADUser',
        @{Name='Set-ADUser'; Parameters=@(
            @{Name='Identity'},
            @{Name='Enabled'},
            @{Name='Description'}
        )},
        @{Name='Unlock-ADAccount'; Parameters=@{Name='Identity'}},
        @{Name='Set-ADAccountPassword'; Parameters=@(
            @{Name='Identity'},
            @{Name='Reset'},
            @{Name='NewPassword'}
        )}
    ) `
    -VisibleFunctions @('Get-EventLogSummary') `
    -FunctionDefinitions @{
        Name        = 'Get-EventLogSummary'
        ScriptBlock = {
            Get-EventLog -LogName System -Newest 50 |
                Select-Object TimeGenerated, EntryType, Source, Message
        }
    } `
    -VisibleExternalCommands @() `
    -VisibleProviders @()

Step 2: Create a Role Capability for DNS Administrators

A separate role for DNS technicians who only need to manage DNS records:

New-PSRoleCapabilityFile -Path "$modulePathRoleCapabilitiesDNSTech.psrc" `
    -Description 'DNS record management only' `
    -ModulesToImport 'DnsServer' `
    -VisibleCmdlets @(
        'Get-DnsServerZone',
        'Get-DnsServerResourceRecord',
        @{Name='Add-DnsServerResourceRecordA';       Parameters=@('ZoneName','Name','IPv4Address','TimeToLive')},
        @{Name='Add-DnsServerResourceRecordCName';   Parameters=@('ZoneName','Name','HostNameAlias')},
        @{Name='Remove-DnsServerResourceRecord';     Parameters=@('ZoneName','Name','RRType'); Mandatory=@('ZoneName','Name','RRType')},
        @{Name='Set-DnsServerResourceRecord';        Parameters=@('ZoneName','OldInputObject','NewInputObject')}
    )

Step 3: Create the Session Configuration File

The Session Configuration File (.pssc) registers a PowerShell remoting endpoint and maps groups to role capabilities. The virtual account runs as a local administrator on the target server but without any domain-wide privileges:

New-PSSessionConfigurationFile -Path 'C:JEAJEAEndpoint.pssc' `
    -SessionType RestrictedRemoteServer `
    -RunAsVirtualAccount `
    -TranscriptDirectory 'C:JEATranscripts' `
    -RoleDefinitions @{
        'CORPJEA-HelpDesk' = @{ RoleCapabilities = 'HelpDesk' }
        'CORPJEA-DNSTech'  = @{ RoleCapabilities = 'DNSTech'  }
    } `
    -LanguageMode NoLanguage `
    -Description 'Constrained JEA endpoint for delegated administration'

# Validate the file before registering
Test-PSSessionConfigurationFile -Path 'C:JEAJEAEndpoint.pssc'

Step 4: Register the JEA Endpoint

Registering the session configuration installs it as a PowerShell remoting endpoint and restarts the WinRM service:

Register-PSSessionConfiguration -Name 'JEAEndpoint' `
    -Path 'C:JEAJEAEndpoint.pssc' `
    -Force

# Verify the endpoint is registered
Get-PSSessionConfiguration -Name 'JEAEndpoint'

# Check endpoint permissions
Get-PSSessionConfiguration -Name 'JEAEndpoint' | Format-List -Property Permission

# Restrict endpoint so only authorized groups can connect (remove Everyone if present)
Set-PSSessionConfiguration -Name 'JEAEndpoint' `
    -ShowSecurityDescriptorUI

Step 5: Using a Group Managed Service Account (gMSA) Instead of Virtual Accounts

Virtual accounts are local accounts and cannot authenticate to network resources. Use a gMSA when the JEA tasks require access to domain resources such as file shares or AD:

# On a domain controller, create the gMSA
Add-KdsRootKey -EffectiveImmediately   # only needed once per domain

New-ADServiceAccount -Name 'svc-jea-helpdesk' `
    -DNSHostName 'svc-jea-helpdesk.corp.local' `
    -PrincipalsAllowedToRetrieveManagedPassword 'SRV01$','SRV02$'

# On the member server, install and test the gMSA
Install-ADServiceAccount -Identity 'svc-jea-helpdesk'
Test-ADServiceAccount -Identity 'svc-jea-helpdesk'

# Reference the gMSA in the PSSC (instead of RunAsVirtualAccount)
New-PSSessionConfigurationFile -Path 'C:JEAJEAEndpointGMSA.pssc' `
    -SessionType RestrictedRemoteServer `
    -GroupManagedServiceAccount 'CORPsvc-jea-helpdesk$' `
    -TranscriptDirectory 'C:JEATranscripts' `
    -RoleDefinitions @{
        'CORPJEA-HelpDesk' = @{ RoleCapabilities = 'HelpDesk' }
    } `
    -LanguageMode NoLanguage

Connecting to a JEA Endpoint

Users connect to the JEA endpoint the same way as any PS remoting session but they only see the commands defined in their role capability:

# Connect interactively
Enter-PSSession -ComputerName SRV01 -ConfigurationName JEAEndpoint

# Run a single command non-interactively
Invoke-Command -ComputerName SRV01 -ConfigurationName JEAEndpoint -ScriptBlock {
    Unlock-ADAccount -Identity 'jsmith'
}

# Confirm that only allowed commands are visible from inside the session
Invoke-Command -ComputerName SRV01 -ConfigurationName JEAEndpoint -ScriptBlock {
    Get-Command | Select-Object Name, CommandType
}

Auditing JEA Sessions

JEA automatically writes transcripts to the directory specified in the session configuration file. Review them to audit what commands were run and by whom:

# List transcripts
Get-ChildItem 'C:JEATranscripts' | Sort-Object LastWriteTime -Descending | Select-Object -First 10

# Examine a transcript
Get-Content 'C:JEATranscriptsPowerShell_transcript.SRV01.20240415.txt'

# Search for specific command usage across all transcripts
Select-String -Path 'C:JEATranscripts*.txt' -Pattern 'Set-ADAccountPassword' |
    Select-Object Filename, LineNumber, Line

# Event log also captures JEA connections - Event ID 4103 and 4104
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' |
    Where-Object { $_.Id -in 4103,4104 } |
    Select-Object TimeCreated, Id, Message -First 20

Updating and Removing JEA Endpoints

# Update: re-register with the same name (overwrites)
Register-PSSessionConfiguration -Name 'JEAEndpoint' -Path 'C:JEAJEAEndpoint_v2.pssc' -Force

# Temporarily disable by setting security descriptor to deny all
Set-PSSessionConfiguration -Name 'JEAEndpoint' -AccessMode Disabled

# Re-enable
Set-PSSessionConfiguration -Name 'JEAEndpoint' -AccessMode Remote

# Permanently remove
Unregister-PSSessionConfiguration -Name 'JEAEndpoint' -Force

Conclusion

JEA on Windows Server 2019 provides a structured, auditable path for privilege delegation. By constraining what commands, parameters, and parameter values delegated operators can use—while automatically transcribing every session—JEA enforces least privilege at the PowerShell layer without requiring complex firewall rules or separate management servers. Combined with gMSA accounts for network access, it forms a robust component of any Zero Trust administration strategy.