Just Enough Administration in Windows Server 2016

You may already know that Windows Server 2016 has a new feature called JEA – Just Enough Administration. In this post I’d like to show in which circumstances it can be used and how it can be configured. As the purpose of JEA is to give administrators/users as few permissions as required for their work to be done, this technology would be pertinent in situations when different company administrators have different working tasks and when there’s no other way not to give them excessive user rights or permissions on various servers or workstations. Suppose there’s a junior administrator in your company that should have the right to configure the company DNS servers and nothing more, but considering the DNS servers are AD-integrated this administrator must have access to the company DCs because you can’t separate GUI-based administration of AD from DNS. This is where JEA comes into play: it allows you to create PoweShell-based administrative endpoints that strictly define which actions may be taken by which users or groups. Now let’s see how JEA can be deployed on a single domain member server.

As JEA is a built-in feature of Windows Server 2016  no prerequisites must be installed, but it’s highly recommended to enable script block logging in the corresponding GPO wich applies to the server or workstation on which the JEA endpoint to be created:

Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell


1) Enable Turn on Module Logging and select all modules by clicking on Show… and typing \*


2) Enable Turn on PowerShell Script Block Logging (you can also select Log script block invocation start/stop events checkbox)


There’s also one more setting that can be enabled – Turn on PowerShell Transcription – this setting when enabled will log all PS-based commands into the specified directory (please note that we can define a separate transcript folder for each endpoint – I’ll show it a bit later).


In case this policy setting is enabled the complete list of the PowerShell GPO settings will look as follows:

Here’s the example of the transcripts being logged into the default user’s Document folder:

Once the GPO is created we can proceed to the first step in deploying JEA:

Step 1: Creating a new PowerShell module

(All the steps will be performed on my domain controller – DC. This is the server TO WHICH a user named User1 will be given access).

All JEA functionality “contains” in the user-defined PowerShell modules and I prefer creating the new modules beforehand so I can place all needed files in the new module’s folder later on. By default PS looks for its modules in C:\Program Files\WindowsPowerShell\Modules folder so to create a new module I’ll do the following:

a) Create a folder for the module:

b) Create a new empty module (at least one file in the module folder must have the same name as the folder – in this case TestModule) – in fact the module is just a .psm1 file:

New-Item -ItemType File -Path .\TestModule.psm1


c) Create a new manifest file (.psm1 file)

New-ModuleManifest -Path .\TestModule.psd1 -RootModule “TestModule.psm1”


Step 2: Creating role capabilities file (.psrc file)

At least one .psrc file called role capabilities file must be created which defines what user or administrator can do in a JEA session. This file contains all cmdlets and external programs (it can contain providers and functions as well) which will be permitted to use in the JEA session. For this test I’ll create the file which permits a user only to see the list of running process by means of Get-Process cmdlet, the list of services by means of Get-Service cmdlet and to run  the single external program – nslookup. It is worth noting that the cmdlets and external programs typicaly run under virtual administrator account which by default is a member of the local Administrators or Domain Admins groups. The .psrc file must be placed in the RoleCapabilities subfolder of the module’s folder:

a) I create RoleCapabilities folder in the TestModule folder:

b) and the role capabilities file in it:

New-PSRoleCapabilityFile -Path .\RoleCapabilities\Test.psrc

Now I can edit the Test.psrc with Notepad to permit only a few cmdlets/external commands:


Step 3: Creating session configuration file (.pssc file)

To define who will have access to the new endpoint and under which account the new ps session will run, the session configuration file must be created (I’ll create it in the module’s folder):

New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\TestConfiguration.pssc

Sessions configured with -SessionType RestrictedRemoteServer field will operate in the Restricted Language mode which allows by default only the following  commands:

  • Clear-Host (cls, clear)
  • Exit-PSSession (exsn, exit)
  • Get-Command (gcm)
  • Get-FormatData
  • Get-Help
  • Measure-Object (measure)
  • Out-Default
  • Select-Object (select)

More detailed explanation on this mode can be found here – About Language Modes.

Like  .psd1 and .psm1 files,  the .pssc files can be edited in Notepad – I’ll configure the following sections:

TranscriptDirectory – this line enables logging of the commands run in the session (this is the endpoint-specific transcript directory as opposed to the default transcript directory defined in the PS GPO above) .

RunAsVirtualAccount – if set to true runs the session under virtual administrative account (member of either local Administrator‘s or Domain Admins‘ group).

Other options:

1) if you don’t want to run the new session under administrative account you can specifiy any group/groups of wich this virtual account should be the member of:

RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = ‘Network Configuration Operators’

2) for accessing network resourses from the new session you can use group managed service account:
GroupManagedServiceAccount = ‘TestDomain\TestGSA’

RoleDefinitions – defines who (in my test – TestEnterprise\User1) will have access to which endpoint (the name of the endpoint is the RoleCapabilities file name without extension).

SessionType is already set to RestrictedRemoteServer

Description – the optional field.

Before we proceed to registering JEA endpoint it would be pertinent to test the session configuration file using the Test-PSSessionConfigurationFile cmdlet:

Test-PSSessionConfigurationFile -Path  “TestConfiguration.pssc”

Should this test reveal any errors you can edit the file once again in Notepad.

True means the file has the correct syntax.

The last step: Registering the endpoint

The following command will register the new endpoint on the system:

Register-PSSessionConfiguration -Path  TestConfiguration.pssc -Name ‘EndpointTEST1’ -Force

You can see the newly-created endpoint by issuing this command:

Get-PSSessionConfiguration | Select-Object Name

Now it’s time to test the new endpoint: first of all I’d like to make sure the endpoint works as expected by connecting to the local host using User1′ domain credentials.


I) Connecting to the local host

$UserCred = Get-Credential

Enter-PSSession -ComputerName localhost -ConfigurationName EndpointTEST1 -Credential $UserCred

From now on, all cmdlets will be run under virtual administrative account.

Get-Process (It should succeed as it’s defined in the RoleCapabilities file)


Get-Service (It should succeed as it’s defined in the RoleCapabilities file)

Get-Childitem and Get-Date should NOT succeed because they are not listed in the RoleCapabilities file.

Get-Command will succeed as it’s one of the base cmdlets allowed in the restricted language mode:


External commands:

Nslookup is allowed while any others are not:


II Connecting to the remote server – SQL1

I think the more practical approach will be the case when an administrator wants to delegate control of some OS components/features to another administrator or a user. Suppose I want User1 to be able to see the the list of services and the list of processes on DC and run the single external command – nslookup.exe when connected to DC from another computer (in this case from SQL1). Once again: the new module – TestModule1 – has been created on DC and we can connect to it (or to the corresponding endpoint) remotly from another computer (SQL1).

In this case there’s no need to issue the Get-Credential command as I’ve already logged in as User1 onto SQL1:

Enter-PSSession -ComputerName DC -ConfigurationName EndpointTEST1 -Credential $UserCred

Please note the DC prefix when working with the remote server (DC).

Issuing the Exit-PSSession command will end the remote session: the DC prefix will change to PS C:\Windows\system32.

As you’ve already seen, the EndpointTEST1 sessions have their transcript directory set to C:\Transcripts – let’s parse the trascript of the session above (please note that logging occurs on the server where the user-defined PS module is installed):


The new feature of Windows Server 2016 – Just Enough Administration  – can help administrators  control in the most specific way what administrative actions other administrators or users may perform on which systems: this level of control is not possible with Windows GUI.

%d bloggers like this: