Just Enough Administration: Windows PowerShell security controls help protect enterprise data

  • Article

Article

May 2016

Download

Article, 50 KB, Microsoft Word file

Just Enough Administration (JEA)—the latest update that is now included with Windows Management Framework 5.0—is a security technology that helps organizations enforce information security by restricting IT administrative rights. JEA provides a practical, role-based approach to set up and automate restrictions for IT personnel, and reduces the risks associated with providing users full administrative rights.

JEA uses the built-in capabilities of the Windows PowerShell scripting environment. Anything that you can manage with PowerShell, you can manage with JEA more securely. JEA provides standardized methods of reducing administrative access with more granularity than traditional access control models.

JEA allows specific users to perform designated administrative tasks on designated servers without giving them full administrator rights. JEA is based on Windows PowerShell-constrained run spaces, a technology used at Microsoft to help secure administrative tasks in environments like Microsoft Exchange Online.

JEA reduces risk by limiting administrator exposure

When organizations grant users administrative access to servers, they assume a level of risk based on trust. Traditionally, organizations grant administrative rights to users who are entrusted with IT administration. Depending on the system, the level of access ranges from full control over every aspect of the system to more granular levels, where only certain components can be changed.

Before JEA, access control models were potentially risky

Before JEA, access to perform specific tasks was grouped into defined roles. But even the best-intentioned role-based access control (RBAC) models give users more access than they need. This leaves room for potential risk. For example:

  • Operations auditors need access to verify server logs, but they shouldn’t be able to make changes to settings or information on the server. When used as a way to provide access to server logs, unrestricted administrative access opens the opportunity for auditors to inadvertently make changes to business-critical systems.

  • Helpdesk or front-line administrators are responsible for basic troubleshooting tasks on a server, or server instance, but shouldn’t have full administrative access to the server itself.

  • A server operator who is expected to apply the latest security updates typically requires total control over the application server, either directly or through a tool. In addition, the operator may need to complete other tasks— such as starting or stopping services or restarting hardware—before and after applying updates to system components. This full control could result in inappropriate service shutdowns or restarts.

  • In an RBAC model, it’s hard to grant access to a service provider that is responsible for implementing changes on behalf of a tenant without exposing tenant data. Such a service provider needs to be able to restart a service during an outage or to provision additional capability, but shouldn’t be able to sign in to the tenant environment.

How JEA addresses risk

JEA overcomes many of the challenges of implementing a comprehensive RBAC model.

  • Users can perform only those tasks for which they are authorized as part of their role by using Windows PowerShell constrained run spaces.

  • Users can perform required tasks without being given administrator rights on the server.

  • The tasks that users are allowed to perform, and their server access, are defined and managed from a central configuration server by using Windows PowerShell Desired State Configuration (DSC).

  • Constant, detailed logging gives details about who has accessed the environment and what’s been changed.

How JEA works

JEA provides an RBAC platform that allows you to create a management endpoint on any computer and to manage it locally or remotely. JEA is implemented as a Windows PowerShell session endpoint, which includes a PowerShell Session Configuration file and one or more Role Capability files.

  • PowerShell Session Configuration file. This file lets you specify who can connect to an endpoint. You can map users and security groups to specific management roles. You can also configure global settings such as virtual accounts and transcription (logging) policies. PowerShell Session Configuration files are specific to each machine, so you can control access on a per-machine basis, if you want.

  • Role Capability files. These files let you specify what actions users in a particular role can perform. For instance, you can restrict them to using certain cmdlets, functions, providers, and external programs. Role Capability files are often generic for a particular role (such as DNS admin, tier 1 helpdesk, read-only inventory auditing). They are part of PowerShell modules, and you can easily share them with others.

An example of JEA

Suppose you have users in your organization who are part of Tier 1 frontline support. These users typically troubleshoot and perform routine tasks to help resolve issues. They can use many of PowerShell’s diagnostic cmdlets to perform their troubleshooting, while having limited ability to add, remove, or change objects.

To support such users, you can take advantage of the updated JEA Helper Tool, which helps you easily create an endpoint definition—using a graphical user interface (GUI). This tool guides you through creating and deploying your own Session Configuration and Role Capability files. You can use any cmdlets, and specify any roles, security groups, and individuals assigned to a particular role.

Implementing JEA at Microsoft

Microsoft IT conducted a successful pilot using the original version of JEA on many servers in its production environment. Now that JEA has been redesigned, we’re exploring scenarios to drive adoption of least-privileged access to reduce security risk.

Benefits of JEA

  • Reduce the number of administrators in your environment. JEA enables administration and management of computers without the need for privileged credentials.

  • Easily create and configure your own endpoints. Set up your non-administrators to perform specified commands, functions, scripts, and executables as if they were administrators. With new role definitions, virtual accounts, and other improvements, it’s now even easier to create and configure endpoints, by using the JEA Toolkit Helper.

  • Limit what users can do, with control. Decide precisely what actions you’ll let your users carry out; for instance, which cmdlets, functions, and external commands they can run. JEA eliminates the need for elevated, privileged administrator credentials that can be lost, stolen, or misused.

  • See what users are doing, with actionable logging and reporting. All operations performed through the JEA endpoint can be recorded in the Windows event log. These event logs show who accessed the environment and when, and what changes were made.

Challenges

The primary challenge that Microsoft IT has faced while implementing JEA has been that many administrators are still accustomed to using GUIs rather than the Windows PowerShell command-line shell and scripting environment. Windows PowerShell uses common cmdlets to perform common system administration tasks, such as managing the registry, services, processes, and event logs, and using Windows Management Instrumentation (WMI). Beyond using JEA Windows PowerShell security controls to help protect servers in the enterprise, Windows PowerShell proficiency is quickly becoming a necessity in administering Windows-based systems. Although it’s a worthwhile time investment, this learning curve has influenced how quickly JEA can be implemented across the production environment.

Get JEA

The current release of JEA is available on the following platforms:

Windows Server

Windows Client

* Support for virtual accounts in JEA sessions is currently not available on Windows Server 2008 R2 or Windows 7.

For more information

JEA documentation on GitHub

Windows PowerShell blog

Microsoft IT Showcase

microsoft.com/itshowcase

© 2016 Microsoft Corporation. All rights reserved. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.