Just Enough Administration (JEA) Infrastructure: an Introduction

Just Enough Administration (JEA) Infrastructure: An Introduction

By John Slack

Version 0.4

Table of Contents

After reading this document, you should be able to author, deploy, use, maintain, and audit a Just Enough Administration (JEA) deployment on Windows Server 2016 PP1. Here are the topics we will cover:

1. Introduction: Briefly review why you should care about JEA.
2. Prerequisites: Set up your environment
3. Using JEA: Start by understanding the operator experience of using JEA.
4. Remake the Demo:Create a JEA Session Configuration from scratch.
5. Role Capabilities:Learn about how to customize JEA capabilities with Role Capability Files.
6. End to End - Active Directory: Make a whole new endpoint for managing Active Directory
7. Multi-machine:Discover how deployment and authoring changes with scale
8. Reporting on JEA: Discover how to audit and report on all JEA actions and infrastructure.
9. Appendix: Important skills and discussion points

Introduction

Motivation

When you grant someone privileged access to your systems, you extend your trust boundary to that person. This is a risk; administrators are an attack surface. Insider attacks and stolen credentials are both real and common.

This is not a new problem. You are probably very familiar with the principle of least privilege, andyou might use some form of role based access control (RBAC) with applications that provide it. However, limited scope and large grained control limit the effectiveness and manageability of these solutions. Furthermore, there are gaps in RBAC coverage. For example, in Windows, privileged access islargely a binary switch, forcing you to give unnecessary permissions when adding users to the Administrator group.

Just Enough Administration (JEA) provides a RBAC platform through Windows PowerShell. It allows specific users to perform specific administrative tasks on servers without giving them administrator rights. This allows you to fill in the gaps between your existing RBAC solutions, and simplifies management of those settings.

Scope of this Guide

The initial release of JEA, called xJEA, consisted of experimental DSC resources. Our experiences with xJEA helped us refine the JEA concept. Now, many of the capabilities from xJEA are moving into the underlying PowerShell infrastructure. Instead of building JEA on top ofPowerShell Session Configurations, we are building JEA capabilities into PowerShell Session Configurations. Windows Server 2016 PP1 marks the first release of these new capabilities. This experience guide is solely concerned with this new underlying infrastructure.

Prerequisites

Initial State

Before starting this section, please ensure the following:

1)You have either:

1. An instance of Windows Server 2016 TP4instance running
2. An instance of Windows Server 2012 or 2012R2 with WMF 5.0 RTM

2)You have administrative rights on the server

3)The server is domain joined. See the Creating a Domain Controller section for instructions on creating a standalone domain.

Enable PowerShell Remoting

Management with JEA occurs through PowerShell Remoting. Run the following in an Administrator PowerShell window to ensure that this process is set up.

Enable-PSRemoting

Identify Your Users or Groups

To show JEA in action, you need to identify the non-administrator users and groups you are going to use throughout this guide.

If you’re using an existing domain, please identify or create some non-administrator users and groups. You will give these non-administrators access to JEA. Anytime you see the $NonAdministrator variable at the top of a script, assign it to your selected non-administrator users or groups.

If you created a new domain from scratch, it’s much easier. Please use the Set Up Users and Groups section in the appendix to create a non-administrator users and groups. The default values of $NonAdministrator will be the groups created in that section.

Set Up MaintenanceRole Capability File

Run the following commands to create the demo “role capability” file we will be using for the next section. Later in this guide, you will learn about what this filedoes.

$powerShellPath="$env:SystemRoot\System32\WindowsPowerShell\v1.0"

# Fields in the role capability

$MaintenanceRoleCapabilityCreationParams= @{

Author =

"Contoso Admin"

ModulesToImport=

"Microsoft.PowerShell.Core"

VisibleCmdlets=

"Restart-Service"

CompanyName=

"Contoso"

FunctionDefinitions = @{ Name ='Get-UserInfo'; ScriptBlock = {$PSSenderInfo}}

}

# Create the demo module, which will contain the demo Role Capability File

New-Item-Path“$env:ProgramFiles\WindowsPowerShell\Modules\Demo_Module”-ItemTypeDirectory

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

New-Item-Path“$env:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities”-ItemTypeDirectory

# Create the Role Capability file

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

