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 which 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:
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 Mymodule) – in fact the module is just a .psm1file:
New-Item -ItemType File -Path .\Mymodule.psm1
c)Create a new manifest file (.psm1 file)
New-ModuleManifest -Path .\Mymodule.psd1 -RootModule “Mymodule.psm1”
You will have now inside the folder you create 2 files named
- psm1
- psd1
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. The .psrc file must be placed in the RoleCapabilities subfolder of the module’s folder:
a)I create RoleCapabilitiesfolder in the Mymodule folder
b)and the role capabilities file in it
New-PSRoleCapabilityFile -Path .\RoleCapabilities\MyModule.psrc
Now I can edit the MyModule.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 .\ MyModuleConfiguration.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)
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 group).
Other options:
1) if you don’t want to run the new session under administrative account you can specify any group/groups of which 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 = ‘YOURDOMAIN\serviceaccount’
RoleDefinitions – defines who (in my test – Outfield\Jeaoutfield) 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 “MyModuleConfiguration.pssc” (in my test below I called this file PsSessionConfiguration.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 MyModuleConfiguration.pssc -Name ‘Endpoint1’ -Force
You can see the newly created endpoint by issuing this command:
Get-PSSessionConfiguration | Select-Object Name |fl (in my test I called the endpoint as below)
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 Jeaoutfield domain credentials.
I) Connecting to the local host
$UserCred = Get-Credential
Enter-PSSession -ComputerName localhost -ConfigurationName Endpoint1 -Credential $UserCred (in my test I called the endpoint as below)
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 and it also shows all permitted commands on the session:
Issuing the Exit-PSSession command will end the remote session and its mandatory: the DC prefix will change to the previous PATH.
As you’ve already seen, the EndpointOUTFIELD sessions have their transcript directory set to C:\Scripts\JEA\Transcripts – let’s parse the transcript of the session above (please note that logging occurs on the server where the user-defined PS module is installed):
Summary
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.
Note : ENDPOINTS are created “per machine” so now next step is to find a way to deploy this in a automated way , either using Azure Devops , DSC and fully customizable for a IaC infrastructure.
Hope this post can help you!
0 Comments