Just Enough Administration (JEA) Step By Step – useful lesson from Microsoft Ignite 2016 Precon

At Microsoft Ignite 2016 conference we had a pleasure to deliver a session about internal security! This time, we focused on scenarios related to the internal threats and on protection against them. We covered topics like security internals (security internals of internal security sounds cool for us), Windows network protocols security, stealing sensitive data from memory and malware analysis.

As we promised you during our introduction to the pre-conference session at Microsoft Ignite 2016, we are more than happy to share some details about JEA or Just Enough Administration approach. This feature was introduced in the Windows Management Framework version 5.0 which means you have to install it intentionally (it is free and easy to download from the Microsoft website) or you can use Windows Server 2016 where it was built in.

The idea behind the creation of Just Enough Administration

The idea behind the creation of Just Enough Administration is the problem all administrators are facing in every single environment: how to give some administrative privileges to some users but not giving them too much. As we sometimes say: have your cake and eat it too. We could observe some techniques to achieve this goal in the past but all of them were not like a solution ready to use in serious environment.

With PowerShell you can easily establish “PSSession” allowing to control local or remote machine as some user. The main idea behind Just Enough Administration is to allow the user to establish a session, filter things user can do in his session and impersonate his session as an identity actually allowed to perform such action. We all should know about SDDL for services, but let’s skip this topic here to make the description clear – only admins have a permission to restart our services on the managed server. To wrap it up more specific way: how could we allow some users to issue only one PowerShell cmdlet requiring administrative privileges. Kind of a Holy Grail for many environments, right?

To follow best practices from the very beginning we will create an Active Directory group called “JEAdmins”. We will assign our permissions to this group so allowing a new user to do the same stuff will require only adding and user to a group instead of starting entire process from scratch.

Just Enough Administration (JEA) in practice 

So let’s start with your domain\jeadmins group and the user domain\blee is a member of this group. Of course, Bruce is not an admin so if he tries to “Enter-PSSession -computername server1” he will fail.

Let’s switch to the Server1 (we can assume it is Windows Server 2016) and launch PowerShell. The first thing we can do is to create two folders our setup will use.

  1. md “$env:ProgramData\JEAConfiguration\Transcripts” ← for logs of our “half-admin” actions performed in his session. This is a nice feature of PowerShell and using it definitely makes sense.
  2. md “$env:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities” ← for the module responsible for doing all the magic here

We can now create the module Manifest by typing:

New-ModuleManifest -Path “$env:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\Demo_Module.psd1”

Next, we should create role capabilities. We will put them all into one PowerShell variable:

$MaintenanceRoleCapabilityCreationParams = @{

   Author = ‘CQURE Admin’

   CompanyName = ‘CQURE’

   VisibleCmdlets = ‘Restart-Service’

   FunctionDefinitions =

           @{ Name = ‘Get-UserInfo’; ScriptBlock = { $PSSenderInfo } }


Now we can use the variable defined above to create a *.psrc (Role Capability) file for the module:

New-PSRoleCapabilityFile -Path “$env:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\Maintenance.psrc” @MaintenanceRoleCapabilityCreationParams

The next thing is to create *.pssc (PowerShell Session Configuration) file skeleton:

New-PSSessionConfigurationFile -Path “$env:ProgramData\JEAConfiguration\JEADemo2.pssc”

Of course, it contains only default parameters but you can quickly apply four edits here.

In line 16: # SessionType = ‘Default’ → SessionType = ‘RestrictedRemoteServer’

In line 19: # TranscriptDirectory = ‘C:\Transcripts\’ → TranscriptDirectory = “C:\ProgramData\JEAConfiguration\Transcripts”

In line 22: # RunAsVirtualAccount = $true → RunAsVirtualAccount = $true

In line 28: #RoleDefinitions = @{ ‘CONTOSO\SqlAdmins’ = @{ RoleCapabilities = ‘SqlAdministration’ }; ‘CONTOSO\ServerMonitors’ = @{ VisibleCmdlets = ‘Get-Process’ } } →

RoleDefinitions = @{DOMAIN\JEAdmins’ = @{ RoleCapabilities =  ‘Maintenance’ }}

Of course in the last line, you should replace “DOMAIN” with your test domain name.

Now you can easily register the session configuration by typing:

Register-PSSessionConfiguration -Name ‘JEADemo2’ -Path “$env:ProgramData\JEAConfiguration\JEADemo2.pssc”

Done. Now Bruce can try to re-connect specifying the session configuration name:

  • $jeacreds=get-credential ← authenticate as our non-admin “Bruce” user here
  • Enter-PSSession -ComputerName . -ConfigurationName JEADemo2 -Credential $jeacreds

The first thing you can observe is that the connection was established. The real fun begins if you type “Get-Command” and see what Bruce can do. As you can see his possibilities are extremely limited but at the same time, he actually works as an admin! It is easy to verify this by looking at Task Manager.

We can easily say right now we had given admin permissions to our user but at the same time, our admin is extremely limited. So you have your cake and have eaten it too.

Feel free to play this nice technique in your environment. It will not harm you and if you would like to clean your configuration up it is enough to “Unregister-PSSessionConfiguration” and deletes folders you created.

Have fun and #staycqure!

*co-author Grzegorz Tworek