News

Microsoft Previews 'Just Enough Administration' PowerShell Security Controls

• By Kurt Mackie
• 05/16/2014

Microsoft introduced a new PowerShell-based server protection scheme for IT pros at TechEd this week called "Just Enough Administration" (JEA).

JEA is based on the common notion that organizations can best enforce security by restricting IT administrative rights. JEA offers a practical way to set up and automate those restrictions for IT personnel.

The technology is currently being called "xJEA" because it still has some bugs, according to Jeffrey Snover, a Microsoft Distinguished Engineer and the lead architect for Windows Server. Snover, known as the "father of PowerShell," provided a debut of JEA in a TechEd session called "JitJea: A Windows PowerShell Toolkit to Secure a Post-Snowden World."

Restricting Admin Rights
Snover used the example of how administrative rights trumped security in the case of former National Security Agency contractor Edward Snowden. One of Snowden's revelations was that the NSA itself targets IT system administrators to gain access to server traffic.

IT administrators essentially are an "attack surface," Snover contended, and JEA is all about reducing the risks for organizations of having admins. Organizations typically give administrative privileges to IT personnel that just need to restart a box, but Microsoft's idea with JEA is to let those personnel carry out their tasks without having those privileges.

In addition, JEA is designed to limit "pass the hash" techniques of gaining credentials by hacking into a machine, and then using those local credentials to gain the administrative credentials for a computing environment. Snover said that a tool called "mimikatz" can be used to recover passwords, and he was shocked to see it in action exposing his own credentials.

Another concept in JEA is to log all admin actions. Users entering restricted commands don't get any information from those attempts, but those actions do get logged.

JEA is not new, according to Snover. It's based on the PowerShell security features that are currently used with Microsoft online services such as Exchange Online. JEA consists of a toolkit and an endpoint. The toolkit is used to define commands for a set of activities, which might be based on the roles of IT personnel. The endpoint is a management connection point where IT pros get authorized to use those defined commands. Each endpoint has a hidden local administrator account tied to a particular server. If that account gets compromised by malware, the breach stays local.

Connecting to a JEA endpoint is basically the same as connecting to a remote Windows PowerShell session except that the user specifies the name of the endpoint, according to a Microsoft white paper, "Just Enough Administration" (Word doc). Users accessing the endpoint only see the commands specified for them. If they try to run other commands, they just get an error message, and the attempt gets logged.

The JEA technology is based on Windows PowerShell "constrained runspaces" technology used with Exchange Online. The definition of tasks is carried out by using Windows PowerShell Desired State Configuration (DSC). Snover described DSC as the ability to declare how you want a system to be. The system then "makes it so," or returns comments if it can't.

JEA endpoint changes don't necessarily affect the graphical user interface on Windows Server, according to a Microsoft spokesperson, via e-mail:

GUIs that use PowerShell need to allow the user to specify which Endpoint to connect to in order to work with JEA. This is currently not common practice. Because of the custom nature of JEA Toolkits, we anticipate users creating custom GUIs that work against their JEA Endoints and JEA Toolkits. There are a wide range of PowerShell toolkits available to accomplish (this,) including the point-n-click GUI builder PowerGUI from Dell, to PowerShell Studio from Sapien, the ShowUI community toolkit and many others.

JEA Requirements
JEA is currently available as a module in the DSC Resource Kit. It requires the use of Microsoft's current flagship client and server operating systems, Windows 8.1 and Windows Server 2012 R2. It also requires the use of the Windows Management Framework 5.0 Preview, dated May 2014. Snover said that this particular xJEA preview version currently does not support the use of domain accounts and group managed service accounts.

Microsoft may support JEA on earlier Windows versions. However, such support would depend on interoperability with Windows Management Framework 5.0, which currently just supports Windows 8.1 and Windows Server 2012 R2, according to Microsoft's white paper. However, JEA isn't necessarily tied to Windows.

"Although this solution is implemented in Windows, through the use of standards-based management, the technology can be applied to non-Windows systems as well," the white paper states (p. 3).

Microsoft provides a step-by-step guide for setting up JEA here. However, there's a shortcut for MSDN subscribers. They can test it out in a Microsoft Azure virtual machine, which will have xJEA already configured, including the demo scripts. Those details for MSDN subscribers are described in this Microsoft blog post.