Create and Register Demo Session Configuration File

Run the following commands to create and register the demo “session configuration” file we will be using for the next section. Later in this guide, you will learn about what this file does.

#Determine domain

$domain= (Get-CimInstance-ClassNameWin32_ComputerSystem).Domain

#Replace with your non-admin group name

$NonAdministrator="$domain\JEA_NonAdmin_Operator"

$JEAConfigParams= @{

SessionType="RestrictedRemoteServer"

RunAsVirtualAccount =$true

RoleDefinitions = @{ $NonAdministrator= @{RoleCapabilities ='Maintenance'}}

TranscriptDirectory ="$env:ProgramData\JEAConfiguration\Transcripts”

}

if(-not (Test-Path"$env:ProgramData\JEAConfiguration"))

{

New-Item-Path"$env:ProgramData\JEAConfiguration”-ItemTypeDirectory

}

$sessionName="JEA_Demo"

if(Get-PSSessionConfiguration-Name$sessionName-ErrorActionSilentlyContinue)

{

Unregister-PSSessionConfiguration-Name$sessionName-ErrorActionStop

}

New-PSSessionConfigurationFile-Path"$env:ProgramData\JEAConfiguration\JEADemo.pssc"@JEAConfigParams

#endregion

#region Register the session configuration

Register-PSSessionConfiguration-Name$sessionName-Path"$env:ProgramData\JEAConfiguration\JEADemo.pssc"

Restart-ServiceWinRM

#endregion

[Optional] Enable PowerShell Module Logging

This enables logging for all PowerShell actions on your system. You don’t need to enable this for JEA to work, but it will be useful in the Reporting on JEA section.

STEP 1: Open the local group policy editor.

STEP 2: Navigate to “Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell”

STEP 3: Double Click on “Turn on Module Logging”

STEP 4: Click “Enabled”

STEP 5: In the Options section, click on “Show” next to Module Names

STEP 6: Type “*” in the pop up window. This means PowerShell will log commands from all modules.

STEP 7: Click OK and apply the policy.

Note: you can also enable system-wide PowerShell transcription through Group Policy.

Congratulations, you have now configured your server and are ready to get started with JEA!

Using JEA

This section focuses on understanding the end user experience of using JEA. In the prerequisites section, you created a demo JEA endpoint. We will use this demo to show JEA in action. In later sections, the guide will work backwards -- introducing the actions and files that made that end user experience possible.

Using JEA as aNon-Administrator

STEP 1:To show JEA in action, you willneed to use PowerShell remoting as though you were a non-administrator user. Run the following command in a new PowerShell window:

$NonAdminCred=Get-Credential
Enter the credentials for your non-administrator account when prompted. If you followed the Set Up Users and Groups section, they will be this:

• Username = “OperatorUser”
• Password = “pa$$w0rd”

This creates and saves a PSCredential object for an unprivileged user that was created in the prerequisites section.

STEP 2: Run the following command in your PowerShell window:

Enter-PSSession-ComputerName.-ConfigurationNameJEA_Demo-Credential$NonAdminCred

You have now entered an interactive remote PowerShell session against the local machine. By using the “Credential” parameter, you have connected as though you were NonAdminUser. The change in the prompt indicates that you are operating against a remote session.

STEP 3:Run the following in your remote command prompt:

Get-Command

This shows the commands that are available to the operator connecting this JEA endpoint. As you can tell, this is a very limited subset of the command available in a normal PowerShell window (over 1520 commands on my machine).

STEP 4: Run the following command in the remote session:

Get-UserInfo

This custom command shows the “ConnectedUser” as well as the “RunAsUser.” The connected user is the account that connected to the remote session (e.g. your account). The connected user does not need to have administrator privileges. The “Run As” account is the account actually performing the privileged actions. By connecting as one user, and running as a privileged user, we allow non-privileged users to preform specific administrative tasks without giving them administrative rights.

STEP 5: Run the following command in the remote session:

Restart-Service-NameSpooler -Verbose

Restart-Service is one of the commands listed in the above configuration. Normally, this command requires administrator privileges to run.

STEP 6: Try to run a PowerShell command that was not listed in STEP 3, such as:

Restart-Computer

JEA restricts which commands can be run as a privileged user. The operator is restricted to only those commands listed in STEP 3.

STEP 7: Run the following command in the remote session:

Exit-PSSession

This disconnects you from the remote PowerShell session.

Key Concepts

PowerShell Remoting: PowerShell remoting allows you to run PowerShell commands against remote machines. You can operate against one or many computers, and use either temporary or persistent connections. In this demo, you remoted into your local machine with an interactive session. JEA restricts the functionality available through PowerShell remoting. For more information about PowerShell remoting, run the following command:

Get-Helpabout_Remote

“RunAs” User: When using JEA, a non-administrator “runs as” a privileged “Virtual Account.” The Virtual Account only lasts the duration of the remote session. That is to say, it is created when a user connects to the endpoint, and destroyed when the user ends the session. By default, the Virtual Account is a member of the local administrators group. On a domain controller, it is also a member of Domain Administrators.

“Connected” User: The non-administrator user who runs as the “RunAs” user through PowerShell remoting.

Remake the Demo Endpoint

In this section, you will learn how to generate an exact replica of the demo endpoint you used in the above section. This will introduce core concepts that are necessary to understand JEA, including PowerShell Session Configurations.

PowerShell Session Configurations

When you used JEA in the above section, you started by running the following command:

Enter-PSSession-ComputerName.-ConfigurationNameJEA_Demo-Credential$NonAdminCred

While most of the parameters are self-explanatory, the “ConfigurationName” parametermay seem confusing at first. That parameter specified thePowerShell Session Configuration, or Endpoint, to which you were connecting.

PowerShell Session Configuration is a fancy term forPowerShell Endpoint. It is the figurative “place” where users connect and get access to PowerShell functionality. Based on how you set up a Session Configuration, it can provide different functionality to connecting users. For JEA, we use Session Configurations to restrict PowerShell to a limited set of functionality and to “RunAs” a privileged Virtual Account.

You already have several registered PowerShell Session Configurations on your machine, each set up slightly differently. Most of them come with Windows, but the “JEADemo” Session Configuration was set up in the Prerequisites section. You can see all registered Session Configurations by running the following command in an Administrator PowerShell prompt:

Get-PSSessionConfiguration

PowerShell Session Configuration Files

You can make new Session Configurations by registering new PowerShell Session Configuration Files. Session Configuration Files have “.pssc” file extensions. You can generate Session Configuration Files with the New-PSSessionConfigurationFile command.

Next, you are going to create and register a new Session Configuration for JEA.

Generate and Modify your PowerShell Session Configuration

STEP 1: Run the following script to generate a blank PowerShell Session Configuration file.

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

This generates a blank Session Configuration File called “JEADemo2.pssc”

STEP 2: Open it in PowerShell ISE, or your favorite text editor.

ise"$env:ProgramData\JEAConfiguration\JEADemo2.pssc"

STEP 3: You need to set the certain fields to make this Session Configuration File define a JEA Endpoint. Specifically, please set the following lines to the following values (replace this with the name of your non-administrator group):

Line # / Old Value / New Value
16 / SessionType ='Default' / SessionType ='RestrictedRemoteServer'
19 / # TranscriptDirectory = 'C:\Transcripts\' / TranscriptDirectory = “C:\ProgramData\JEAConfiguration\Transcripts”
22 / # RunAsVirtualAccount = $true / RunAsVirtualAccount =$true
31 / # RoleDefinitions = @{ 'CONTOSO\SqlAdmins' = @{ RoleCapabilities = 'SqlAdministration' }; 'CONTOSO\ServerMonitors' = @{ VisibleCmdlets = 'Get-Process' } } / RoleDefinitions = @{'Contoso\JEA_NonAdmin_Operator'= @{ RoleCapabilities ='Maintenance' }}

Here is what each of those entries mean:

1. The SessionTypefield defines preset default settings to use with this endpoint.RestrictedRemoteServer defines the minimal settings necessary for remote management. By default, a RestrictedRemoteServer endpoint will expose Get-Command, Get-FormatData, Select-Object, Get-Help, Measure-Object, Exit-PSSession, Clear-Host, and Out-Default. It will set the ExecutionPolicy to RemoteSigned, and the LanguageModeto NoLanguage. The net effect of these settings is a secure and minimal starting point for configuring your endpoint.
   
