As part of your information security strategy, you are probably familiar with the principle of
. The concept itself is simple -- give your IT staff and end-users as few permissions as necessary to get their jobs done. This helps shrink your attack surface and limit exposure when attackers compromise user credentials through phishing, key logging, or
pass the hash
attacks. Anyone who has tried removing all of their privileged accounts, however, knows that it is impossible to do in an average computing environment. Too many applications require administrator privileges in order to be run, including many components in the operating system itself. This can lead to frustrating situations, where in order to restart a service, install a security update or view event logs to troubleshoot a problem, you need full administrator privileges on that machine. Being a local admin (or, worse yet, a domain admin on an Active Directory Domain Controller) gives you permissions to do anything you want. For an attacker wielding your credentials, that can mean installing malware, stealing files, or finding ways to get access to even more privileged credentials.
Some applications use role based access controls (RBAC) to get around these issues. By implementing authorization logic within the application, the requirement for administrator privileges can often be relieved. For example, Active Directory Domain Services has a delegated administration model that enables help desk staff to reset passwords for users without having the ability to manage the rest of the directory. While powerful, these RBAC tools are often limited to the scope of the application for which they were written. The AD RBAC tools cannot be used to manage DNS servers, for example.
Just Enough Administration
Just Enough Administration (JEA) was created to solve this exact problem. JEA is a PowerShell security feature that helps you create constrained management endpoints using role based access controls for
that can be managed with PowerShell. With JEA, a non-administrator is able to run specific commands, scripts, and executables as if they were an administrator on the machine and all their actions are fully logged. A single JEA role may allow users to manage a few pieces of multiple applications, enabling scenarios not possible with built-in RBAC solutions.
Let's examine the typical JEA workflow, as shown in the diagram above. First, a highly trusted security admin has to configure a JEA endpoint on each server. This involves creating or downloading one or more Role Capability files, which define
a user is able to do when they belong to a role (including which cmdlets, providers, and executables they may use), and a Session Configuration file which maps users and groups to those roles. These users and groups do not need to be assigned administrative rights on the system; they can just be domain users or local users. Behind the scenes, JEA uses temporary, per-session local admin accounts to execute commands on their behalf. (Detailed information about these configuration files will be covered in a future blog.) Next, a user connects to the JEA endpoint using PowerShell remoting and their unprivileged user credentials. The JEA endpoint will examine the connecting user's group membership and grant the user access to all the appropriate commands for their role(s). The user can then run their PowerShell commands to get their job done without ever actually being an admin on the machine.
JEA configurations are designed to support complex environments. The endpoints themselves are local to each machine, allowing you to customize them for that machine's particular needs. For more general endpoints, you can use our DSC resource to quickly and consistently deploy JEA configurations across many machines -- even your whole datacenter!
How to Get Started
Just Enough Administration is built into Windows PowerShell 5.0+. If you're running Windows Server 2016 or Windows 10, you likely already have it installed on your machine. It is also available on Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2 when you install
Windows Management Framework 5.0