From the course: PowerShell: Scripting for Advanced Automation

Concepts of JEA

From the course: PowerShell: Scripting for Advanced Automation

Start my 1-month free trial

Concepts of JEA

- [Instructor] The more you explore and use PowerShell, the more you realize that you may not need a GUI on your Windows servers anymore. When you factor in PowerShell remoting, it becomes clear that you won't be using your key to the server room very often either, but this convenience comes at a price. If you're not sure what that price is, have a talk with your security team. Performing administration with PowerShell requires you to connect with elevated privileges. This becomes especially challenging if your IT department has any depth to it. For example, a help desk operator will need to manage user accounts or restart the print service once in a while, maybe a couple of other tasks that require elevated privileges, but do you want someone in that position to have the ability to connect as admin with all of the access that that entails? Just Enough Administration or JEA is the tool that you can use to grant very specific administrative abilities to users or groups in PowerShell and what I mean by very specific is that you can whitelist the commandlets that a person can use when exercising their JEA rights. Not only that, you can narrow it down further. You can specify the parameters that they're allowed to use with those commandlets. And there's that word again, setting up JEA needs to be a reliable process, so item potency is once again the order of the day. Let's say that our help desk team spends their entire day fixing hardware issues, resetting passwords and restarting the spooler service to get printing working again. There are only so many PowerShell commandlets that they need to run on a server to accomplish those tasks. They can be granted permission to run the Set-AdAccountPassword commandlet as well as Get-Service and Restart-Service, but you may not want to grant them access to restart just any service so you can narrow it down and specify that for Restart-Service, their permissions are limited to Name Spooler. If they wanted to restart BITS, they would get a bunch of red text. If you're not aware, BITS, the Background Intelligent Transfer Service, is a service that you may never use. It's a good one to test your service management commandlets on because it's pretty safe. It's not likely that anyone's going to notice even if you mess it up, which is I think why it shows up in so many instructional demos and labs, but there is another risk in granting a user administrative access, even limited administrative access. It's hard to keep track of what access is granted to different users. It's often the case that once a user is given some admin privileges, they end up keeping them and that introduces two problems. The first is that job descriptions change and not all access is meant to be retained. The second is that there are different types of malware or malicious coworkers that find ways to exploit a user's permissions. If for example Cindy White, a member of our technical team, can restart passwords, a piece of malware that piggybacks on her administrative session can learn how to connect as Cindy and change passwords and gain unwanted access down the road. JEA addresses this through the use of virtual accounts. When a user with JEA rights connects to an endpoint to administer it, a virtual account is created and used to accomplish the task. Then, when the task is complete and the session is closed, the virtual account is removed. If the account used to reset passwords was compromised during use, that's not as big a deal because the account being used is not the user's actual account. It's the virtual account that will vanish along with any benefit the malware has designed to exploit.

Contents