How To Setup PowerShell’s Just Enough Administration (JEA)
Think you can do better? Show us!
Do you allow users on your domain controller? If so, you’re a braver man than I but did you know some people like Matt, actually do? Crazy, right? Not really. Using PowerShell JEA, you’re able to lock down PowerShell commands only to certain commands and apply all kinds of restrictions. In this video, Matt walks us through how to get it done.
In this video I'm going to show you how to set up Powershell's just enough administration or JEA for short before we get started. I just wanted to mention that for this exercise, you will need to be running at least PowerShell 5.1 in order to get the full functionality of JEA. I've also provided a link to a JEA overview page. This page contains a lot more information on JEA as well as a link which lays out the prerequisites. Now let's get started to configure JEA. We're going to need to set up a few things first. We need to create a module folder, which will contain a file that will tell powershell what the user connecting to the JEA endpoint has access to run so let's create the folder. I'm going to call it helpdesk because I want to create a JEA endpoint that help desk employees can use since this is a module and it will be deployed to the server where our JEA endpoint will be running. You could also create a PSM one file which contains any functions that you would like. Users of this endpoint have access to for simplicity. I'm going to just leave this file blank and give access to built in commandlets later. Next I'm going to create a new module manifest called help desk dot PSD one. Now that the module is set up we need to create a folder in the module called role capabilities in this folder. We're going to create a new PS role capability file and I'm going to call it helpdesk. JEA roll dot PSRC. Let's open the new PS role capability file. This file is what is going to tell the JEA endpoint? What the user logging in has access to do in this file you can specify things like modules to import visible aliases. Visible commandlets and functions. You can also specify visible. External commands like ping or IP config for example, but for this demo. I'm only going to use the visible commandlets. I like to keep the example. That is provided commented out for reference. And just start. New line for visible commandlets. I'm going to specify the get service commandlet this will give users access to use get service, but no other commandlets. You can also use wildcards here if you want as well. Let's save that file and go back to our setup script our next step is to create a PS session configuration file when we go to create our new GM point. This file is going to tell powershell how that end point should be configured so let's create that new file with a session type of restricted remote server. And let's take a look at that file in this file. We're going to concentrate on the last section role definitions. I'm going to copy the example to a new line to make my edits role definitions as a hash table, which you can use to specify who has access to this end point and what role capabilities. They will have I'm going to edit this value to give the user Matt? Which is myself access to this end point. And I'm going to tell it to give me the helpdesk. JEA roll role capability, it will find this in the module that we're going to deploy to the remote server later. Let's save that file and go back to our setup. I'm going to run test PS session configuration file to make sure that my file looks good, I get a value of true which means the test passed. If I go to my helpdesk folder you can see our module files as well as our role capabilities file at the root level of my JEA folder you can also see my helpdesk endpoint. PS session configuration file now that we have our files that we need created and configured. Let's go on to the end point set up first. I'm going to open up a new session to my remote server in order to copy the necessary files and configure the JEA endpoint. Then I'm going to copy my helpdesk module, which contains my role capabilities file to the modules folder on the remote server. Now I'm going to copy the PS session configuration file to the C drive on the remote server. Once all the files are in place. I'm going to use invoke command to register. The new end point using the session configuration file and I'm going to call that endpoint helpdesk, sometimes, this will throw me an error because win RM needs to restart. In this case, it did throw an error but I should be all set to move forward. Before I connect to the new end point I'm going to switch to the powershell console and enter a new session to the default endpoint on server one if I run get PS session configuration. This will list the available endpoints on that server. As you can see we have a helpdesk endpoint and under permission. We see the account that we gave access to during the setup. In just to demonstrate that I have all command. That's available to me. I'm going to run get command. Now let's switch back to the ISE and enter a PS session to server one. But this time, we're going to specify the configuration name's help desk. If I run get command here, you can see that I only have a handful of commands available to me some get included by default. But you can see that we have get service at the bottom of the list, which I specified in the role capabilities file. I can now run get service to see the list of services on this server. I can also use the name parameter to specify the name of the particular service. But what happens when I try to run stop service that command that is not available to me on this end point. The same is true if I try to run another command, let like get process and that is how to set up Powershell's just enough administration.