Weekend Scripter: Taking JEA for a Spin—Part 1
Summary: Thomas Rayner explores code promotion with Just Enough Admin (JEA) in Windows Server 2016.
Hello! I’m Thomas Rayner, a proud Cloud and Datacenter Management Microsoft MVP, filling in for The Scripting Guy this weekend. You can find me on Twitter (@MrThomasRayner). I also post my blog bi-weekly: Working Sysadmin—Figuring stuff out at work. The temperature is dropping and the snow is starting to fly here in Alberta, Canada so I’m going to stay in this weekend and take an awesome new feature in Windows Server 2016, Just Enough Admin (JEA), for a spin. I’ll explore how it can be applied in a situation where a limited user has permissions to run only one script for code promotion.
JEA was one of the new features introduced with Windows Server 2016 TP4 when it was released in November 2015. Previously, JEA had existed as a DSC module, but now it is baked right into the operating system. I couldn’t wait to get my hands on it, so I put together a first look on my blog: Just Enough Administration (JEA) First Look.
At the end of that post, I shared a handful of potential use cases, and this weekend I’m going to demonstrate a couple of them. If this is the first you’ve heard of JEA, I’d suggest taking a look at this article on MSDN: Using Just Enough Administration Windows PowerShell Security Controls to Help Protect Enterprise Data.
Today, the use case I’m going to demonstrate is code promotion. There are about a billion different ways to promote code through a software development lifecycle, but for this proof of concept, I will tackle a situation where files are staged somewhere and must simply be copied to a production server. Let’s take a look at the requirements for the remote PowerShell sessions that JEA is going to manage for this purpose.
Users must be able to:
- Copy files from a known source to a known destination.
- Overwrite existing files in the destination.
- Create new files in the destination.
- Restart the app we’re promoting code for.
Users must NOT be able to:
- Interact with other files or systems on the server.
- Edit any scripts related to the code promotion process.
Looks pretty simple, right? Let’s get to it…
First I’m going to set up a location for a new module to hold my JEA configuration files:
Here is the output:
I’ve only got one machine in the lab I’m using for this demo, so I’m building the module to hold this JEA configuration in the location that I intend for it to end up. I need to create a new configuration file and open it in the Windows PowerShell ISE:
This file has a bunch of general configuration settings for our JEA endpoint. I’m only going to leverage a few. First, I need to change the SessionType to RestrictedRemoteServer (line 16 in the following image); otherwise, none of this is going to work the way I want it to.
I could also configure a bunch of other interesting things, such as where to save a mandatory transcript or items related to virtual accounts. For this demo, I’m only going to edit the role definitions on the last line (line 31 in the following image). This is where we essentially say, “Users in this group get this role when they connect.”
I have a user named Reg Guy who I want to allow the code promotion role. In the following PSSC file, note that Reg Guy is a member of the Reg Users group that I’m assigning this role to.
Now I can save and close the PSSC file because I’m done with it.
Next, I need to configure that CodePromo role I assigned to the Reg Users group in the PSSC. To do this, I need to make a CodePromo role capabilities file. All role configuration files need to go in a RoleCapabilities folder in the same directory as the PSSC.
Now it’s time for the thinking part. How am I going to restrict my remotely connecting users but at the same time, give them the permissions to promote code as previously described? The answer is brutally simple…
I know where the files are being copied to and from, and I don’t want users doing anything else. Instead of trying to do all kinds of weirdness with file system permissions and which cmdlets to restrict or open up, I’m simply going to write a script that promotes this code.
With that in place, I need to allow Reg Guy to run this script using the VisibleExternalCommands item (line 31 in the following image). I’m also going to give users a nice little function to run so they don’t need to remember where the script lives (line 43 in the following image).
When Reg Guy remotely connects (I’ve already given him those permissions) and runs Invoke-CodePromo, the code promotion script will be triggered. I simply have to apply this JEA configuration to an endpoint (safely ignoring warnings), test it, and turn it over to Reg Guy.
Now let’s see what it’s like to be Reg Guy…
Perfect! Reg Guy can connect to a remote session and run our code promotion script. He can’t do anything else though (note the errors are supposed to occur). It looks like my JEA-configured remote PowerShell endpoint is behaving exactly like I want it to.
Join me tomorrow when I tackle another example use case for JEA: enabling limited rights to interact with Active Directory.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy