I’ve got my head around JEA and the thinking behind constrained endpoints vs traditional RBAC, but one thing still confuses me slightly. JEA controls cmdlets on the endpoint on which you’re carrying out a task and the permissions required on that box to run them, but what happens when you run a cmdlet/script that can require permissions on other servers to complete. Lets take DFS for example, think of this scenario.
You have two new web servers that require a shared IIS config, you use a script to build those and configure IIS on them. Within that script is the DFS part that has a dependency on you having the correct AD permissions to be able to create the new DFS shares locally and publish that namespace to AD. How does this work with JEA?
I think I know how it’ll work, I’d need to create an endpoint constraint on the Domain Controller restricting the use of DFS commands to the user. But will I then need to change the script to cater for JEA in that I now need to connect directly to a DC and run those commands? Or does JEA handle that?
So, there are a couple of concepts you might be conflating, so let’s just be sure we’re on the same page.
There are actually two things in the world, JIT and JEA. “JIT” means “Just in Time,” and that’s the bit that basically “gives you the exact permissions you need, right then, and then takes them away when you’re done.” JIT is significantly more complex and involves more tooling that PowerShell alone.
JEA is “Just Enough Administration,” and that translates to, “only the exact commands you need.” At a basic stage, JEA requires that you already have sufficient permissions to do the job, and just exposes the needed commands. That alone doesn’t really lend much to security, though, so part of a constrained endpoint is the ability to run the endpoint using a “RunAs” account. The theory is that YOU have ZERO permissions, but the RunAs account has JUST the needed permissions. Normally, you create the RunAs account in advance, and permission it in advance. So long as the RunAs account has all the needed permissions, you’re good to go.
The JIT piece - again, requiring tooling aside from just PowerShell - is what creates that RunAs account dynamically, if I can just grossly oversimplify what happens ;).