2. The RoleDefinitions field gives RoleCapabilities to specific groups. It defines who can do what as a privileged account. With this field, you can specify the functionality available to any connecting user based on group membership. This is the core of JEA’s RBAC functionality. In this example, you are exposing the pre-made “Demo” RoleCapability to members of the “Contoso\JEA_NonAdmin_Operator” group.
   
3. The RunAsVirtualAccount field indicates that PowerShell should “run as” a Virtual Account at this endpoint. By default, the Virtual Account is a member of the built in Administrators group. On a domain controller, it is also a member of the Domain Administrators group by default. Later in this guide, you will learn how to customize the privileges of the Virtual Account.
   
4. The TranscriptDirectory field defines where “over-the-shoulder” PowerShell transcripts are saved after each remote session. These transcripts allow you to inspect the actions taken in each session in a readable way. For more information about PowerShell transcripts, check out this blog post. Note: regular Windows Eventing also captures information about what each user ran with PowerShell. Transcripts are just a bit more readable.

STEP 4: Save JEADemo2.pssc

Apply the PowerShell Session Configuration

To create a Session Configuration from a Session Configurationfile, you need to register the file. This requires a few pieces of information:

1. The path to the Session Configuration File.
2. The name of your registered Session Configuration. This is the argument users provide to the “ConfigurationName” parameter when they connect to your endpoint.
3. [Optional] A custom SDDL that defines access conditions for this Session Configuration. This is only required for scenarios like two factor authentication. Otherwise, PowerShell uses the “RoleDefinitions” field to determine access. See this section in the appendix for more information.

To register the Session Configuration on your local machine, run the following command:

Register-PSSessionConfiguration-NameJEADemo2-Path"$env:ProgramData\JEAConfiguration\JEADemo2.pssc"

Congratulations! You have set up your first JEA endpoint.

Test Out Your Endpoint

Re-run the steps listed in the “Using JEA” section against your endpoint to confirm that your endpoint is operating as intended.

To ensure you are operating against your new endpoint, run the following command instead of STEP 2:

Enter-PSSession-ComputerName.-ConfigurationNameJEADemo2-Credential$NonAdminCred

Key Concepts

PowerShell Session Configuration: Sometimes referred to as PowerShell Endpoint, the figurative “place” where users connect and get access to PowerShell functionality. You can list the registered Session Configurations on your system by running Get-PSSessionConfiguration. When configured in a specific way, a PowerShell Session Configuration can be called a JEA Endpoint.

PowerShell Session Configuration File (.pssc): A file that, when registered, defines settings for a PowerShell Session Configuration. It contains specifications for user roles that can connect to the endpoint, the “run as” Virtual Account, and more.

Role Definitions: The field in a Session Configuration File that defines the Role Capabilities granted to connecting users. It defines who can do what as a privileged account. This is the core of JEA’s RBAC capabilities.

SessionType: A field in a Session Configuration Filethat represents default settings for a Session Configuration. For JEA Endpoints, this must be set to RestrictedRemoteServer.

Security Descriptor Definition Language (SDDL): The SDDL defines who has access to an Endpoint, and is set when an Endpoint is registered. By default, access to an endpoint is limited to the groups listed in Role Definitions.

PowerShell Transcript: A file containing an “over-the-shoulder” view of a PowerShell session. You can set PowerShell to generate transcripts for JEA sessions using the TranscriptDirectory field. For more information on transcripting, check out this blog post.

RoleCapabilities

Overview

In the above section, you learned that theRoleDefinitions field definedwhich groupshad access to which Role Capabilities. You may have wondered, “What are Role Capabilities?” This section will answer that question.

Introducing PowerShell Role Capabilities

PowerShell Role Capabilities define “what” a user can do at a JEA endpoint. They detail a whitelist of things like visible commands, visible applications, and more. Role Capabilities are defined by files with a “.psrc” extension.

Role Capability Contents

We will start by examining and modifying the demo Role Capability file you used before. Imagine you have deployed your Session Configuration across your environment, but you have gotten feedback that you need to change the capabilities exposed to users. Operators need the ability to restart machines, and they also want to be able to get information about network settings. In addition, the security team has told you that allowing users to run “Restart-Service” without any restrictions is not acceptable. You need to restrict the services that operators can restart.