How to Configure Windows Server Just Enough Administration (JEA) Profiles

The Domain Admin Dilemma

In traditional Windows Server environments, IT administrators have historically relied on the “all or nothing” security model. If a junior helpdesk technician needs to restart the Microsoft Exchange Transport Service on a server or modify a DNS record, they are often given full Membership to the Domain Admins or local Administrators group. This is incredibly dangerous. Once they have those keys, they can also delete the entire Active Directory forest, read the CEO’s emails, or accidentally format the SAN storage.

Microsoft solved this by introducing Just Enough Administration (JEA). JEA is a PowerShell-based security technology that completely eliminates the need to give technicians administrative rights. Instead, you create a highly restricted, virtualized PowerShell sandbox. When the helpdesk technician logs in remotely, they are trapped in this sandbox. They can only execute the exact 5 cmdlets you explicitly whitelist (e.g., Restart-Service), and they can only execute those cmdlets against the exact parameters you allow (e.g., they can restart MSExchangeTransport, but if they try to restart NTDS, the system blocks them). Furthermore, the commands they run are executed by a temporary, invisible Virtual Account that possesses the actual admin rights, while the technician remains a standard user.

Step 1: Creating the Role Capability File (.psrc)

The first step in building a JEA endpoint is defining exactly what the technician is allowed to do. This is done by creating a Role Capability file.

Open an elevated PowerShell ISE or VS Code session on your administrative workstation and execute:

New-PSRoleCapabilityFile -Path .\HelpdeskRole.psrc

Open the newly created HelpdeskRole.psrc file. It is a configuration document. You must meticulously define the whitelist.

# Inside HelpdeskRole.psrc

# Allow them to run ONLY these specific cmdlets
VisibleCmdlets = 'Get-Service', @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidatePattern = '^(MSExchangeTransport|W3SVC)$' } }

# Allow them to run these specific external executables
VisibleExternalCommands = 'ping.exe', 'ipconfig.exe'

Notice the incredible granularity: The technician is allowed to use Restart-Service, but the Regular Expression (ValidatePattern) dictates they can only restart the Exchange or IIS services. Anything else will throw an Access Denied error.

Step 2: Deploying the Role Capability

To make this role available to the server, you must place the .psrc file inside a specific directory structure within a PowerShell Module.

# Create the directory structure
New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\JEARoles\RoleCapabilities" -ItemType Directory -Force

# Move the file into the module
Copy-Item .\HelpdeskRole.psrc -Destination "C:\Program Files\WindowsPowerShell\Modules\JEARoles\RoleCapabilities\"

Step 3: Creating the Session Configuration File (.pssc)

Now that the Role exists, you must create a Session Configuration file. This file tells the server who is allowed to connect, and which Roles they receive when they do.

New-PSSessionConfigurationFile -Path .\HelpdeskEndpoint.pssc -SessionType RestrictedRemoteServer -RunAsVirtualAccount $true -RoleDefinitions @{ 'CORP\Helpdesk_Tier1' = @{ RoleCapabilities = 'HelpdeskRole' } }

Understanding the Configuration:

• SessionType RestrictedRemoteServer: This is the magic lock. It strips away all native PowerShell commands (like cd, dir, Invoke-Command) and traps them in the sandbox.
• RunAsVirtualAccount $true: This tells the server to generate a temporary, highly privileged, invisible local administrator account to actually execute the commands on behalf of the technician.
• RoleDefinitions: This maps the Active Directory security group (CORP\Helpdesk_Tier1) to the HelpdeskRole.psrc file we built in Step 1.

Step 4: Registering the JEA Endpoint

The final step is to officially register this configuration with the Windows Remote Management (WinRM) service on the target server.

Register-PSSessionConfiguration -Name 'HelpdeskMaintenance' -Path .\HelpdeskEndpoint.pssc -Force

Restart the WinRM service to apply the new endpoint:

Restart-Service WinRM

The Execution (The End-User Experience)

The JEA environment is now live. A junior technician in the Helpdesk_Tier1 group opens PowerShell on their local laptop.

They cannot RDP into the server. They cannot use the standard Computer Management GUI. They must use PowerShell Remoting, specifically targeting the new endpoint:

Enter-PSSession -ComputerName "EXCHANGE-SRV-01" -ConfigurationName 'HelpdeskMaintenance'

When the session connects, they are trapped. If they type Get-Command, they will only see Get-Service, Restart-Service, ping, and ipconfig. The rest of the Windows Operating System is mathematically invisible to them. If they type Restart-Service -Name Spooler, JEA will instantly block the execution because it violates the RegEx pattern. You have achieved perfect, granular, Zero Trust administrative delegation.