Experience shows that a high number of incidents and security breaches on IT systems are due to human error. Some IT professionals got accustomed to opening their sessions directly on servers or running applications and services with full administrative rights. They would rather continue like this, as long as they do not encounter an incident. High privilege access is also due to wrong design with applications that do not offer role-based access control and will run only with Domain Admin or Local Admin profiles.

For some years now, Microsoft has been insisting that Windows administrators use the principle of least privilege, user account control (UAC) and role-based access control (RBAC) whenever possible. With Windows Server 2016, Microsoft takes this vision one step further. It’s a brand new concept for Active Directory environments: Just Enough Administration (JEA).

Let’s see what’s behind this new feature.


What is Just Enough Administration?

Think of it as the SUDO command in Linux environments, but with more control.

JEA provides an RBAC platform that will allow the user to create a management endpoint on any Windows domain computer and manage it locally or remotely. It’s designed to help administrators delegate tailored privilege to other team members. Using PowerShell, these users will be able to remotely access servers and execute commands with elevated privileges to specified servers in the domain.

JEA is based on Windows PowerShell-constrained run spaces, a technology used at Microsoft to help secure administrative tasks on cloud platforms like Exchange Online.

All admissible user tasks are defined and managed centrally from one server, using Windows PowerShell Desired State Configuration (DSC). Moreover, all activities performed can be logged by enabling the PowerShell module logging.

With JEA, the number of administrators in an Active Directory environment can be drastically reduced, without affecting administrative task execution.


How Does JEA Work in a Windows Server 2016 Environment?

JEA is built into Windows PowerShell 5.0+. It requires the installation of Windows Management Framework 5.0 Preview.

It comes as a module in the Windows PowerShell DSC Resource Kit and includes two set of resources:

  • xJEAToolKit will help for toolkit configuration, with a set of tasks that a user can perform on the server. These tasks are configured and run through cmdlets and parameters.
  • xJeaEndPoint will help for endpoint configuration.

A JEA endpoint represents an administration point for users on Windows Server instances and consists of one or more toolkits.


Role Capability and Session Configuration Files

A PowerShell Role Capability file is used to define what a user can do at a JEA endpoint. It’s actually a whitelist of commands and applications that will be made accessible (or “visible”) to the user. Role Capability files have the “.psrc” extension.

Also, creating a JEA endpoint will require the user to create and register a PowerShell Session Configuration file, configured for the specific type of usage it’s intended for. It can be generated with the New-PSSessionConfigurationFile cmdlet.

Finally, PowerShell Remoting needs to be enabled for JEA to work. The Enable-PSRemoting cmdlet will help accomplish this.


How to use JEA in a Windows Server 2016 Environment

The most complex part is the configuration. Once your environment is set for JEA, here’s how delegated users will perform actions with elevated privilege.

Let’s assume the delegated user has no administrative permissions and is logged on a domain computer with his or her account.

  • Step 1: Start the PowerShell prompt
  • Step 2: Enter the interactive remote PowerShell session on the remote server
    Enter-PSSession –ComputerName TheRemoteServer -ConfigurationName TheConfigurationIdentifier
  • Step 3: Run authorized cmdlets

From this point, any cmdlet that was authorized in the configuration can be executed. Any attempt to run a cmdlet that is not authorized will simply fail.

Once the delegated user is done, he can end the interactive mode by running the Exit-PSSession cmdlet.

It’s that simple.


Is JEA the Perfect Response to the Privilege Elevation Issue?

The idea of privilege has evolved. In the early years of the Windows operating system, there were basically three types of accounts that ran things: guests, standard (normal) users and administrators. Windows security had been built on discretionary access control (DAC) with access control lists (ACLs) that defined permissions on objects. Security groups are an implementation of this DAC notion, like Domain Admins security group.

With the notion of role-based access control (RBAC), the focus has been more on the application side, giving end-users specific privileges within it, which has created the notion of roles. User Account Control (UAC) on the other hand, introduced a context in which Windows would notify the user and ask for privilege elevation to run tasks that required modifications on the operating system. Logged-on users with no admin permissions would not be able to execute the task unless they provided other admin credentials. This is considered a  local safeguard for security purposes.

Just Enough Administration (JEA) deals with domain-wide security. Over the years, emphasis has been put on educating administrators to stop connecting directly on servers to carry on their tasks. At some point, best practices recommended administrators  have a non-privilege account for accessing the domain and keep a second account for actions requiring elevated permissions. It’s a safe bet that these practices were not followed by a majority of professionals. Let’s take domain administration as an example. In this case, Remote Server Administration Tools and PowerShell with the WinRM service became recommended alternatives to directly accessing servers. But administrators would still need to use their account with elevated privilege to run them. JEA adds another level of flexibility. It makes it possible to delegate specific tasks in the domain or on the servers that require elevated permissions to some users, without giving them an administrator access.


SherWeb Performance CloudNeed help building your WS2016cloud servers?

Ask for a Demo Now

Written by Sadissa Babeni Marketing Content Writer @ SherWeb

Sadissa is an IT professional and joined SherWeb in 2013 as a technical writer and trainer. A former systems administrator, she brings her decade-long field experience to SherWeb's marketing department, with her broad knowledge of cloud computing and service management. Sadissa is a Microsoft Certified Solutions Associate in Windows Server and Office 365, and has earned other IT certifications over the years. She has a passionate interest in singing in vocal ensembles and learning foreign languages.